On this page#
What changes when an agent does this#
An API exposes operations; MCP standardizes how an AI agent discovers and uses tools, resources, and prompts. The agent helps by connecting intent to available capabilities, but quietly hurts when probabilistic tool selection replaces explicit application logic. The bottleneck moves from writing integrations to controlling context, permissions, invariants, and review.
That distinction matters more than the usual api vs mcp comparison suggests. An API is a contract that software calls directly. The Model Context Protocol is a protocol for connecting AI applications to external systems in a consistent way. MCP does not make the underlying operation safer, correct, or deterministic.
A large language model generates outputs from learned statistical patterns. Put one between a request and an API, and the call path changes:
| Direct API integration | Agent using MCP | |---|---| | Your code chooses the operation | The model may choose the tool | | Your code constructs arguments | The model may construct arguments | | Control flow is explicit | Control flow can emerge from context | | Failures follow programmed branches | Failures include interpretation errors | | Tests cover known call paths | Evaluation must cover choices and outcomes |
MCP’s client–server architecture gives hosts a standard way to connect to servers and expose capabilities. That is useful plumbing. It is not a substitute for domain rules.
The agent helps most when the task requires interpretation: locating relevant repository context, assembling evidence, or proposing a change across several files. It hurts when the task contains hard invariants but the agent is allowed to infer them from prose.
Keep authorization, validation, and irreversible actions outside the model’s discretion. If an agent can decide both what should happen and whether its own result is acceptable, the design is wrong.
Photo by Christina Morillo on Pexels.
The prompt chain#
A reliable agent workflow uses separate prompts for discovery, planning, execution, and verification. Each stage should produce an inspectable artifact and narrow the next stage’s freedom. One giant prompt hides assumptions, encourages premature edits, and makes it difficult to identify where a bad decision entered the chain.
1. Discover without changing anything#
Inspect the repository for the requested change. Do not edit files or run mutating commands. Identify the relevant modules, existing conventions, tests, and documented invariants. Return evidence with file paths, unresolved questions, and the MCP tools or resources you used.
This prompt separates observation from action. “Understand the repository and fix it” is too broad: the agent can form an early theory, edit toward it, and then interpret later evidence as confirmation.
Ask for paths and evidence because summaries are lossy. MCP can expose tools and resources consistently, but the official protocol cannot guarantee that the model reads the right resource or interprets it correctly.
2. Produce a bounded plan#
Using only the discovered evidence, propose the smallest change that satisfies the request. List files to modify, invariants to preserve, validation steps, and rollback boundaries. Mark every assumption. Do not implement the plan.
This forces hidden guesses into reviewable text. The smallest-change constraint also limits the blast radius: an agent should not “clean up” adjacent code merely because it is already present in context.
If the plan crosses unfamiliar subsystems, stop. Use PairFoundry’s free Foundations track before adding more agent autonomy, or compare the focused options in the pack overview.
3. Execute exactly the approved scope#
Implement only the approved plan. Preserve unrelated changes. Do not add dependencies, alter public interfaces, or expand scope unless the plan explicitly permits it. After each logical change, report the invariant it preserves. Stop on contradictory evidence.
“Stop on contradictory evidence” is essential. Without it, the agent is rewarded for completing the task even after discovering that the approved plan rests on a false assumption.
MCP architecture separates the host, clients, and servers, with the host retaining coordination and security responsibilities. That boundary, described in the architecture documentation, should appear in the prompt chain too: the model proposes and invokes; trusted code enforces.
4. Verify from a fresh position#
Review the resulting diff as if you did not author it. Map each changed line to the approved plan, run the specified checks, and report failures without repairing them. Identify untested behavior, widened permissions, unexpected tool calls, and changes outside scope.
Do not ask the same turn to “fix all issues found.” First preserve the diagnosis. Otherwise the agent can repeatedly modify code until checks pass while quietly drifting away from the reviewed plan.
For a reusable workflow centered on this boundary, see PairFoundry’s Review and Repair. Related agent workflows are collected in the workflow library.
The gate#
The mandatory human gate is between the bounded plan and execution. A person must verify the target files, assumptions, invariants, permissions, validation commands, and rollback boundary before any write-capable tool is enabled. Reviewing only the final diff is too late because the agent may already have changed external state.
The gate should answer six questions:
- Is the agent solving the requested problem?
- Does the plan name every file and system it may change?
- Are repository invariants stated as enforceable checks rather than aspirations?
- Are MCP tool permissions narrower than the task?
- Can validation detect semantic failure, not merely successful execution?
- Can every proposed action be reversed cleanly?
The approval must bind to a specific plan. “Proceed” should not authorize a revised plan generated after new evidence appears.
Use technical controls as well as prompt language. Expose read-only resources during discovery, then enable only the write tools required for the approved execution. MCP provides the connection model; the MCP specification does not remove the host’s responsibility to enforce consent and access boundaries.
Photo by Lukas Blazek on Pexels.
What it gets wrong#
Agents fail most dangerously when they produce a coherent result from incomplete context. The output looks intentional, tests may pass, and the tool calls may all be valid. The error lies in choosing the wrong operation, omitting an invariant, or treating successful execution as proof of correctness.
Watch for these failure modes:
- Plausible tool substitution: The agent selects a similarly named MCP tool whose side effects differ. Detect it by logging the resolved tool, arguments, and authorization scope before execution.
- Context omission: The relevant policy, schema, or test never enters the model’s context. Detect it by requiring an evidence inventory and comparing it with known repository ownership boundaries.
- Argument invention: Required fields are guessed from nearby examples. Detect it with schema validation and reject defaults that were not explicitly approved.
- Success confusion: A tool returns successfully, so the agent declares the task correct. Detect it with independent postconditions tied to repository invariants.
- Scope creep: The agent repairs adjacent code or reformats unrelated files. Detect it by comparing the final diff against the approved file list.
- Self-review blindness: The same context that produced the mistake rationalizes it during review. Detect it with a fresh review prompt and an unchanged acceptance checklist.
- Prompt injection through resources: Repository text or external content instructs the agent to ignore the task. Treat retrieved content as data, never authority.
The architectural point is simple: an MCP server exposes capabilities, while the host controls the interaction around them. The architecture guide explains the components; your implementation must add the invariant checks specific to your repository.
Rollback#
Clean rollback starts before execution: isolate the change, record the pre-change state, separate code edits from external side effects, and define a reversal for every authorized action. Reverting files is not enough if the agent also changed tickets, deployments, credentials, databases, or remote configuration through an MCP server.
Use this sequence:
- Stop further tool calls and preserve the complete action log.
- Classify effects as local files, repository history, remote configuration, or irreversible external actions.
- Reverse actions in dependency order using the pre-approved rollback procedure.
- Re-run the original invariant checks against the restored state.
- Review the action log to find the first divergence, not merely the final visible error.
Do not ask the agent to improvise rollback after failure. That gives the same mistaken context another chance to act. A rollback command or compensating operation should be explicit, narrow, and independently authorized.
The safest design makes local edits disposable and external mutations exceptional. MCP can standardize access to both, but standardization does not make their recovery characteristics equal. The protocol documentation defines how systems connect; you still define what “back to clean” means.
Photo by Digital Buggu on Pexels.
Related reading#
- Claude Code code review — where the agent helps and where it quietly hurts
- Terraform MCP server: making the output reviewable, not just correct
FAQ#
Will MCP replace API?#
No. MCP commonly sits above APIs, databases, files, or application-specific interfaces and exposes their capabilities to AI hosts in a standard form. APIs remain useful for deterministic software integration. MCP addresses agent-facing discovery and invocation; it does not eliminate the underlying service contracts.
What is the difference between API and MCP?#
An API defines how software interacts with a particular service. MCP defines a standard way for AI applications to connect with servers that expose tools, resources, and prompts. The practical difference is control: direct API code chooses calls explicitly, while an agent may interpret intent and choose among MCP capabilities.
Is MCP server like an API?#
Yes, in the limited sense that both expose callable capabilities across a defined boundary. But an MCP server participates in an agent-oriented protocol and can expose more than operations. Calling it “just an API” hides the model-driven selection, context, consent, and host-control issues that create the real engineering risk.
Do you need an API for MCP?#
No. An MCP server can wrap an API, but it can also expose files, databases, local tools, or application logic directly. It still needs some concrete implementation behind each capability. MCP standardizes the agent-facing connection; it does not generate the underlying functionality.
Is MCP a glorified API?#
No, but treating it as magic is worse. MCP is useful protocol infrastructure for connecting AI applications to capabilities consistently. Its value is interoperability, not correctness. The agent remains probabilistic, the underlying systems retain their own contracts, and your host must enforce permissions, invariants, review gates, and rollback.