MCP on AGTP: Adding the Layer MCP Was Missing

MCP got something important right. It defined a shared protocol for tools, resources, and prompts that an AI client can speak to any compliant server, without bilateral integration. Claude Desktop, Cline, and a growing set of clients all converged on a single JSON-RPC vocabulary. Hundreds of MCP servers exist now. The format is stable. The community is active. The protocol is doing what protocols are supposed to do.

What MCP deliberately punted on is everything underneath the tool call.

This is a strength, by design. MCP is a tool-call protocol. Its scope is the shape of the message between a client and a tool server, expressed cleanly in JSON-RPC. It leaves identity, transport security, audit, scope enforcement, budget enforcement, and cross-agent attribution to the surrounding infrastructure. The team behind MCP made a sound architectural call: define one thing well, let other layers handle the rest.

The problem is that almost no one is handling the rest.

Most MCP deployments today run over stdio or HTTP, with whatever identity model the host application happens to use, whatever logging the framework happens to do, and whatever authorization scheme the operator happens to wire up. When an MCP server is local and runs as a subprocess, this is fine. When the same MCP server is exposed across organizations, called by agents acting on behalf of users, and asked to handle high-stakes operations, the underneath-the-tool-call surface starts to matter quite a lot.

The Agent Transfer Protocol is what that surface looks like when someone designs it on purpose. And the way AGTP composes with MCP turns out to be the cleanest demonstration of what AGTP is for.

What the bridge actually does

The agtp-mcp gateway is a translation layer. AGTP traffic comes in on TLS. The gateway parses the AGTP request, verifies the agent's identity against the AGTP registry, enforces Authority-Scope and Budget-Limit, then translates the request into JSON-RPC and sends it to the backing MCP server over stdio. The MCP server runs unmodified. The MCP server is the official @modelcontextprotocol/server-filesystem, or @modelcontextprotocol/server-brave-search, or whatever your own implementation happens to be.

The verb mapping is small and intentional:

AGTP verb + path        MCP JSON-RPC
DESCRIBE + tools        tools/list
EXECUTE  + tools        tools/call
DISCOVER + resources    resources/list
QUERY    + resources    resources/read
DISCOVER + prompts      prompts/list
QUERY    + prompts      prompts/get

The architecture is one Python process:

AGTP client ──TLS──▶  agtp-mcp gateway  ──stdio──▶  MCP server
                          │                         (unmodified)
                          ▼
                      registry.agtp.io
                      (agent identity)

This is small on purpose. The gateway does four things: terminate TLS, verify identity, enforce policy, translate verbs. Everything else is delegated. AGTP keeps doing what AGTP is for, MCP keeps doing what MCP is for, and the gateway is the seam.

What MCP gains, with zero MCP changes

Run the gateway in front of an existing MCP server, and the MCP server inherits properties it never had before.

Cryptographic agent identity. Every request to the gateway carries an Agent-ID. The gateway looks the agent up in the AGTP registry, verifies the signed Agent Identity Document, and confirms the request is coming from the agent it claims to be from. The MCP server above the gateway sees only the JSON-RPC call. The gateway has already answered the question of who is calling.

Authority-Scope enforcement. The AGTP request declares what the agent is authorized to do. The gateway parses Authority-Scope and refuses any request whose scope exceeds the agent's declaration. A tools/call to a sensitive tool can be gated by whether the calling agent has the right scope token, enforced before the MCP server ever sees the request.

Budget-Limit enforcement. Long-running or expensive MCP operations can be bounded. The agent declares a budget in the AGTP request, the gateway tracks consumption, and the gateway refuses requests that would exceed the limit. This closes a real failure mode in production MCP deployments where an agent loop calls an expensive tool more often than anyone intended.

Signed Attribution-Records. Every consequential interaction produces a signed envelope binding the agent's identity, the request hash, and the response status into a single artifact. The records are signed with the gateway's Ed25519 key and written to an append-only attribution log. The MCP server never produced these records. The gateway produced them, on the MCP server's behalf, from the AGTP traffic.

TLS by default. Mutual TLS for client-to-gateway. The backing MCP server still speaks stdio to its child process. Transport security is handled at the AGTP layer.

The MCP server's source code is untouched. The MCP server's specification is untouched. The MCP community can keep evolving MCP without coordinating with AGTP, and the AGTP community can keep evolving AGTP without coordinating with MCP. Both ecosystems benefit.

A canonical name for every MCP

There is a small detail in the addressing model worth dwelling on, because it changes how MCP servers think about themselves.

When an MCP server runs behind the AGTP gateway, it acquires an agtp:// URI. The MCP server living at mcp.example.tld is reachable at:

agtp://mcp.example.tld

Agents hosted by that MCP server get their own canonical addresses. An agent named lauren at that server is addressable as:

agtp://mcp.example.tld/lauren

This sounds like a syntactic detail. It is more than that.

Under HTTP, an MCP server is a URL to a JSON-RPC endpoint. The server has no identity of its own. The agents it hosts have no identities of their own. Whatever the client sees is whatever the framework happened to expose. Discovery is bilateral, ad-hoc, and per-vendor.

Under AGTP, the MCP server is an addressable entity in a registry. The agents it hosts are addressable entities in a registry. ANS, the Agent Name Service, can return agtp://mcp.example.tld/lauren as a result for a capability query. Trust tiers, behavioral trust scores, and signed manifest documents apply at the agent level. The MCP server's host domain becomes a namespace, the way gmail.com is a namespace for email addresses.

This is the move that turns MCP servers from endpoints into citizens of an agent economy. Lauren the agent has an identity. Lauren the agent can be discovered by other agents that need her capabilities. Lauren the agent can be delegated to, audited, and held accountable. Lauren the agent stays Lauren even if her MCP server moves to a different host, because her canonical Agent-ID is a hash of her Genesis rather than a label on her hostname.

The MCP server still implements tools/call. AGTP makes the server, and every agent it hosts, findable, identifiable, and accountable.

The bridge as proof of the substrate thesis

Step back and look at what this composition demonstrates.

AGTP has argued, since the beginning, that it is a substrate rather than a competitor. The argument is intellectually clean: MCP, A2A, and ACP are application protocols that need transport. AGTP is the transport. The substrate carries identity, scope, audit, and discovery; the application protocol carries the tool calls or the agent messages or whatever the domain requires.

The MCP-on-AGTP gateway is the existence proof. An unmodified MCP server, running official upstream code, gains every governance property the AGTP layer provides, with zero changes to the MCP layer. The composition works. The boundary is clean. Both ecosystems retain their own evolution paths.

This is the property the agent economy has been needing. MCP is one of several application protocols in the agent space. A2A is rising. ACP exists. New protocols will emerge. Every one of them needs identity, scope, audit, and discovery, and every one of them is currently solving those problems differently or skipping them. A shared substrate that any of them can ride on solves the problem once for all of them.

AGTP is the substrate. The MCP bridge is the demonstration that the substrate composes the way the design promised.

What this means for MCP server operators

If you operate an MCP server today, the practical implications are small and welcome.

You install the gateway. You point it at your existing MCP server. You configure TLS certificates, the AGTP registry URL, the path to a gateway signing key, and a path to your attribution log. You set the AGTP_MCP_BACKEND environment variable to the command that launches your MCP server. You start the service.

export AGTP_MCP_BACKEND="npx -y @modelcontextprotocol/server-filesystem /var/lib/agtp/mcp-sandbox"
export AGTP_MCP_CERT=/etc/letsencrypt/live/mcp.example.com/fullchain.pem
export AGTP_MCP_KEY=/etc/letsencrypt/live/mcp.example.com/privkey.pem
python gateway.py

Your MCP server now has cryptographic identity. Your MCP server now enforces scopes and budgets at the wire. Your MCP server now writes signed attribution records. Your MCP server now has a canonical AGTP URI and is discoverable through ANS.

Existing MCP clients that speak only the legacy protocol can still reach your server through whatever bridge or shim you have in place. New AGTP-aware clients can reach the same server and get the full governance surface. The path forward is incremental: ship the gateway, register the server in AGTP, let the AGTP-aware clients adopt as they appear.

Where this goes

The bridge is a beginning. As the AGTP ecosystem matures, MCP servers exposed through AGTP gateways will start to compose with the rest of the AGTP stack: ANS discovery, federated registries, transparency logs, cross-organization delegation, marketplace primitives.

The MCP server stays an MCP server. The AGTP layer keeps doing its job. The two ecosystems evolve independently, composed cleanly at the gateway.

This is what protocol design looks like when the layers are honest about what they are for. MCP is a tool-call protocol. AGTP is a transport substrate. The bridge is the place where the two layers meet, and both stay true to their respective scopes. Nobody had to give anything up. Both got stronger.

The gateway is open source. The protocol is open standard. The MCP servers are unmodified. The community in front of either protocol can adopt without coordinating with the other. That is the architecture working the way it was supposed to.