The API-versus-MCP debate is settling into a sensible consensus — and it is still one layer above the decision that matters. The question is not which protocol connects your agents to your systems. It is where an agent's permission to observe ends, where its permission to act begins, and what enforces that boundary.
A recent piece in The New Stack, written from inside the incident management world, lands the consensus position well: APIs remain the right tool for deterministic, repeatable workflows, while MCP earns its place in exploratory, human-driven work — triage, diagnosis, investigation — where an agent needs to assemble context from a sprawl of tools. The article is right, and it is refreshingly free of the "MCP is the new API" framing that dominated the last eighteen months. Take its taxonomy as settled. The architectural work starts underneath it.
The Protocol Question Is a Proxy
When architects debate API versus MCP, they are usually debating something else without naming it: how much autonomy to grant a probabilistic system. The deterministic-versus-non-deterministic split is real, but it describes the workflow, not the control. A scripted workflow invoked through an API feels safe because an engineer decided every step in advance and encoded it. A non-deterministic path traversed through MCP feels risky because the model decides the steps at runtime. The instinct is to sort work into those two buckets and pick the protocol accordingly.
That sorting exercise misses the property that actually governs risk. What matters is not whether the path through your systems is predetermined. It is whether the actions available along that path are bounded by something the model cannot talk its way past. An agent that can read fifty systems and mutate none of them is a low-risk agent, no matter how unpredictable its reasoning. An agent with write access to one production system is a high-risk agent even if its workflow is scripted end to end.
So the durable line is not API versus MCP. It is read versus act. MCP is, at its core, a standardization of observation. It gives agents a consistent way to acquire context across tools and vendors, and that is genuinely valuable — context fragmentation is the reason most enterprise agents have underwhelmed. But nothing about standardizing what an agent can see should be allowed to blur the question of what it may do. Those are separate architectural decisions, and only one of them is a protocol decision.
A Human in the Loop Is a Mitigation, Not an Architecture
The article makes an observation worth pausing on. MCP can ride on the same authorization the underlying APIs already enforce, yet teams still want a human approving actions "because an AI agent is choosing what to run." That clause deserves more weight than it gets, because it quietly concedes the whole problem. If inherited API authorization were sufficient, no human gate would be needed. The gate exists because that authorization model was designed for callers whose behavior was fixed at deployment time, and it is now being asked to govern a caller whose behavior is decided at inference time.
Human-in-the-loop is the correct interim answer. It is a poor terminal one. Approval fatigue is well documented in every domain that has leaned on this pattern, from code review to alert triage: when the approval rate approaches one hundred percent, the human stops evaluating and starts clicking. At incident-response tempo — 3 a.m., pager firing, executives on the bridge — the click comes faster. A control that degrades under exactly the conditions it exists for is not a control. It is a liability with an audit trail.
The structural problem is the same one we see across agentic systems: governance investment is misallocated when it concentrates at the model layer, in prompts, guardrails, and human review of probabilistic outputs. The reliable controls are deterministic, and they live at the execution layer. Identity that distinguishes the agent from the human it acts for. A tool registry that exposes actions to an agent only through explicit registration, with typed parameters and scoped permissions. Gateway-level policy that evaluates every action call against rules that are indifferent to how persuasive the model's reasoning was. When those controls exist, the question "what if the agent decides to run something destructive" has a boring answer: it cannot. The destructive action was never in its registered set, or the policy engine rejected the call — deterministically, in milliseconds, without waking anyone.
This is why the read-versus-act line matters more than the protocol line. Reads can be governed generously, because observation carries bounded risk and enormous value. Acts must be governed deterministically, because mutation carries unbounded risk and the model layer offers no reliable brake. Choose protocols however you like. Enforce the boundary in the execution layer or you have not enforced it at all.
What This Looks Like When the Pager Fires
Stay with the article's own scenario: checkout errors spiking in the EU. An on-call engineer asks the agent what is happening. Through MCP, the agent pulls the active incident record, the last six hours of deploy and config-change events, error traces and latency percentiles from observability, the recent history of the payments on-call channel, and the service ownership map. It correlates a config change to the EU payment gateway with the onset of the error curve and proposes a hypothesis, with the supporting evidence assembled in one place.
Everything in that paragraph is a read. None of it required approval, all of it was logged, and the agent's non-determinism was an asset rather than a threat — nobody scripted that investigation in advance because nobody could have predicted this incident. This is MCP doing exactly what it is good at, and the architecture should make this path fast and frictionless.
Then the agent proposes remediation: revert the config change and post a stakeholder update. Now the boundary is crossed. In a well-architected system, "revert config" is not something the agent reaches through an MCP server that happened to inherit write scope from the underlying API. It is a registered tool — one action, typed parameters, constrained to named services — invoked through the same gateway that governs every other caller in the enterprise. Policy decides whether this agent, acting for this engineer, may revert this change at this severity tier. For a low-blast-radius service, policy may say yes automatically. For tier-one payments infrastructure, it may require the on-call engineer's explicit approval. Either way, the decision logic is deterministic, versioned, and auditable, and it does not care how confident the model sounded.
Notice what happened to the human in the loop. They did not disappear; they moved to where they belong. Instead of approving every action because the architecture cannot distinguish safe from unsafe, they approve only the actions policy has deliberately reserved for human judgment. Approval becomes rare and meaningful instead of constant and reflexive. That is the difference between a mitigation and an architecture.
Where to Draw the Line, Starting Now
Three moves follow for anyone accountable for this.
First, inventory your act surface, not your integration surface. Most organizations can list which systems their agents connect to. Far fewer can say which systems their agents can mutate, through which paths, under whose identity. That second list is the one your regulator, your CISO, and your postmortem will care about.
Second, treat every new MCP server as an authorization event, not a connectivity event. The convenient failure mode of the current moment is standing up MCP servers that expose writes alongside reads because the underlying API did. Each one silently widens the act surface. Read-only by default; writes only as registered, policy-gated tools.
Third, place the boundary in the execution layer before your agent count grows. With three agents, human review and good intentions roughly hold. With thirty agents composed into workflows that call each other, they do not — and retrofitting identity, registration, and gateway policy under an agent estate already in production is the kind of project that consumes a year and a reorg.
MCP is likely to win as the standard for agent observation, and that is a good outcome. But protocols standardize how agents connect. Only architecture decides what they are permitted to do. The organizations that keep those two decisions separate will run agents aggressively and sleep. The ones that let a context protocol quietly become their authorization model will discover the difference during an incident, which is the most expensive classroom there is.