Protocol and Adoption Reality
The Model Context Protocol, introduced by Anthropic and since adopted broadly across the industry, standardizes how an application supplies context and tools to a language model. Through a client-server protocol, an MCP server exposes tools the model can call, resources it can read, and prompts it can use, and an MCP client, embedded in the host application, brokers the model's access to them. The achievement is real and the adoption is wide: before MCP, every integration between a model and an external tool or data source was bespoke, and MCP replaced that sprawl with one protocol that a tool provider implements once and any MCP-aware host can consume. It is now a de facto standard for connecting models to the world.
What MCP standardizes is access: how a model reaches tools and resources. That is a necessary layer, and the agent schema is not a competitor to it. The schema addresses a different question, one MCP does not attempt to answer.
The Structural Choice: An Agent Is a Client of Endpoints
In the MCP model, the unit of design is the tool-and-resource interface. A server advertises an endpoint surface, and the agent is a client that consumes it: the protocol defines the calls between them, the shapes of requests and responses, and the negotiation of what is available. What the protocol does not define is what the agent itself is. There is no portable representation of the agent's intent, its accumulated memory, the policy that governs it, the mutation it is about to perform, or the lineage of how it arrived at its current state. The agent, in MCP terms, is whatever the host application happens to maintain in its own runtime, and that internal state is neither standardized nor portable nor governed by the protocol. MCP makes the agent's tools interoperable; it leaves the agent itself an unstandardized, host-local thing.
What the Agent Schema Provides
The Agent Schema, as disclosed in United States Patent Application 19/452,651, standardizes the agent rather than its tool access. A semantic agent object carries up to six canonical fields: an intent that names what it seeks, a context that situates it, a memory that holds its accumulated trace outcomes, a policy reference that governs what it may do, a mutation descriptor that declares the transformations it is permitted, and a lineage that records how it got here. A full agent carries all six; a partial agent carries a valid subset, since the schema treats presence of at least two coherent fields as sufficient structure to interpret and govern. Because the agent is a structured object rather than host-local runtime state, it is portable across systems, serializable and rehydratable, structurally validatable from its own contents, and governable by construction, since the policy and lineage it must satisfy travel with it. An agent that calls tools through MCP and is itself a semantic agent object gains a governed, portable identity that MCP does not provide, while losing nothing of MCP's tool interoperability. The two layers compose cleanly: MCP defines how the agent reaches its tools, and the schema defines what the agent is as it does so.
A skilled implementer can build this object layer over an MCP deployment without prescribing any particular runtime. The specification describes validation performed solely from the object's embedded fields, so a receiving node, a validating peer, or a federated resolver can each decide admissibility independently. Missing fields are handled by field-aware structural scaffolding: an absent intent may be inferred under schema-defined rules from context, lineage, or policy-encoded defaults; an absent memory is initialized as a blank, explicitly-scaffolded trace rather than fabricated history; an absent mutation descriptor renders the object immutable until authorization is granted. The object is transport-agnostic and serialized in any extensible, hierarchically addressable format, so the same agent can move across stateless nodes, edge devices, federated infrastructures, and asynchronous message-passing layers. Field integrity and lineage references may optionally be bound with cryptographic signatures or hashes to make provenance tamper-evident, though the validation model itself is independent of any specific cryptographic primitive, programming language, or execution engine. These embodiments are illustrative, not exhaustive; the disclosed schema also contemplates versioned schema evolution, distributed template and contract registries, and language-model-driven mutation of agent objects.
Composable, Not Competing
MCP and the agent schema occupy different layers of the same stack. One is a protocol for tool and context access; the other is a structural definition of the agent object. A host that speaks MCP can carry semantic agent objects as its agents, and a semantic agent object can reach its tools over MCP, so adopting both is additive rather than a choice between them. The schema is the missing object layer beneath the access layer MCP standardized. No relationship, endorsement, or infringement is asserted; the comparison is architectural.
Disclosure Scope
The semantic agent object and its six canonical typed fields, intent, context, memory, policy reference, mutation descriptor, and lineage, together with structural validation, partial-agent support, and traceable semantic lineage that make the agent a portable, governable object, are disclosed in United States Patent Application 19/452,651. This article compares that disclosed object model with Anthropic's publicly documented Model Context Protocol and positions the schema as the agent-object layer beneath MCP's tool-access protocol. The description of MCP is drawn from its public specification and is provided as external context for comparison only; it is not a claim of the filing, and no relationship with, endorsement by, or infringement of Anthropic is asserted.
