MCP vs A2A vs WebMCP: How Appnalysis Uses All Three

Appnalysis now implements all three AI agent protocols live in production: MCP (Model Context Protocol), A2A (Agent2Agent) and WebMCP. The three are often framed as competing, but they are not. MCP standardises the boundary between an agent and the tools it uses. A2A standardises the boundary between one agent and another. WebMCP standardises the boundary between an agent and a live web page. They solve different problems and are deliberately complementary. The agent stack question is not which one wins; it is how all three fit together.

That matters for anyone building, buying or auditing software right now. AI agents are moving out of the every-integration-is-bespoke phase. The question "what is this agent allowed to do, and against what?" is being replaced by "which protocol does this agent speak, and what does that protocol constrain or expose?". For regulated software, the second question is the one with answerable audit trails.

This article walks through the three protocols, compares MCP vs A2A directly (which is where most of the practical confusion sits), covers the current browser landscape for WebMCP, explains how Appnalysis implements all three, and ends with what it all means for compliance and audit work. It is part of the Appnalysis series on how software is growing up.

Key takeaways

• MCP is the most mature of the three, now governed by the Linux Foundation's Agentic AI Foundation, with a July 28 2026 specification revision and widespread production adoption
• A2A is the leading cross-vendor candidate for general agent-to-agent interoperability, with v1.0.1 (May 2026) and 150+ participating organisations, but not yet a universal standard
• WebMCP is a W3C Community Group draft (October 9 2026) edited by Google and Microsoft engineers, with Chrome and Edge in origin trial but no cross-browser consensus yet
• The three protocols are complementary, not competing: MCP handles tools, A2A handles peers, WebMCP handles live web pages
• For compliance and audit work, protocol boundaries become places where identity, authorisation, evidence and logging can be made explicit and reviewable

What is MCP?

The Model Context Protocol (MCP) is an open standard that lets AI models and agents call tools, read data and invoke services through a consistent interface, independent of which model or vendor is doing the calling. Anthropic introduced MCP in November 2024; governance has since moved to the Linux Foundation's Agentic AI Foundation, alongside A2A. The July 28 2026 specification revision introduced a stateless protocol core, header-based routing, cacheable list responses, authorisation hardening and a formal extensions framework.

MCP is the most mature of the three protocols covered here. Current documentation gives examples spanning chat agents, IDEs, databases and external workflows. Compatible clients include Claude, ChatGPT, Cursor, Zed, Windsurf, VS Code and Xcode 26.3.

What is WebMCP?

WebMCP is a proposed browser-side mechanism that lets a web page expose structured tools and semantic actions to an AI agent, so the agent can act on the page through declared interfaces rather than by inferring behaviour from visual elements. The specification is published as a W3C Community Group Draft edited by Brandon Walderman of Microsoft and Khushal Sagar and Dominic Farolino of Google, incubating in the W3C Web Machine Learning Community Group. It is explicitly not on the W3C Recommendation track yet.

The architectural distinction from remote MCP is important: an ordinary MCP server runs behind a network API, while WebMCP registers tools inside the currently loaded page itself. A checkout page, compliance portal or reporting interface can tell an agent "these are the actions available, these are their schemas, this is how to invoke them" instead of waiting for the agent to figure out what buttons and fields mean.

What is A2A?

A2A (Agent2Agent) is an open agent to agent protocol for discovery, delegation and collaboration, letting one agent find another agent, understand its advertised capabilities and delegate tasks to it without knowing its internal model, framework or implementation. Google introduced A2A in April 2025 with more than 50 named technology partners, then contributed it to the Linux Foundation in June 2025. By April 2026 the project had passed 150 participating organisations and seen enterprise production adoption.

The protocol reached v1.0.0 in March 2026 and v1.0.1 in May 2026. Current A2A documentation describes agent discovery, structured messages and tasks, asynchronous and long-running work, streaming, and enterprise authentication. It deliberately supports opaque agents: participants do not have to reveal their internal memory, model or implementation to collaborate.

A2A separates discovery from execution. The /.well-known/agent-card.json discovery endpoint lets crawlers and orchestrators index agent capabilities globally and verify authentication requirements upfront. Execution runs over JSON-RPC over HTTP/SSE, covering message sending, task creation and task status polling, which supports both direct synchronous calls and durable asynchronous task runs.

MCP vs A2A: how they differ

The question most teams actually ask is "do I need both?" and the answer is usually yes, because they solve different problems.

MCP standardises what sits between an agent and the tools, data and services it uses. A2A standardises what sits between an agent and another agent. An agent that calls a database over MCP is still a single agent making a single reasoning step. Two agents collaborating over A2A are separate reasoning systems coordinating on a task, each potentially using their own MCP tools underneath.

Google's own A2A documentation explicitly characterises the two as complementary rather than competing. MCP connects agents to tools and context. A2A lets independent agents collaborate. The Linux Foundation now hosts both protocols under its Agentic AI Foundation, which is practical acknowledgement of the same point.

The architectural difference comes down to where reasoning happens and who holds the context. Over MCP, a specialist platform can expose granular inspection tools and the calling agent's model consumes raw tool results into its own context window to reason over them. Over A2A, an external orchestrator can delegate a complete objective (such as "assess whether this app's last three releases introduced new tracking SDKs") as a task; the specialist agent coordinates the multi-round work, evidence checks and synthesis internally, and returns a verified brief without pushing dozens of intermediate payloads into the caller's context. For long or expensive investigations, the second pattern is substantially cheaper on tokens and clearer on provenance, since the evidence stays with the agent that gathered it.

For a mobile app compliance scenario, the distinction looks like this. An AI assistant running in a developer's IDE uses MCP to call Appnalysis for shipped-app evidence (agent-to-tool). The same assistant uses A2A to delegate a specialist audit to Appnalysis as a peer agent, which then runs its own multi-round investigation internally and returns a verified result (agent-to-agent). Both protocols can run in the same workflow, doing different jobs.

The confusion comes from products that implement both protocols at once, which is increasingly common. Salesforce Agentforce via MuleSoft Agent Fabric uses both MCP and A2A for orchestrating agents, APIs and applications. MongoDB Atlas Agent Engine, announced September 29 2026, cites support for both as part of its argument against locking agents to one model, framework or cloud. Microsoft Copilot Studio can both expose and consume A2A agents, and uses MCP for tool integration.

The three-protocol comparison

Each protocol is at a different point in its maturity curve. Confusing the three leads to overclaims in both directions: either dismissing WebMCP as a tech demo because it is not yet a stable browser standard, or overclaiming "the agent stack is standardised" when meaningful competing approaches still exist for browser integration, identity, authorisation and discovery.

For completeness, a fourth protocol increasingly appears in agent-to-agent comparisons: ACP (Agent Communication Protocol), a REST-oriented interoperability mechanism that overlaps with A2A's territory. It is not covered in depth here because A2A has materially stronger cross-vendor adoption, but readers reaching this article from an ACP comparison should know the two share overlapping use cases and that mature stacks will probably settle on whichever earns the broader orchestrator support.

The browser landscape: WebMCP and the agent browsers

The browser side of the agent stack is where terminology gets muddled fastest. Not every AI browser uses WebMCP. Not every MCP client is a browser. The honest current picture:

Claude in Chrome is a production browser agent extension across paid Claude plans, integrating with Claude Code and Claude Cowork, able to read, click, type, navigate and fill forms. Its actual browser-control mechanism is the Chrome extension scripting, tabs and debugger permissions, not MCP for page control. Claude's broader environment separately consumes remote MCP connectors.

OpenAI's browser workflow has moved through Operator (January 2025) to ChatGPT agent (July 2025) and most recently to ChatGPT Work plus ChatGPT's cloud browser (September 2026 update). The OpenAI ecosystem supports MCP and ships ChatGPT Desktop as a WebMCP consumer per the WebMCP implementation tracker, but there is no primary-source confirmation that the browser-control channel itself uses MCP or WebMCP transport.

Google's Gemini in Chrome is directly integrated into Chrome as a personal AI assistant, able to use context from open tabs and browsing history. Separately, Chrome is implementing WebMCP as a browser platform feature. The two should not be conflated.

Perplexity Comet is an agentic browser product across Mac, Windows, iOS and Android. There is no primary-source confirmation of native MCP or WebMCP transport inside Comet at the time of writing; it is better described as browser automation than as a confirmed MCP-in-browser implementation.

Brave Leo has experimental WebMCP support listed in the project implementation tracker. Microsoft Edge has a WebMCP origin trial with Microsoft's trial documentation giving an expiration date of March 30 2027.

The important point for teams making architectural choices: WebMCP is progressing but is not yet a stable browser web platform API. Chrome's documentation identifies the shipping target as Chrome 157 for desktop, Android and WebView, which is a target rather than evidence that shipping has occurred. Mozilla has recorded a neutral standards position, and WebKit's recorded position is oppose. The cross-browser picture is the biggest reason not to call WebMCP settled.

The agent stack is acquiring standard interfaces

The honest framing is not "the AI agent stack is standardised" but "the AI agent stack is acquiring standard interfaces", at different speeds in different places.

MCP has become the common tool boundary. A2A has become the leading candidate for the common peer boundary, with real production adoption rather than demo-only credibility. WebMCP is the newest of the three and still experimental, but the fact that Google and Microsoft engineers are co-editors and that Chrome and Edge are already in origin trial puts it on a materially faster path than most web platform features historically travel.

A reasonable prediction, assuming current direction holds: WebMCP shipping stable in Chrome and Edge within 12 to 18 months, giving it de facto Chromium standardisation and a working majority of the web. Firefox parity would follow if Mozilla commits engineering capacity, probably 2 to 4 years out. WebKit's architectural objections (parallel machine-facing representation of websites, API duplication, privacy, security) are unlikely to resolve on AI timescales alone; formal W3C Recommendation requiring cross-browser consensus may take 5+ years, or may not arrive.

That matters for buyers more than vendors. Buyers who commit to protocol-based integrations now get portability and auditability that proprietary SDKs do not provide. Buyers who wait for formal W3C Recommendation status will miss the practical standardisation that happens through major-vendor shipping decisions.

The protocol story also keeps changing on the identity side. The OpenID Foundation's AI Identity Management Community Group is actively working on authentication and authorisation for AI agents, and in July 2026 solicited participants for an interoperability demonstration specifically for securing MCP flows with open identity standards. That is a sign the industry has not finished answering the basic questions of "which agent is this?", "whose authority is it exercising?", "what can it delegate?" and "how does a downstream system prove the chain of authorisation?". Those questions are the next standards fight, and they sit on top of MCP, WebMCP and A2A rather than inside them.

What this means for compliance and audit

Audit and compliance have properties that fit protocolised agent access unusually well. Evidence must come from authoritative systems, permissions matter, actions need attribution, outputs need provenance, controls should be repeatable, and reviewers need to reconstruct what happened. Protocol boundaries make all of that cleaner than ad-hoc integrations.

An MCP tool can present a constrained operation such as "retrieve current control evidence" rather than giving an agent unrestricted access to a database. An A2A agent can delegate a specialist task to an externally governed agent with its own permission scope and reasoning. WebMCP can expose similarly constrained actions from systems where no convenient back-end API exists. These architectural characteristics follow directly from the protocols' structured tool and delegation models.

The compliance connection is not hypothetical. Drata launched Drata MCP as a developer platform for AI agents to interact with Drata, automate compliance workflows and manage controls through natural language. A compliance vendor directly building on MCP is evidence that the protocol-to-compliance connection has moved from thought experiment to production.

Regulators have not yet blessed any of these protocols as a compliance mechanism, and that framing matters. The EU AI Act moved into enforcement phase on August 2 2026, with the AI Office and national competent authorities assuming implementation and supervision responsibilities. NIST's AI Risk Management Framework continues to be revised. Neither regime confers special legal status on MCP, WebMCP or A2A. The protocols are an auditability enabler, not an audit certificate.

Microsoft's A2A guidance is instructive here: when delegating to external agents, consider data flows, legal requirements, quality, security, permissions, observability, identity, traceability and human oversight. That is much closer to how compliance teams should think about agent delegation than treating protocol adoption as a safety guarantee. For how continuous compliance work takes advantage of these protocol boundaries, Continuous Compliance in Practice covers the operational layer.

How Appnalysis fits

Appnalysis implements all three protocols as a live production capability.

MCP server. The Appnalysis MCP endpoint exposes Appnalysis's mobile-intelligence capability as remote MCP tools, so compatible AI assistants and coding agents can query evidence and invoke Appnalysis tools directly from inside their own workflow. Named compatible clients include Claude Code, ChatGPT, Cursor, Zed, Windsurf, VS Code and Xcode 26.3. For teams building with AI-assisted development, this means Appnalysis's shipped-app evidence becomes available to the AI assistant during development rather than waiting for a separate audit step. For the specialist-knowledge pattern this fits inside, Your AI Coding Agent Only Sees Half the Picture covers the wider frame.

WebMCP. The Appnalysis web interface implements the current WebMCP browser API, so a WebMCP-aware browser agent (Chrome in origin trial, Edge in origin trial, Brave Leo experimental, ChatGPT Desktop) can discover and invoke Appnalysis actions through structured tools exposed by the page itself, rather than inferring behaviour from DOM structure. This is the production-side use of a browser API that is still formally experimental, which is the practical trade-off teams adopting WebMCP are making right now.

A2A agent. Appnalysis publishes a public A2A Agent Card at https://info.appnalysis.com/.well-known/agent-card.json and serves native A2A tasks and messages at https://info.appnalysis.com/a2a. Another A2A-compliant agent can discover Appnalysis's declared skills and delegate compliance queries, market investigations or release-evidence audits to it directly, without any custom integration code. Appnalysis is not a passive tool proxy at this boundary: it accepts opaque task delegations, applies its own reasoning engine to plan and run the work, sanitises incoming prompts for safety, verifies evidence before returning it, and uses A2A's structured clarification states to query the delegating agent back whenever app identity, storefront market or compliance scope is ambiguous.

Honest limits apply. Protocols give compliance systems standardised places to enforce identity, scope, evidence, delegation and logging. They are an auditability enabler, not an audit certificate. Observable shipped evidence from Appnalysis can establish facts about the released artefact, but it cannot establish every fact about internal organisational processes, cannot necessarily observe server-side behaviour, and does not replace SOC 2 reports, ISO certification or the organisation's own control environment.

For how this capability fits inside wider compliance work, the hidden regulation pyramid covers which regulatory layers any mobile app sits under, and the /product and /agencies pages cover how different teams use the platform.

Closing

Three protocols. Three maturity levels. Same direction.

MCP is becoming the common tool boundary. A2A is becoming the common peer boundary. WebMCP is attempting to create the equivalent boundary between agents and the live web, and is on a materially faster path than most web platform features historically travel, even if the cross-browser consensus question remains open.

For compliance and audit work the direction matters more than the destination. Protocol boundaries are places where organisations can authenticate, authorise, constrain, log and audit what an agent does. That is the standardisation story that matters to regulated software: not that an AI can click faster, but that its access to evidence and its actions can increasingly be made explicit and reviewable.

Frequently asked questions

Further reading

External references

• Model Context Protocol: introduction. The MCP specification entry point.
• MCP July 28 2026 specification release notes. The current specification revision.
• Anthropic: Introducing the Model Context Protocol. The original November 2024 announcement.
• A2A Protocol specification. The current A2A spec reference.
• Linux Foundation: Agent2Agent Protocol. The Linux Foundation announcement.
• Google: A2A announcement. The original Google blog introducing A2A.
• WebMCP W3C Community Group Draft. The current WebMCP specification.
• Chrome WebMCP documentation. Chrome's developer documentation for WebMCP.
• WebMCP implementation status. The project's own implementation tracker.
• Mozilla standards position on WebMCP (neutral). Mozilla's recorded position.
• WebKit standards position on WebMCP (oppose). WebKit's recorded position.
• OpenID Foundation AI Identity Management Community Group. The emerging agent-identity standards work.
• Agentic AI Foundation projects. Linux Foundation umbrella for MCP, A2A and related projects.

Related reading on the Appnalysis site

• Software Is Growing Up. Now the Institutions Are Arriving.. The institutional backdrop to the protocol story.
• Your AI Coding Agent Only Sees Half the Picture. What MCP connects to coding agents in practice.
• Continuous Compliance in Practice. How continuous compliance work takes advantage of protocol boundaries.
• The Hidden Regulation Pyramid. Which regulatory layers any mobile app sits under.
• Appnalysis MCP endpoint. The remote MCP endpoint for AI assistants and coding agents.
• Appnalysis A2A Agent Card. The public Agent Card for A2A discovery.