Problem

The generic MCP bridge exposes mcp_list_servers, mcp_list_tools, and mcp_call_tool. That is useful, but too broad for locked-down profile/runtime deployments because a model can potentially call any tool exposed by a configured server.

Generic use case

Profiles and managed deployments can expose a remote MCP server while allowing only specific tools, argument shapes, or risk classes. This supports safer MCP adoption without requiring one bespoke Rust wrapper per MCP tool.

Managed-runtime use case

A compiled runtime contract can declare exactly which MCP server/tool pairs are allowed. The runtime rejects undeclared MCP calls before network dispatch and can prove no raw write-capable MCP surface is visible.

Proposed shape

• Extend MCP server config with include/exclude lists or a policy callback.
• Enforce allowlists in mcp_list_tools and mcp_call_tool.
• Add denial messages that tell the model which server/tool pair was blocked.
• Include allowlist state in diagnostics.

Acceptance criteria

• Tests show hidden MCP tools are not listed.
• Tests show blocked MCP calls do not reach the remote client.
• Existing configs behave the same by default.
• Related to Feature Request : Global MCP tool registry - centralised discovery, versioning, and routing for all MCP tools across the swarm #1848 and Feature Request : Native context-mode MCP integration - context window protection, session continuity, and sandbox execution for all OpenHuman agents #1857, but scoped to enforcement/allowlisting for the current bridge.

Alignment

This helps OpenHuman MCP generally. It also keeps Composio and MCP complementary: Composio handles managed OAuth/provider breadth; MCP allowlists handle precise external tool exposure.