The MCP Protocol War: A Standards Battle for AI Agent Infrastructure

The Model Context Protocol is becoming a test of whether the infrastructure surrounding artificial-intelligence agents will be controlled by individual platforms or shared through open standards. Anthropic’s MCP specification defines a common interface through which agents can discover tools, retrieve resources and invoke outside systems, including databases, code repositories and internal applications. For businesses, the attraction is straightforward: A company could expose a capability once rather than build a different connector for every model provider. The protocol is also undergoing its most consequential redesign. The Register reported in August that MCP’s largest overhaul would move it away from connection-bound sessions and toward stateless requests. Anthropic’s current specification already permits Streamable HTTP servers to operate without issuing session identifiers, while retaining sessions as an option. The roadmap would push that design further, making MCP easier to place behind conventional load balancers and reducing the operational burden of preserving client affinity. That shift has generated resistance as well as support. A Hacker News discussion of the MCP roadmap drew more than 174 points and 80 comments, with participants debating whether statelessness simplifies distributed deployment at the cost of subscriptions, server notifications and other long-running interactions. The disagreement is less about whether state exists than where it resides: in the protocol server, a shared database, the agent host or the underlying application. MCP also faces competition at several layers. The Register reported that the Agent Plugins 1.0 specification is seeking to standardize agent-tool integration through a competing open framework. OpenAI’s function-calling interface remains the incumbent by reported adoption and offers a simpler model-native tool loop, according to OpenAI’s API documentation. Google’s A2A documentation defines a separate protocol for agents to delegate work to other agents. The ATProto Spaces proposal, meanwhile, explores private data sharing for agents using infrastructure associated with Bluesky. No single specification necessarily has to displace the others. An A2A agent could use MCP tools, while a model could invoke either through a vendor’s function-calling API. For enterprise architects, the decisive issues will be governance, identity, conformance testing, observability and the ability to move integrations between model vendors. An open specification reduces lock-in only when independent implementations behave consistently.

For engineers, MCP is an abstraction boundary between an agent host and the systems on which the agent acts. Anthropic’s specification divides server capabilities into tools, resources and prompts: tools perform operations, resources expose addressable data, and prompts supply reusable message templates. A client initializes the connection, negotiates a protocol version and discovers the capabilities it may present to a model. The stateless redesign changes deployment more than application semantics. According to The Register’s account of the August overhaul, the MCP roadmap would drop protocol-managed sessions as a default architectural assumption. Under Anthropic’s published Streamable HTTP rules, however, servers can currently choose whether to issue an MCP-Session-Id. A stateless server must reconstruct the information needed for each request from the request itself, an external store or an application identifier. Statelessness therefore removes affinity requirements; it doesn’t eliminate business state. That distinction matters for subscriptions and notifications. Anthropic’s documentation allows servers to notify clients when tool or resource lists change, but continuity-dependent features require a reachable client and, in distributed deployments, shared routing or durable state. Teams adopting the proposed profile should inventory those features before treating stateless operation as a drop-in transport change. The basic tool flow remains compact. Anthropic’s specification assigns tools/list to discovery and tools/call to execution, while resources/list and resources/read serve content addressed by URI. Tool implementations aren’t registered through a standard network method; each server loads its own implementations and publishes the resulting catalog. That separation lets organizations put an MCP façade over existing services without rewriting the underlying APIs. OpenAI function calling takes a narrower approach. According to OpenAI’s API documentation, applications include tool schemas with a model request, receive calls containing names, arguments and identifiers, execute them, and return the corresponding outputs. That design is efficient when one application owns the complete loop. MCP adds remote discovery, transport and lifecycle conventions, but also introduces another network boundary and another component to secure. Google’s A2A protocol addresses a different problem. Google’s documentation describes agent cards, tasks, messages and artifacts for agent-to-agent delegation rather than primarily for tool invocation. An A2A service can therefore delegate a task to an agent that, internally, calls MCP servers. Agent Plugins 1.0 overlaps more directly with tool integration; its versioned specification, released in August and covered by The Register, gives architects another manifest-and-capability model to evaluate. The emerging ecosystem remains uneven. OzBrain and Autolith are among the projects building on MCP, according to project references discussed in the 174-point Hacker News roadmap thread, but community implementations vary in security posture and operational maturity. Enterprises should test schema compatibility, authorization behavior, cancellation and error handling rather than equate the existence of a connector with production readiness. MCP is most compelling when several agent hosts must share integrations or when model portability has material value. Direct API calls remain preferable for a small number of latency-sensitive operations, specialized streaming interfaces or tightly coupled authorization models. In either design, production systems need deadlines, bounded retries, idempotency controls, circuit breakers and trace identifiers spanning the model, agent host, protocol server and downstream service.

MCP’s wire model is JSON-RPC 2.0 carried over transports defined by Anthropic’s specification, principally local standard input and output, or Streamable HTTP for remote servers. Requests contain a method, parameters and identifier; responses carry either a result or JSON-RPC error. Notifications omit the identifier and don’t receive responses. The specification’s primary server primitives are tools, resources and prompts, with capability declarations used during initialization to indicate which optional operations are available. Initialization is a negotiation rather than an authentication mechanism. Under Anthropic’s documentation, a client sends initialize with its supported protocol version, capabilities and client information. The server returns the selected version, its capabilities and identifying metadata, after which the client sends notifications/initialized. For subsequent HTTP traffic, the client supplies the negotiated MCP-Protocol-Version header. Authentication and authorization remain separate concerns. Session handling is where the old and proposed models diverge. Anthropic’s current Streamable HTTP specification allows a server to issue MCP-Session-Id during initialization and require that value on later requests. It also allows a server not to issue an identifier, producing a stateless deployment. The Register reported that the August roadmap would make the latter model central to MCP’s largest overhaul, reducing reliance on protocol-level sessions rather than changing JSON-RPC itself. A stateless implementation should treat each request as independently routable. Authentication claims, tenant identity, negotiated version and request correlation must be recoverable without process-local memory. If an operation requires durable workflow state, the server should place it in a shared store keyed by an application-level identifier. Load balancers can then route requests to interchangeable instances, though downstream databases and queues may still retain extensive state. Discovery and execution are separate protocol operations. According to Anthropic’s specification, tools/list returns tool names, descriptions and input schemas, while tools/call supplies a tool name and arguments. Tool inputs are described using JSON Schema. Servers should validate arguments independently rather than assume a model generated compliant data, because schema-guided generation doesn’t guarantee that a request is authorized or semantically safe. Results can contain textual or other MCP content blocks and, where supported, structuredContent, according to Anthropic’s tool specification. An application-level tool failure can be returned with isError set to true, allowing the model or host to interpret the failure as part of the tool loop. Malformed protocol messages instead use JSON-RPC errors, including minus 32700 for parsing failures, minus 32601 for unknown methods and minus 32602 for invalid parameters, as incorporated by the MCP specification. The client, not MCP, schedules work. Anthropic’s documentation defines invocation but doesn’t provide a distributed planner or transaction coordinator. A host may issue independent calls concurrently, but it must enforce ordering for dependent operations and prevent unsafe duplication. OpenAI’s API documentation similarly allows models to request multiple tool calls and exposes parallel-tool-call controls, while leaving execution and side-effect management to the application. The architectural difference is discovery. OpenAI’s function-calling documentation places tool definitions directly in the model API request and associates returned calls with identifiers that the application later resolves. MCP permits a client to obtain a catalog from a separately operated server. The direct OpenAI pattern has fewer moving parts; MCP can reduce duplicated integration work when several hosts consume the same service. Neither design removes the need for application-level authorization. Google’s A2A documentation operates above that tool layer. It describes discoverable agent cards and task-oriented exchanges containing messages, status updates and artifacts. An organization could expose a specialist agent through A2A while allowing that agent to call inventory, document or source-control systems through MCP. Such composition increases interoperability, but it also creates multiple identity boundaries: the requesting user, delegating agent, receiving agent and tool server may each have different permissions. Agent Plugins 1.0 presents a more direct standards challenge. According to the specification released in August and The Register’s coverage, it seeks a portable contract for agent-tool integration rather than relying on one vendor’s SDK. Architects should compare its capability declarations, version negotiation, packaging, permission model and conformance process with MCP’s equivalents. A published document alone doesn’t establish interoperability; independent implementations and shared test suites do. ATProto Spaces targets another adjacent problem. The Bluesky-associated proposal describes private spaces through which agents could share nonpublic data using AT Protocol concepts. Because it is a proposal rather than a mature deployment baseline, enterprises should scrutinize its access-control, encryption, revocation and replication rules before using it for regulated information. Private sharing also raises questions that tool protocols don’t resolve, including who can re-share derived data and how deletion propagates across agent replicas. Production MCP servers should authorize at the level of individual tools and resources. Anthropic’s security guidance calls for protected remote transports and explicit authorization rather than trusting tool descriptions. Servers should validate token audiences, map scopes to operations, constrain filesystem paths and network destinations, cap output sizes and place high-impact actions behind policy or user approval. Arguments should be treated as untrusted input even when generated by a model. Clients should cache discovery conservatively and refresh when the server advertises list-change notifications, as provided by Anthropic’s capability model. They should attach deadlines to calls, propagate cancellation where supported and retry only failures known to be transient. A non-idempotent operation shouldn’t be replayed unless the tool accepts an idempotency key or offers an equivalent deduplication mechanism. The final requirement is observability. Each invocation should carry a trace identifier across the model request, agent host, MCP or plugin boundary and downstream system. Audit records should identify the principal, agent, tool, authorization decision, duration and outcome while redacting credentials and sensitive arguments. As the Hacker News debate over MCP’s roadmap illustrated, removing sessions simplifies one operational layer; it doesn’t remove the distributed-systems obligations that production agents inherit.