AI Agent Protocols in 2026: MCP vs A2A vs ACP vs WebMCP

TL;DR

Four protocols now describe most of how AI agents plug into the rest of the stack, and each one sits at a different layer. MCP connects an agent to tools and data. A2A connects an agent to other agents. ACP, in its current meaning (Zed’s Agent Client Protocol), connects a code editor to a coding agent. WebMCP lets a web page hand tools to an agent running inside the browser. MCP is the mature one: its 2026-07-28 specification made the core stateless and deprecated the old HTTP+SSE transport, and both MCP and A2A are now run by the Linux Foundation’s Agentic AI Foundation. This guide maps the four layers, covers what changed in MCP during 2026, adds a census of the official MCP Registry I ran for this page, and ends with a reading order.

One map, four layers

Each protocol standardizes a different connection, and a single agent session in 2026 can use three of them at once.

In a JetBrains IDE, the editor talks ACP to a Claude or Devin agent running as a subprocess. That agent calls tools through MCP servers, which the editor can hand over when it opens the session. One of those servers might be Chrome DevTools MCP, which can in turn call WebMCP tools that a page registered in the browser. If the task then has to leave your company, say to a supplier’s procurement agent, that hop is what A2A exists for.

Two unrelated protocols share the ACP acronym. IBM’s BeeAI project published an Agent Communication Protocol in 2025, a REST-based agent-to-agent protocol. In August 2025 it merged into A2A under the Linux Foundation. The ACP that ships in Zed, JetBrains and Devin Desktop today is the unrelated Agent Client Protocol, which Zed started the same month. Comparison posts from early 2025 usually mean IBM’s; anything about editors means Zed’s.

MCP in 2026: what changed under the tutorials

Anthropic open-sourced MCP in November 2024 and donated it to the Agentic AI Foundation on 9 December 2025, alongside Block’s goose and OpenAI’s AGENTS.md. The protocol keeps its own maintainers and spec process. That process has shipped five dated revisions:

The 2026-07-28 revision is the biggest break since launch. Every request now carries its protocol version and client capabilities, so a remote MCP server can sit behind an ordinary load balancer without sticky sessions. Servers that used to send their own requests back to the client (sampling, elicitation mid-call) now return an input_required result and let the client make the next move. Deprecated features get a minimum 12-month window under the new lifecycle policy, so clients that only speak the old HTTP+SSE transport keep working for now, but nobody should build a new server on it. (Server-sent events as such survive: Streamable HTTP can still stream a response as an SSE stream.)

The SDKs moved with it. The official Python package mcp hit 2.0 on release day and renamed its bundled high-level class from FastMCP to MCPServer, which will confuse anyone reading older tutorials. The standalone FastMCP project from Prefect, the one the FastMCP tutorial uses, shipped 4.0 on 31 August on top of the new spec, and the tutorial now targets it. The official Go SDK reached v1.0 in September 2025 and added the new revision in v1.7.0; for the raw tool-calling loop that all of this standardizes, the from-scratch Go agent tutorial builds one without any SDK.

One thing to unlearn from 2024-era material: MCP’s remote transport isn’t HTTP+SSE anymore. Streamable HTTP replaced it in March 2025, and the 2026-07-28 revision formally lists HTTP+SSE as deprecated; the ACP guide and WebMCP tutorial now describe MCP’s transports that way.

Client setups have moved as well. The Gemini CLI tutorial predates a big change: Google stopped serving Gemini CLI requests for individual accounts on 18 June 2026. The CLI still works with Code Assist Standard or Enterprise licences and paid API keys, and consumer users were pointed to Antigravity CLI, whose MCP config paths are covered in the Antigravity vs Claude Code comparison.

What’s in the official MCP Registry

The official MCP Registry opened in preview on 8 September 2025, and its docs still call it a preview. It hosts only metadata: a server.json per server that points at a package (npm, PyPI, NuGet, crates.io, an OCI image on Docker Hub, GHCR or another container registry, or an MCPB bundle) or at a remote URL. What it verifies is ownership, meaning the namespace plus a back-reference inside any linked package; nothing checks what a remote URL does. A name under io.github.alice/ needs a GitHub login as alice, and com.example/ needs a DNS TXT record or an HTTP file on example.com (authentication guide). Security scanning is left to the package registries and to “downstream aggregators”, the marketplaces the docs expect clients to use instead of the registry itself.

To see what that design produces, I crawled the registry’s public API on 4 October 2026. The crawler pages through GET /v0.1/servers?version=latest&limit=100 (392 pages) and saves one JSON line per server. The counting loop, trimmed to its main counters:

OFFICIAL = "io.modelcontextprotocol.registry/official"
rows = [json.loads(line) for line in open("tmp/registry_latest_1004.jsonl")]
active = [r for r in rows if r["_meta"][OFFICIAL]["status"] == "active"]

for r in active:
    s = r["server"]
    remote = {x["type"] for x in s.get("remotes") or []}
    local = {(p.get("transport") or {}).get("type", "stdio") for p in s.get("packages") or []}
    both = remote | local
    c["remote endpoint only"] += bool(remote) and not local
    c["installable package only"] += bool(local) and not remote
    c["advertises an SSE transport"] += "sse" in both
    no_repo = not (s.get("repository") or {}).get("url")
    c["remote-only AND no source repository"] += bool(remote) and not local and no_repo
    namespaces[s["name"].split("/")[0]] += 1

The full script prints:

entries: 39144  status: {'active': 38672, 'deprecated': 472}
remote endpoint only                        22386  (57.9%)
installable package only                    13944  (36.1%)
both                                         1882  ( 4.9%)
advertises an SSE transport                  1103  ( 2.9%)
SSE is its only transport                     721  ( 1.9%)
no source repository listed                 10378  (26.8%)
remote-only AND no source repository         9503  (24.6%)
remote URL on a trycloudflare.com tunnel      149  ( 0.4%)
GitHub-user namespace (io.github.*)         25234  (65.3%)
latest version published since 2026-07-28   25272  (65.3%)
  ...of those, advertising SSE: 433 (1.7% of 25272)
package registries: {'npm': 10201, 'pypi': 4079, 'oci': 1023, 'mcpb': 974, 'nuget': 134}
namespaces: 22997 (20787 with one server); top 10 hold 7441 servers
largest namespaces: [2365, 1716, 1113, 802, 375]
remote hosts: [('workers.dev', 3051), ('pipeworx.io', 1716), ('mcp.ai', 1115), ('vercel.app', 310), ('m2mcent.com', 276)]

Of the 38,672 active servers, 57.9% are nothing but a URL and 36.1% are only an installable package; 4.9% offer both. Among packages, npm leads PyPI by 10,201 to 4,079, so npx is still how most local servers ship, and a Python server like the one in the FastMCP tutorial is in the minority even among local ones. SSE is rare: 1,103 servers (2.9%) still advertise it and 721 offer nothing else, and of the 25,272 servers whose latest version came out on or after 28 July 2026, the day the spec formally deprecated HTTP+SSE, 433 (1.7%) still list it.

The number I’d worry about is 9,503. That’s how many active servers, about a quarter of the registry, are remote-only and list no source repository, leaving a name, a description and a URL to judge them by. Namespace verification tells you which GitHub account or domain published such a listing, and nothing about how the endpoint handles the prompts and data an agent sends it.

A handful of publishers account for a large slice. Of 22,997 namespaces, 20,787 hold a single server, yet the ten largest hold 7,441, or 19% of everything active. The biggest is one GitHub account that published 2,365 single-purpose servers in September, all served by one Cloudflare Workers app and nearly all linking the same public repository; they’re tiny utilities such as an ISO country-code record or an XML entity counter. Next come pipeworx.io, a gateway with 1,716 listings that each wrap a public API, and a publisher whose 1,113 listings point at api.mcp.ai and describe pay-per-query lookups, mostly in Brazilian government records. Both link a public repository for every listing.

The listings churn fast, too: 14,827 active servers got their latest version in September 2026 alone. And 149 listings point at trycloudflare.com, the domain of Cloudflare’s quick tunnels, which Cloudflare’s docs describe as “for testing and development”, with “no uptime guarantee” and a hostname that changes every time a tunnel starts.

To check whether the URLs answer at all, I sent one MCP initialize request, the handshake every pre-July client still sends, to each of 300 remote-only servers drawn at random with a fixed seed, so the sample is reproducible. The probe, trimmed:

INIT = json.dumps({"jsonrpc": "2.0", "id": 1, "method": "initialize", "params": {
    "protocolVersion": "2025-06-18", "capabilities": {},
    "clientInfo": {"name": "registry-census", "version": "0.1"}}}).encode()

def probe(server):
    req = urllib.request.Request(server["remotes"][0]["url"], data=INIT, method="POST", headers={
        "Content-Type": "application/json",
        "Accept": "application/json, text/event-stream"})
    try:
        with urllib.request.urlopen(req, timeout=15) as resp:
            return f"HTTP {resp.status}"
    except urllib.error.HTTPError as e:
        return f"HTTP {e.code}"
    except Exception:  # DNS failure, refused connection, TLS error, timeout
        return "no HTTP response"

Output, which came back the same on three runs:

remote-only active servers: 22386, sampled: 300
200 OK                            181  (60.3%)
401/403 (auth required)            75  (25.0%)
404/410 (endpoint gone)            11  ( 3.7%)
402 (payment required)             10  ( 3.3%)
no HTTP response                    9  ( 3.0%)
5xx (server error)                  7  ( 2.3%)
other 4xx/3xx                       5  ( 1.7%)
templated URL                       2  ( 0.7%)

Most listed endpoints are alive: 181 returned HTTP 200 and 75 asked for credentials, 85% between them. But 27 of the 300, roughly one in eleven, returned 404 or 410, failed with a server error or never answered. A 200 only means the endpoint returned success to an initialize request, which says nothing about whether its tools match the listing. The ten 402 responses come from servers that want payment before they’ll talk.

My read is that the registry is a phone book, and its maintainers say as much: the docs call the metadata “deliberately unopinionated” and say host applications shouldn’t consume the registry directly. Choose servers through a curated layer on top of it (your client’s directory, GitHub’s MCP Registry with its few hundred entries, or an enterprise allowlist), prefer listings with a public repository, and treat a remote-only server with no source like any unknown API that will see your prompts.

A2A: the agent-to-agent layer

A2A is the one protocol on the map this blog hasn’t covered yet, and it has grown well past its Google origins. Google announced it in April 2025, handed it to the Linux Foundation that June, absorbed IBM’s ACP in August, and shipped v1.0 on 12 March 2026 with signed Agent Cards, multi-tenancy, and three bindings (JSON-RPC, gRPC, HTTP+JSON). On 17 August it joined the Agentic AI Foundation, so MCP and A2A now share a steward.

An MCP server exposes functions with schemas, and the calling agent decides when to use them. An A2A peer is another agent: it advertises skills in an Agent Card, accepts a task, may run for hours, asks for more input, and returns artifacts. If the thing on the other end can be described as a list of typed functions, use MCP. If it runs its own model on someone else’s behalf, A2A fits better.

My take is that most teams shipping a single product won’t need A2A this year. A coding agent, a support bot or an internal data assistant talks to tools, and other companies’ agents rarely enter the picture. A2A earns its keep at organizational boundaries such as procurement, travel and supply chains, anywhere two companies want their agents to negotiate without sharing code. Official SDKs already exist for Python, Go, Java, JavaScript, .NET and Rust, and an A2A tutorial is next on this blog’s list.

ACP: any agent in any editor

The Agent Client Protocol guide describes ACP as “LSP for AI agents”, and that’s the right mental model. Before it, every editor needed a custom integration for every agent. With it, the editor launches the agent as a subprocess, they exchange JSON-RPC over stdio, and a Claude, Gemini or Codex agent runs in Zed, JetBrains or Neovim without either side writing glue code for the other.

The protocol has settled since that guide was written. Zed and JetBrains govern it jointly and describe the goal as an independent foundation. The stable v1 schema reached 1.24.1 on 30 September, a v2 draft is in alpha, and the ACP Registry has listed agents since January. Devin Desktop shows the MCP handoff in a shipping product: per Devin’s ACP docs, the editor passes the working directory and any configured MCP servers to the agent when it opens a session. That’s the stacking from the map above. Remote transport over HTTP or WebSocket is still only a proposal, so ACP remains a local-machine protocol for now.

WebMCP and the browser

WebMCP takes MCP’s tool shape into the web page. A site either annotates its existing forms or calls document.modelContext.registerTool(), and an agent running in the browser can call those tools directly instead of screen-scraping the page and clicking buttons. The draft is edited by people from Google and Microsoft in a W3C community group.

It’s still early. Chrome ran a developer trial from M146 and opened an origin trial for M149 to M156. On 28 September the Chrome team filed an intent to extend that trial through M162, which doesn’t reach stable until early 2027. The other engines aren’t on board yet: Mozilla’s standards position is neutral, and WebKit’s is oppose, citing privacy, security and API-design concerns. The practical way to test WebMCP tools today is through Chrome DevTools MCP, which reached v1.0 in May and has experimental list_webmcp_tools and execute_webmcp_tool tools (enabled with --categoryExperimentalWebmcp=true), so a terminal agent like Claude Code can exercise a page’s tools the same way an in-browser agent would.

Security: known attacks and current mitigations

Every protocol here moves untrusted text into a model’s context and gives the model a way to act on it. The spec work since 2025 has hardened authentication and transport, but models still act on whatever a tool tells them. The documented problems fall into four groups:

1. Tool poisoning and rug pulls. Invariant Labs showed in April 2025 that a malicious tool description can carry hidden instructions, and that a server can change its tool definitions after you’ve approved them.
2. Prompt injection through tool output. In May 2025 the same team got the GitHub MCP server to leak private repository data through an issue planted in a public repo. The server behaved as designed; the leak came from the agent obeying instructions planted in the issue.
3. Token and proxy mistakes. The spec’s security best practices now say servers “MUST NOT accept any tokens that were not explicitly issued for the MCP server”, and require per-client consent in proxies to avoid confused-deputy attacks.
4. Plain software bugs in MCP plumbing. mcp-remote had a CVSS 9.6 command injection (CVE-2025-6514), the MCP Inspector a 9.4 RCE (CVE-2025-49596), and Anthropic’s own git server had three chainable flaws, fully fixed by December 2025 and disclosed in January 2026. The LiteLLM vulnerability roundup covers a case close to home: MCP test endpoints that spawned arbitrary stdio commands.

The supply-chain angle is newer. MCP config files are now a place attackers look, which is why the Perplexity Bumblebee review spends a section on a scanner that inventories them. One detail from that story: the Miasma worm it describes planted itself in agent hooks, which are a different mechanism from MCP servers, and the Claude Code hooks guide explains how hooks run.

Today’s mitigations are mostly configuration. Pin tool definitions: Claude’s MCP connector added a mcp-client-2026-09-15 beta header that records and pins a server’s tool list so a server can’t swap tools mid-conversation, and GitHub added enterprise MCP allowlists in August. Curate instead of allowing everything, as Google’s Jules does with its short list of audited servers (Jules review). Scope servers to the agents that need them, since Claude Code subagents inherit every configured server by default. And keep a human confirmation on anything that writes, which is the thread running through the AI agent guardrails piece.

Reading order

For a developer starting from zero, this order works:

1. FastMCP in Python: build a small MCP server with tools, a resource and a prompt, then add HTTP and OAuth.
2. Chrome DevTools MCP: use a large real-world server and feel how dozens of tool definitions crowd the context window.
3. Context engineering: what that crowding costs and how to keep tool output from drowning the agent.
4. Agent Client Protocol: run the same agent in several editors and pass your MCP servers through.
5. WebMCP tutorial: expose your own site’s actions as tools.
6. Perplexity Bumblebee and the LiteLLM CVEs: what goes wrong once these servers sit on real machines.
7. Mem0 vs Cognee vs Letta: memory systems that ship as MCP servers, for when an agent needs to remember across sessions.

If you only have an hour, read 1, 2 and 6.

What’s next

Three guides are still missing from this set. There’s no A2A tutorial yet, and a Python or Go walkthrough of an Agent Card plus a long-running task is the obvious next piece. The 2026-07-28 spec also deserves a migration guide: moving a server off sessions and SSE, implementing server/discover, and switching OAuth clients from dynamic registration to Client ID Metadata Documents. MCP Apps, the first official extension, which lets a server return interactive UI inside Claude, ChatGPT or VS Code, is a third candidate. Beyond those, the registry census above invites a follow-up on the quarter of listed servers that are remote-only and list no source repository: who runs them and how they handle the data agents send.

FAQ

What is the difference between MCP and A2A?

MCP connects an agent to tools and data: the server exposes typed functions and the agent decides when to call them. A2A connects an agent to another agent that has its own model and judgment, which can accept a task, run for a long time and return artifacts. Both are now governed by the Agentic AI Foundation under the Linux Foundation, and they’re designed to be used together.

Is A2A replacing MCP?

No. They cover different connections, and the A2A project describes them as complementary. An agent typically uses MCP internally to reach its tools and A2A externally to hand work to other agents. IBM’s older Agent Communication Protocol is the one that was absorbed, into A2A, in August 2025.

What does ACP stand for in AI agents?

Two different things. In 2025 it often meant IBM’s Agent Communication Protocol, which merged into A2A. Today it usually means Zed’s Agent Client Protocol, which connects code editors such as Zed and JetBrains IDEs to coding agents such as Claude, Gemini and Codex over JSON-RPC.

Does MCP still use SSE?

Not as its own transport. Streamable HTTP replaced the HTTP+SSE transport in the 2025-03-26 spec, and the 2026-07-28 revision formally lists HTTP+SSE as deprecated, with a minimum 12-month window before removal. Streamable HTTP can still stream responses as server-sent events, so SSE survives as a response format. In my 4 October 2026 crawl of the official MCP Registry, 2.9% of active servers still advertised an SSE transport.

How many MCP servers are there?

The official MCP Registry listed 38,672 active servers on 4 October 2026, out of 39,144 entries including deprecated ones. That’s an upper bound on distinct, maintained servers: the ten largest publishers account for 7,441 of them, mostly bulk-generated listings served from a handful of backends, and some endpoints no longer answer. It’s also incomplete, because publishing to the registry is optional and plenty of open-source servers on GitHub never do. Curated directories are far smaller; GitHub’s MCP Registry lists a few hundred.

Who owns MCP now?

Anthropic created it and donated it to the Agentic AI Foundation, a Linux Foundation fund co-founded with Block and OpenAI, on 9 December 2025. MCP’s maintainers still run its technical direction through the public spec-proposal process.

Sources

• MCP specification changelog, 2026-07-28: what the current revision changed and deprecated
• MCP blog: the 2026-07-28 release: release post and lifecycle policy
• MCP security best practices (2026-07-28): token passthrough, confused deputy and related rules
• Official MCP Registry and its preview announcement: data source for the census in this guide
• MCP Registry docs: about and authentication: what the registry hosts, how namespaces are verified, and where security scanning is delegated
• Cloudflare docs: Quick Tunnels: why trycloudflare.com endpoints are temporary
• Linux Foundation: Agentic AI Foundation formed: MCP’s governance since December 2025
• A2A v1.0 announcement and A2A joins the AAIF: A2A status
• LF AI & Data: ACP joins forces with A2A: IBM’s Agent Communication Protocol merger
• Agent Client Protocol governance: Zed and JetBrains stewardship
• Chrome for Developers: WebMCP origin trial: browser status
• Invariant Labs: tool poisoning attacks and GitHub MCP exploit: the core MCP security research
• Claude MCP connector docs: tool-list pinning with mcp-client-2026-09-15
• Google Developers Blog: transitioning Gemini CLI to Antigravity CLI: Gemini CLI consumer shutdown

Bottom line

The agent-to-tool layer is mostly settled: MCP won it, and the 2026-07-28 revision made it much easier to run remotely at scale. A2A is the credible answer for agent-to-agent work across companies, ACP for editors, and WebMCP is a promising browser experiment that isn’t expected in stable Chrome before 2027. The registry numbers add a caveat to MCP’s win: there are tens of thousands of servers to choose from, and the registry checks who published each one, not what it does. If you build one thing this quarter, make it a well-scoped MCP server on Streamable HTTP with pinned, reviewed tools; that choice is the least likely of any here to need redoing next year.