{
  "source_file": "0930",
  "source_platform": "Dev.to",
  "author": "Edward Izgorodin",
  "title_listed": "Do I need A2A if my agents already use MCP?",
  "keywords": "",
  "domain": "大模型算法",
  "content_type": "深度技术解析",
  "is_paid_flag": "否",
  "url": "https://dev.to/izgorodin/do-i-need-a2a-if-my-agents-already-use-mcp-37im",
  "publish_date": "2026-09-25",
  "corpus_stage": "",
  "notes": "",
  "id": "7a065f43b3ea",
  "collected_at": "2026-10-02T14:02:57",
  "title": "Do I need A2A if my agents already use MCP? - DEV Community",
  "body_markdown": "Your agents already call tools over MCP. A search tool, a database, a file system, maybe a memory server. Then someone on the team reads about A2A and asks whether you should be moving to it, and the conversation turns into which protocol is winning.\nIt is the wrong race to watch. MCP and A2A answer different questions, and both projects say so in their own words. The question worth asking is narrower: is the thing on the other end of this connection a tool you call, or an agent that runs on its own and hands you back a result?\nOne line to carry: MCP connects an agent to things it uses, A2A connects an agent to another agent that owns its own process, both can now keep a long piece of work open and pause it for input, and neither protocol carries what was learned into the next piece of work.\nWhat each one connects\nMCP is the vertical one. An agent, through its client, discovers the tools, resources and prompts a server offers and calls them. The unit of work is a tool call or a resource read. The current revision of the specification lists \"Stateless, self-contained requests\" among its design points, and its\ntools page\nis blunt about it:\nMCP has no protocol-level session, so a server cannot rely on implicit per-connection state to relate one tool call to the next.\nA2A is the horizontal one. It is a protocol for agents to hand work to other agents without seeing inside them, and the\nA2A specification\nstates that directly: agents coordinate \"without needing access to each other's internal state, memory, or tools\". Its building blocks are an Agent Card, a manifest of what an agent can do and where to reach it, and Tasks, which carry Messages and produce Artifacts. The specification defines JSON-RPC, gRPC and HTTP+JSON bindings. And a Task has a lifecycle, with states such as working, input-required and completed, at the core of the protocol.\nThe lifecycle alone no longer separates them. Since the July revision an MCP tool call can come back asking for more input, and MCP's official tasks extension, opt-in on both client and server, gives long-running operations the same kind of states: working, input_required, completed, failed, cancelled. What separates the two is what sits on the other side. An MCP task is a long operation of a tool you called and understand. An A2A task is work handed to an agent you cannot see into, which decides for itself how to do it and hands you back a result.\nBoth projects say they compose\nThe A2A documentation has a page on exactly this question,\nA2A and MCP\n, and describes the two as addressing \"distinct but highly complementary needs\". It uses an auto repair shop to make the point: mechanics use their tools to do the work, and talk to each other to coordinate it.\nGoogle's launch post for A2A put it the same way from the start, describing A2A as a protocol that \"complements Anthropic's Model Context Protocol (MCP), which provides helpful tools and context to agents\" (\nGoogle Developers Blog\n). A 2025 analysis of integrating the two,\narXiv 2505.03864\n, frames them as horizontal and vertical integration standards respectively.\nIn practice a system that uses both looks like this. A planner agent receives a request. It delegates part of it over A2A to a specialist agent that another team runs. The specialist calls its own tools over MCP, finishes the task, and returns an Artifact over A2A. The planner never sees the specialist's tools, and does not need to.\nThe test for any given connection\nLook at the other end of the connection you are about to build.\nIf it is a tool, an API, a data source, a file system or a context provider, something that does what it is told and returns, MCP is the protocol. That covers most of what a single agent needs.\nIf it is another agent, something with its own model, its own tools and its own judgement, that you want to hand a goal rather than a function call, A2A is the protocol. That matters most when the other agent is opaque to you: owned by another team or another company, running somewhere you do not control, and not something you want to import into your own process.\nAnd if all your agents live in one process inside one framework, you may not need A2A at all yet. Handing work between them is a function call in your own code. A2A earns its place at the boundary where you stop owning the other side.\nWhere composing them costs something\nThe same 2025 analysis lists the costs at the seam: matching what a task means to what a tool can do, security exposure that compounds when discovery and execution are chained across agents, and debugging tools that do not span both protocols.\nSecurity is the least settled of the three. A February 2026 threat-modelling study of MCP, A2A, Agora and the Agent Network Protocol,\narXiv 2602.11327\n, says in its abstract that standardised threat modelling is limited and that \"no protocol-centric risk assessment framework has been established yet\". When an A2A task on one agent triggers MCP tool calls on another, each protocol's security model covers its own hop, and a model for the chain is exactly what that study is trying to start.\nA2A is also not the only protocol on the horizontal axis. The same study covers Agora and the Agent Network Protocol, and the field has not settled on one.\nWhat neither of them does\nBoth protocols move information. Neither keeps it.\nMCP can connect an agent to a memory tool, and the agent can read and write through it like any other tool, but the protocol defines nothing about memory itself, and two agents with their own MCP connections do not share anything unless the server behind them does. A2A deliberately keeps agents opaque to each other: a task carries messages and artifacts, and nothing in the protocol carries the context the two agents built into the next task. It survives only if one side, or something outside the protocol, decides to keep it.\nResearch names the same gap.\nSAMEP\nopens with the claim that current agent architectures \"suffer from ephemeral memory limitations\" and proposes a memory exchange layer built to work alongside MCP and A2A. A 2026 position paper on\nmulti-agent memory from a computer architecture perspective\nnames two protocol gaps, \"cache sharing across agents and structured memory access control\", and calls multi-agent memory consistency the most pressing open challenge.\nThat is not a defect in either protocol. It is a layer neither was designed to fill, and it is worth knowing before you expect A2A to give your agents a shared history. It gives them a shared task. The history is a separate decision.\nSo the answer to the question in the title is usually no, not yet, and not instead. Keep MCP for everything an agent uses. Add A2A at the point where you delegate to an agent you do not own. Then decide separately what should outlive the task.\nWhere in your system is the first agent you hand work to without owning it?\nDisclosure: I work on\nMnemoverse\n, a memory service for agents that connects over MCP, which is one way to fill the gap in the last section, so weigh that section accordingly. The longer version with every source is on our library, and the MCP server is open source (MIT):\ngithub.com/mnemoverse/mcp-memory-server\n.",
  "metadata": {
    "title": "Do I need A2A if my agents already use MCP? - DEV Community",
    "description": "Your agents already call tools over MCP. A search tool, a database, a file system, maybe a memory... Tagged with ai, mcp, agents, architecture.",
    "keywords": "ai, mcp, agents, architecture, software, coding, development, engineering, inclusive, community",
    "author": null,
    "og:type": "article",
    "og:url": "https://dev.to/izgorodin/do-i-need-a2a-if-my-agents-already-use-mcp-37im",
    "og:title": "Do I need A2A if my agents already use MCP?",
    "og:description": "Your agents already call tools over MCP. A search tool, a database, a file system, maybe a memory...",
    "og:site_name": "DEV Community",
    "og:image": "https://media2.dev.to/dynamic/image/width=1200,height=627,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fkcoij88drgyl7l2ridis.png",
    "twitter:site": "@thepracticaldev",
    "twitter:creator": "@",
    "twitter:title": "Do I need A2A if my agents already use MCP?",
    "twitter:description": "Your agents already call tools over MCP. A search tool, a database, a file system, maybe a memory...",
    "twitter:card": "summary_large_image",
    "twitter:widgets:new-embed-design": "on",
    "twitter:image:src": "https://media2.dev.to/dynamic/image/width=1200,height=627,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fkcoij88drgyl7l2ridis.png"
  },
  "paywall": {
    "listed_paid": false,
    "detected": false,
    "marker": "",
    "public_only": false,
    "policy": "付费/会员内容只保留页面公开可见部分，不绕过付费墙"
  },
  "crawl": {
    "success": true,
    "status_code": 200,
    "error": ""
  },
  "code_blocks": [],
  "images": [],
  "audio": [],
  "videos": [],
  "links": [
    {
      "href": "https://modelcontextprotocol.io/specification/2026-07-28/server/tools",
      "label": "tools page",
      "type": "a"
    },
    {
      "href": "https://a2a-protocol.org/latest/specification/",
      "label": "A2A specification",
      "type": "a"
    },
    {
      "href": "https://a2a-protocol.org/latest/topics/a2a-and-mcp/",
      "label": "A2A and MCP",
      "type": "a"
    },
    {
      "href": "https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/",
      "label": "Google Developers Blog",
      "type": "a"
    },
    {
      "href": "https://arxiv.org/abs/2505.03864",
      "label": "arXiv 2505.03864",
      "type": "a"
    },
    {
      "href": "https://arxiv.org/abs/2602.11327",
      "label": "arXiv 2602.11327",
      "type": "a"
    },
    {
      "href": "https://arxiv.org/abs/2507.10562",
      "label": "SAMEP",
      "type": "a"
    },
    {
      "href": "https://arxiv.org/abs/2603.10062",
      "label": "multi-agent memory from a computer architecture perspective",
      "type": "a"
    },
    {
      "href": "https://mnemoverse.com/",
      "label": "Mnemoverse",
      "type": "a"
    },
    {
      "href": "https://github.com/mnemoverse/mcp-memory-server",
      "label": "github.com/mnemoverse/mcp-memory-server",
      "type": "a"
    }
  ],
  "repair_version": 2,
  "repaired_at": "2026-10-14T10:49:24Z",
  "source_url": "https://dev.to/izgorodin/do-i-need-a2a-if-my-agents-already-use-mcp-37im",
  "papers": [
    {
      "status": "ok",
      "url": "https://arxiv.org/pdf/2505.03864",
      "bytes": 4033944,
      "reused": false,
      "local_path": "papers/repair/19c55e6d33d51bdda111.pdf"
    },
    {
      "status": "ok",
      "url": "https://arxiv.org/pdf/2602.11327",
      "bytes": 6383246,
      "reused": false,
      "local_path": "papers/repair/94b958dbc66baca605c6.pdf"
    },
    {
      "status": "ok",
      "url": "https://arxiv.org/pdf/2507.10562",
      "bytes": 1578696,
      "reused": false,
      "local_path": "papers/repair/a2c542a95e19f158386b.pdf"
    },
    {
      "status": "ok",
      "url": "https://arxiv.org/pdf/2603.10062",
      "bytes": 4122041,
      "reused": false,
      "local_path": "papers/repair/4b926c98bea9e3bc84d6.pdf"
    }
  ],
  "actual_video_files": [],
  "body_chars": 7201,
  "expected_body_images": 0,
  "discovery_status": "ok",
  "delivery_status": "ok",
  "missing_reason": "",
  "raw_html": "attachments/7a065f43b3ea/pages/source.html",
  "local_html": "attachments/7a065f43b3ea/pages/article.html",
  "body_base_path": "attachments/7a065f43b3ea/pages/",
  "body_markdown_path": "attachments/7a065f43b3ea/pages/article.md"
}