OpenClaw and MCP servers

MCP is how an OpenClaw agent borrows tools from another program. A server exposes tools, resources and prompts; OpenClaw connects to it, discovers the tools, and puts them behind the same tool-profile and tool-policy controls as its own. That last part is the point people miss: connecting a server does not bypass the policy. Here is how a server gets added, why saving it proves nothing until the probe runs, how approvals work, and the failures the docs list.

The Model Context Protocol (MCP) is how an agent borrows tools from another program: an MCP server exposes tools, resources, and prompts, and OpenClaw connects to it and makes those tools available to your agents.

Four ways to add one

• Settings, MCP, Add server in the Control UI: a unique name, a transport, Streamable HTTP, SSE or stdio, then a URL or a command with its arguments; headers, environment values, OAuth metadata, TLS, timeouts and tool filters live in the scoped config editor below.
• The composer’s connectors menu, with a choice between this session only and everywhere; either way the definition is global and the session scope is a policy layer.
• The CLI, with an add command that takes a command or a URL and an include filter, or the config file directly under the servers key; an enabled server needs a command or a URL, and credentials stay out of config literals.

Saving is not connecting

The docs are blunt: a saved definition proves nothing about reachability, and the doctor command with a probe flag is what does. It validates the saved definition, opens a live connection and reports the tools and capabilities the server advertises. With hot reload on, changed or removed servers retire immediately and the next turn discovers the new definition, while unchanged servers keep their connections and cached tools.

Approvals

Tool approvals follow the session’s permission posture: the default full-permission posture does not prompt, stricter modes check tools without safety annotations, and a workspace posture can review automatically while guarded and read-only can prompt the operator. Allow Always saves a per-agent grant for that exact server and tool that survives restarts; an explicit prompt mode on a server keeps asking regardless. OpenClaw sandboxing explained explains where a sandbox sits relative to tool policy.

The failures the docs list

• The server appears in Settings but exposes no tools: run the doctor probe, then check the include and exclude filters.
• A stdio server does not start: the command has to resolve in the Gateway’s process environment, the working directory has to exist, and arguments belong in their own field.
• An HTTP server needs authorization: set the auth mode to OAuth with its metadata and run the login command; the loopback redirect is captured automatically, with a code fallback when the browser cannot reach it.
• Changes do not reach an active agent: the reload command refreshes runtimes owned by the current CLI process, and a Gateway running elsewhere needs its own reload or restart.

MCP servers, OpenClaw skills explained and OpenClaw plugins are three different ways of extending the agent, and the docs keep them apart: a plugin is code loaded into OpenClaw, a skill is instructions, an MCP server is a separate program the agent calls.

On Diali

On Diali you add MCP servers to an assistant from the dashboard, with the same rule that the tools land behind the assistant’s policy, and the server runs on your side or a host you trust, never inside the instance. Hosted OpenClaw on Diali is the assistant and Security on Diali describes the boundary.

• Four ways in; one probe to prove any of them.
• Tools from a server obey the same policy as built-in tools.
• Keep the credentials in the secret mechanisms, not the config literal.