The MCP vs A2A vs API question has a short answer. Use MCP for reusable tools and data shared across clients, A2A when another team or vendor runs an opaque agent, and a direct API or CLI when one application owns the whole integration.
MCP vs A2A vs API: what each integration mechanism is for
The MCP vs A2A vs API decision maps to three distinct jobs. MCP (Model Context Protocol, an open standard for connecting AI applications to external systems) gives an agent typed tools and data. A2A (Agent-to-Agent protocol, an open protocol for communication between opaque agentic applications) hands a whole task to another agent. A direct API or CLI call keeps the integration inside one application where your own code controls it.
The official MCP site describes MCP as a universal connector for AI applications and calls it a "USB-C port for AI applications". The A2A project frames its protocol around agents that cannot see inside each other. Anthropic own documentation recommends pairing the two: equip agents with MCP for their tools, then let agents talk to each other over A2A.
The practical distinction is who owns the logic. With MCP you call functions with typed inputs, and your team defines what each tool does, such as looking up an order or filing a ticket. With A2A you hand over a task and receive a result while the other agent's reasoning stays private, such as a supplier's agent negotiating delivery dates.
A CLI fits coding agents that already have a shell. Anthropic Claude Code can run a single permitted command pattern and nothing else, which costs no tool schema at all. The tradeoff is that a shell is a large permission, so the rule must stay narrow and cover every enabled tool, not just the obvious one. In a demo build, leaving the read tool enabled let Claude read a file a different way, which is why least privilege has to cover the whole tool set.
Integration is the largest domain on Anthropic Claude Certified Architect exam, worth 19% (about 12 questions), which is why the source series splits it across two episodes.
How do you pick between MCP, A2A, API and CLI?
Pick the mechanism by asking who needs the capability and who controls its logic. Shared tools across several clients point to one MCP server. A partner's private agent points to A2A. A single application's own integration points to a direct API call, and an agent with a shell can use a narrowly permitted CLI.
A worked example makes the rule concrete. If an assistant must read tickets and add comments from Claude Code, Claude Desktop, and an internal support agent, one shared MCP server beats three separate integrations. Building it once gives one place to manage permissions and one audit trail, while copying code three times means three things to secure. Nightly exports are stale, and a whole separate agent is overkill when all you need is a few tools.
| Mechanism | Use when | Main risk |
|---|---|---|
| Direct API | Your code owns the integration inside one app | None specific; you control the surface |
| CLI | A coding agent already has shell access | Shell access is a broad permission |
| MCP | Reusable typed tools shared by many clients | Capability bloat from too many tools |
| A2A | Another team or vendor runs an opaque agent | Untrusted results and unclear task contracts |
A second worked example from the certification material: a procurement agent must agree delivery dates with a supplier that runs its own AI agent with private negotiation logic and will not expose its internal systems. The answer is A2A. You do not call the supplier's functions, you talk to its agent. Scraping their website hourly is less integration, more stalking.
When you do connect to another agent, treat it as a network boundary. Authenticate both sides before any task is exchanged, share only the data the task needs, and treat returned content as untrusted data rather than instructions. Agree the task and result format up front, and set timeouts with a fallback for silence.
What does capability bloat look like on a real tool server?
Capability bloat means an agent can do far more than its job requires. In a mock support desk built for the demo, 12 MCP tools included order lookup alongside refunds, account deletion, a full customer export, admin password resets, and a raw SQL tool pointing at production. Only the first few matched what a support bot actually needs. Each extra tool sits one clever prompt away from a bad outcome.
The same refund request produced the same safe outcome twice. With all 12 tools offered, the model checked order 1042, saw it was still out for delivery, and declined to refund. Good judgment, but the architect's question is whether you would bet the company on judgment, because that is a control you cannot audit. With only three least-privilege tools offered, the refund became technically impossible rather than merely unlikely, which is the difference between a behavior you hope for and a control you can defend in a security review.
The cost of bloat shows up in three places: a larger attack surface, worse tool selection as the list grows, and more tokens spent on every request. Removing a capability removes the risk. A prompt instruction asking the model to avoid a tool is a suggestion, and logging only records damage after it happens. A smarter model with write access is still a model with write access.
A related exam scenario: an internal analytics agent has a runSQL tool with write access to production and is only ever used for monthly reports. The fix is to narrow it to read-only report tools against a reporting replica, so the capability the role does not need stops existing.
How should tools be designed so the model uses them well?
Design each tool for one narrow job, then state in its description what it does, when to use it, and when not to. Clear names and scoped inputs beat generic power. Get order status is a better tool than run SQL, and typed validated inputs with obvious formats prevent a class of errors before the model can make them.
Tool returns land in the model's context, so return only what the step needs, with limits and pagination. Helpful errors that explain how to recover keep an agent on track. Irreversible writes should be idempotent where possible, offer a dry-run mode, and sit behind human confirmation or a separate tightly controlled agent.
Role-based tool sets follow from the same principle. Each agent should receive only its own job's tools, read permissions should be split from write permissions, and tool sets deserve the same review cycle as cloud permissions. The model never decides who someone is; the platform does, and the tools enforce it.
Authentication and authorization: where do agent identity gaps appear?
Authentication answers who the user or service is. Authorization answers what they may do and to which data. For agents the decisive question is whose identity the agent carries. Under delegated access the agent acts on behalf of a signed-in user with that user's permissions, and service accounts stay limited to system tasks with tight scope.
The MCP specification's authorization guidance applies OAuth to HTTP transports, with HTTPS required. The security best practices page states that tokens must be bound to their intended audience, servers must validate that a token was issued for them, and token passthrough is forbidden. Local stdio servers take credentials from the environment rather than from the conversation.
The identity gaps to look for are consistent across reviews: one shared super-user account for every request, identity taken from the prompt ("I'm the admin"), secrets sitting in prompts, tool output or logs, token passthrough where a server forwards the user's token to other services, and authorization checked by the prompt instead of by the tool or the API.
A secure path has four steps, and the model appears in none of them:
- The user signs in with SSO, and the application holds the session.
- The MCP client receives a user-scoped OAuth token.
- The MCP server validates the token's audience and scopes.
- The backend enforces per-customer access on every call.
A demo showed the last step in code. The application set the signed-in customer in the server environment, and every order tool checked that the order belonged to that customer. The session was customer C-100, and a message claimed to be the store administrator and asked for order 1043, which belonged to someone else. The tool refused in code, not authorized, and Claude explained it could not verify admin access in a chat. The same session still had broader tools available, including the raw SQL and export tools, which shows why enforcement and removal are separate jobs: they were offered, just not allowed.
The two changes that close it are delegated user-scoped tokens, so the agent can never do more than the customer could, and authorization enforced in the tools and APIs on every call based on the authenticated session rather than on the text.
Which integration config flaws break a deployment?
A configuration can look ordinary and still open six holes at once. The demo config carried a live API key in the file, plain HTTP to a CRM, a production database with admin credentials and a password of admin123, an email server sending as the CEO, blanket shell and MCP permissions, and one shared config for every agent committed to git.
Each flaw maps to a specific fix. The corrected version used HTTPS with per-user OAuth handled by the client, so no key sat in the file. The database server became read-only against a reporting replica with its connection string read from the environment. The email server disappeared because the role did not need it, only two named tools were allowed, and each role got its own config.
Secrets follow the same discipline. Keep them in a vault or the environment, injected at runtime. Prefer short-lived scoped tokens over long-lived keys. Never put secrets in prompts, tool output, or logs, redact sensitive fields before results reach the model, and rotate credentials with alerts on unusual use.
Local versus remote MCP servers is the other structural choice. A local server runs as a process on the same machine as the client and takes its credentials from the environment. A remote server is a shared service that many clients connect to over HTTP, with per-user OAuth tokens over HTTPS. Anthropic documents this model in its MCP connector and authentication material, where remote servers use per-user OAuth and local servers read environment credentials. Enterprises usually favor remote servers for shared systems because audit and updates live in one place.
How does progressive discovery cut tool context cost?
Progressive discovery keeps a small index of tools in context and loads full definitions only when a step needs them. Anthropic tool search tool documentation reports that a typical multi-server setup can spend roughly 55,000 tokens on tool definitions before Claude does any work, and that tool search typically cuts that figure by more than 85 percent.
Those numbers are Anthropic-reported documentation figures, not an independent benchmark, and they describe tool definitions rather than total request size. The same documentation notes that tool selection accuracy degrades once an agent faces roughly 30 to 50 tools, which is the failure mode progressive discovery addresses. The catch is that tools need clear names and descriptions, or they cannot be found in the index.
Monolithic context is not always wrong. It suits a handful of tools that most requests use anyway, a small stable reference document that caches well, or a latency-critical path where an extra search step costs too much. The rule is to measure tokens and accuracy, then decide.
Live behavior matched the pattern. With 42 tools available, including built-in tools and the 12 support tools, Claude Code loaded exactly one definition, get order status, and called it. The same on-demand idea appears in skills that load a description before a body, retrieval that fetches relevant chunks per question, subagents that read heavily in a separate context, and MCP resources that are listed first and read only when needed.
What does a full architecture look like when the pieces combine?
A claims assistant shows how the mechanisms divide the work. The adjuster signs in with SSO, the claims app holds the session, MCP servers expose the policy system as read-only and the claim system with writes behind approval, and a partner body shop that runs its own agent is reached over A2A to book repairs. Every call is logged with the user and the scope.
Why each choice: MCP for your own systems because it is reusable, scoped and discoverable; A2A for the partner because it is their agent with their own private logic; delegated tokens so the agent never exceeds the adjuster's rights; writes behind approval so payouts stay a human decision; and an audit trail that answers who did what, when, and with which permission.
How should integrations fail?
Integrations fail, so design for the failure. The workable defaults:
- Slow dependencies: set time budgets and fail fast.
- Rate limits: back off, queue, and spread the load.
- Partial failures: retries are only safe with idempotent writes.
- Dependency outages: circuit breakers and graceful fallbacks.
- Bad data from a tool: validate it before the model trusts it.
FAQ
Is MCP a replacement for direct API calls? No. MCP exposes reusable typed tools that many clients can share, while a direct API call keeps the integration inside one application where your code controls it. Use MCP when several clients need the same capability, and an API when one app owns the workflow.
What is the difference between MCP and A2A in one sentence? MCP connects an agent to tools and data, while A2A connects agents to other agents. A2A applies when the other side owns private logic you cannot inspect, such as a supplier's own agent negotiating delivery dates.
Where should agent authorization be enforced? In the tool and API layer on every call, based on the authenticated session rather than on text in the prompt. Tokens must be audience-bound, passthrough is forbidden by the MCP specification, and a shared super-user account for every customer defeats per-user scoping.
Does progressive discovery work for every agent? It helps most when an agent has access to many tools or large reference documents. For a small stable tool set on a latency-critical path, loading everything up front can stay the simpler choice, so measure tokens and selection accuracy before switching.
How do you close integration gaps found in a config review? Replace embedded keys with per-user OAuth over HTTPS, read database credentials from the environment against a read-only replica, remove servers the role does not need, allow named tools only, and keep a separate config per role.
Turning an agent architecture walkthrough into a written article
The lesson running through this walkthrough is that the integration mechanism sets the shape of the risk. MCP, A2A, and direct APIs each move the boundary somewhere different, and least privilege, platform-issued identity, and on-demand tool loading decide whether that boundary holds under a hostile prompt. The trap list is short: tools the role never needs, generic tools instead of narrow ones, identity decided by the prompt, secrets in prompts, token passthrough, shared super-user accounts, and loading every tool on every request.
If you have recorded that kind of walkthrough, with a demo server, a config review, or a live test where a tool refuses a request, the same reasoning can serve readers who will never watch the video. Gustavo dev doido and other practitioners publish long technical explanations on YouTube where much of the value sits in the sequence of decisions rather than the conclusion.
Skalablog turns a YouTube video into a draft article: paste the URL, transcribe the video, and get a structured piece you can edit before publishing.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits