BridgeToAgent
Get the kit — $49
All posts
Explainer7 min read

MCP vs A2A vs agents.json vs WebMCP — the standards map for site owners

Four standards keep showing up in agent-readiness discussions — MCP, A2A, agents.json, WebMCP. They solve different layers of the same overall problem. This post is the orientation map — what each one is, who designed it, where it lives on the network, and which one a public website actually needs to ship in 2026.

BridgeToAgentEditorial team

MCP vs A2A vs agents.json vs WebMCP — the standards map for site owners

If you've been reading vendor blogs about agent-readiness in 2026, you've likely hit four acronyms in four different contexts and walked away unsure which one applies to your website. The standards aren't competing — they sit at different layers of the same overall problem. But the docs treat them as separate worlds, and the result is site owners trying to decide between standards that don't actually overlap.

This post is the orientation map. What each standard is, who designed it, where it lives on the network, what problem it solves, and — for a public website — which ones you actually need to ship.

The 30-second version

StandardLives atWho reads itPublic-website relevance
MCP (Model Context Protocol)A server you runLLM applications via SDKLow — server-side, not public-web
A2A (Agent-to-Agent)Inter-agent communication channelAgents communicating with other agentsNear-zero for static sites
agents.jsonhttps://yourdomain.com/agents.jsonWeb agents discovering site actionsHigh — direct install
WebMCPHTML annotations on your pagesAgents acting through a browserEmerging — Chrome 146+

If you build a public-facing website and want it to be agent-ready, agents.json is the one to ship. MCP and A2A solve adjacent problems for adjacent audiences. WebMCP is the future-state for the in-browser layer but isn't required in 2026.

The rest of this post unpacks why each fits where it does, and walks the cases where MCP or A2A actually do matter for site owners.

MCP — Model Context Protocol

Designed by: Anthropic, open-spec at modelcontextprotocol.io.

Released: Late 2024, stabilized through 2025.

What it is: A protocol for LLM applications to connect to data sources and tools. An MCP server exposes resources, tools, and prompts; an MCP client (typically an LLM application like Claude Desktop, Cursor, or a custom integration) connects to the server and uses what it exposes. The transport is stdio or Streamable HTTP; the wire format is JSON-RPC.

Where it lives: On a server you run. The server can be local (Claude Desktop launches it as a subprocess) or remote (HTTP-accessible). The server speaks MCP; the LLM application speaks MCP back.

What problem it solves: Giving an LLM controlled, structured access to data and tools that aren't in its training. Examples: an MCP server for your company's Postgres database, an MCP server for your internal Confluence wiki, an MCP server for your team's calendar.

Does a public website need to ship MCP? Generally no. MCP servers are for the data your team works with internally, or for SaaS products that want to integrate into the LLM-application ecosystem. A static or e-commerce public site doesn't have a use case that maps to MCP.

The exception: if your business is a SaaS that other AI applications want to integrate with — analytics tool, CRM, project management — shipping an MCP server is high-leverage. It gets you native distribution into Claude Desktop, Cursor, custom Claude/GPT applications, and the growing list of MCP-aware tools.

A2A — Agent-to-Agent

Designed by: Google, open-spec at github.com/google/A2A.

Released: Early 2025.

What it is: A protocol for autonomous agents to communicate with other autonomous agents. Each agent advertises an "Agent Card" describing its capabilities; agents discover each other and delegate tasks via A2A messages. The transport is HTTPS with JSON payloads.

Where it lives: Agent-to-agent on a network. Most A2A deployments are inside agentic frameworks (an orchestrator agent delegating sub-tasks to specialized agents), not on the open public web.

What problem it solves: Multi-agent coordination. Example: a "shopping assistant" agent delegates "find the best price for X" to a "price-comparison" agent, which delegates "fetch product details" to a "site-reader" agent. A2A is the protocol they speak to each other.

Does a public website need to ship A2A? Near-zero. A2A is a protocol for agents talking to other agents — not for public sites talking to agents. If you're building an agentic platform, A2A matters. If you're building a public-facing website, it doesn't.

The exception: if your business operates an agent that other businesses' agents would want to call — for example, a "tax calculation" agent that retail-site agents delegate to — A2A is your distribution layer. Again, this is platform-builder territory, not public-site territory.

agents.json

Designed by: Wild Card AI + community, open-spec at github.com/wild-card-ai/agents-json.

Released: Mid-2024, evolved through 2025-2026.

What it is: A JSON file at your domain root declaring which actions on your site are agent-callable. Each action has a name, description, URL, HTTP method, and typed parameters. Agents reading the file know what they can do on your site without simulating a human in a browser.

Where it lives: At https://yourdomain.com/agents.json. Public-web discoverable.

What problem it solves: Letting agents act on a public website. Without agents.json, an agent that wants to search your catalog or submit a contact form has to render the page, identify the form, fill it field-by-field. With agents.json, the agent calls a typed action directly — same outcome, lower cost, higher reliability.

Does a public website need to ship agents.json? Yes. This is the standard that makes a public website agent-actionable in 2026. Atlas, transactional agents, and the integration layers built on top of LLMs all read it. The corresponding Lighthouse audits (agents-json-present + agents-json-actions-typed) check that you ship a valid one.

Companion files: llms.txt (for citation-layer reading) and agent-instructions.md (for behavioral rules) sit alongside agents.json in the same three-file mental model. The primer on the three layers covers what each one does.

WebMCP

Designed by: The same MCP community that designed MCP, extending the protocol into the browser. Open-spec, with reference implementations in Chrome (since version 146, Feb 2026) and Edge (147, March 2026).

Released: Spec published 2025; first browser support Feb 2026.

What it is: HTML-level annotations on interactive elements declaring them as agent-callable actions. A <form> with data-mcp-action="search" and typed data-mcp-param attributes tells the browser's MCP layer that the form is a search action with declared parameters. Agents running in the browser can call the action via the MCP protocol, similar to how they'd call a server-side MCP tool.

Where it lives: In your page HTML. The browser exposes a window.mcp API to detect annotated elements; agents interacting with the page consume them.

What problem it solves: Bridging in-page actions to the MCP ecosystem. agents.json declares server-side actions; WebMCP declares in-page actions. The two are complementary — one is for things you'd call as an API, the other is for things that require the rendered page state (multi-step forms, dynamic UI, post-render computation).

Does a public website need to ship WebMCP? Not yet in mid-2026. The Lighthouse Agentic Browsing audit weighs webmcp-annotations low because the annotation conventions are still moving. The right answer for most sites is to monitor the spec and revisit when the conventions stabilize. The Cluster-2 pillar's Audit 9 section covers when to ship and when to wait.

Practical 2026 reality: Sites that ship WebMCP annotations today get a small audit-score lift and a signal of forward-leaning agent-readiness. The labor isn't load-bearing — annotation patterns will shift before they stabilize.

How the four fit together

Drawing a network diagram of where each standard lives:

                Public website
                      │
                      ├─ /agents.json         (Public-web manifest — REQUIRED 2026)
                      ├─ /llms.txt            (Reading layer manifest)
                      ├─ /agent-instructions.md (Behavioral runbook)
                      ├─ <head> auto-discovery <link> tags
                      └─ HTML page body
                            └─ WebMCP annotations    (Emerging — Chrome 146+)


                Site owner's MCP server
                      ├─ Tools (database queries, ticket creation, etc.)
                      ├─ Resources (internal docs)
                      └─ Prompts (preset workflows)
                            │
                            └─ Read by → LLM application (Claude Desktop, Cursor, etc.)


                Agent ecosystem
                      └─ A2A protocol
                            └─ Agent-to-agent communication (inter-agent only)

The four standards don't compete. They occupy different layers:

  • agents.json + llms.txt + agent-instructions.md = public-web layer. Discoverable by any agent that visits your domain.
  • WebMCP = in-page layer. Same audience as agents.json but for actions that need the rendered page state.
  • MCP servers = private-tooling layer. Connects LLM applications to your private data, not to your public website.
  • A2A = inter-agent layer. Coordinates multiple agents, not site-to-agent.

For a public website, ship the three kit files. For a SaaS that other AI applications want to integrate with, ship an MCP server. For an agentic platform, ship A2A. The four are additive, not alternatives.

Why the confusion exists

Vendor blogs in 2026 conflate the four standards because each vendor has a horse in each race:

  • Anthropic ships MCP (their protocol) and Atlas-equivalent tooling reads agents.json (the public-web standard).
  • Google ships A2A (their protocol) and Gemini reads public-web standards.
  • OpenAI ships Atlas (which reads agents.json) and is rumored to be shipping a competing public-web manifest.
  • Microsoft Copilot reads everything it can find.

The vendor incentive is to position their own standard as the central one. The site-owner reality is simpler: there's one layer that affects your public website, and it's the agents.json + llms.txt + agent-instructions.md trio. The other layers exist; they're just not yours to ship.

What to actually do

If you run a public website:

  1. Ship agents.json — the canonical install. The agents.json primer covers the file shape; the WordPress install path and the Shopify install paths cover the platform-specific upload step.
  2. Ship llms.txt alongside — the citation-layer file. Same install path, different content. The reference doc covers the shape.
  3. Ship agent-instructions.md alongside — the runbook. The reference doc covers the three sections.
  4. Add the three auto-discovery <link> tags to your homepage <head> — so agents that don't probe root paths blindly can still find the kit files. The auto-discovery audit deep-dive walks the paste.
  5. Skip WebMCP for now — the annotation conventions aren't settled. Revisit in Q4 2026 or when the spec stabilizes.
  6. Skip MCP and A2A — neither applies to a public website.

This is roughly two minutes of generation time plus five to fifteen minutes of upload time per platform. The free Lighthouse Agentic Browsing audit confirms whether the install succeeded.

Related

Keep reading

All posts →