openclaw - 💡(How to fix) Fix MCP tools bypass per-agent tools.allow / tools.deny filter [1 participants]

Bug: MCP tools bypass per-agent tools.allow / tools.deny filter

Summary

OpenClaw 2026.4.5 makes all globally configured MCP tools available to ALL agents, regardless of the agent's tools.allow, tools.alsoAllow, tools.deny, or tools.profile configuration. The per-agent tool restriction system applies to built-in tools (read, edit, write, exec, web_search, sessions_spawn, etc.) but NOT to MCP tools, which are auto-injected from mcp.servers globally.

This makes per-agent MCP scoping impossible via config alone — there's no way to say "the router agent can only call sessions_spawn, but the pleres agent can call ms365__* tools". Either all agents get access to all MCP tools, or none do.

Environment

• OpenClaw 2026.4.5 (3e72c03)
• Ubuntu 24.04.4 LTS, Node v24.14.1 via nvm
• MCP server: @softeria/ms-365-mcp-server (110+ tools), but the issue is general — happens with any MCP server

Steps to reproduce

1. Configure an MCP server in mcp.servers:

   {
     "mcp": {
       "servers": {
         "ms365": {
           "command": "npx",
           "args": ["-y", "@softeria/ms-365-mcp-server", "--org-mode"]
         }
       }
     }
   }

2. Configure a "router" agent with the strictest possible tool restriction — explicit allow of only sessions_spawn, plus an explicit deny list, plus profile=minimal:

   {
     "agents": {
       "list": [
         {
           "id": "router",
           "model": "litellm/claude-haiku-4-5",
           "tools": {
             "profile": "minimal",
             "allow": ["sessions_spawn"],
             "deny": ["read", "edit", "write", "exec", "process",
                      "canvas", "nodes", "cron", "message", "tts", "gateway",
                      "agents_list", "sessions_list", "sessions_history",
                      "sessions_send", "sessions_yield", "subagents", "session_status",
                      "web_search", "web_fetch", "image", "pdf", "browser"]
           },
           "skills": []
         }
       ]
     }
   }

3. Send a message to the router agent that would naturally invoke an MS365 tool (e.g., "list my recent calendar events").

4. Observed: the router agent calls ms365__list-calendar-events directly. The lane in the gateway logs is agent:router:msteams:default:direct:..., confirming this is the router itself, NOT a spawned subagent. Despite tools.allow=["sessions_spawn"] being explicit, the MS365 tools are present in the router's tool list.

5. Confirm via tcpdump on the LiteLLM port (or by capturing the LLM request body via a wrapper script): the structured tools array sent to the model includes all 110+ MS365 tool definitions, alongside sessions_spawn.

Expected behavior

tools.allow should be the COMPLETE allowlist for an agent's tool surface. If tools.allow=["sessions_spawn"], then ONLY sessions_spawn should appear in the agent's tool list — no built-ins, no MCP tools, no skills. The current behavior is closer to "alsoAllow" semantics: tools.allow adds to whatever was going to be allowed anyway.

Either:

• tools.allow is treated as an explicit allowlist (most correct), OR
• A new tools.mcp field exists for per-agent MCP server scoping:

  "tools": {
    "mcp": {
      "allow": ["ms365"],   // server names, not tool names
      "deny": []
    }
  }

Actual behavior

tools.allow only filters built-in tools. MCP tools and skill tools are auto-injected separately and bypass the filter.

Severity

High for any deployment with both:

• A multi-agent architecture (router + specialists)
• Globally configured MCP servers

In our deployment, the router agent is supposed to be a fast triage layer that ONLY classifies and delegates via sessions_spawn. But because MS365 tools leak into its tool list, the router is encouraged by the LLM (Haiku in our case) to call MS365 tools directly when the user asks for calendar/email — completely bypassing the specialist agents that should own that capability.

This also has security implications: an MCP server scoped to one tenant's credentials should not be reachable from agents that have access to a different tenant's data.

Workaround

None reliable. Things we tried that didn't work:

• tools.profile=minimal + tools.alsoAllow=["sessions_spawn"] + 23-name explicit deny — MCP tools still present
• tools.allow=["sessions_spawn"] (replacing alsoAllow with explicit allow) — MCP tools still present
• tools.deny listing every MCP tool name — would work but brittle (need to update for every package update of every MCP server)

The only effective workarounds are:

• Only configure MCP servers globally if EVERY agent needs access to those tools, OR
• Restructure to launch a separate gateway instance per "scope" (massive infrastructure cost)

Suggested fix paths

1. Make tools.allow an explicit allowlist that filters ALL tool sources (built-in, MCP, skills). Backward incompatibility risk: existing configs that use tools.allow to add to defaults would break. Mitigate via a config schema version bump or a deprecation period with both behaviors supported.

2. Add tools.mcp for per-agent MCP server scoping:

   tools?: {
     // existing fields...
     mcp?: {
       allow?: string[];   // mcp.servers names whose tools are visible to this agent
       deny?: string[];
       allowTools?: string[];  // optional: per-tool-name granularity
       denyTools?: string[];
     }
   }

   This is additive (no backward incompat) and gives operators clean control.

3. At minimum, document the current behavior in the OpenClaw docs page for tools config so operators know that allow/deny doesn't gate MCP tools, and the only way to scope MCP tools currently is to launch separate gateway instances.

Where this bit us

Synap deployment, 2026-04-08. Wiring @softeria/ms-365-mcp-server for pleres + family agents. The router was supposed to triage and sessions_spawn to pleres for M365 questions; pleres would then own the MS365 tool calls. Instead, MS365 tools leaked into the router's tool list, so the router called them directly using its Haiku model. Combined with the Vertex thought_signature bug (#34-to-file) and the OpenAI schema validation bug (#35-to-file), every direct call from the router failed in a different way.

Related upstream issues

• #62763, #62764, #62765, #62766, #63357, #63394 (other OpenClaw issues from the same Synap deployment)
• The to-be-filed Vertex thought_signature bug
• The to-be-filed OpenAI MS365 tool schema validation bug