The Protocol Layer: MCP, A2A, ACP, Skills

TL;DR MCP governs agent-to-tool, A2A governs agent-to-agent, Skills govern reusable knowledge. The test is whether the data changes: if it changes between calls you need MCP; if it's stable enough to write down, a skill file is simpler and has no runtime that can fail on its own.

#mcp #agent-skills #ai-agent #tool-use #llm

Table of Contents

From function calling to MCP: the path and the price
MCP's five primitives
A2A and ACP: how agents talk to each other
MCP vs Agent Skills: not the same problem
1. A corollary for anyone maintaining skills
Why screenshots and existing REST APIs aren't enough
The series
References

Series: The Agent Production Line (6 / 7)

Security: Prompt Injection Can Only Be Contained in the Harness Three Shapes of RAG and the Evaluator Paradox

🌏 中文版

Part 1 placed MCP as "the standard interface for how an LLM uses tools" without elaborating. This part covers the protocol layer — what it solved, what it cost, and why Skills are not a competitor to MCP.

From function calling to MCP: the path and the price

Connecting LLMs to the Real World tells this history most completely:

Mid-2023, function calling became a first-class feature of the OpenAI API — the model emits a structured intent to call something, the application executes it
ChatGPT Plugins tried to productize this, but discovery was hard, quality was uneven, and the security model was immature; they were retired entirely in April 2024
Every vendor defined its own schema, producing the N×M problem: N agents against M backends, every pair implemented separately
MCP turned that into N+M: agents implement a client once, backends implement a server once, and one protocol sits between
Donated to the Agentic AI Foundation under the Linux Foundation at the end of 2025

Steps 3 to 4 are the whole value. It is the same category of move as ODBC for databases or LSP for editors — not making any single integration better, but turning the count of integrations from multiplication into addition.

The costs are real, and there are two:

September 2025 brought the first supply-chain attack targeting MCP: a package impersonating an official Postmark integration, quietly copying outgoing email. A widely adopted protocol is also a new, shared attack surface
Every tool definition consumes context. This is easy to underrate — an agent with dozens of MCP servers attached can burn a meaningful part of its context budget before doing any work, and Part 3 explained that this has quality consequences, not just cost

Pinterest's handling is worth borrowing: many small servers rather than one large one (different servers need different access controls), plus a central registry as the governance backbone — only registered servers count as production-approved. The registry is a gate, not a phone book.

MCP's five primitives

Most introductions stop at the Host / Client / Server roles, but the protocol defines five primitives across two sides.

The server provides:

Tools — actions that can be invoked
Resources — data that can be read
Prompts — prewritten templates

The client provides:

Roots — safe filesystem access boundaries
Sampling — the server asking the AI for help in return, for example generating a database query

Sampling's direction reversal is the notable one: rather than the agent calling the server, the server calls back for model assistance. That lets a server handle steps requiring language understanding without shipping its own model, keeping cost and API keys on the client side. Most MCP write-ups skip it entirely.

A2A and ACP: how agents talk to each other

MCP covers agent ↔ tool. Agent ↔ agent is a separate group of protocols:

	Covers	Discovery
MCP	agent ↔ tools	server declares tools / resources / prompts
A2A	agent ↔ agent	Agent Card, published at a well-known URL
ACP	REST-first agent ↔ agent	Agent Manifest, plain HTTP

A2A's flow is: discover peers via Agent Card → delegate a task → receive a structured result. If the peer needs more input mid-task it enters an input-required state and asks back. ACP took the REST route with synchronous responses or async SSE streaming, and has since been folded into A2A.

In production the two are complementary rather than competing: MCP governs tool access, A2A governs communication between agents.

MCP vs Agent Skills: not the same problem

These two get compared constantly, but they solve different problems. Five dimensions:

	MCP	Agent Skills
Integration	client-server protocol; N agents reach M backends through one interface	a folder plus `SKILL.md`, loaded when triggered
Architecture	separate process, own runtime, speaks JSON-RPC	just a directory: `SKILL.md` plus optional scripts / references / assets
Invocation	typed parameters, schema validation, composable	the agent reads `SKILL.md` and runs the bash / python / curl inside
Runtime	usually its own container or service	runs in the agent's own environment, no extra infrastructure
Fits	connecting to live systems and data	giving the agent reusable knowledge and procedures

A comment thread offered a better test than the article body:

If the data changes between calls, you need MCP (the agent needs live access). If the knowledge is stable enough to write down and still correct weeks later, a skill file is simpler and cheaper — and it doesn't require a runtime that can fail independently of the agent.

That last clause is the point. An MCP server is a separate process; it breaks on its own and needs its own deployment and monitoring. A markdown file does not.

The realistic answer is both: skills tell the agent how to think, MCP gives it live data to think about.

A corollary for anyone maintaining skills

The Skills loading model exists precisely to fight context dilution: the agent first receives a skills index containing only names and short descriptions, and only after choosing one does the full SKILL.md load. This is the same idea as OpenAI's deferred tool discovery.

The implication is direct: a SKILL.md's description field should be written as a retrieval key, not as a comment. It is the only part that enters the context before the skill is selected, so a vague description means the skill never gets selected.

LinkedIn goes further: they built a skill registry with similarity checking and human review to stop skills from proliferating. The direction is interesting too — moving from "application teams declare which skills they want" to "downstream systems declare which skills they provide, and applications discover them."

Why screenshots and existing REST APIs aren't enough

The Figma piece offers the most concrete argument for "why build an MCP server instead of using what exists":

Screenshots alone → the LLM has to guess values from pixels. It cannot tell 24px spacing from 20px, and the result "looks very similar but isn't the same"
The REST API alone → returns complete JSON, and it is too much data. A single page produces thousands of lines stuffed with pixel coordinates, visual effects and internal layout rules

MCP's value is returning a curated representation in between. That is also a good test for whether a given system needs an MCP server at all: is the existing interface too coarse (guessing) or too fine (drowning)? If it is already about right, you don't need one.

The series

Drawing the Lines: Agent, Workflow, RAG, and MCP
The Model Is a Component, the Harness Is the System
Context and Memory: Where Agents Actually Fail
Launch Is Where the Work Starts: Enterprise Cases Read Sideways
Security: Prompt Injection Can Only Be Contained in the Harness
The Protocol Layer: MCP, A2A, ACP, Skills (this post)
Three Shapes of RAG and the Evaluator Paradox