The MCP Surface and the Exec Surface
Why every LLM-generated tool call should cross one audited surface — and what stays in code.
In an agent system there are two very different kinds of “run this”: calls a language model decides to make, and calls deterministic code makes because the program said so. Treating them as the same surface is where auditability quietly dies.
Two surfaces, one wrapper
The rule I’ve converged on:
- The agent-facing surface is a single MCP面. Every tool call the model generates goes through it, and only through it. Budget limits, citation requirements, idempotency, and the audit log all live underneath this surface, in the wrapper — not in the model’s prompt, where they’re advisory at best.
- The code-facing surface is a direct function call. Deterministic pipelines don’t need to negotiate with a model; they call the same underlying wrapper directly.
Both paths pass through one wrapper, so the enforcement and the audit trail are shared. What differs is who’s allowed to originate a call and how it’s constrained.
Why it matters
If the model can reach the shell directly — or if half the tools are MCP and half are ad-hoc exec — then “what did the agent actually do?” has no single answer, and the guarantees you care about (spend caps, provenance, no double-writes) are enforced in some paths and not others. Funnelling every model-originated action through one surface is what makes the answer knowable.
This is a note-in-progress; the boundary is clear but I’m still working out where retries and human-approval gates sit relative to it.