--- title: "Orrery Studio Part 2: MCP vs A2A, When an Agent Needs a Tool or a Peer" url: "https://tirraflow.com/posts/orrery-studio-part-2-mcp-vs-a2a-when-an-agent-needs-a-tool-or-a-peer" author: "taoufiq" published: "2026-10-25T13:05:49Z" updated: "2026-10-25T13:00:49Z" category: "AI Agents" difficulty: "intermediate" series: "Orrery Studio" series_part: 2 series_url: "https://tirraflow.com/series/orrery-studio" tags: ["Agents", "MCP", "A2A"] --- # Orrery Studio Part 2: MCP vs A2A, When an Agent Needs a Tool or a Peer > **Status, October 2026:** Orrery Studio is a preview (Orrery 0.10.0, admins only). The protocols below are stable; the Studio features built on them are still growing. [Part 1](https://tirraflow.com/posts/orrery-studio-part-1-a-visual-builder-for-multi-agent-ai-systems) has the full status. MCP vs A2A, in one line: the Model Context Protocol connects an AI agent to tools and data, and the Agent2Agent protocol connects an agent to another agent. They don't compete. This part explains the difference with a real example, shows how Orrery Studio uses both, and answers the questions people ask most. --- ## MCP vs A2A: The Short Answer ![MCP vs A2A compared: MCP connects an agent to a server's tools with a call and a JSON result; A2A connects an agent to an opaque remote agent through a task that moves from submitted to working to completed](https://tirraflow.com/uploads/066af281-49fc-436a-b505-9fb8f7241b1d.png) - **MCP is for tools.** Your agent sees each tool's name, description and input schema, picks one, and calls it with typed arguments. Usually one call, one answer. - **A2A is for peers.** The remote agent has its own model, prompt and tools, and you see none of them. You read its _Agent Card_, send it a message, and get back a _task_ that can work for a while, finish, fail, or ask you a question. --- ## MCP vs A2A Side by Side | | MCP | A2A | | --- | --- | --- | | **Connects** | an agent to tools, resources, prompts | an agent to another agent | | **Discovery** | `tools/list` on the server | Agent Card at `/.well-known/agent-card.json` | | **What you see** | every tool's description and schema | skills and an endpoint; the inside stays opaque | | **Unit of work** | a function call and its result | a task with states and artifacts | | **Wire format** | JSON-RPC over stdio or streamable HTTP | JSON-RPC over HTTPS (gRPC and REST bindings too) | | **Started by** | Anthropic, November 2024 | Google, April 2025 | Both are open standards governed under the Linux Foundation today. --- ## One Example Using Both The Studio's demo composition writes release notes from what Tirraflow has published: 1. A **research** node searches the blog through Tirraflow's public MCP server. Searching is a clear input and output, so it's a tool: **MCP**. 2. A **writer** node hands the notes to a separate agent, written with the plain `a2a-sdk` and no Orrery code at all. It's someone else's agent with its own logic, so it's a peer: **A2A**. 3. A **critic** node approves the draft or sends it back. Both arrive in the operator's registry, a YAML file the Studio reads at startup: ```yaml mcp: - id: tirraflow url: https://tirraflow.com/mcp transport: streamable_http tools: [search_articles, get_article, list_series, list_articles] read_only: [search_articles, get_article, list_series, list_articles] a2a: - id: demo-writer card_url: https://demo-writer.studio.internal:8443/.well-known/agent-card.json skills: [draft] effect: read_only private_network: true ``` A node then names what it may use: `mcp:tirraflow.search_articles` or `a2a:demo-writer.draft`. No MCP server or remote agent outside this file can be reached. --- ## One Design Choice: Everything Is a Tool In Orrery Studio, a remote A2A agent is **never a node on its own**. It is a tool held by an LLM node, exactly like an MCP tool. (The canvas does offer a "Remote agent" node, but it's a shorthand: it expands into an LLM node holding one `a2a:` tool.) The model sees two functions: ```text mcp_tirraflow_search_articles(query) a2a_demo_writer_draft(request) ``` That one choice means every guard Orrery has applies to both: the safety screen, PII redaction, output caps, budgets and the audit log. [Part 3](https://tirraflow.com/posts/orrery-studio-part-3-how-the-a2a-protocol-works-from-agent-cards-to-tasks) shows what goes wrong otherwise. --- ## When to Use MCP vs A2A - **Choose MCP** when the capability has a clear input and output: search, read a file, query a database, call an API. You want to see the schema, and you usually want one answer per call. - **Choose A2A** when another team or vendor owns the work, in a framework you don't control, and it may take several steps or need to ask a question back. - **Use both** in most real systems: your agents use MCP for their tools and A2A to reach each other. A remote A2A agent may well use MCP inside; you'll never know, and that's the point. --- ## Frequently Asked Questions **Is A2A replacing MCP?** No. They solve different problems. A2A covers agent-to-agent delegation; MCP covers tool access. Most stacks need both. **Can an A2A agent use MCP tools?** Yes. Inside, a remote agent can use any tools, MCP included. A2A only defines how you talk to it from outside. **Are MCP and A2A secure?** The protocols define transport and authentication hooks, not trust. A tool description can carry a prompt injection, and an agent card can point your requests somewhere unexpected. The client has to defend itself, which is what Parts 3 and 4 are about. **Does Tirraflow have an MCP server?** Yes, a public read-only one at `https://tirraflow.com/mcp`. [Building Tirraflow Part 6](https://tirraflow.com/posts/building-tirraflow-part-6-an-mcp-server-for-the-blog) explains how it was built, and the Studio's demo uses it. Next: [Part 3, how the A2A protocol works](https://tirraflow.com/posts/orrery-studio-part-3-how-the-a2a-protocol-works-from-agent-cards-to-tasks).