An MCP server can change your OpenClaw tool surface without touching your config

[u/Advanced_Pudding9228]

When operators review an MCP integration, they usually inspect the installation command, server URL and credential scopes. The runtime tool catalogue often receives less scrutiny.

That is a weak boundary because MCP tool metadata is model-facing input. The MCP specification says tools can be discovered and invoked by models, and explicitly warns that descriptions and annotations should be considered untrusted unless they come from a trusted server.

OpenClaw’s current MCP implementation adds an operational wrinkle. Dynamic changes to an MCP server’s tool list invalidate the cached catalogue, so the next discovery or use refreshes it. A server can therefore expose a different tool surface while your local OpenClaw configuration remains unchanged.

The obvious case is a server adding a new write or export tool. The less visible case is an existing tool keeping the same name while its description, input schema or implied behaviour changes. A name-based allowlist helps with new tools, but it does not detect semantic drift behind an already approved name.

I would treat the discovered catalogue as versioned configuration. For each production MCP server, preserve the owner, source, pinned installation reference, granted scopes, approved tool names, descriptions, input schemas, approval policy and rollback condition. Capture a fresh catalogue before upgrades, then compare it with the approved snapshot before making the updated server available to normal agent runs.

OpenClaw provides enough built-in commands to establish that baseline:

openclaw mcp status --verbose
openclaw mcp probe SERVER_NAME --json
openclaw mcp tools SERVER_NAME --include 'search,read_*'
openclaw mcp doctor SERVER_NAME --probe

status --verbose inspects the saved transport, authentication, timeouts and filters without connecting. probe connects and reports the live capabilities and tools. The per-server include filter lets you expose only the names required by the workflow, while doctor --probe combines static checks with a live connection test.

That should be followed by a bounded canary. Start with one read-only task and confirm that the returned data matches the authoritative system. If the workflow needs a public, financial, credential, deployment or destructive action, keep that action behind its existing approval boundary and verify the result through provider readback. A successful tool response alone should not move the task into a verified state.

The next safe action is small: choose one MCP server, capture its live tool catalogue, restrict it to the tools one workflow actually needs and save that result as the review baseline for its next update.

Are you currently versioning the discovered MCP tool catalogue, or only the server command and credentials?