MCP and A2A are not competing standards. MCP lets an agent call a tool. A2A lets an agent delegate a task to another agent. The A2A documentation states the split directly: "A2A connects the agents to each other; MCP connects each agent to its own tools."
That single distinction decides which protocol belongs in front of a document generation API. This article checks both protocols against their primary sources, compares them on eight dimensions, and then answers the practical question: for a PDF generation service like PDF4.dev, what do you expose, and when. If you want the MCP mechanics first, read what the Model Context Protocol is and how to use it for PDF generation.
What does MCP standardize?
MCP standardizes the connection between one agent and the tools, data, and prompts it uses. Anthropic released it in November 2024 and contributed it to the Linux Foundation, where it anchored the formation of the Agentic AI Foundation in December 2025.
The current protocol revision is 2026-07-28. That revision is stateless by design: "Every request declares the protocol version it is using via the io.modelcontextprotocol/protocolVersion key in its _meta field, and the server accepts or rejects each request independently." There is no initialize handshake and no session identifier to carry. A client that wants to know a server's capabilities up front calls server/discover, a mandatory RPC that returns supported versions, capabilities, and identity in one request, and calling it is optional.
The A2A docs describe what lives behind MCP well: tools and resources "are typically primitives with well-defined, structured inputs and outputs. They perform specific, often stateless, functions."
That is a fair description of a PDF render. Give it HTML or a template id plus data, get back bytes. Nothing to negotiate.
What does A2A standardize?
A2A standardizes how one autonomous agent hands work to another autonomous agent across an organizational boundary. Google announced it in April 2025 and donated it to the Linux Foundation on June 23, 2025 at the Open Source Summit North America, alongside AWS, Cisco, Microsoft, Salesforce, SAP and ServiceNow. On August 27, 2026 the project joined the Agentic AI Foundation as a Growth Stage project, putting A2A and MCP under the same Linux Foundation umbrella.
The current version is 1.0, announced on March 12, 2026 as the first stable, production-ready release, with three protocol bindings (JSON-RPC, gRPC, HTTP+JSON/REST), signed Agent Cards, and SDKs in Python, Go, Java, JavaScript, .NET and Rust. The steering committee lists representatives from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow.
Four terms carry the protocol, quoted from the A2A specification:
- Agent Card: "A JSON metadata document published by an A2A Server, describing its identity, capabilities, skills, service endpoint, and authentication requirements." By convention it sits at
/.well-known/agent-card.json, per RFC 8615. - Task: "The fundamental unit of work managed by A2A, identified by a unique ID. Tasks are stateful and progress through a defined lifecycle."
- Message: "A communication turn between a client and a remote agent, having a
role('user' or 'agent') and containing one or moreParts." - Artifact: "An output (e.g., a document, image, structured data) generated by the agent as a result of a task, composed of
Parts."
A Task walks through eight declared states: submitted, working, completed, failed, canceled, input-required, rejected, auth-required. Two of those, input-required and auth-required, are interrupted states rather than terminal ones. That is the shape of work that pauses, asks a question, and resumes.
The binding-independent operations include SendMessage, SendStreamingMessage, GetTask, ListTasks, CancelTask, SubscribeToTask, and four push-notification config operations for webhook delivery. Long work is a first-class citizen, not an afterthought.
MCP vs A2A: the full comparison
| Dimension | MCP | A2A |
|---|---|---|
| Purpose | Give one agent access to tools, data and prompts | Let one agent delegate work to another agent |
| Who talks to whom | Agent to tool, vertical | Agent to agent, horizontal, across vendor and org boundaries |
| Transport | STDIO for local servers, Streamable HTTP for remote ones | Three bindings in v1.0: JSON-RPC 2.0, gRPC, HTTP+JSON/REST, all over HTTP(S) |
| Discovery | tools/list at connection time, plus server/discover for versions and capabilities in revision 2026-07-28 | Agent Card fetched from /.well-known/agent-card.json, from a curated registry, or by direct configuration |
| State | Stateless in the current revision. State spanning requests is referenced by an explicit identifier the client passes each time | Stateful by design. A Task has an ID, a lifecycle and eight declared states, and follow-up turns reuse the same context id |
| Long-running work | Not the native shape. A tool call returns a result | Native. Streaming via SendStreamingMessage, resubscription via SubscribeToTask, and webhook push notification configs per task |
| Authentication | HTTP headers at the transport level, typically a bearer token, so the key never enters the model's context | Declared in the Agent Card. The spec lists API key, HTTP auth, OAuth 2.0, OpenID Connect and mutual TLS schemes, plus an auth-required task state |
| Maturity and governance | Revision 2026-07-28 is current. Anthropic contribution, now at the Agentic AI Foundation under the Linux Foundation | v1.0 since March 12, 2026. Google contribution, Linux Foundation since June 2025, Growth Stage at the Agentic AI Foundation since August 2026 |
| Client support | Broad: Claude, ChatGPT, Cursor, VS Code, Windsurf, Codex CLI, Gemini CLI | More than 150 organizations supporting the standard as of April 9, 2026, with platform integrations at Google, Microsoft and AWS |
The two are explicitly complementary. The Linux Foundation states it plainly: "A2A defines how agents communicate and coordinate with each other across organizational boundaries, while MCP defines how agents connect to internal tools and data sources."
Why "a sales agent asks a document agent for an invoice" is an A2A case
This scenario is the clearest test of the boundary, and most people get it backwards.
If a sales agent calls render_pdf with a template id and a data object, that is MCP. The sales agent is doing the work. The PDF service is a function it invokes. Nothing on the other end reasons, plans, or holds an opinion about the document.
If a sales agent says "produce the September invoice for Acme" to a separate documents agent that owns the billing templates, looks up the account, decides whether a credit note applies, chooses the right legal footer for the jurisdiction, and comes back three minutes later with a signed PDF, that is A2A. The receiving side is an agent with its own judgment and its own state, not a parameterized endpoint. The request is a Task. The finished PDF is an Artifact. The moment the documents agent needs a missing VAT number, the Task moves to input-required rather than failing.
A useful rule: if you can write the full request as a JSON object with typed fields, it is a tool call and MCP fits. If the request needs a sentence, and the answer may take turns, it is a delegation and A2A fits.
The A2A docs frame the same idea in human terms: "It is closer to how one person reaches out to another for help: 'Are you working on this project? Do you know about it? Can you share what you have, and if not, which agent can?'"
What should a PDF generation API expose?
For a PDF generation API, MCP is the correct layer today, and the reason is structural rather than a matter of taste.
A render is a bounded transformation. The inputs are a template id or raw HTML, a data object, a page format, and a delivery mode. The output is a PDF plus its size and duration. There is no negotiation, no multi-turn dialogue, no judgment call about scope. That is a tool, and MCP's stateless request-response model matches it exactly. Wrapping it in an A2A Task would add a lifecycle, a task store, a polling or streaming channel and an Agent Card to maintain, in exchange for no capability the caller actually needs.
Render latency reinforces the point. A PDF4.dev render takes roughly 200 to 500 milliseconds with a warm browser pool. Task states, resubscription and webhook push configs exist for work that outlives the request. A sub-second render does not.
What PDF4.dev exposes today
PDF4.dev ships an MCP server at https://pdf4.dev/api/mcp over Streamable HTTP, with 14 tools covering rendering, template CRUD, component CRUD and generation logs, plus 4 documentation resources and 3 prompts. Every tool carries annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) so clients can auto-approve reads and confirm deletes. The build details are in how we built an MCP server for PDF generation.
There is no A2A implementation. No Agent Card, no Task store, no /.well-known/agent-card.json. Saying otherwise would be easy and wrong. The honest version is that PDF4.dev is a tool in the A2A sense, not a peer agent, and the protocol that describes a tool is MCP.
When A2A would become the right layer
A2A starts to earn its complexity when the document work stops being a single call. Three concrete triggers:
- The job has its own lifecycle. Assembling a 200-page tender response from a contract database, a pricing engine and a compliance reviewer is not one render. It is a Task with intermediate states, partial Artifacts and a real chance of pausing on input-required.
- The work crosses an organizational boundary. A customer's procurement agent talking to a supplier's billing agent is exactly the cross-vendor peer-to-peer case A2A was built for, with the Agent Card declaring skills and auth scheme up front and signed cards proving the card came from the domain owner.
- A human sits in the loop. Waiting on a legal signature, a manager approval or a compliance review is minutes to days of suspended work. The auth-required and input-required states, plus push notification configs, model that natively. A stateless tool call does not.
If PDF4.dev ever grows a document agent that plans a multi-source deliverable rather than rendering one that is handed to it, that agent would publish an Agent Card and speak A2A, while continuing to call its own MCP tools underneath. That is the layering both projects describe, and it is the reason adopting one has never required dropping the other.
Can one service speak both protocols?
Yes, and the two do not collide, because they occupy different layers. The A2A documentation makes the geometry explicit: "MCP is vertical. It deepens a single agent." and "A2A is horizontal. It connects agents across that boundary."
A service that does both looks like this: an Agent Card at the well-known path advertising what the agent can do and how to authenticate, an A2A endpoint accepting SendMessage and returning Tasks and Artifacts, and, behind that agent, an ordinary MCP client calling render, template and storage tools. Peers see one agent. The agent sees a toolbox.
The practical advice for anyone exposing an API to agents in 2026 is unchanged by A2A's arrival. Ship MCP first, because that is what every major AI client speaks today and because most APIs are tools. Reach for A2A when your service starts making decisions instead of executing instructions.
Convert HTML to PDF, freeTry it freeFree tools mentioned:
Start generating PDFs
Build PDF templates with a visual editor. Render them via API from any language in ~300ms.
