MCP: Transport, Gateway, Registry
This is the reference design for MCP as transport. Principles live in G.A.I.N MCP. The tool contract (what the LLM may propose) lives in the Agents Blueprint under Manifests. Playbooks: MCP (transport) · Agents: Manifests. Policy verdicts stay in Governance Runtime.
THE CLAIM
MCP is a governed capability surface, not the tool allowlist. The pinned manifest is the contract. MCP, OpenAPI, and domain APIs are adapters. The client plans; the gateway permits; the server executes.
What you are building
An MCP path that does not become the catalog:
- Server registry: which MCP servers exist, who owns them, which environments may call them
- Gateway: one choke point; clients do not dial arbitrary servers
- Scoped exposure:
list_toolsreturns only what the pinned manifest already allows - Invoke:
call_toolstill hits the agentic app check, then PEP, then the server - Observe: results return to the app, not raw to the LLM without validation
Owns / does not own
| Owns | Does not own |
|---|---|
| MCP gateway, server registry, transport auth | Tool schema, pdp_action, unknown-tool reject (Agents: Manifests) |
How list_tools / call_tool are wired | PEP verdicts (Governance Runtime) |
| Federation of domain MCP servers | Route pin of tool_manifest (Agents Plane ①) |
Do not collapse
| Anti-pattern | Fix |
|---|---|
| Manifest lives only inside MCP | Manifest is transport-agnostic; MCP is one adapter |
| Client connects to any server | Gateway + server registry |
list_tools dumps the whole server | Scope to the pinned manifest |
call_tool skips PEP | Same hop as any other tool: app validate, then PEP |
Playbooks
- MCP overview for transport
- Manifest registry · Manifest lifecycle
- Runtime for PEP/PDP