A2A, WebMCP, and MCP: Three Agent Protocols, Three Layers, One Deploy Pipeline

A developer types "deploy the staging branch and tell me when it's healthy" into a chat window, and ten minutes later the service is live, the migration ran, and the logs say so. Nothing about that sentence mentions a protocol — but everything about making it reliable does. Behind "deploy from chat" sits a stack of agent protocols that settled into their final shape in 2026, and the teams shipping agent-operated infrastructure keep tripping over the same question: which protocol does what, and where does my tool surface belong?

The short answer is that there is no single winner because there was never a single contest. Three specs cover three different layers, and a deploy-from-chat platform touches each one differently. Here is the map first, then the reasoning behind every placement.

The 30-second map: tools, teammates, tabs​

Mnemonic: MCP gives your agent hands, A2A gives it colleagues, WebMCP gives a web page a voice. A platform that confuses the three ends up either screen-scraping its own dashboard to deploy (wrong layer) or building a bespoke RPC framework for agent-to-agent handoff (reinvented layer). The rest of this post puts a concrete artifact behind each row: the tool list, the delegation walkthrough, and the explicit ruling-out.

MCP: the tool layer your deploy server already speaks​

The Model Context Protocol started at Anthropic in November 2024 as an open spec for the N×M integration problem: every agent needing a custom connector to every data source and tool. OpenAI adopted it in March 2025, and on December 9, 2025, Anthropic donated it to the Agentic AI Foundation, a Linux Foundation directed fund co-founded by Anthropic, Block, and OpenAI. Vendor-neutral governance plus every major AI platform shipping native support is why MCP crossed 97 million monthly SDK downloads and 10,000+ active servers by early 2026 — the network effect is locked in, and the official registry (in preview since September 2025) is where servers get discovered.

The spec has kept moving under that governance. The March 2025 revision added Streamable HTTP transport and an OAuth authorization framework for remote servers; June 2025 brought structured tool output and RFC 8707 resource binding; and the July 28, 2026 revision is the stateless rewrite — no initialize handshake, no Mcp-Session-Id, every request self-contained over Streamable HTTP with Mcp-Method/Mcp-Name routing headers, full JSON Schema 2020-12 for tool schemas, and authorization hardened around OAuth 2.1 and OIDC patterns. For a platform audience, that last line is the one that matters: a remote, multi-tenant MCP server with real auth is now a spec-shaped thing, not a bespoke hack.

So what does a deploy-from-chat MCP server concretely expose? Typed tools with JSON schemas, roughly this set:

• deploy — given a repo, branch, and environment, start a build and rollout; returns a deployment ID, not a prose summary.
• deployment-status — poll or stream the rollout state machine behind that ID.
• tail-logs — stream recent logs for a service, bounded by line count and time window.
• describe-service — return the machine-readable state: replicas, image digest, health, config hash.
• promote / rollback — move a known-good artifact between environments or revert to the previous digest.

Notice what every tool returns: structured data the agent can branch on, not chat text a human has to read. describe-service returning an image digest and a health enum is what lets the agent decide "healthy, report back" versus "degraded, roll back" without asking the human. That is the whole game for MCP as infrastructure surface: the deploy server stops being a CLI the agent shells out to and becomes a typed API the agent reasons over — with OAuth 2.1 scoping which tenant's apps each token may touch.

If you build one thing from this post, it is this row. MCP is the only layer of the three where "ship it this quarter" is the right advice, because it is the only one that is simultaneously a stable standard, natively spoken by every agent runtime your users already run, and pointed at exactly the server-side operations a deploy pipeline performs.

A2A: the delegation layer for when one agent isn't enough​

Google launched the Agent2Agent protocol in April 2025, donated it to the Linux Foundation that June (absorbing IBM's competing Agent Communication Protocol along the way), and shipped v1.0 in March 2026 with 150+ participating organizations — AWS, Microsoft, Salesforce, SAP, ServiceNow, Anthropic among them. In August 2026, A2A formally joined the Agentic AI Foundation alongside MCP, so both halves of the agent stack now share one vendor-neutral home. The "which protocol wins" debate ended the way protocol debates should: with a merger, not a victor.

A2A's mechanics are deliberately boring, which is a compliment. An agent publishes an Agent Card — a JSON discovery document at /.well-known/agent-card.json advertising its skills, endpoint, input/output formats, and auth schemes. A client agent sends tasks to it over JSON-RPC 2.0 on HTTPS, with Server-Sent Events for streaming updates. Long-running work is modeled as a task with an explicit lifecycle — submitted, working, completed, failed, canceled, plus input-required when the remote agent needs something from the caller. Cancellation, structured results, and auth negotiation are all first-class instead of everybody's bespoke convention.

Here is the concrete walkthrough the TODO-spec promised — where A2A slots into a deploy pipeline that MCP alone cannot cover. Your deploy agent (an MCP client holding the deploy tools from the previous section) receives "ship v2.4 to production." The rollout plan includes a Postgres schema migration, and migrations are owned by a specialist agent operated by the data team, with its own review policy and its own blast-radius limits. Instead of the deploy agent calling migration tools directly — borrowing authority it should not have — it does this:

1. Discover: fetch the migration agent's Agent Card, confirm it advertises a run-migration skill accepting a migration bundle plus a dry-run flag.
2. Delegate: send a task with the bundle, dry-run first. The task sits in working while the specialist runs checks the deploy agent knows nothing about.
3. Resolve: the task returns completed with a structured receipt (migration ID, duration, verification queries passed) — or input-required if a destructive statement needs human approval, which propagates back up the chain instead of stalling silently.

MCP is vertical (agent reaches down into tools); A2A is horizontal (agent reaches across to a peer). The deploy agent never learns how migrations work, and the migration agent never learns how deploys work. Each keeps its own tools, its own policy, its own audit trail — the task receipt is the seam between them.

Should you ship A2A today? Probably not this quarter. The honest trigger is organizational, not technical: A2A pays off the day two agents owned by two different trust domains need to cooperate — your deploy agent and someone else's migration, security-review, or cost-approval agent. Until then, a single agent with well-scoped MCP tools is simpler and has fewer moving parts. What you should do now is cheaper: keep your agent's capabilities factored as discrete skills with typed inputs and receipts, so that when the second agent shows up, promoting a skill to an Agent Card is paperwork, not a rewrite. Design the seam; defer the protocol.

WebMCP: the page layer — powerful, and wrong for infra ops​

WebMCP is the genuinely new idea of the three: a browser-native API through which a live web page exposes structured, typed tools to an agent — registerTool() on the page's model context — so the agent can act on the page's own capabilities instead of scraping its DOM or screenshotting pixels. Coverage pegs the token savings around 89% versus screenshot-based operation, and the direction of travel is one-directional: web app exposes tools, agent calls them, with the human in the loop in the tab where they already are. Think of it as MCP for the storefront while server-side MCP handles the back office.

The status line requires precision, because it is doing a lot of work in the build/skip decision. WebMCP is a W3C Draft Community Group Report from the Web Machine Learning Community Group, edited by Microsoft and Google engineers — explicitly not a W3C Standard and not on the Standards Track, with parts of the agent-side surface still marked TODO. It previewed behind a flag in Chrome 146 Canary in February 2026 and remains pre-standardization: method names can still change, and production use is premature. Real sites are experimenting — WordPress Playground wired up agent tools via a WebMCP proxy, and Turkish Airlines documented a production pilot — but experimenting is the right verb.

Now the ruling, stated plainly because the TODO spec demands it: WebMCP is the wrong layer for infrastructure operations. A deploy pipeline has no browser tab. deploy, rollback, and tail-logs execute against APIs and clusters, not against a rendered page holding an authenticated session — there is nothing for registerTool() to attach to, and routing a deploy through a page that happens to have buttons for it would be screen-scraping with extra steps and a draft-spec dependency. The token-efficiency argument does not transfer either: the 89% savings measure "agent operates a GUI" versus "agent calls page tools," and your deploy agent was never going to operate a GUI.

The one place WebMCP could legitimately fit a platform like bex is the operator console: the dashboard page itself exposing "restart this service" or "open this log stream" as page tools, so an agent assisting a human already looking at the dashboard acts in context. That is a storefront enhancement for a human-in-the-loop workflow — worth tracking as the draft matures, worth zero engineering quarters today. For the deploy path itself: skip, without guilt.

What to build on each layer: the decision table​

Pulling the three rulings into one build plan for a deploy-from-chat platform:

Two failure modes to avoid, one per tempting mistake. First, do not build a custom JSON API "for agents" alongside your MCP server — every agent runtime already speaks MCP natively, and a bespoke endpoint is a second contract to version, secure, and document for zero additional reach. Second, do not adopt A2A because multi-agent sounds like the future; adopt it when you can name the two agents and the trust boundary between them. Protocols are answers to coordination problems — no coordination problem, no protocol.

One stack, three jobs, no winner — and that is the point​

Six months ago a reasonable person could ask "MCP or A2A?" the way people once asked "REST or GraphQL?" — as if one had to win. With both protocols now under the Agentic AI Foundation and WebMCP incubating in the open at W3C, 2026 answered the question differently: the stack has three layers because agents genuinely do three things. They use tools, they delegate to each other, and they act inside web pages. A deploy-from-chat platform lives or dies on the first, grows into the second, and can safely ignore the third until the standard — and the use case — exists.

The practical upshot is a short roadmap: typed MCP tools with real auth now, skill-shaped seams for A2A delegation later, and no WebMCP on the deploy path. Ship the hands, plan for colleagues, leave the talking web pages to the storefronts that need them.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with machine-readable infrastructure state your agents can operate. Star the repo on GitHub or deploy your first app today.