MCP Servers

6 min read·Updated 30 Jul 2026

The Model Context Protocol gives any compatible tool a standard way to offer capabilities to an agent. Arble speaks it natively, so a server you install becomes a set of typed tools sitting alongside the built-in ones — same registry, same permission gate, same audit log.

How Arble uses MCP

Most clients treat MCP as the way they get tools. Arble treats it as one of three sources, all of which land in the same registry and are chosen between by the same agent.

Because they share a registry, the agent does not need to know which source a tool came from. A skill can read a file with a built-in tool, open a pull request through an MCP server, and take a screenshot on a paired desktop, in one run.

Built-in vs MCP

The split is roughly: things tied to your device are built in, and things tied to an external account arrive through a server.

Why not a plain client

MCP is a protocol for exposing tools. It says nothing about memory, device access or how approval works — those are the client's job, and most clients leave them out.

Featured servers

A handful worth starting with. The full list is below.

Directory

Every server Arble is known to work with. Each installs separately and can be revoked on its own.

Installing a server

Five steps, the same for every server.

1. 1InstallAdd the server from the directory, or point Arble at an endpoint.
2. 2AuthenticateSign in to the underlying service. Tokens go to the device keystore.
3. 3Review permissionsSee every tool the server exposes and decide which run without asking.
4. 4ReadyThe server's tools appear in the registry next to the built-in ones.
5. 5Use in agentAsk for the work. The agent picks the tool.

Setup by client

Every client below connects to the same server. Pick the one you use.

General. Any MCP-capable client needs a command, its arguments, and an optional environment:

Command:      npx
Arguments:    -y mcp-remote https://mcp.example.com/mcp
Environment:  none

Claude, Cursor, Windsurf. Add from settings, or paste into the config file:

{
  "mcpServers": {
    "arble": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.example.com/mcp"]
    }
  }
}

Claude Code. Register once, then run /mcp in a session to authenticate.

claude mcp add --transport http arble https://mcp.example.com/mcp

Codex. The IDE extension and the CLI share one configuration.

codex mcp add arble --url https://mcp.example.com/mcp

Visual Studio Code. Command palette → MCP: Add Server → Command (stdio), then:

npx -y mcp-remote https://mcp.example.com/mcp

Zed. Add a context server in settings:

{
  "context_servers": {
    "arble": {
      "source": "custom",
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.example.com/mcp"],
      "env": {}
    }
  }
}

Remote vs local

Most servers can run either way. The choice is about privacy and availability, not capability.

Choose remote when the service is a cloud product anyway and you want it on every device. Choose local when the data should not leave the machine, or when you need it to work with no connection.

Permission flow

An MCP tool is not privileged. It takes exactly the same path as a built-in one.

1. 1RequestThe model proposes a call with arguments.
2. 2Permission checkRules and mode decide: auto, ask, or deny.
3. 3SandboxThe server runs in its own process, scoped to what it was granted.
4. 4ExecuteThe call runs and returns a typed result.
5. 5Audit logWhat ran, with what, and what came back is recorded.

Security

Server health

Connected servers, what they cost you in latency, and what they are allowed to do.

Example values. Wire this table to live server state before publishing.

Example workflows

Servers compose. One instruction can cross as many as the task needs.

Write your own

If the tool you need has no server, write one. The protocol is open and the SDK ships for Python, TypeScript, Go and Rust.

1. 1Create
2. 2Register tools
3. 3Run
4. 4Publish
5. 5Share

Common use cases

FAQ