MCP and A2A as Context Engineering Infrastructure

Why Protocols Matter for Context Engineering

Before MCP, context assembly was ad-hoc. Each application wrote its own code to gather files, query databases, call APIs, and assemble the results into a prompt; the context engineering decisions were buried in application code, invisible to anyone who didn’t read the source.

MCP and A2A change this by moving context decisions to the protocol level, where they become explicit, inspectable, and reusable. An MCP server’s tool descriptions, resource endpoints, and prompt templates are context engineering decisions that any client can consume. An A2A agent card is a context handoff contract that specifies what an agent needs to receive and what it will return. The protocols don’t eliminate the need for context engineering; they formalize it.

MCP Tool Descriptions as Context Engineering

Every MCP server exposes tools with descriptions, and those descriptions are context. They enter the model’s context window alongside the system prompt and conversation history, which means a badly written tool description wastes tokens and confuses the model about when to use the tool; a well-written one guides behavior as well as a system prompt instruction.

This is the Tool Descriptions pattern implemented at the protocol level. The description tells the model what the tool does, when to use it, when not to use it, and what the parameters mean. But MCP adds a dimension that direct function calling doesn’t: the descriptions come from an external server, which means the application developer doesn’t necessarily control them.

{
  "name": "search_documents",
  "description": "Search the knowledge base for documents matching a query. Use this when the user asks about company policies, procedures, or technical documentation. Do not use for general knowledge questions that don't relate to internal documents. Returns top 5 results with relevance scores.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "Natural language search query. Be specific; 'vacation policy' works better than 'policy'."
      }
    }
  }
}

That description is ~80 tokens. It enters the context window of every conversation where this server is connected, regardless of whether the user’s current query involves document search at all. Connect 5-10 MCP servers and tool descriptions alone consume 500-1000 tokens. Every word in a tool description competes with every other token in the window, making description economy a protocol-level context engineering concern.

Resources as Progressive Disclosure

MCP resources are the protocol’s answer to the “should I pre-load or load on demand” question. A resource endpoint exposes data that the model can request when it needs it, rather than requiring the application to predict what data the model will need and pre-load it.

This is Progressive Disclosure as a protocol primitive. The model sees a list of available resources (a lightweight index) and can request specific ones when the task requires them. A file system MCP server exposes the directory structure as a resource listing; the model reads specific files only when it needs their contents. A database server exposes table schemas; the model queries specific tables on demand.

The context engineering benefit is substantial. Without resources, the application either pre-loads data (wasting tokens on unused content) or requires the user to specify exactly what to include (shifting context engineering to the user). Resources let the model participate in its own context assembly. It requests what it determines is relevant rather than getting everything upfront.

The risk is equally real: models over-fetch. Given access to resource endpoints, a model will pull in data it thinks might be useful, filling its context window with low-relevance content. The same Select, Don’t Dump discipline applies: the model needs guidance on when to read resources and how much to read.

A2A Agent Cards as Handoff Contracts

Google’s Agent-to-Agent protocol introduces agent cards: structured descriptions of what an agent can do, what inputs it expects, and what outputs it produces. From a context engineering perspective, an agent card is a Context Handoff contract that formalizes the boundary between agents.

An agent card specifies the agent’s capabilities (what tasks it handles, in enough detail for a calling agent to decide whether to delegate), its input schema (what context it expects, including required and optional fields), and its output schema (what it will return, structured so the calling agent can integrate results without parsing unstructured text).

This is the handoff problem solved at the protocol level. Instead of each multi-agent system designing its own context passing format, A2A provides a standard contract: the calling agent knows what to send because the agent card specifies it, and the receiving agent knows what it will get because the input schema guarantees it.

Protocol Constraints as Context Engineering

The most underappreciated aspect of both protocols is that their constraints force good context engineering practices. MCP servers must describe their tools in a structured format, which means someone has to think about what each description says. A2A agent cards must declare input and output schemas, which forces explicit decisions about what context crosses agent boundaries.

Compare this with ad-hoc context assembly, where context decisions are implicit. A function that reads three files and concatenates them into a prompt has made context engineering decisions (which files, what order, how much), but those decisions are invisible. An MCP server that exposes the same data as resources has made the same decisions explicitly, in a format that any client can inspect and any developer can review.

The protocol overhead is real: writing good MCP tool descriptions takes effort, designing A2A agent cards requires thinking about handoff contracts upfront, and the indirection adds latency. But the overhead buys visibility into context engineering decisions that would otherwise be buried in application code, and visibility is the first step toward systematic improvement.

When to Use Each

MCP when the context source is data or tools that multiple clients might consume. A database, a file system, an API: these are naturally MCP servers because the context they provide is useful across different applications.

A2A when the context challenge is agent-to-agent coordination. Research agents delegating to specialist agents, support workflows escalating between tiers, multi-step processes where each step is handled by a different agent with different capabilities.

Direct function calling when the tool is tightly coupled to the application, the description is simple, and the overhead of a protocol server isn’t justified. Not everything needs to be an MCP server; a tool that formats dates doesn’t need a protocol layer.