MCP Tool Governance: who can call which tool, in one permission plane
Aggregate external MCP servers behind one gateway /mcp endpoint — per-key-group tool allow/deny and label filters, with calls / violations / sessions fully audited.
What the community actually complains about
Once an agent framework is wired to a pile of MCP servers, permissions spiral: there is no unified control over who can call which tool, and no audit trail when something goes wrong. Configuring each agent separately scatters credentials and drifts policies.
"How do I restrict Claude Code to just these MCP tools" is a recurring question for platform teams.
How GateLLM does it
GateLLM ships a built-in MCP proxy: multiple external MCP tool servers (streamable HTTP / SSE) are aggregated behind one /mcp endpoint, with endpoint, auth header (forwarded verbatim), labels, priority, and lazy loading configured once. Key groups govern tools with allow/deny lists (deny wins) and label filters — the same ACL plane that governs models.
When the tool list grows long, context budgets trim it and built-in BM25 retrieval locates the relevant tools. MCP tool calls, access-rule violations, and session setup all land in the audit log.
MCP server credentials never reach the agent: tool access is granted and revoked with the gateway key group.
5 levers that actually land
- Server aggregation: streamable HTTP / SSE MCP servers behind one /mcp endpoint
- Lazy loading: tools discovered on first use, cutting startup cost and attack surface
- Tool-level ACL: per-key-group allow/deny, deny overrides allow, label filters in bulk
- Context budget + BM25: long tool lists trimmed to budget, relevant tools located by search
- Full audit: tool calls / access violations / session setup logged and exportable