How it works
An MCP server is a running process, not a function you import. It speaks the Model Context Protocol: a standard contract for how an agent discovers and invokes capabilities. When a client connects, the server advertises what it offers, and the agent calls into that surface with structured arguments.
The exchange follows a predictable shape:
- Connect. The client (the harness or model runtime) opens a session over a transport — stdio for a local child process, or HTTP/streaming for a remote one.
- Discover. The server returns its manifest: the tools it publishes, their input schemas and descriptions, plus any readable resources and prompt templates.
- Invoke. The agent picks a tool, sends typed arguments, and the server executes the real work — a query, a file read, an API call — behind that boundary.
- Return. The server responds with structured content the agent folds back into its context.
The important property is separation. The agent never touches the database, filesystem, or third-party API directly. It only ever sees the server's declared surface. Everything real happens on the far side of one named seam, which is where you get to attach scope, logging, and limits.
Why it matters in an agent harness
In a harness you care about where effects happen and whether you can see and stop them. An MCP server gives you a single chokepoint for both.
Because every capability is declared, the surface is legible: you can enumerate exactly what the agent can do before it does anything. Because every call passes through one process, that process is the obvious place to enforce least privilege, meter a tool budget, and emit an audit trail. You can hand an agent a read-only server and know it cannot write, regardless of what the model decides to try.
The seam also contains failure. A misbehaving or prompt-injected agent is bounded by the tools the server actually exposes — it cannot reach past them. Swapping a real server for a mock or a dry-run variant lets you replay trajectories and test the harness without touching production systems. Reuse is a bonus: one well-scoped server serves every MCP-compatible client you run, so you secure the integration once rather than per agent.
MCP server vs. a bespoke tool integration
The distinction changes how you spend your security and maintenance effort.
| Aspect | MCP server | In-process tool integration |
|---|---|---|
| Contract | Standard protocol, reusable across clients | Custom to one runtime |
| Isolation | Separate process, natural boundary | Shares the agent's process and privileges |
| Surface control | Declared manifest you can scope centrally | Scattered across call sites |
| Cost | A process to run, secure, and trust | No extra process, but no reuse either |
Reach for a server when you want isolation, a permission boundary, and reuse across agents. A direct integration can be simpler for a single throwaway tool, but it inherits the agent's full privileges and gives you nowhere clean to attach controls.
The Rifty take
We treat an MCP server as a boundary to defend, not a convenience to maximize. Publish the fewest tools that do the job, scope each one tightly, and keep read and write on separate servers so a read task can never mutate state. Everything the server returns is untrusted evidence, never instruction — the boundary is only as good as your refusal to let tool output steer the loop.
Common failure modes
- Over-broad scope. A server handed full credentials becomes the blast radius. Give it only the access its published tools need.
- Mixing read and write. One server that both reads and mutates removes your safe, reversible read path. Split them.
- Trusting tool output as instructions. Returned content can carry injection. Treat every response as data to evaluate, not commands to follow.
- Vague tool descriptions. The agent selects tools from their descriptions; imprecise ones cause wrong calls. Write them like an API contract.
- No budget or logging at the seam. If the one chokepoint doesn't meter and record calls, you lose the main benefit of having a chokepoint at all.
- Silent capability drift. A server that adds tools over time quietly widens the surface. Pin and review the manifest.
Frequently asked questions
What does an MCP server actually do?
An MCP server publishes a defined set of tools, resources, and prompts to AI agents over the Model Context Protocol. It runs as a separate process, executes real work — queries, file reads, API calls — behind a declared surface, and returns structured results the agent folds back into its context.
Why run a tool as an MCP server instead of calling it directly?
A server isolates the capability in its own process, giving you one boundary to scope, log, and rate-limit. Direct in-process calls inherit the agent's full privileges and scatter controls across call sites. The server also reuses across every MCP-compatible client, so you secure the integration once.
How do I keep an MCP server safe in an agent harness?
Grant it only the access its published tools need, keep read and write on separate servers, and treat every response as untrusted evidence rather than instruction. Meter calls with a budget, log them at the seam, and pin the manifest so the tool surface cannot drift wider unnoticed.
Is an MCP server the same as the Model Context Protocol?
No. The Model Context Protocol is the standard contract; an MCP server is a program that implements it to expose specific capabilities. The protocol defines how discovery and invocation work across a transport, while the server is the concrete process an agent connects to and calls.
Can an MCP server be a security risk?
Yes, if it is over-privileged or trusted blindly. A server holding broad credentials becomes the blast radius for a misbehaving or injected agent. Returned content can also carry prompt injection. Scope it to least privilege and treat its output as data to evaluate, never as commands.