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 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

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:

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.
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.
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:

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:

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 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 explains how it was built, and the Studio's demo uses it.

Next: Part 3, how the A2A protocol works.