MCP Servers and Subagent Orchestration

An agent is only as useful as what it can see and touch. Two mechanisms extend that reach in orthogonal directions. The Model Context Protocol (MCP) extends what a single agent can act on — databases, ticket trackers, design tools, internal APIs — through a standard interface instead of a bespoke integration per tool. Subagents extend what a task can accomplish by splitting it across multiple agent instances, each with its own context window, run one after another for isolation or side-by-side for speed.

Both mechanisms solve a scaling problem, and both introduce a new failure surface once you use them for real work. This subject covers the mechanics of each, the trust boundary MCP crosses that local file edits don't, and how to design a multi-agent pipeline — using a code review system as the running example — that is faster and more reliable than one agent working alone.

What Is MCP and Why It Exists

Before MCP, connecting an agent to an external system meant writing a bespoke integration: a custom tool definition, a bespoke auth flow, bespoke error handling, one per (agent framework, external system) pair. If you have M agent frameworks and N tools you want them to reach, you end up building and maintaining roughly M \times N integrations — most of which duplicate the same plumbing (list available operations, validate arguments, execute, format a result the model can read) against a different pipe.

MCP is an open protocol that standardizes that pipe. A tool or data source implements the protocol once, as an MCP server. Any MCP-compatible agent — Claude Code, Claude.ai, or a third-party client — can connect to it without custom glue code. The official framing is deliberately mundane: MCP is "a USB-C port for AI applications" — a standard connector, not a smarter cable. The value isn't in any single connection; it's that the connector is the same everywhere, so the M \times N integration problem collapses to M + N: each server is built once, each client implements the protocol once, and the two sides are automatically compatible.

Without a standard protocol:              With MCP:

Agent A ──custom──> Database              Agent A ─┐
Agent A ──custom──> Ticket tracker        Agent B ─┼─ MCP ──> Database
Agent B ──custom──> Database              Agent C ─┘         (implements MCP once)
Agent B ──custom──> Design tool
Agent C ──custom──> Database              Agent A ─┐
Agent C ──custom──> Ticket tracker        Agent B ─┼─ MCP ──> Ticket tracker
                                           Agent C ─┘

M×N bespoke integrations                  M clients + N servers, each built once

This matters at the scale a platform like Claude Code operates at: it isn't one team building one integration to one internal database, it's an ecosystem where any team can stand up a server for their internal system and it becomes usable by every MCP client without asking the client's maintainers for anything.