What Is the A2A Protocol? Agent2Agent Explained, A2A vs MCP, and a Working Agent on Twitter (X) Data

A2A treats every agent as opaque: a client agent does not see the remote agent's prompts, memory, model or tools. It only sees what the remote agent advertises and what it returns. That is the design choice that separates A2A from frameworks that orchestrate agents inside one process. Two agents written by different teams, in different languages, on different clouds can still cooperate, because the only thing they share is the protocol.

Agent Card. A JSON document, served by convention at https://{server_domain}/.well-known/agent-card.json, that says who the agent is and how to talk to it. The v1.0 schema requires name, description, version, supportedInterfaces, capabilities, defaultInputModes, defaultOutputModes and skills; optional fields include provider, documentationUrl, securitySchemes, securityRequirements, signatures (signed cards) and iconUrl.

Skill. An entry in the card's skills list with an id, name, description and tags (all required), plus optional examples and input/output modes. Skills are how an orchestrator, or a model choosing between agents, decides who gets a task.

Message and Part. A message has a messageId, a role (ROLE_USER from the client, ROLE_AGENT from the agent) and a list of parts. A part is exactly one of text, raw (bytes, base64 in JSON), url (a file by reference) or data (any JSON value), with optional mediaType, filename and metadata.

Task. The unit of work. It carries an id, a contextId that groups related tasks into one conversation, a status with a state, plus artifacts and history. Tasks are what make A2A suitable for work that takes minutes or hours rather than one request.

Artifact. The output of a task: an artifactId, an optional name and description, and parts. A report, a JSON payload or an image all come back as artifacts, and can be streamed in chunks.

Origin. Google announced Agent2Agent in April 2025. The GitHub repository a2aproject/A2A was created in March 2025 and is licensed Apache-2.0; when we checked it this session it had about 26,500 stars and 2,700 forks and had received commits the same day.

Linux Foundation. On June 23, 2025, at Open Source Summit North America, the Linux Foundation launched the Agent2Agent Protocol Project around the protocol Google had created and launched that April. The announcement quotes Google Cloud, SAP, ServiceNow and Cisco as founding contributors or members, carries statements of support from AWS, Microsoft and Salesforce, and puts support at more than 100 companies at the time.

Agentic AI Foundation. On August 17, 2026 the AAIF announced that A2A was joining it as a hosted project, still governed openly under the Linux Foundation; the same announcement says A2A is "backed by over 150 organizations".

v1.0. The AAIF post describes v1.0 as "the first stable specification", shipped in March 2026, and lists what it added: multi-protocol bindings, version negotiation, multi-tenancy and signed Agent Cards. The repository tagged v1.0.0 in March 2026 and v1.0.1 in May 2026; the spec page lists 0.3.0, 0.2.6 and 0.1.0 as earlier versions.

Version negotiation. Clients send an A2A-Version header (or an A2A-Version query parameter). A server that does not support the requested version returns VersionNotSupportedError, and an empty value is treated as 0.3, so v1.0 servers can still talk to older clients that never sent the header.

SDKs. The A2A site lists official SDKs for Python, Go, Java, JavaScript, C#/.NET and Rust, all implementing the same v1.0 specification. The Python package is a2a-sdk on PyPI (version 1.3.0 when we checked).

A full exchange has four steps. Discover: the client fetches the Agent Card and reads supportedInterfaces, each with a url, a protocolBinding (JSONRPC, GRPC or HTTP+JSON; the field is open, so custom bindings are allowed) and a protocolVersion. Authenticate: if the card declares securitySchemes (API key, HTTP auth, OAuth 2.0 with authorization-code, client-credentials or device-code flows, OpenID Connect, or mutual TLS), the client gets credentials out of band. Send: the client calls SendMessage (or SendStreamingMessage for server-sent events). Follow up: it polls with GetTask, subscribes with SubscribeToTask, or registers a webhook for push notifications.

The operations are the same in every binding; only the framing changes. The table maps the core ones:

Task states. A task moves through TASK_STATE_SUBMITTED and TASK_STATE_WORKING to one of the terminal states TASK_STATE_COMPLETED, TASK_STATE_FAILED, TASK_STATE_CANCELED or TASK_STATE_REJECTED. Two states pause the task and hand control back to the client: TASK_STATE_INPUT_REQUIRED (the agent needs more information) and TASK_STATE_AUTH_REQUIRED (it needs credentials). Those two are what let an A2A agent hold a multi-turn conversation inside one task.

Push notifications. If the card sets capabilities.pushNotifications to true, a client can register a webhook url (plus an optional token and authentication info) and the agent will POST StreamResponse payloads to it as the task progresses, as plain HTTP with JSON whatever binding the agent uses. The spec warns that neither push nor streaming is a reliable delivery mechanism for critical information, so a client should still call GetTask for the final state.

The request below is the smallest valid JSON-RPC call. The response wraps either a task or, for a quick answer that needs no task, a message.

The short version is the A2A site's own line: MCP connects an agent to tools, APIs and data; A2A connects it to other agents. The longer version is about what each protocol assumes about the thing on the other end. An MCP server is a tool: it exposes typed functions (tools), readable context (resources) and templates (prompts), and the calling model decides exactly which function to run with which arguments. An A2A agent is a peer: the caller describes a goal in a message, and the remote agent decides how to reach it, may ask for more input, and may take a long time.

When MCP alone is enough. If one agent needs to read data or call APIs, MCP (or a plain REST call) is the whole answer. Connecting Claude Code, Cursor or another host to our hosted X server is one config entry with your API key as a Bearer token, and the agent gets 12 read-only tools for searching posts and reading profiles, timelines, replies, followers and trends. Adding A2A here would add a hop and gain nothing.

When you need A2A. When the work crosses an ownership boundary: a procurement agent at one company asking a supplier's agent for a quote, an orchestrator delegating to specialist agents another team deploys and updates on its own schedule, or any case where you must not (or cannot) see the other agent's tools and prompts. A2A gives you discovery, a task lifecycle and auth negotiation that MCP was not designed to provide between peers.

How they combine. The common pattern is the one in the hero diagram: agents talk to each other over A2A, and each one reaches its own tools over MCP. A research agent that answers "what is X saying about our launch?" can expose that as an A2A skill, and internally call an X MCP server or the REST API to fetch the posts. The client agent never learns which data source was used; it just receives an artifact.

Where the line is getting blurry. MCP's current spec revision (2026-07-28) makes requests stateless and self-contained and adds an opt-in Tasks extension for long-running operations, so MCP now covers some async work that used to be A2A-only. The difference that remains is the peer model: MCP still assumes the caller picks the tool and its arguments, A2A assumes the callee owns the plan.

To see how builders actually talk about A2A, we searched X for "A2A protocol" (newest and top posts) and "agent2agent", with retweets excluded, and de-duplicated the results into 708 posts from 551 accounts. For scale we also pulled the newest 200 posts containing "MCP server". Every number below comes from that sample.

MCP is the protocol A2A is discussed with. 19.5% of A2A posts also mention MCP (138 posts), far ahead of any other agent protocol: x402 appears in 6.8%, ACP in 1.8%, AP2 in 1.0%. About a quarter of the A2A-plus-MCP posts (25.4%) frame them as a comparison ("vs", "difference", "compare"); the rest mostly list them side by side as parts of one stack. The link does not run the other way: none of the 200 recent "MCP server" posts mentioned A2A.

Google still owns the story. 32.2% of A2A posts mention Google, ADK, Vertex or Gemini, more than Anthropic or Claude (8.9%), OpenAI (7.1%), Microsoft (6.6%) and AWS (3.7%) combined. Agent frameworks are a small slice: LangChain or LangGraph 4.1%, CrewAI 2.5%.

Security and payments dominate the themes. 30.4% of posts touch security, auth, trust, identity or signatures; 19.1% touch payments or commerce; 17.5% are tutorials, guides or demos; 13.4% talk about Agent Cards or discovery. 14.0% carry crypto-token vocabulary (tickers, onchain, airdrop), which is worth knowing if you plan to monitor the term: filter it or your feed will fill with token launches that borrow the A2A name.

Few posts point at the spec. 44.6% of A2A posts carry a link, but only 2.5% link to a2a-protocol.org or the a2aproject GitHub organization, and 5.5% link to GitHub at all. 18.5% contain a question mark. For a reader, that means most of what circulates on X about A2A is commentary on the protocol rather than the protocol; the spec is the place to check field names.

Volume tells a different story from the specs. In its newest 30 days the "A2A protocol" search returned 73 posts, about 2.4 a day; the "agent2agent" search ran at 2.4 a day over the 83.6 days its 200 posts covered. The newest 200 "MCP server" posts, by contrast, all fell inside 6.2 hours, a rate of about 775 a day, roughly 323 times the A2A rate.

Attention per post runs the other way. The median post in the A2A Latest sample had 350 views and 6 likes; the median MCP-server post had 24.5 views and 0.5 likes, and 50% of MCP-server posts got no like at all, against 5.4% of A2A posts. 73.0% of A2A posts came from blue-verified accounts. A plausible reading, which the sample cannot prove: MCP servers are now a commodity people announce daily, while A2A is still discussed mostly by people who follow agent infrastructure closely.

Among the 90 Top-ranked A2A posts, 25.6% mention MCP, and those had a median of 92 likes against 45 for the rest. The A2A vs MCP framing is what travels, which is also why this page answers both.

A practical way to understand A2A is to stand up one agent. The script in the code section below is a complete v1.0 agent in about 140 lines of standard-library Python plus requests: it serves an Agent Card with one skill (search-x), accepts SendMessage over JSON-RPC, runs the text of the message as an X advanced-search query against TwitterAPI.io's REST API, and returns a completed Task whose artifact is a data part holding the posts. Its client half does what any A2A client does: read the card, choose the JSONRPC interface, send the message with an A2A-Version: 1.0 header, and read the artifact.

Why REST inside the agent, not MCP. Inside an agent you control, a direct call is the shortest path: one GET to /twitter/tweet/advanced_search with an X-API-Key header returns up to 20 posts per page plus has_next_page and next_cursor, and the fields (createdAt, text, likeCount, viewCount, author.userName) map straight into the artifact. If the agent is itself an LLM loop (ADK, LangGraph, the OpenAI Agents SDK, the Claude Agent SDK), point it at https://mcp.twitterapi.io/mcp with Authorization: Bearer <your key> instead, and let the model pick among the 12 read-only tools. Either way the remote A2A client only sees the skill.

What to change for production. Swap the hand-rolled server for the official a2a-sdk, which handles streaming (SendStreamingMessage), task storage for GetTask, push notifications and auth; declare a securitySchemes entry in the card (an API key or OAuth 2.0) instead of leaving the agent open; and keep tasks in TASK_STATE_WORKING while a long search paginates, so a client can poll or subscribe rather than block.

Reads need no X account. The search runs on TwitterAPI.io's own collection, so the agent needs an API key, not an X developer app or an X login. If you later want an agent to post, our write endpoints (/twitter/create_tweet_v2 and others) run through an authenticated session: one /twitter/user_login_v2 login ($0.10, with a proxy you supply) returns login_cookies, then each action is 60 credits ($0.0006), billed per HTTP 200 call. That call acts as that account, so keep a normal human pace on your own account only; X can rate-limit, lock or suspend it, and the session can need a re-login.

TwitterAPI.io bills per tweet returned: 15 credits per tweet, which is $0.15 per 1,000 tweets, with a 15-credit minimum when a search returns nothing ($0.00015). A full 20-post page costs $0.003. X's own API, on its pay-per-usage rate card at docs.x.com/x-api/getting-started/pricing, charges $0.005 per post read, or $5 per 1,000 posts, about 33x more per 1,000 tweets. The study on this page read 973 posts in 50 requests: $0.15 with us, $4.87 at X's post-read price.

A2A-specific sizing. A2A tasks are usually bursts, not streams: an orchestrator asks "what is X saying about this?" and the X agent reads one to five pages. At $0.003 per full page that is $0.003 to $0.015 per task. Even a monitoring skill that polls a niche term is cheap, because empty checks cost the minimum: at the 2.4 posts a day we measured for "A2A protocol", a 5-minute poll finds nothing most of the time, so the floor of about $1.30 a month is most of the bill.

New accounts that pass the automatic bot check get up to $1 of free credits (at most 100,000 credits, no card, one per person or network, expiring after 31 days), enough to run the study above several times. The rate limit is 0.2 requests per second before the first payment and 20 once paid. Purchased credits never expire; plans and higher limits are on the pricing page.

Question. How do people on X talk about the A2A protocol, how often do they pair it with MCP, and how does the A2A conversation compare in volume and attention with the MCP-server conversation?

Queries. Four searches on /twitter/tweet/advanced_search, all with -filter:retweets: "A2A protocol" Latest (25 pages, 483 posts), agent2agent Latest (10 pages, 200 posts), "A2A protocol" Top (5 pages, 90 posts) and "MCP server" Latest (10 pages, 200 posts). The three A2A sets were merged and de-duplicated by post id into 708 posts from 551 accounts. 50 requests, 973 posts, $0.15 in credits.

Window. The newest matching posts at collection time, collected in 2026. Each query covers a different span: the newest 200 MCP-server posts covered a few hours, while the A2A searches reach back over many months. Per-day rates use each sample's own span; the A2A rate uses its newest 30 days.

Method. Keyword matching on lowercased post text (and expanded link domains), with the regular expressions in analyze.py; a post can count toward several protocols, vendors or themes. Engagement is the likeCount and viewCount at collection time.

What the sample cannot show. Search results are not a census: X search coverage varies, older posts are sparser, and Top is X's ranking, not ours. Keyword matching misses posts that discuss A2A without the words and catches some that use "A2A" for unrelated things (crypto tokens, account-to-account payments). The MCP-server sample covers hours, so time-of-day affects its rate. None of this measures adoption of the protocol, only the conversation about it.

Privacy. Aggregates only. Most authors are private individuals, so raw search pages were not kept; the published sample holds de-identified rows (no post id, URL, text, author id or handle). No account is named or profiled.