Connect OpenClaw to an MCP server

Start with the service you want to use

An MCP server is the program that supplies tools, not necessarily another computer you need to rent. Some services publish a remote endpoint. Others distribute a program that runs alongside your agent. Use the service’s own connection instructions to establish which one you have and what account access it asks for.

Prefer a connection that can do the job with limited access. Searching a knowledge base does not call for permission to delete it. A third-party server that asks for a service token may gain the token’s full reach, even if you only intend to use one of its tools. The server’s publisher and the account permissions matter as much as the tool names.

Add the server to OpenClaw

The current OpenClaw connection guide documents this path:

1. Open Settings → MCP in the Control UI.
2. Under Configured servers, choose Add server and give it a unique name.
3. Select the transport the server supports. A remote server usually supplies a Streamable HTTP URL; a local program uses Stdio. Use SSE only when the server’s instructions specify it.
4. Enter the endpoint URL, or the local command and arguments, then save.

Advanced settings, including authentication and tool filters, live in the scoped configuration editor on that page. Use the supported secret fields or secret references for credentials, not a token pasted into a conversation.

For a local server, “local” means the machine running OpenClaw, not the laptop where you opened its dashboard. The program, its dependencies and its working directory must exist there. An installation that works in your own terminal does not establish that the Gateway process can launch it.

Complete the right kind of sign-in

Some HTTP servers use OAuth: you sign in through the provider and approve the requested access. Others require a token in a documented header. Follow the server’s supported method rather than adding both. OpenClaw’s transport and authentication reference describes the difference; with OAuth enabled, a static Authorization header is not the credential path.

For an OAuth server, the CLI sign-in command is:

openclaw mcp login <name>

Replace <name> with the name you saved. Check which account you authorize and which resources that account can reach. Successful sign-in establishes an identity; the next step establishes whether it can do the work.

Verify the connection, then the agent’s access

Run this on the OpenClaw host:

openclaw mcp doctor <name> --probe

The MCP registry CLI reference distinguishes this live check from openclaw mcp status --verbose, which reports configuration. Doctor checks the definition and attempts to reach the server. A successful probe should report the capabilities the server advertises.

Next, ask the agent to retrieve one known, non-sensitive item through that server. Check the returned content, not merely its promise to look. Tool discovery, authorization and a successful tool call are separate boundaries: a server can list its tools before a particular operation discovers that the account lacks access.

In a September 20, 2026 test, a small MCP client could call an external service, while OpenClaw’s registered-tool path still returned an authentication error. That result did not establish that the native connection worked. If another client succeeds, compare the endpoint and authentication route; do not treat its success as a substitute for a call from the agent you will actually use.

When the server is connected but the tools are missing

Check the server’s tool filters and the agent’s tool policy. OpenClaw applies those controls to MCP tools too; connecting a server does not override a restriction. The runtime handling the conversation also matters, so inspect the tool access for the affected session rather than relying on a different agent’s successful run.

If the probe cannot start a local program, check its command and working directory in the Gateway’s environment. If an HTTP server returns an authentication error, revisit sign-in, token scope and endpoint before changing unrelated model settings. These are connection failures, not evidence that a more capable model is needed.

Do not confuse connecting a server with becoming one

openclaw mcp serve is the reverse direction: it exposes OpenClaw to another MCP client. It is not the command for adding your service’s tools. Saved native connections live under mcp.servers; an older workflow using a separate mcporter registry is another client configuration, not automatically the same connection.

Once the read-only task works, grant any additional write capability deliberately and try it on a disposable item first. Keep the service’s account permissions narrow enough that a misunderstood instruction cannot reach unrelated work.