Three Ways an Agent Reaches Beyond Itself: Tools, MCP, and A2A

A language model, on its own, only produces text. Everything an agent does beyond that — searching the web, querying a database, executing a trade, delegating a task to another system — happens because something extends the agent beyond plain text generation. There are three distinct mechanisms for doing this, and understanding the differences between them is one of the more practically useful pieces of architecture in the whole field, because choosing the wrong one for a given job creates real complexity later.

Tools: reaching in-process

A tool is a discrete, atomic function an agent can invoke in-context to extend its capabilities — a web search, a file read, a database query. The defining trait of a tool is that it runs in-process: the function's code lives inside the same application as the agent runtime, so calling it is a single hop with no protocol boundary to cross. It's worth being precise about what "in-process" does and doesn't mean: a tool's own function body is entirely free to make an outbound network call inside itself — hitting a weather API, say — without that turning it into the second mechanism, MCP. What makes something a direct tool rather than an MCP-exposed one is who owns the process boundary and the schema, not whether the underlying work happens to touch the network.

MCP: reaching out-of-process, over a protocol

The Model Context Protocol (MCP) extends an agent out-of-process: a separate program exposes tools over a standard protocol, discovered dynamically at runtime rather than hardcoded in advance. Where a direct tool call is one hop, an MCP call typically involves four: the model emits a tool call, the host sends a JSON-RPC request to the MCP server, that server does the actual work, and the result travels back the same two hops in reverse. Every one of those additional hops is a real round trip — the practical cost of the protocol boundary MCP introduces. What that boundary buys in return is real too: tools discovered dynamically at session start rather than compiled into the application, and scoped permissions per server, so an agent's reach can be extended without recompiling anything or granting blanket access to everything a server happens to expose.

A2A: reaching sideways, to another agent

The Agent2Agent (A2A) protocol lets one agent delegate a task to another agent, built on a completely different framework, without either side needing to know anything about the other's internal implementation. Where Tools and MCP both reach "downward" — an agent extending itself with a capability — A2A reaches "sideways," to a peer. The mechanics rest on two primitives worth knowing by name: an Agent Card is a JSON discovery document, served at a conventional address, that functions like a digital business card for the agent — what it can do, where to send requests, how to authenticate. An Agent Skill describes one specific capability the agent is good at — the unit a Host Agent matches against when deciding which Remote Agent to route work to. The parallel to MCP is worth drawing explicitly: an MCP server advertises its tools so a host can discover and call them; an A2A Agent Card advertises an entire agent's skills so another agent can discover and delegate to it.

Choosing between the three

In practice, the choice is rarely difficult once the distinction is clear. If the capability is something your own application owns and can execute in-process, a direct tool is simplest and fastest. If the capability lives behind a separate system that should be discoverable and swappable without redeploying your agent, MCP is the right shape — and in an enterprise setting, MCP is usually the right boundary wherever an agent crosses a system-ownership line, since permissions and audit are enforced at the protocol boundary instead of buried in application code. And if the actual unit of work belongs to another autonomous agent, A2A is what lets you delegate to it as a peer rather than awkwardly wrapping it as if it were a plain function.