MCP defines a JSON-RPC 2.0 protocol between a host application, its clients, and servers that expose resources, prompts and tools. The current 2026-07-28 revision is a structural break from earlier versions: it removed the initialize handshake, made requests stateless and self-contained with per-request capability negotiation carried in _meta fields, and added a mandatory server/discover method. Two standard transports are specified — newline-delimited JSON-RPC over stdio for subprocess servers, and Streamable HTTP where each message is a POST that returns either a JSON object or a request-scoped SSE stream. Optional extensions (Tasks for long-running work, MCP Apps for UI, Skills over MCP) are negotiated per-connection rather than baked into the core. Everything is Apache-2.0; docs are CC-BY-4.0.
| Maintainer | Model Context Protocol, a Series of LF Projects, LLC; lead maintainers David Soria Parra and Den Delimarsky |
|---|
| Spec status | Stable, revision 2026-07-28 (released 28 Jul 2026); prior revision 2025-11-25 |
|---|
| Transport | stdio (newline-delimited JSON-RPC) and Streamable HTTP (POST + request-scoped SSE); custom transports allowed |
|---|
| Adoption | TypeScript and Python SDKs passed 1 billion cumulative downloads by Jul 2026; supported by Claude, VS Code, Copilot, Cursor, Goose, Postman |
|---|
| Problem solved | N×M integration explosion between LLM applications and the tools/data they need |
|---|
Watch out: Version churn is the real cost: 2026-07-28 removed the initialize handshake that every prior revision required, so modern clients silently fail against legacy servers and you need dual-era support or hard pinning. Governance is a BDFL model with two lead maintainers, not a consensus standards body, so you have little formal influence on breaking changes. The protocol also has no built-in authorization story beyond what the transport provides, and tool descriptions are explicitly untrusted input — the spec itself warns that annotations must be treated as adversarial unless the server is trusted. Wrong choice when your "tools" are already a well-documented HTTP API that the model can call directly.
$0. Apache-2.0 specification and SDKs, CC-BY-4.0 documentation. No membership or conformance fees.
· open source
MCP Apps is an opt-in extension (capability id io.modelcontextprotocol/ui) where a tool description carries a _meta.ui.resourceUri pointing at a ui:// resource containing an HTML page. The host preloads and renders it in a sandboxed iframe, and app-to-host communication runs over postMessage using a JSON-RPC dialect that shares some methods with core MCP (tools/call) and adds ui/-prefixed ones. The sandbox blocks parent DOM, cookie and storage access; _meta.ui.permissions and _meta.ui.csp control camera/microphone access and which external origins may load. The @modelcontextprotocol/ext-apps package is a convenience wrapper, not a requirement, and starter templates exist for React, Vue, Svelte, Preact, Solid and vanilla JS.
| Maintainer | MCP project working group (modelcontextprotocol/ext-apps) |
|---|
| Spec status | Extension specification 2026-01-26; opt-in, negotiated via the extensions capability map |
|---|
| Transport | postMessage between host page and sandboxed iframe, carrying a JSON-RPC dialect of MCP |
|---|
| Adoption | Claude, Claude Desktop, VS Code Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam, Archestra.AI |
|---|
| Problem solved | Tool results that need interaction (forms, charts, viewers) rather than a block of text |
|---|
Watch out: Host support is uneven and this is an extension, not core MCP: Claude, Claude Desktop, VS Code Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam and Archestra support it, but any other client will fall back to the plain tool result, so you must build a text path anyway. You are also writing and shipping a web app inside your MCP server, with the debugging and CSP pain that implies. Wrong choice for anything a markdown table or an image would convey — and if your users would be equally happy with a link to a real web app, build the web app.
$0. Part of the Apache-2.0 MCP project; specification revision 2026-01-26 published in the ext-apps repository.
· open source
A2A standardizes agent-to-agent delegation rather than tool calling. Each server publishes an Agent Card — a JSON document describing identity, skills, service endpoint and auth requirements — which clients fetch to discover what an agent can do. v1.0 defines three protocol bindings (JSON-RPC, gRPC, and HTTP+JSON/REST) plus a path for custom bindings, and models work as long-running tasks with streaming updates rather than single request/response calls. The design premise is explicitly that wrapping an agent as a stateless tool is limiting: A2A keeps multi-turn negotiation between peers. Originally developed by Google, donated to the Linux Foundation, and it joined the Agentic AI Foundation in August 2026 under a TSC with members from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow.
| Maintainer | Technical Steering Committee under the Agentic AI Foundation / Linux Foundation (AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, ServiceNow) |
|---|
| Spec status | v1.0.0, latest released version; joined Agentic AI Foundation Aug 2026 |
|---|
| Transport | JSON-RPC, gRPC, and HTTP+JSON/REST bindings; custom bindings permitted |
|---|
| Adoption | SDKs in Python, JavaScript, Java, C#/.NET, Go, Rust; backed by eight major vendors on the TSC |
|---|
| Problem solved | Point-to-point custom integrations between agents built on different frameworks and owned by different companies |
|---|
Watch out: Massively over-engineered for anything inside one codebase — if your agents share a process, a function call is the right answer, and if they share a trust boundary, exposing the sub-agent as an MCP tool is usually enough. v1.0 also carries real breaking changes from the 0.x line (the kind discriminator was removed, extended agent card fields relocated), so 0.x implementations need migration. Three transport bindings means interop testing is three times the work and in practice you will meet peers that only implement one. Real-world adoption is still far behind MCP's, so you may be the only A2A speaker your partners have met.
$0. Apache-2.0 specification and SDKs (Python, JavaScript, Java, C#/.NET, Go, Rust).
· open source
ACP is the Language Server Protocol idea applied to coding agents: instead of every editor building a custom integration for every agent and every agent shipping editor-specific plugins, both sides speak one protocol. Local agents run as a subprocess with JSON-RPC over stdio; remote agents over HTTP or WebSocket are explicitly still a work in progress. It uses Markdown as the default text format and deliberately reuses MCP's JSON representations where they fit, so an agent that already speaks MCP has less new surface to implement. Note the name collision: this is unrelated to the Agentic Commerce Protocol, also abbreviated ACP.
| Maintainer | Zed Industries and open-source contributors; maintainer identity not stated on the docs site |
|---|
| Spec status | Active; version number not published on the documentation site. Remote-agent support explicitly work in progress |
|---|
| Transport | JSON-RPC over stdio for local subprocess agents; HTTP or WebSocket for remote (WIP) |
|---|
| Adoption | Centred on Zed and collaborating agents; no published implementer list |
|---|
| Problem solved | Every editor building a bespoke integration for every coding agent, and vice versa |
|---|
Watch out: Much narrower blast radius than MCP — it standardizes the editor↔agent channel only, and the remote/HTTP story is unfinished, so today it is realistically a local-subprocess protocol. Adoption is concentrated around Zed and its collaborators rather than being an industry-wide default, and the major agent vendors still ship their own first-party editor extensions, so ACP support is often the second-class path with fewer features. The docs do not currently state a version number or license clearly, which is a governance smell for anything you plan to depend on commercially. Wrong choice if you only ever need one agent in one editor.
$0. Open specification with reference implementations; no fees. Exact license not stated on the documentation site.
· open source
AG-UI standardizes the wire format between a running agent and the user-facing app, on the argument that REST and GraphQL assume short deterministic request/response cycles while agent runs are long, nondeterministic, and mix structured state with unstructured text. It is an event-based, bidirectional layer over HTTP and WebSockets carrying things like token deltas, tool-call starts, state patches and human-in-the-loop prompts. CopilotKit provides first-party support and there are integrations with LangChain, CrewAI, Microsoft Agent Framework, Google ADK and AWS Bedrock, plus community SDKs in Kotlin, Go, Dart, Java, Rust, Ruby, C++ and .NET.
| Maintainer | AG-UI Protocol community; first-party support from CopilotKit |
|---|
| Spec status | Described as production-ready; no published version number on the docs site |
|---|
| Transport | Event stream over HTTP and WebSockets |
|---|
| Adoption | CopilotKit, LangChain, CrewAI, Microsoft Agent Framework, Google ADK, AWS Bedrock; SDKs in 8+ languages |
|---|
| Problem solved | REST/GraphQL do not model long-running, streaming, stateful agent interactions with a UI |
|---|
Watch out: It solves a problem many teams do not have — if your frontend and backend are one codebase and one framework, a plain SSE stream with your own event shapes is less work and one fewer dependency. Governance is community-plus-one-vendor (CopilotKit) rather than a foundation, so its direction tracks that vendor's roadmap. The long list of "supported" framework integrations varies a lot in depth, and you should assume you will read integration source code. It also overlaps with what MCP Apps and native host UIs already give you if you are shipping into an existing host rather than your own app.
$0. Open-source protocol and SDKs; specific license listed only in the GitHub repository, not on the docs site.
· open source
Not a standard in any formal sense — it is one vendor's REST endpoint that the rest of the industry copied, and that accident is now the most portable interface in AI. A messages array of role/content objects, a tools array of JSON Schema function definitions, and SSE streaming is the shape that Gemini, Anthropic, Mistral, Groq, Together, vLLM, llama.cpp, Ollama, LiteLLM, OpenRouter and effectively every gateway implement. Google's Gemini exposes it at generativelanguage.googleapis.com/v1beta/openai/ and supports streaming, function calling, structured output, embeddings, batch and reasoning-effort controls through it. As of September 2026 OpenAI's own deprecations page does not list Chat Completions as deprecated or legacy, though the current quickstart documents only the Responses API.
| Maintainer | OpenAI; no standards body, no formal specification document |
|---|
| Spec status | Active and not listed as deprecated on OpenAI's Sept 2026 deprecations page; no version numbers |
|---|
| Transport | HTTPS POST returning JSON, or server-sent events for streaming |
|---|
| Adoption | Implemented by Gemini (beta), Anthropic, Mistral, Groq, Together, vLLM, Ollama, LiteLLM, OpenRouter and most gateways |
|---|
| Problem solved | Provider lock-in at the inference call site; one client library reaches almost every model |
|---|
Watch out: There is no specification, no conformance suite and no versioning — "OpenAI-compatible" means whatever each vendor decided to implement, and the differences bite exactly where it hurts: tool-call streaming chunk shapes, structured-output enforcement, reasoning fields, and error codes. Google's own docs call their compatibility layer beta and recommend the native Gemini API if you are not already invested. It also cannot express newer capabilities cleanly (server-side conversation state, hosted tools, multi-step reasoning traces), which is exactly why OpenAI built Responses. And because it belongs to one company, its long-term support is a business decision, not a governance commitment.
unknown — the interface itself costs nothing to implement, and per-token charges depend on which provider's endpoint you call; no single pricing page applies.
POST /v1/responses is the endpoint OpenAI's current documentation leads with — the quickstart teaches it exclusively and does not mention Chat Completions at all. It replaces the client-managed messages array with server-side conversation state, folds in built-in hosted tools, and presents one interface across text, vision, files and reasoning models, with streaming over SSE and companion /v1/files and Realtime (WebRTC/WebSocket) endpoints. New OpenAI capabilities land here first. It is proprietary: unlike Chat Completions, other providers have largely not cloned it, so code written against Responses is code written against OpenAI.
| Maintainer | OpenAI |
|---|
| Spec status | Active and documented as the primary interface in the Sept 2026 quickstart; proprietary, unversioned |
|---|
| Transport | HTTPS POST /v1/responses returning JSON or SSE; Realtime API over WebRTC/WebSocket |
|---|
| Adoption | OpenAI first-party SDKs and Codex; not meaningfully cloned by other providers |
|---|
| Problem solved | Client-side conversation state and hand-rolled tool loops that Chat Completions forces on you |
|---|
Watch out: Portability is the trade: essentially no other provider implements Responses, so adopting it is a deliberate lock-in decision that Chat Completions lets you avoid for very little effort. OpenAI has also shown a willingness to kill adjacent surfaces fast — the v1/prompts reusable-prompt API, the Evals platform and Agent Builder were all announced for shutdown on 30 Nov 2026 — so building deeply on newer OpenAI abstractions carries real migration risk. Server-side state also means your conversation history lives on OpenAI's servers, which some compliance regimes will not accept. Wrong choice if multi-provider failover or self-hosted models are anywhere on your roadmap.
unknown — the API surface costs nothing but usage is billed per token at OpenAI's published model rates, which were not verified for this entry.
The vendor-neutral answer to "what should I call the span attribute holding the model name". The conventions define spans, metrics and events for GenAI clients, agent invocations and MCP calls, plus provider-specific conventions for OpenAI, Anthropic, AWS Bedrock and Azure AI Inference. They moved out of the main semantic-conventions repository into their own repo (open-telemetry/semantic-conventions-genai) with reference implementations kept alongside. Because it is OpenTelemetry, any backend that ingests OTLP — Grafana, Datadog, Honeycomb, Langfuse, Phoenix, Jaeger — can read your traces without a proprietary SDK.
| Maintainer | OpenTelemetry project (CNCF), GenAI semantic conventions SIG |
|---|
| Spec status | Development (unstable) as of Sept 2026; relocated to its own repo from the main semantic-conventions repo |
|---|
| Transport | OTLP over gRPC or HTTP; conventions are attribute naming, transport-agnostic |
|---|
| Adoption | Provider conventions for OpenAI, Anthropic, AWS Bedrock, Azure AI Inference; consumed by most OTLP-compatible observability backends |
|---|
| Problem solved | Every LLM tracing tool inventing its own attribute names, making traces non-portable between backends |
|---|
Watch out: Still marked Development status, which in OpenTelemetry terms means attribute names can and do change between releases — dashboards and alerts you build today may need rewriting, and there is no stability guarantee to point at in a design review. Coverage is also thinner than commercial LLM-observability SDKs: you get naming conventions, not turnkey instrumentation for forty frameworks, so you write more glue. Capturing prompt and completion content raises immediate PII questions that the conventions push onto you as opt-in configuration. Wrong choice if you need working traces across LangChain, LlamaIndex and CrewAI this week — use OpenInference or a vendor SDK and migrate later.
$0. Apache-2.0 CNCF project; you pay only your observability backend, not the conventions.
· open source
OpenInference is a set of tracing conventions plus auto-instrumentation plugins designed to complement rather than replace OpenTelemetry, capturing LLM invocations along with the surrounding retrieval and tool-use context. Its practical advantage over the official OTel GenAI conventions is breadth of shipped instrumentation: 40+ Python packages (OpenAI, Anthropic, LangChain, LlamaIndex and more), 11+ JavaScript/TypeScript packages, four Java libraries including LangChain4j and Spring AI, and Go packages for the OpenAI and Anthropic SDKs. The spec is deliberately transport- and format-agnostic (JSON, ProtoBuf, DataFrames), and traces land in Arize Phoenix — which is itself open source and self-hostable — or any OTLP collector.
| Maintainer | Arize AI |
|---|
| Spec status | Active and actively maintained; no formal stability level published, versioned per-instrumentation package |
|---|
| Transport | Transport- and format-agnostic (JSON, ProtoBuf, DataFrames); commonly exported via OTLP |
|---|
| Adoption | 40+ Python instrumentations, 11+ JS/TS, 4 Java (incl. Spring AI, LangChain4j), 2+ Go; ~1.2k GitHub stars |
|---|
| Problem solved | Getting usable LLM/RAG traces out of existing frameworks without writing instrumentation yourself |
|---|
Watch out: It is a single vendor's convention set, not a neutral standard — Arize maintains it, and the strategic direction of the industry is toward the official OpenTelemetry GenAI conventions, so you may be signing up for a migration. Attribute names differ from the OTel GenAI ones, so mixing both in one backend produces two vocabularies for the same concept unless you normalize. Instrumentation depth also varies sharply between the 40+ Python packages and the much thinner Java and Go coverage. Wrong choice if your organization has already standardized on OTel semantic conventions and treats non-canonical attribute names as tech debt.
$0 for the conventions and instrumentation (Apache-2.0). Arize's hosted commercial platform is priced separately and was not verified here.
· open source
A convention, not a standard: put a markdown file at your site root (or a subpath) containing an H1, an optional blockquote summary, and H2-delimited lists of links with one-line descriptions, so a model reading your site gets a curated map instead of scraping navigation chrome. The spec also recommends publishing .md versions of pages and linking them with rel="alternate" and rel="describedby". Proposed by Jeremy Howard in September 2024, with a version 2 published in August 2026. OpenAI, Anthropic and Google's Gemini docs all publish one, Mintlify, GitBook and Wix generate them automatically, and Chrome's Lighthouse now audits for it. The MCP documentation site itself advertises its llms.txt at the top of every fetched page.
| Maintainer | Jeremy Howard; developed openly on GitHub, no standards body |
|---|
| Spec status | Informal proposal; v1 Sept 2024, v2 published Aug 2026. Explicitly not formally standardized |
|---|
| Transport | Static markdown file served over HTTP at /llms.txt |
|---|
| Adoption | Thousands of sites incl. OpenAI, Anthropic, Gemini docs; auto-generated by Mintlify, GitBook, Wix; audited by Chrome Lighthouse |
|---|
| Problem solved | LLMs scraping HTML navigation and boilerplate instead of the actual documentation |
|---|
Watch out: Nothing enforces it and no major crawler has publicly committed to privileging it, so the honest position is that you are publishing a file and hoping — it is not robots.txt, which has decades of respected convention behind it. It is also a maintenance burden that silently rots: a stale llms.txt is worse than none, because it confidently points models at deleted pages. Auto-generators from docs platforms tend to emit a link dump with no curation, which delivers little over a sitemap. And it offers zero access control — it is a helpful index for scrapers you may not want, not a way to restrict them (see AIPREF for that).
$0. A file format — nothing to license, nothing to buy.
· open source
A README for agents: plain Markdown at the repo root holding build steps, test commands, code conventions and anything else you would otherwise cram into a human README or a per-tool config file. There are no required fields and no schema — agents just read the text. Nested AGENTS.md files in monorepo subpackages take precedence over the root file by path proximity. The format emerged from parallel efforts at OpenAI Codex, Amp, Google Jules, Cursor and Factory converging on one filename rather than five, and is now stewarded by the Agentic AI Foundation under the Linux Foundation. Over 60,000 open-source projects use it, including Apache Airflow and Temporal's Java SDK.
| Maintainer | Agentic AI Foundation, Linux Foundation; originated across OpenAI Codex, Amp, Google Jules, Cursor and Factory |
|---|
| Spec status | Active open format; no required fields, no version number, no schema |
|---|
| Transport | Plain Markdown file read from the filesystem; nested files override by directory proximity |
|---|
| Adoption | 60,000+ open-source repos; read by Codex, Jules, Aider, VS Code, Devin, Copilot, Cursor, Zed, Warp, Gemini CLI |
|---|
| Problem solved | Every coding agent needing its own proprietary instructions file in the repo root |
|---|
Watch out: Zero specification means zero guarantees — there are no required fields, so two agents can read the same file and act differently, and nothing validates it. Long AGENTS.md files eat context window on every session, and there is a real tendency to accumulate stale instructions that actively mislead agents months later. The precedence rules for nested files are convention rather than spec, so monorepo behaviour varies by tool. Several vendors also still read their own proprietary files (CLAUDE.md, .cursorrules and friends) either instead of or in addition to AGENTS.md, so you may end up maintaining a symlink farm. Wrong choice as a substitute for actual documentation humans read.
$0. A filename convention with no schema, no tooling and no fees.
· open source
A skill is a folder containing SKILL.md — YAML frontmatter with a required name and description plus markdown instructions — optionally bundled with scripts/, references/ and assets/. Loading works by progressive disclosure in three stages: at startup the agent reads only names and descriptions, when a task matches it pulls the full SKILL.md into context, and only then does it execute bundled code or open referenced files. That keeps many skills available at a small context cost, which is the whole point versus stuffing everything into a system prompt. Originally developed by Anthropic and released as an open standard; adopted by Claude Code, ChatGPT/Codex, Gemini CLI, Cursor, GitHub Copilot, VS Code, JetBrains Junie, OpenCode, OpenHands, Goose, Roo Code, Kiro, Letta, Spring AI, Databricks and Snowflake among many others.
| Maintainer | Originated at Anthropic, released as an open standard; developed at github.com/agentskills/agentskills |
|---|
| Spec status | Active open standard; specification published at agentskills.io, no public version number confirmed |
|---|
| Transport | Filesystem folder containing SKILL.md with YAML frontmatter, plus optional scripts/references/assets |
|---|
| Adoption | 40+ named clients incl. Claude Code, ChatGPT/Codex, Gemini CLI, Cursor, GitHub Copilot, VS Code, Junie, Goose, OpenHands, Spring AI, Databricks, Snowflake |
|---|
| Problem solved | Procedural knowledge that is too large for a system prompt and too specific to be a tool |
|---|
Watch out: Skills execute bundled scripts, so installing a third-party skill is running someone else's code with your agent's permissions — treat a skill repo exactly like an npm dependency, because the format has no signing, sandboxing or provenance story. Discovery depends entirely on the description field, so a badly worded description means the skill never fires and debugging that is guesswork. Behaviour also differs between hosts despite the shared format: what a skill can invoke in Claude Code is not what it can invoke in Cursor. And there is real overlap with AGENTS.md and MCP prompts — three ways to inject instructions, with no guidance on which wins. Wrong choice for knowledge that should just be a tool or an API call.
$0. Repository code Apache-2.0, documentation CC-BY-4.0. Anthropic's document-handling example skills (docx/pdf/pptx/xlsx) are source-available rather than open source.
· open source
C2PA defines a signed manifest attached to a media file recording its origin and edit history — who or what produced it, which tools touched it, and whether a generative model was involved. Version 2.4 is the current specification, with a conformance program launched in mid-2025 that publishes lists of conforming products and maintains an official Trust List; the older interim trust list was frozen on 1 January 2026 with no new entries, pushing implementers onto the conformance framework. The steering committee is Adobe, Amazon, BBC, Google, Meta, Microsoft, OpenAI, Publicis Groupe, Sony, TikTok and Truepic — which is why Content Credentials show up in Adobe tooling, on TikTok, in Sony cameras and on OpenAI image output.
| Maintainer | Coalition for Content Provenance and Authenticity; steering committee of Adobe, Amazon, BBC, Google, Meta, Microsoft, OpenAI, Publicis, Sony, TikTok, Truepic |
|---|
| Spec status | Version 2.4 current (2.3 also published); conformance program operational since mid-2025, interim trust list frozen 1 Jan 2026 |
|---|
| Transport | Signed manifests embedded in media containers (JPEG, PNG, MP4, WAV and others), with cloud/sidecar options |
|---|
| Adoption | Adobe products, TikTok, Sony cameras, OpenAI image output, Google, BBC; published conforming-product lists |
|---|
| Problem solved | No verifiable record of where a piece of media came from or whether a model generated it |
|---|
Watch out: The manifest is metadata, and metadata is fragile: a screenshot, a re-encode, most social-platform upload pipelines, or any tool that does not preserve C2PA strips it silently, and absence of a manifest proves nothing. It establishes provenance, not truth — a correctly signed manifest on a staged photograph is still a staged photograph. Verification also requires trusting the signer, which means the Trust List and conformance program become the real gate, and the ITL freeze in Jan 2026 means anyone still on the interim model has migration work. Version fragmentation across 1.x and 2.x deployments is an acknowledged ecosystem problem. Wrong choice if you need to detect AI-generated content in the wild — that is a detection problem, and C2PA deliberately does not solve it.
unknown — the specification is publicly readable and free to implement, but C2PA membership tiers and conformance-program certification fees were not verified from an official pricing page.
· open source
The formal standards-track attempt to answer "how do I say no to AI training in a way a crawler must parse the same way I meant it". The working group, chaired by Mark Nottingham and Suresh Krishnan, is producing two standards-track documents: draft-ietf-aipref-vocab, a vocabulary of preferences (training, inference, search and similar uses) that is independent of how it is delivered, and draft-ietf-aipref-attach, which defines how to attach those preferences to content using IETF protocols — well-known URIs and HTTP header fields. Both carry an August 31, 2026 milestone for submission to the IESG. This is the piece that llms.txt and robots.txt conspicuously do not provide.
| Maintainer | IETF AIPREF Working Group; chairs Mark Nottingham and Suresh Krishnan |
|---|
| Spec status | Internet-Drafts, standards track; draft-ietf-aipref-vocab and draft-ietf-aipref-attach, IESG submission milestone 31 Aug 2026. Not yet RFCs |
|---|
| Transport | HTTP header fields and well-known URIs; also content metadata |
|---|
| Adoption | Pre-RFC; no significant production deployment yet |
|---|
| Problem solved | No interoperable, machine-readable way to express whether content may be used for AI training or inference |
|---|
Watch out: Not finished: both documents are still Internet-Drafts and had not reached RFC status as of September 2026, so anything you deploy now may need to change. More fundamentally, a preference is not access control — it depends entirely on crawlers voluntarily honouring it, and the enforcement question is legal, not technical. Deployment tooling and CDN support are thin compared with robots.txt. Wrong choice if you need to actually block scrapers today: rate limiting, authentication and bot management do that, and AIPREF does not.
$0. IETF drafts and RFCs are freely published; participation in the working group is free and open.
· open source · beta
Where MCP and A2A each standardize one wire protocol, AGNTCY is a stack of components for running multi-vendor agents in an enterprise: Directory, a federated registry for discovering agents across frameworks and protocols; SLIM, a protocol for secure agent-to-agent network messaging; Identity, for issuing and verifying agent and tool identities across organizational boundaries; OASF, the Open Agentic Schema Framework — a taxonomy at version 1.1.0 maintained by Cisco that categorizes agent skills across 18 domains from language processing to cybersecurity to governance; plus a Secure Runtime combining identity verification, secrets management and sandboxing, and AgentBridge for connecting coding agents. Governed by a TSC with Cisco, Dell, Google, Oracle and Red Hat, operating as a Series of LF Projects, LLC.
| Maintainer | AGNTCY, a Series of LF Projects, LLC; TSC with Cisco, Dell, Google, Oracle, Red Hat |
|---|
| Spec status | Active, multi-component and evolving; OASF at 1.1.0. No single unified spec version |
|---|
| Transport | SLIM for agent-to-agent messaging; Directory over HTTP/registry APIs; interoperates with MCP and A2A |
|---|
| Adoption | Backed by five vendors on the TSC; production adoption outside that circle is limited |
|---|
| Problem solved | Discovery, identity, secure messaging and observability for agents spanning vendors and frameworks |
|---|
Watch out: Far less proven than MCP or A2A — it is a stack of several evolving components rather than one narrow spec, and adopting it means betting on all of them. The TSC is Cisco-led in practice (OASF is maintained by Cisco, and Outshift is Cisco's incubator), so vendor-neutrality is structural rather than demonstrated. SLIM competes directly with A2A for agent-to-agent messaging, which puts you in the middle of an unresolved overlap. OASF's 18-domain skills taxonomy is the kind of ontology that looks tidy in a diagram and gets argued about in practice. Wrong choice for a small team: the value is governance and identity at organizational scale, and if you do not have that problem you are carrying the complexity for nothing.
$0 for the open-source components. Cisco's commercial Outshift/Motific offerings around them are priced separately and were not verified.
· open source
ACP standardizes the checkout flow between a buyer, an AI agent and a merchant, so an agent can initiate and complete a purchase while the merchant keeps the customer relationship, the order of record and the payment processor they already use. It is jointly developed by Stripe and OpenAI under Apache-2.0, supports both REST and MCP integration patterns, and covers physical goods, digital goods, subscriptions and asynchronous purchases. Credentials never reach the agent: Stripe's Shared Payment Token gives a PCI-compliant handoff so the merchant charges without the agent seeing card details. ChatGPT was the first agent platform to integrate it. Note the acronym collision with the Agent Client Protocol.
| Maintainer | OpenAI and Stripe, jointly |
|---|
| Spec status | Active and in production; no public version number on the official site |
|---|
| Transport | REST over HTTPS, with an MCP integration pattern as an alternative |
|---|
| Adoption | ChatGPT is the first integrated agent platform; Stripe Shared Payment Token is the reference payment path |
|---|
| Problem solved | Agents cannot complete a purchase without either scraping checkout or holding the buyer's card details |
|---|
Watch out: Written by the two companies with the most to gain, and its practical value today is almost entirely "be sellable in ChatGPT" — that is a distribution deal wearing a specification's clothes, and the neutrality claim is untested. It also competes directly with Google's AP2 and with x402, so integrating one does not get you the others and there is no sign of convergence. Merchant-side implementation is real work (product feed, inventory truth, order status callbacks, returns) for traffic volumes most merchants cannot yet forecast. Wrong choice unless agent-originated purchases are already a measurable channel for you; waiting for the standards war to resolve costs almost nothing.
$0 for the specification (Apache-2.0). Payment processing fees are your processor's — Stripe's standard card rates apply if you use Shared Payment Token; those rates were not verified here.
· open source
AP2 tackles the authorization problem rather than the checkout flow: it defines Verifiable Digital Credentials — cryptographically signed intent, cart and payment mandates — that create a non-repudiable audit trail proving a human authorized this agent to spend this much on this thing. That matters for dispute resolution and chargebacks, where "my agent did it" is otherwise unanswerable. It is structured as an extension to A2A and the Universal Commerce Protocol, integrates with MCP for tooling and with agent frameworks including Google's ADK, and is Apache-2.0. Standardization is moving into the FIDO Alliance's Agentic Authentication and Payments technical working groups. Initial support is card-based pull payments, with e-wallets and push payments such as real-time bank transfers on the roadmap.
| Maintainer | Google, with standardization through FIDO Alliance Agentic Authentication and Payments working groups |
|---|
| Spec status | v0.2 is the most recent release published on the official site (16 Sept 2025); may be out of date — treat as pre-1.0 |
|---|
| Transport | Extension to A2A (JSON-RPC/gRPC/REST); Verifiable Digital Credentials as signed mandate objects |
|---|
| Adoption | Google ADK and A2A ecosystem; broad issuer/network adoption not demonstrated |
|---|
| Problem solved | No non-repudiable proof that a human authorized an autonomous agent's payment |
|---|
Watch out: Version confidence is low: the official site's most recent release marker is v0.2 announced 16 September 2025, which is a year stale for a space moving this fast, and its move into FIDO working groups means the shape may still change. It is also not standalone — it presumes A2A, which presumes you have already made that bet. Nothing works without issuer and network adoption, and card networks move on multi-year timelines, so the mandate chain is currently a well-designed artifact with few counterparties who will honour it. It competes head-on with OpenAI/Stripe's ACP for the same merchants. Wrong choice today unless you are a payments participant helping define the standard rather than a merchant trying to take orders.
$0 for the Apache-2.0 specification and SDK. Underlying payment network and processor fees are unchanged and separate.
· open source · beta
x402 puts the long-reserved HTTP 402 Payment Required status code to work: a server responds 402 with payment requirements, the client pays on-chain, retries with proof of payment, and gets the resource — no account, no API key, no subscription. That makes it the only one of the agent-payment protocols aimed at machine-to-machine micropayments for API and content access rather than retail checkout. The Linux Foundation announced the x402 Foundation to govern it. There are no protocol fees; participants pay only the underlying payment network's costs. The project publishes live volume figures — as displayed on the official site, 75.41 million transactions worth $24.24M across 94,060 buyers and 22,000 sellers over a trailing 30 days.
| Maintainer | x402 Foundation, announced by the Linux Foundation |
|---|
| Spec status | Active and in production use; no public version number on the official site |
|---|
| Transport | HTTP 402 status code plus payment headers on standard HTTP requests; on-chain settlement |
|---|
| Adoption | Self-reported 30-day figures on the official site: 75.41M transactions, $24.24M, 94,060 buyers, 22,000 sellers |
|---|
| Problem solved | API access requires accounts and API keys, which autonomous agents cannot obtain on their own |
|---|
Watch out: Settlement is on-chain, so adopting it means adopting stablecoins, wallets, key custody and the accounting and compliance treatment that follows — a hard stop for most enterprise finance and legal teams regardless of the engineering merits. The self-published volume figures come from the project's own dashboard and should be read as marketing, not audited data; average transaction value implied by those numbers is well under a dollar, which tells you the actual use cases are narrow. There is no fiat path, so it is disjoint from ACP and AP2 rather than complementary. Wrong choice for retail checkout, for anything requiring chargebacks or reversibility, or anywhere crypto is a policy non-starter.
Zero protocol fees per the official site; participants pay only nominal payment-network (blockchain) fees. No subscription or prepaid credit model.
· open source
WebMCP inverts the browser-agent relationship: instead of an agent scraping the DOM and simulating clicks, a page registers its own functionality as tools. The API centres on document.modelContext.registerTool(), where each tool carries a name, a natural-language description, a JSON Schema input schema and a JavaScript callback; agents call getTools() to discover and executeTool() to invoke, sharing context with the page's own UI so state stays consistent. It is incubated in the W3C Web Machine Learning Community Group with authors from Microsoft (Brandon Walderman, Leo Lee, Andrew Nolan) and Google (David Bokan, Khushal Sagar, Hannah Van Opstal). The specification draft is still evolving.
| Maintainer | W3C Web Machine Learning Community Group; contributors from Microsoft and Google |
|---|
| Spec status | Community Group incubation; draft specification still evolving, not a W3C Recommendation |
|---|
| Transport | In-page JavaScript API (document.modelContext) — no network transport; tool schemas use JSON Schema |
|---|
| Adoption | Experimental; no stable cross-browser shipping implementation confirmed |
|---|
| Problem solved | Browser agents driving web apps by DOM scraping and simulated clicks, which breaks on every redesign |
|---|
Watch out: This is an incubation, not a shipped web standard: it lives in a Community Group, the draft is explicitly still changing, and there is no interoperable cross-browser implementation you can target in production. Even if it ships, it inherits every prompt-injection problem of the open web — a page describes its own tools in natural language, which is an attacker-controlled string handed to an agent. It also only helps agents that run inside a browser with the API, which excludes server-side agents entirely. Wrong choice today for anything shipping this year; expose an MCP server or a documented HTTP API instead and revisit when a browser ships it unflagged.
$0. W3C community group incubation; the specification and explainer are freely published.
· open source · beta
UTCP is the deliberate counter-proposal to MCP: rather than running a wrapper server that proxies every tool call, an agent reads a manifest describing tools and then calls the underlying endpoint directly using its native protocol. It supports HTTP, CLI, gRPC and — notably — MCP itself as call targets, so it can front an MCP server rather than replace it. The claimed benefits follow from removing the hop: lower latency, no wrapper process to deploy and maintain, and reuse of the API's existing authentication rather than reimplementing auth in a server. Version 1.1, marked stable, last updated 30 November 2025, Apache-2.0 (API reference docs under MPL-2.0), with Python, TypeScript and Go libraries and a public tool registry.
| Maintainer | UTCP Contributors, github.com/universal-tool-calling-protocol; no foundation backing |
|---|
| Spec status | v1.1, marked stable; last documented update 30 Nov 2025 |
|---|
| Transport | Calls native protocols directly — HTTP, CLI, gRPC, and MCP as a target |
|---|
| Adoption | Python, TypeScript and Go libraries plus a public tool registry; not supported by any major agent host |
|---|
| Problem solved | Running and maintaining a wrapper MCP server in front of APIs that are already callable |
|---|
Watch out: The ecosystem gap is decisive: MCP is supported natively by Claude, VS Code, Copilot, Cursor and Goose, and UTCP is not, so choosing it means your tools do not appear in the clients your users already run. Direct calling also moves the security boundary — the agent holds credentials for the real endpoint instead of a server mediating access, which is simpler but strictly less controllable, and there is no equivalent of MCP's consent and sandboxing guidance. The last documented update was 30 November 2025, a long gap in this space. Governance is "UTCP Contributors" with no foundation backing. Wrong choice unless you control both the agent and the tools; if a third-party client has to connect, you need MCP.
$0. Apache-2.0 protocol and libraries; API reference documentation under MPL-2.0.
· open source