AI Guides › Playbooks
By Nigel Guy · 8 min read
When a governance headline lands, the usual reaction is one of two defaults: ignore it as dull plumbing, or read it as "everything now talks to everything" and start connecting tools on the strength of a logo. The second is how people end up granting write access to a server they have never vetted because a vendor page said "MCP and A2A ready".
The rule: a shared standard tells you how two systems can talk, not whether you should let them. Sort every "works with agents" claim into its lane, then check who holds the keys before you connect.
There are two different handshakes here, and most confusion comes from treating them as one.
| MCP (Model Context Protocol) | A2A (Agent2Agent) | |
|---|---|---|
| Who made it | Anthropic, released as an open standard | Google, launched April 2025 |
| What it connects | One AI app to tools and data: your calendar, a database, a file store | One agent to another agent, often run by a different company |
| Direction | Vertical: an agent reaching down into its own tools | Horizontal: agents talking as peers |
| What the other side is | Usually a fairly predictable tool that does what it's asked | An agent that does its own reasoning and may not show you how it works |
| Where you meet it in Claude | Connectors, including custom connectors built on remote MCP servers | No native A2A setting in the Claude apps that I could confirm at time of writing |
The A2A project puts it neatly in its own docs: A2A connects agents to each other, and MCP connects each agent to its own tools. An A2A agent publishes an "Agent Card", a JSON description of who it is, what skills it offers, where to reach it and how it expects callers to authenticate.
The timeline, from the primary sources:
So both protocols now sit with the same neutral foundation rather than with the companies that wrote them. The practical meaning is narrower than the headlines suggest: one governance home makes it easier for the two specs to be kept compatible, and reduces the risk that either one gets pulled in a direction that suits a single vendor. It is not a merger. They remain two specifications with two jobs.
Very little overnight, and that is the honest answer. Your existing Claude connectors keep working exactly as they did. What changes over time:
Run this every time a tool, vendor or colleague suggests connecting something new. It takes five minutes.
| Step | Question | What a good answer looks like | Stop if |
|---|---|---|---|
| 1. Lane | Is this an MCP server (a tool for your agent) or an A2A agent (a peer your agent hands work to)? | The vendor says which, plainly | They can't say, or use both words as decoration |
| 2. Host | Who runs the server or agent, and where? | A named company, or software you run yourself | Anonymous repo, no maintainer, no address |
| 3. Reach | What can it read, and what can it write, send or delete? | Read-only to start, or a named, narrow write scope | It asks for broad write access on day one |
| 4. Keys | How does it authenticate, and can you revoke access in one place? | OAuth or a key you can revoke; for A2A, auth listed in its Agent Card | Shared passwords, or no way to disconnect |
| 5. Hand-back | When it acts, do you see what it did before anything leaves your hands? | Claude shows tool calls; you approve sends | It acts silently or in the background |
If a candidate fails any "Stop if", skip it. You are not obliged to connect something because it uses an open standard.
For MCP, the place you act is connectors. Per Anthropic's help centre at time of writing:
Anthropic's own warning on that page is worth repeating: only connect to servers you trust, and remember a malicious MCP server can carry hidden instructions aimed at making Claude do something you didn't ask for.
Paste the vendor's own description into Claude and let it sort the claim before you touch any settings. Fill in the vendor name, paste their text, and say what you want it to do for you.
You are a cautious integration reviewer helping a non-technical small-business owner decide whether to connect a new AI tool.
Context: the tool is [VENDOR_OR_TOOL_NAME]. I want it to [WHAT_I_WANT_IT_TO_DO]. I use Claude on the [MY_CLAUDE_PLAN] plan. Here is the vendor's own description, pasted exactly:
[PASTE_VENDOR_TEXT]
Goal: tell me which lane this is and whether it passes a basic safety check, using only the text above.
Steps:
1. Classify it as an MCP server (gives my agent a tool or data source), an A2A agent (a separate agent my agent would hand work to), both, or unclear. Quote the phrase that justifies your answer.
2. State who runs it and where, if the text says so.
3. List what it can read and what it can write, send or delete. Mark anything not stated as "not stated".
4. Describe how it authenticates and how I would revoke access, if stated.
5. Give a verdict: "connect read-only", "connect with named limits", or "don't connect yet", with one sentence of reasoning.
Output: a five-row table (Lane, Host, Reach, Keys, Verdict), then a list of questions I should send the vendor.
Constraints: do not assume capabilities the text does not state. Do not recommend broad write access. If the pasted text is missing or too vague to classify, ask me for the vendor's documentation link instead of guessing.
Before answering, check: is every cell in the table backed by a quote or marked "not stated"?
Priya runs a two-person bookkeeping practice. A practice-management vendor emails: "Now MCP and A2A ready, connect your AI assistant in one click." She runs the check.
Her decision: connect the MCP server once a read-only option is confirmed; ignore the A2A agent for now, because she has no other agent that needs to hand it work.