Some of the most consequential AI developments in 2025–2026 have come from standards work. In December 2025, Anthropic donated the Model Context Protocol (MCP) to the newly formed Agentic AI Foundation, a directed fund under the Linux Foundation cofounded by Anthropic, Block, and OpenAI, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg. Six months earlier Google had contributed its Agent2Agent protocol (A2A) to the same foundation family. Companies that compete on models are now cooperating under neutral governance on the interfaces between models, tools, and hosts.
What MCP and A2A standardize
The Model Context Protocol standardizes how an AI application connects to tools and context: it uses JSON-RPC messages between hosts, clients, and servers. Servers can expose tools that a model invokes, resources containing context and data, and prompts that describe templated workflows. The spec cites the Language Server Protocol as an inspiration. The current MCP spec is dated July 28, 2026, and is the fifth dated protocol revision since the project launched in November 2024 — a pace that reflects active governance and signals implementers to expect change.
Agent2Agent addresses the next boundary: agents discovering and communicating with one another across vendors. A2A reached v1.0 in April 2026 with more than 150 supporting organizations, signed Agent Cards for verifiable identity, SDKs in five languages, and general availability in Microsoft Copilot Studio, Azure AI Foundry, and Amazon Bedrock AgentCore. A2A is younger and less proven in production than MCP, but its governance and adoption expand agent-to-agent communication beyond single-platform confines.
Complementary projects and telemetry
The emerging stack includes other projects: OpenAI’s AGENTS.md convention for giving coding agents repository-level instructions joined MCP as a founding project of the Agentic AI Foundation. The OpenTelemetry generative AI semantic conventions are evolving a shared vocabulary for traces and metrics from model and tool calls, although that work is not yet stable. Connection, cooperation, instruction, and telemetry are beginning to acquire common interfaces.
Practical consequences for engineering teams
The immediate benefit is reuse: an MCP server for an internal ticketing system can serve every compatible IDE, chat application, and agent host. Models and hosts will continue to change; the interface contract, server implementation, schemas, and authorization wiring can persist. Integrations can therefore become reusable assets shared across applications, similar to how language servers remained useful as editors changed.
A shared protocol also concentrates attention on a common security boundary. Custom integrations often get inconsistent review; a common interface provides a clear seam where teams can specify identity, permissions, data flow, and audit behavior and apply those controls broadly. The MCP authorization specification builds on established IETF work (including OAuth 2.1, protected resource metadata, authorization server metadata, and resource indicators) and requires Proof Key for Code Exchange (PKCE) to protect authorization codes from interception. MCP servers must reject tokens issued for another audience and must not forward them downstream. Familiarity with OAuth deployments is a practical advantage here.
The spec is explicit about what metadata cannot prove. Tools may carry behavioral annotations (for example: read-only, destructive, idempotent, or open-world) to give hosts a policy vocabulary, but the current tools specification requires clients to treat such annotations as untrusted unless they come from a trusted server. Self-description can inform decisions but cannot by itself establish the trust those decisions require.
Discovery and supply-chain risks
Once servers share an interface, they become discoverable. The MCP Registry is an open catalog and API for public servers, designed to feed downstream marketplaces and private catalogs. It plays a discovery role similar to npm or PyPI but stores standardized server metadata while leaving package distribution elsewhere. The registry is in preview, with possible breaking changes and no durability guarantee.
Discovery brings familiar supply-chain risks to components with unusually powerful access. Typosquatting, abandoned packages, malicious updates, and uncertain provenance now concern software that may hold live credentials and act on production systems. The registry provides namespace verification and moderation, and its downstream model lets organizations build curated catalogs. An internal subregistry or allowlist is therefore a sensible first control when adopting public servers.
Testing and contract verification
A shared contract improves testing. MCP tools can declare a JSON Schema for inputs and structured outputs; under the current tools specification, servers that declare an output schema must return conforming structured results and clients should validate them. Teams can test a server without putting a model in the loop, mock it with recorded or synthetic behavior, and contract-test both sides as they would a REST or gRPC boundary.
That separates two uncertainties often mixed in agent evaluations: protocol tests can verify whether an integration exchanged valid messages and enforced its contract, while model evaluation can focus on whether the agent chose the right tool and interpreted its output correctly. OpenTelemetry’s emerging conventions extend this pattern to runtime evidence by providing a common language for tool calls.
Limits: semantics, trust, and delegation
These benefits stop where the interfaces stop. A schema captures the shape of a tool’s arguments, but meaning remains mostly in free-form descriptions the model must interpret. A schema cannot tell an agent when a tool is appropriate, how tool effects interact, or whether similarly named operations are semantically equivalent. Portability makes a server available across hosts; behavior can still vary across models and contexts.
The semantic gap creates a trust gap. MCP can carry a server’s claims, and an A2A Agent Card can carry a digital signature, but a signature only ties a statement to an identity. Organizations still need policies and evidence to decide which identities, publishers, code, and claims deserve authority. The protocol can carry those decisions through a system but does not make them for the organization.
Delegation increases complexity. MCP’s authorization model handles a client calling a server with an audience-bound token. Production systems increasingly chain calls (an agent calls another agent, which calls a tool or a third agent). Preventing token passthrough is necessary, yet each downstream hop still needs a narrower grant derived from the user’s original authority. No common mechanism yet defines how rights should attenuate across an arbitrary chain; platforms currently solve this locally or leave excessive authority in place.
Young infrastructure: plan for change
All of this is unfolding on young infrastructure: the registry is preview, telemetry conventions are unstable, and MCP has produced five dated protocol revisions in less than two years. Revision is how standards mature, so teams should pin versions, keep protocol code behind thin internal adapters, and budget for migrations. Some abstractions will prove wrong as standards and practice co-evolve.
Recommended practices include clear ownership and containment for each internal server, treating the protocol surface as an architecture decision, applying schema validation, conformance tests, and protocol mocks, placing third-party servers behind allowlists or private catalogs with provenance requirements, and encapsulating the emerging telemetry vocabulary to limit exposure to draft revisions.
Teams with a large stake in agents should also participate in the standards work: the Agentic AI Foundation and the A2A project are still young enough that outside engineering teams can influence what becomes portable, observable, and enforceable. Model improvements will continue to attract headlines, but standards will determine whether those models can join an ecosystem. The interfaces now emerging are likely to endure, even as their current forms continue to change.
