Model Context Protocol

How it works

MCP separates the agent from the tools it uses by putting a standard interface between them. Instead of hand-wiring each integration into your loop, you run servers that expose capabilities, and a client — usually embedded in the harness or model runtime — that connects to them.

The exchange follows a small, predictable shape:

1. Connect. The client opens a session to a server over a defined transport (local process I/O or a network stream).
2. Discover. The server advertises what it offers: tools (callable functions), resources (readable data), and prompts (reusable templates), each with a name, description, and input schema.
3. Invoke. The model picks a tool, the client sends a typed request, the server executes and returns a structured result.
4. Repeat. Results feed back into the agent loop, which decides the next call.

The key move is that capability description is data the model reads at runtime, not code you compile against. A server can be swapped, versioned, or restricted without touching the agent. Because the interface is uniform, the same harness can talk to a filesystem server, a database server, and a SaaS API server through one contract instead of three integrations.

Why it matters in an agent harness

MCP matters because it turns the tool surface into something you can govern, not just something that grows. A protocol boundary is where control lives.

• Legible surface. Every capability the agent can reach is an enumerable, described server call. You can inventory the full tool surface instead of grepping for API clients scattered through the codebase.
• Enforceable permissions. Because access flows through a server the harness controls, you can scope, gate, or deny at the boundary — read-only servers, per-session credentials, human approval before a write server executes.
• Containment. A misbehaving or compromised server is a bounded blast radius. You can kill one connection without unwinding the agent.
• Swappability. Point the same agent at a mock server for evals, a sandboxed server for staging, and the real server in production. The loop doesn't change.

The failure mode MCP guards against is the sprawling, undocumented integration layer — the place where an agent quietly acquires powers nobody tracked. A protocol makes the surface explicit, and an explicit surface is one you can reason about.

MCP vs bespoke tool integrations

The distinction changes how you build. Bespoke integration is faster for the first tool and worse for the tenth.

Bespoke wins when you need one deep, tightly optimized integration and nothing else. MCP wins the moment the tool surface is plural, changing, or something you must audit.

The Rifty take

We treat the tool surface as a boundary to govern, not a feature to accumulate, and MCP is useful precisely because it makes that boundary explicit and inspectable. We optimize for a surface you can enumerate, scope, and swap — a read-only server in eval, a gated write server in production — and we accept the extra indirection of a protocol to get it. Standardizing how a tool is reached is worth more than the convenience of reaching one tool quickly, because control compounds and shortcuts don't.

Implementation checks

• Enumerate the surface. List every server and every tool the agent can reach; if you can't produce that list, the surface is already out of control.
• Scope credentials per server. Give each server the least privilege it needs; never hand the agent one key that unlocks everything.
• Separate read from write. Route destructive or state-changing servers through an approval gate; keep read servers freely callable.
• Trust tool descriptions carefully. A server's advertised tool descriptions enter the model's context — treat a third-party server's text as untrusted input, not instructions.
• Sandbox untrusted servers. Run servers you don't own with contained filesystem and network access so a bad one can't reach beyond its job.
• Version and pin. Track which server version an agent ran against so you can reproduce a trajectory and roll back a bad upgrade.
• Time out and budget. Cap latency and call counts per server so one slow or chatty tool can't stall or drain the loop.

Frequently asked questions

What problem does the Model Context Protocol actually solve?

MCP solves integration sprawl. Without it, every tool an agent uses is bespoke client code baked into the loop. MCP replaces that with a uniform server interface, so tools become swappable, describable, and governable at one boundary instead of scattered across the codebase.

How is MCP different from ordinary tool use or function calling?

Tool use is the general capability of an agent invoking functions; MCP is a specific open protocol for exposing and discovering those functions over a standard server interface. Function calling defines the model-side contract; MCP standardizes the transport, discovery, and packaging so tools stay swappable across harnesses.

What are the main security concerns with MCP servers?

Two dominate. First, servers can hold real credentials and powerful actions, so scope each to least privilege and gate writes behind approval. Second, a server's tool descriptions and results enter the model's context — treat third-party servers as untrusted input and sandbox ones you don't own.

Do I need MCP for a small agent with one or two tools?

Not necessarily. Bespoke integration is faster for a single deep tool. MCP earns its indirection once the tool surface is plural, changing, or something you must audit and swap — for example, pointing the same agent at mock servers in evals and real servers in production.

Can I swap MCP servers between environments without changing the agent?

Yes — that is a core benefit. Because the agent talks to a uniform protocol rather than each API directly, you can point it at a mock server for evals, a sandboxed server for staging, and the real server in production while the agent loop stays unchanged.