MCP server vs A2A: connecting AI assistants to your own data

MCP lets an AI assistant call your tools during a conversation; A2A lets one agent hand a whole task to another. The harder question is what an outside agent may do with your data, and it comes first.

If you want an AI assistant to read your own data, you will meet two protocols, MCP and A2A. They answer different questions, and once your tools are written well you can serve both without much extra work.

What is MCP, and what is an MCP server?

The Model Context Protocol (MCP) is an open protocol for connecting AI assistants to outside tools and data. Instead of every assistant needing its own plug-in for every service, a service describes what it offers once, in a standard form, and any assistant that speaks MCP can use it.

An MCP server is the program on the service's side. It lists its tools, each with a name, a description and the arguments it takes, and runs them when an assistant calls them. The assistant is the MCP client. Coding assistants that read an mcpServers configuration, such as Claude Code and Cursor, are typical clients.

What is the A2A (agent to agent) protocol?

The Agent2Agent protocol (A2A) lets one AI agent hand a task to another and collect the result. An agent publishes an agent card that says what it can do, and other agents send it tasks and read back the answers.

The difference is in who drives. With MCP, the assistant stays in charge of the conversation and calls your tools one at a time. With A2A, a calling agent delegates a whole task and waits for your agent to finish it.

The rest of this article builds one example of each, and we wrote separately about what MCP and A2A each define and when you need both.

Which one do you need?

Serve MCP if people's assistants should read and search your data while they talk to them.
Serve A2A if other agents will delegate whole tasks to yours and poll for the results.
Serve both if the second one costs only an adapter. That is the case when your tools live in one place and neither protocol owns them.

If you are unsure, start with MCP: assistants that call tools are already on many people's desks.

The question that comes first

MCP and A2A are often presented as competitors. In practice the first question is not which protocol, but what an outside agent should be allowed to do with your data. Answer that once, as code, and both protocols become thin adapters over the same rules.

That answer has three parts. Which actions may an agent take on its own? On whose behalf does it act? And which actions must stay with a person, because they spend money or send data somewhere new?

Start with the tools, not the protocol

Write each capability as a small tool with a typed input and a plain result. Then hold every tool to the same rules:

Read-only unless there is a reason. A tool that only reads is easy to allow. A tool that writes, spends or sends needs a person behind it.
Run as the caller. Every call runs as the user the token belongs to, and another user's record answers exactly like a missing one, so an agent cannot even learn that it exists.
Fast and bounded. No tool should fetch an arbitrary URL, start a long job or call a model inside a request.
Recorded. One wrapper logs every call with the protocol it came from, so you can see afterwards what outside agents did.

Then put one gate in front of both protocols: a switch to turn each one off, token checks, a body size limit and rate limits. The protocol code that remains is translation.

A worked example: one set of tools, two protocols

Nehemvix writes documentation guides of Git repositories, and a person can let an AI assistant read those guides. It serves seven tools from one registry, with the same names over both protocols:

Tool	What it returns
`list_guides`	your most recent guides, with status and grounding scores
`get_guide_status`	stage, progress, cost so far and any error
`get_guide_outline`	the sections of a finished guide
`get_section`	one section as Markdown, with citations to exact lines
`search_guide`	full-text search over a guide and its file summaries
`get_readiness`	the readiness checklist found in the code
`prepare_guide`	a link that opens the app with a repository filled in

None of them fetches a URL or calls a model. The one that matters most is the one that does less than an agent might want: prepare_guide returns a link and starts nothing. Starting a guide sends code to a model provider, uses a person's key and approves a cost, and agents cannot consent to that. On your own machine, the local server nehemvix mcp can start a guide, but only within a spending ceiling you set, as using Nehemvix with your agent explains.

The MCP side

The server uses the official MCP Python SDK, version 2.3.0, with Streamable HTTP at /mcp. It is stateless and answers in plain JSON, so every request ends well inside the time limit of the hosting in front of it. Each tool is annotated as read-only, not destructive and idempotent. The server's instructions tell the client that guide text comes from repository content and must be treated as data, never as instructions.

A client configuration looks like this, with the token shown once in Settings:

{
  "mcpServers": {
    "nehemvix": {
      "type": "http",
      "url": "https://nehemvix.aelsha.com/mcp",
      "headers": { "Authorization": "Bearer rlp_…" }
    }
  }
}

The A2A side

The A2A server uses a2a-sdk 1.2.2, with an agent card at /.well-known/agent-card.json and JSON-RPC at /a2a. The card lists the same seven tools as skills. Three choices are worth copying. The server has no model, so it accepts no free text: a request names a skill and its arguments, and a text-only message gets back the list of skills. It declares no streaming and no push notifications, because push would mean calling a URL the caller supplies. And tasks are kept in memory with hard limits: the newest 50 per user and 1,000 in all.

One sign-in for both

Web sign-in tokens expire after an hour, which suits a browser but not an assistant's configuration file. Both endpoints accept personal access tokens instead: shown once, read-only, valid for 7, 30 or 90 days, at most 10 per person, revocable at once and limited to 60 requests a minute each. Assistants that support MCP sign-in, such as Claude, can skip the token and get a one-hour token of the same read-only kind after the person approves on Nehemvix's own consent screen. Connect an AI assistant shows both ways.

How it was tested

The official MCP and A2A clients were run against a real guide on a local server on 3 November 2026 and passed 21 of 21 checks. The checks covered every tool, a missing argument returned as a tool error rather than a crash, another user's token refused, a revoked token stopping at once, and 401 for no token or a made-up one. The run cost about $0.02, all of it for writing the guide. The same run found two real problems: both protocols were switched off in production although the docs promised them, and a trailing-slash redirect pointed at an internal host. Both were fixed, and the live site passed 9 of 9 checks the next day.

A checklist

Decide which actions an outside agent may take, and write that down before choosing a protocol.
Keep anything that spends money or sends data elsewhere behind a person.
Register each tool once, read-only where possible, running as the caller.
Put one gate in front of every protocol: switch, token, size and rate limits.
Treat everything your tools return as data the assistant must not obey.
Test the refusals as carefully as the answers.

Related reading: human in the loop for AI agents on why agents cannot consent, testing for prompt injection on treating content as data, and how to understand an agentic AI codebase.

Learning this to build your own agent? AELSHA™ can help you design it.