A Manifest Is Not an Identity

Where A2A describes an agent, the Model Context Protocol describes a server.

A service exposing tools, resources, and prompts to a model. Its registry catalogs those servers. Reading it against the same five criteria is worthwhile precisely because it exposes a category boundary the field routinely crosses: the habit of treating a server-and-tool manifest as if it were an agent-identity record. It is not, it was never designed to be, and the confusion is the field’s, not the protocol’s.

What MCP Actually Ships

Begin with what is shipped, because MCP’s maturity is real and worth stating plainly. The official MCP Registry reached v1.7 in 2026 across more than thirty releases, community-owned and backed by a working group with contributors across the ecosystem, with a published server.json specification and a REST API that entered a stability freeze to let integrators build against it.[1][3] Publishing is namespace-verified: a publisher authenticates through GitHub OAuth or OIDC, or proves domain ownership through a DNS or HTTP challenge, and the registry enforces namespace ownership before a record is accepted.[1] This is a well-governed, genuinely useful piece of infrastructure. Any reading that treats it as immature is wrong on the record.

Now the structure. A server.json describes a server: its reverse-DNS name, description, repository reference, and a packages array specifying how to obtain and run it — npm, PyPI, OCI, NuGet — with transport type and required environment variables.[1] The registry that indexes these is, in its own words, a metaregistry: it hosts metadata about servers, pointing to the package registries where the actual code lives, and deliberately does not host the binaries themselves.[3] The unit of description is a server and the tools it exposes. The discovery question it answers is “what tool-providing servers exist, and how do I install and connect to them.” The field survey characterizes MCP the same way — a centralized publish-and-discover metaregistry, distinct in kind from the agent-descriptor formats it sits beside.[2]

The Category Boundary

That is real Discoverability and real Action surface — for tools. And here is the category boundary, stated precisely. An agent-identity record answers “who is this autonomous actor, what is it authorized to do, and can I revoke that.” A server manifest answers “what does this endpoint offer, and how do I run it.” These are different questions about different entities. A server is a capability provider; an agent is an actor that may invoke it. The error is not that the field compares MCP alongside A2A and AgentFacts. The survey does, this arc does, and there is good reason to — they occupy the same layer of the stack. The error is conflation: reading MCP’s server manifest as though it were a record of agent identity and authority, and then scoring it as one. That quietly recategorizes MCP from what it is — a catalog of tool-providing servers — into what it is not. The recategorization is not MCP’s claim. The protocol’s own materials are clear that it describes servers. So this arc scores MCP on the scope it actually claims. Its ratings below describe how well a server catalog serves an enterprise that needs agent-level assurance — not a failure to be something it never set out to be.

This matters for the enterprise because the two entities carry different assurance obligations. The server-tool relationship is where MCP’s real security surface lives, and it is a surface enterprises must take seriously: a namespace-verified publisher is authenticated, but the tools a server exposes are described by that server, and the trust boundary between a model and the tools it invokes is exactly where prompt-injection and confused-deputy risks concentrate. That is a live concern — but it is a concern about tool invocation, not about agent identity. Reading MCP against the five criteria has to hold that distinction, or it scores the wrong entity.

Read against the five Substrate Fitness Criteria — scoping the assessment to what MCP describes, a server and its tools, not an agent:

Discoverability — strong, for servers. Namespace-verified publishing, a canonical metaregistry, a stable REST API, reverse-DNS naming.[1][3] As a mechanism for finding and installing tool-providing servers, it is the most operationally mature format in this arc. What it discovers is servers, not agents.

Context integrity — partial. Records are versioned and the registry seeds from a validated production set; package references point to versioned artifacts.[1] But the manifest describes a server’s declared configuration, not an agent’s live authority state — and for the entity MCP actually describes, freshness is version-pinned rather than continuously attested.

Action authority — partial, and mislocated if read as an agent record. MCP describes what tools a server offers; it does not bind what an agent is authorized to invoke. Authority in the MCP model lives at the host-client boundary — the application deciding which servers and tools a model may use — not in the registry record. The registry tells you a tool exists; it does not tell you an agent was permitted to call it.

Permissioning — weak, at the registry layer. Namespace ownership gates publishing.[1] It does not gate invocation, and there is no registry-level mechanism to grant, scope, or revoke an agent’s authority to use a server — because that is not the registry’s job. Revocation of a bad server is a delisting action, not a governance-clock credential revocation.

Provenance — partial, and improving where it counts. Publisher identity is verified through OAuth/OIDC/DNS, which is meaningful provenance of who published a server record.[1] It is not provenance of what a tool actually does at runtime versus what its manifest claims, and it is not an attestation binding an agent’s capability claim to an accountable issuer. The provenance is of the publisher, not of the behavior.

The Honest Accounting

The accounting is a clarification, not a verdict, and the credit is unqualified. The MCP Registry is excellent at the job it was built for: a governed, namespace-verified, broadly adopted catalog that lets clients discover and install tool-providing servers. Anthropic and the working group built real publisher-authentication and namespace-ownership machinery, and the metaregistry design — metadata pointing to existing package registries rather than re-hosting code — is a clean architectural choice that inherits the security posture of established distribution channels. The category error the enterprise must avoid is not in MCP. It is in the reading of MCP: treating a server-and-tool manifest as the agent-identity-and-authority record it never claimed to be, and then finding it “lacking” trust primitives it was never scoped to provide. MCP answers “what tools exist and how do I connect to them.” It does not answer “who is this agent and what may it do” — and it does not pretend to. The formats that do make that claim are the ones the rest of this arc holds to it.