SSOGEN / Learn / A2A vs MCP: What Each Protocol Does and Where Identity Fits

Compare

A2A vs MCP: What Each Protocol Does and Where Identity Fits

MCP connects an agent to tools with a name and a schema, A2A connects it to another agent, and most real systems run both side by side.

Request a Quote

Read the two specifications as one table, row by row.

A2A vs MCP comes down to what is on the other end of the connection. The Model Context Protocol (MCP) links an AI agent to tools and data: a function with a name, an input schema and a result. The Agent2Agent protocol (A2A) links an agent to another agent. That one can reason, ask follow-up questions and take its time.

The A2A project puts it this way on A2A and MCP (read 2026-10-08). MCP is vertical: it gives one agent more depth. A2A is horizontal: it connects agents across a boundary. Real systems often run both.

Below, we compare the two from their specifications, then look at where identity and authorization fit in each.

What MCP does

With MCP, a client finds and calls the tools a server offers. Each tool has a name, a description and an inputSchema in JSON Schema.

Discovery. The client sends tools/list to see what tools exist.
Call. The client sends tools/call with a tool name and arguments to run one.
One round trip. A tool call is one request and one response.
Result. The server returns content, optionally structuredContent, and sets isError if the call failed.
Model-controlled. Tools are model-controlled, the specification says.
Human in the loop. The specification says a human should always be able to deny a tool invocation.

This is from the MCP specification on tools, revision 2026-07-28, read 2026-10-08.

What A2A does

A2A is for independent agents. Different teams may build them on different frameworks, and they keep their internals hidden. This is from the A2A specification, version 1.0.0, read 2026-10-08.

Agent Card. Each agent publishes a card at /.well-known/agent-card.json. The card lists the agent’s name, skills, endpoint and required security schemes.

Task. Work in A2A is a task with a lifecycle. The states include TASK_STATE_SUBMITTED, TASK_STATE_WORKING, TASK_STATE_COMPLETED, TASK_STATE_FAILED, TASK_STATE_CANCELED and TASK_STATE_REJECTED.

Interrupted states. Two states interrupt a task: TASK_STATE_INPUT_REQUIRED and TASK_STATE_AUTH_REQUIRED.

Message. Agents exchange messages made of parts (text, files, structured data).

Binding. The specification defines three bindings: JSON-RPC, gRPC and HTTP with JSON.

A2A and MCP side by side

Every row is a fact stated in the specification named in the last column.

	MCP	A2A
What is on the other end	A server that exposes tools (and resources, prompts)	Another agent, treated as opaque
Unit of work	A tool call: `tools/call` with a tool `name` and `arguments`	A task with states from `TASK_STATE_SUBMITTED` to a terminal state
Discovery	`tools/list` after connecting	Agent Card at `/.well-known/agent-card.json`
Multi-turn	One request, one result (a server may ask for more input)	Built in: `TASK_STATE_INPUT_REQUIRED` and message exchange
Transport	JSON-RPC messages; HTTP-based transports can use authorization	JSON-RPC, gRPC or HTTP+JSON bindings
Authentication stated by the spec	Optional. HTTP transports should follow the OAuth-based flow	Declared in the card’s `securitySchemes`; servers must authenticate every request
Credential type named	OAuth 2.1 draft, bearer tokens in the `Authorization` header	API key, HTTP auth, OAuth 2.0, OpenID Connect, mutual TLS
Scope or permission model	Scopes in `WWW-Authenticate`; `403` with `insufficient_scope`	Not defined: the server authorizes by its own policies
Spec version read	2026-07-28	1.0.0

Do they compete or combine

They combine. The A2A project’s example is a repair-shop agent. It uses MCP to run diagnostic tools and pull up repair manuals. It uses A2A to talk to a shop-manager agent or a parts-supplier agent.

Its rule of thumb: MCP handles primitives with structured inputs and outputs; A2A handles autonomous systems that hold multi-turn dialogues.

Security teams care because a request can travel a chain:

A person asks agent A.
Agent A hands the work to agent B over A2A.
Agent B calls a tool over MCP.
At that last hop, the tool server still has to know which agent is calling, and for whom.

Where identity and authorization fit in MCP

MCP handles authorization at the transport level, and it is optional. The full flow is in MCP authentication.

Resource server. Over HTTP, an MCP server acts as an OAuth resource server, and a separate authorization server issues the tokens.
Resource parameter. The client sends a resource parameter naming the server it wants. The server must check that the token was issued for it.
Scopes. Scopes say what a token may do.
Insufficient scope. If a valid token is not enough, the server answers 403 with error="insufficient_scope" and the scope it needs.
Per-tool decisions. These are still on you. The specification says servers must implement proper access controls, and the tool list may change with the authorization presented. See MCP tool permissions.

Where identity and authorization fit in A2A

A2A leaves identity to established web schemes.

Transport. Section 7 of the specification says production deployments must use HTTPS (or TLS for gRPC).

Credentials. The client reads securitySchemes from the Agent Card and gets credentials out of band. The server authenticates every request.

Authorization. Section 7.5: the server authorizes requests based on the authenticated identity and its own policies. The protocol defines no scope vocabulary.

Auth required. TASK_STATE_AUTH_REQUIRED covers a task that needs authorization partway through. Per section 7.6, the state does not authorize anything by itself, and its meaning is implementation-defined.

Out of band. Credentials for an auth-required task should arrive out of band over a secure channel.

Questions to ask before you connect agents

Own identity. Does each agent have its own identity, or does it borrow a person’s password or a shared key?
Actor. When agent A calls agent B for a person, does the credential still name the person, and does it name agent A as the actor? OAuth token exchange is the standard way to carry that.
Bound key. Is the credential tied to a key the agent holds (DPoP), so a copied token fails?
Stop. Can you stop one agent, and how long until every enforcement point obeys?
Record. Is every decision recorded with the agent, the person and the tool?

The non-human identity explainer covers the identity side of these questions.

What SSOGEN offers for each protocol

SSOGEN enforces identity on the MCP hop. The MCP Gateway, a capability of the SSOGEN Gateway, sits in front of your MCP server and checks each tools/call against scopes you map to exact tool names.

DPoP only. It takes only DPoP-bound tokens and refuses plain bearer tokens.
Verified identity. Your server gets the agent’s verified identity in request headers, not the token.
Approval. Scopes marked Sensitive need a person’s approval every time.
Setup. Setup is in the Oracle EBS MCP guide, and the overview is on MCP Gateway.
Own identity in a chain. Whatever chain of agents a request passes through, the agent that reaches your tool server carries its own SSOGEN identity, bound to its key.

For the agent identity model (owners, keys, delegation, kill switches), see AI agent identity.

Questions people ask

Is A2A a replacement for MCP?

No. The A2A project describes them as complementary: MCP gives an agent access to tools, A2A lets agents work with each other.

No. The Agent Card declares schemes such as OAuth 2.0, OpenID Connect, API keys or mutual TLS, and the client gets credentials outside the protocol.

Does MCP require authentication?

Authorization is optional. When an HTTP-based server supports it, the specification says to follow its OAuth-based flow.

Which one does a tool server like invoices or purchase orders use?

MCP. A tool server exposes named functions. A2A is for another agent that holds a conversation about a task.

Where to go next

New to MCP. Start with what an MCP server is and MCP vs API.
The flow. Read MCP authentication.
Per-tool control. Read MCP tool permissions.
Sign-in. Read MCP SSO for how people and agents sign in to MCP servers.

Sources, all read 2026-10-08: A2A specification, A2A and MCP, MCP specification on tools.