MCP Is Not Just Another API Standard

Balaji Venkatasubramaniyar · rss · 2026-09-23 Reader 🖥️

Agent-Native Design Agent Security Agent Tool Management API Products & Sprawl Emergent Tool Composition MCP (Model Context Protocol)

MCP is not a plumbing/API-standard convenience but a structural shift in who composes integration logic — from developers pre-agreeing a contract to an agent assembling one at runtime out of natural-language tool descriptions — which makes tool descriptions the real interface, unplanned tool composition a structural risk no test suite catches, and enforced governance a precondition for production use rather than later hardening.

mixed, leaning practical · argumentative — The piece builds a theoretical case for reclassifying MCP (rejecting the 'plumbing'/'just another API standard' framing) through several sections of exposition and evidence, but it converges on explicit prescriptions for what a team should do ('here's what I'd tell a team starting today') — tool-description discipline, governance-before-capability, current-baseline targeting. The unity is a claim about what MCP *is*, but the piece's payoff is what practitioners should *do* about it.

Structure

Part	Role
What MCP actually standardizes	context/exposition
Where the old model breaks down (per-framework duplication, and the deeper reframing of who composes the integration and when)	core argument — rejects the plumbing metaphor
The description is the interface now (before/after tool-description example)	evidence for the 'tool description is the real interface' sub-claim
Composition is emergent, and that cuts both ways	evidence/argument for the 'structural, untestable risk' sub-claim
The protocol is catching up to its own success (July 2026 spec: statelessness, Tasks, MCP Apps, OAuth 2.1/OIDC, deprecation policy; adoption numbers)	evidence for durability, read against production pain
Governance hasn't caught up (vulnerability research + prescriptions: allowlist, universal auth, audit logging, dynamic secrets)	conclusion/practical mandate — governance as precondition
Closing paragraph restating the thesis	conclusion

Key terms

plumbing (rejected metaphor)
A fixed, pre-designed system that moves something through channels you already engineered in advance — used as the foil for what MCP is not.
Tools / Resources / Prompts
MCP's three client-facing primitives: Tools are callable functions with a JSON Schema (the 'do something' side); Resources are URI-addressed readable context pulled in without a function call (the 'read' side); Prompts are reusable server-offered templates for common workflows.
the description (as interface)
A tool's name and natural-language description, which the author argues function as the actual behavioral contract determining whether and when an agent uses a tool — a separate job from the JSON Schema, which only specifies parameter shape.
composition (emergent) Emergent Tool Composition
The runtime-generated sequencing of tool calls that a model assembles fresh for a given task out of whatever tools happen to be available in that session — not designed, written, or reviewed by a human in advance.
governance
A specific, enforced bundle of technical controls — an explicit allowlist of vetted tools per agent, authentication on every remote endpoint with no 'internal traffic' exception, centralized immutable audit logging, and secrets pulled dynamically from a secrets manager — required before an agent gets access, not aspirational policy language.
stateless (protocol core)
The removal of protocol-level session tracking (the MCP-Session-Id header), so that any server instance behind ordinary load balancing can answer any request, rather than requiring sticky sessions.

Propositions

explicitMCP is best understood not as plumbing (pre-designed, pre-agreed channels) but as a shift in who composes integration logic — moving that decision from developers at design time to an agent reasoning at runtime.conf: high
explicitMCP standardizes a small, fixed set of primitives: Tools (callable functions with a JSON Schema), Resources (URI-addressed readable context), and Prompts (reusable templates), plus server-to-client capabilities — sampling, elicitation, and roots.conf: high
explicitNone of MCP's primitives are individually novel; what's novel is that they are the same five primitives regardless of model, framework, or vendor.conf: high
explicitBefore MCP, every agent framework had its own function-calling convention, so adding a second framework to a stack didn't double the work — it produced a second, incompatible copy of the same integration logic; MCP collapses that duplication into one contract that scales with the number of systems rather than the number of frameworks.conf: high
explicitA traditional API integration is a contract two systems negotiate in advance, with a project plan preceding the code; an MCP server has no such predetermined plan — the agent composes one at runtime out of whatever tools happen to be available to it.conf: high
extendsMCP Is Making API Sprawl Worse · p3 — Extends the 'MCP exposes actions, not just data, so it carries a higher risk profile' claim by locating the mechanism specifically in who composes integration logic and when (runtime agent composition vs. pre-agreed contract), rather than just the action-vs-data distinction.
explicitA tool's JSON Schema only solves the mechanical question of parameter shape; the tool's name and description do the separate job of telling the agent when to use it at all and how to distinguish it from an adjacent tool — and only one of those two jobs is solved by a well-formed schema.conf: high
extendsThe Interfaces Are Arriving · p9 — Gives a concrete before/after tool-description example and names the observed consequence (agents avoiding a well-schemaed but badly-described tool) for a claim the earlier piece states abstractly: that a schema captures shape but not meaning.
explicitAgents misuse or avoid technically-correct-but-poorly-described MCP tools in favor of worse-but-better-described alternatives, and this failure mode surfaces as subtly wrong downstream output rather than a stack trace.conf: medium
explicitWriting tool descriptions well is closer to technical writing and product design than to backend engineering, and it's a skill most integration teams don't walk in with.conf: high
explicitBecause tool-call sequencing logic is generated fresh by the model's runtime reasoning rather than written and reviewed by a human, it cannot be unit tested the way traditional integration code can — the decision doesn't exist until the moment it's made.conf: high
explicitA tool that behaves correctly in isolation can still produce a bad outcome the first time an agent calls it in an untested sequence or with input passed from another server's output rather than a human's direct input — a production-only failure mode that ordinary testing can't reliably pre-empt.conf: high
explicitThe July 28, 2026 MCP specification revision — the largest since the protocol's November 2024 launch — traces every major change to a real production failure mode: a stateless protocol core, formalized long-running Tasks, MCP Apps for interactive UI approval, OAuth 2.1/OpenID-Connect-aligned authorization, and a formal deprecation policy for the legacy transport.conf: high
supportsAAIF's MCP Dev Summit: Gateways, gRPC, and Observability Signal Protocol Hardening · p3 — Confirms the stateless-core transition (SEP-1442) landed in the July 28, 2026 spec, and supplies the operational motivation (horizontally-scaled-fleet incident risk) the earlier extraction states as a bare requirement.
explicitMCP's combination of real production scale (roughly 10,000 registered servers, SDKs individually past a billion downloads, adoption by the protocol originator's competitors) and a spec that keeps changing in response to genuine production failure is a stronger durability signal than either fact alone.conf: high
explicitIndependent 2026 security research found that a large majority of publicly registered MCP servers carry file-operation patterns prone to path traversal, with a meaningful share vulnerable to command injection or SSRF, plus documented cases of tool description poisoning and configuration poisoning, and at least one disclosed missing-authentication flaw in a major vendor's production package.conf: high
supportsArticle: Securing MCP in Production: Defense-in-Depth Beyond the Gateway · p10 — Independent 2026 security findings (path traversal, command injection, SSRF, tool description poisoning, configuration poisoning) corroborate the claim that MCP's security maturity lags its production-adoption rate, and add configuration poisoning as a further vulnerability class.
explicitAdoption scale and ecosystem security maturity are separate axes that shouldn't be conflated — MCP's technical durability and its current governance immaturity both hold at once.conf: medium
implicitThe author assumes responsibility for closing MCP's governance gap sits with the integrating enterprise (via allowlisting, universal auth, audit logging, dynamic secrets) rather than with protocol maintainers or the registry closing it upstream.conf: medium
implicitThe author treats natural-language tool descriptions as an inherently probabilistic interface — a 'handful of tokens' decision — and accepts this as a cost of the paradigm to be managed through better writing, rather than a reason to prefer more constrained, typed, or retrieval-based tool-selection mechanisms.conf: medium
implicitThe author treats months of hands-on production integration experience as the privileged epistemic vantage point for evaluating MCP, over spec-reading or demo-level familiarity.conf: medium

Arguments

MCP is not 'just another API standard' / not plumbing. strength: medium

Explicit premises:

Plumbing moves water through pipes you already designed — a metaphor for a pre-arranged, static integration.
In a traditional API integration, the contract (endpoints, payloads, auth, versioning) is negotiated in advance, and the project plan predates the code.
An MCP server has no idea which agent will call it, in what sequence, alongside which other servers, for what goal — the plan doesn't exist as a concrete thing until the agent composes it at runtime.

Implicit premises:

The identity of who or what does the composing (human-authored code vs. a model reasoning over natural-language descriptions) is the relevant axis for classifying an integration paradigm — not the wire format or transport mechanics.
Relocating the point of integration-decision-making from design time to runtime constitutes a different category of engineering problem, not merely a more convenient version of the same one.

Inferences:

If the plan doesn't exist until runtime, any governance or safety property that assumes a knowable, enumerable set of possible integrations cannot be verified in advance — testing paradigms built for pre-planned integrations are structurally inadequate for MCP-based systems in general, a stronger and more general claim than the author's specific untested-tool-chain example.

Tool descriptions must be engineered and reviewed with the same rigor as code, because they function as the actual interface an agent uses to decide behavior. strength: high

Explicit premises:

JSON Schema handles only parameter shape (mechanical).
The name/description handle the separate 'when to use this, and how to disambiguate from an adjacent tool' job.
A minimal-but-correct description and a richly specified description of the same tool produce measurably different agent behavior in the author's direct observation.

Implicit premises:

The agent has no other channel — no colleague to ask, no tacit institutional knowledge — to resolve ambiguity that a human engineer would silently fill in from experience, so anything the human 'already knows' must be made explicit in text or is simply unavailable to the agent.
Natural-language quality is a legitimate, first-class engineering property, not a documentation nice-to-have that can be deprioritized relative to schema correctness.

Inferences:

If description quality is load-bearing for behavior correctness, description changes should go through the same review/versioning/regression-testing discipline as code changes — implying a need for automated tool-selection eval suites the author gestures at ('test it against how an agent actually behaves') but never specifies a method for.

Governance controls (an explicit tool allowlist, universal authentication, centralized immutable audit logging, dynamically-sourced secrets) must be in place before an agent gets access to a tool, not applied afterward as hardening. strength: high

Explicit premises:

Independent security research found large-scale vulnerabilities across the current MCP server population (path traversal, command injection, SSRF, tool description poisoning, configuration poisoning, at least one missing-authentication flaw in a major vendor's package).
These are the same controls any experienced integration team already applies to systems carrying real privileges.
MCP hands an autonomous caller (the agent) real privileges and the ability to improvise its own sequence of actions.

Implicit premises:

Because composition is emergent (per Argument 1/2), a vulnerability's trigger condition may be some future, un-reviewed combination of calls, so controls that assume an enumerable, pre-approvable set of 'dangerous' cases won't hold — only always-on structural controls survive an unenumerable threat surface.
The cost of retrofitting governance after an incident exceeds the cost of building it in up front — an unstated but load-bearing cost-benefit assumption.

Inferences:

If governance must precede capability, and most current servers ship without it (per the cited stats), then a large share of the roughly 10,000 registered servers the author elsewhere cites as durability evidence are, by his own governance standard, not currently safe to connect to anything that matters — a tension between the durability argument and the governance-gap argument the author doesn't explicitly reconcile.

Narratives

The extended plumbing/wrench metaphor: "Plumbing moves water through pipes you already designed. MCP changes who's holding the wrench."
→ Carries the article's entire thesis as a compact image rather than a formal argument — stands in for the runtime-vs-design-time distinction before it's spelled out explicitly.
Two versions of the same `get_status` tool description — one minimal and technically correct, one that spells out the domain, ID format, valid status values, and the adjacent tool it's commonly confused with.
→ A worked mini-case that shows, rather than argues, what 'the description is the interface' means in practice — supports Argument 2.
The unspecified anecdote of teams shipping technically correct MCP servers that agents used badly or avoided entirely.
→ Evidentiary backing for the description-quality claim, but told with no company, date, or measurement attached — thin narrative evidence flagged as a gap below.
A hypothetical incident-review scenario: a routine deploy drops in-flight sessions because sticky-session state and horizontally-scaled load balancing don't coexist.
→ Illustrates why the July 2026 spec's move to a stateless protocol core addresses a real, felt operational liability rather than a cosmetic change.

Questions addressed

✅ What does MCP actually standardize, and is that standardization meaningful?
Yes — the five primitives (Tools, Resources, Prompts, plus sampling/elicitation/roots), whose value is being identical across every model, framework, and vendor.
✅ Is 'plumbing' / 'just another API standard' the right way to understand MCP?
No — the real change is who composes integration logic and when (agent at runtime vs. developer at design time).
✅ Where does the MCP abstraction leak once you're past the demo?
Two failure classes: (a) descriptions are the real interface and most teams under-invest in writing them well; (b) unplanned tool composition creates untestable, production-only failure modes.
✅ What does the protocol's July 2026 evolution reveal about where the real production pain has been?
Statelessness, long-running task support, interactive UI approval, hardened OAuth 2.1/OIDC authorization, and a formal transport deprecation policy — each mapped to a named production failure the author claims to have seen or anticipated.
✅ Is the current MCP ecosystem trustworthy enough to connect to systems that matter?
Not yet, by the author's own account — governance is behind the adoption curve; the article prescribes an explicit allowlist, universal authentication, centralized audit logging, and dynamic secrets as the entry price.
⭕ Will MCP's own ecosystem-level mechanisms (the registry, the Agentic AI Foundation, vendor gateways) close the governance gap, or does every integrating enterprise have to build its own controls indefinitely?
⭕ Does the same self-correcting mechanism that produced the July 2026 spec's fixes (production pain driving protocol revision) also apply to the security gap, or does closing that gap require a categorically different mechanism than the one that fixed statelessness and long-running tasks?

Gaps

incompleteThe vulnerability statistics ('the large majority,' 'a meaningful share,' one named missing-auth flaw) are asserted without methodology, source citation, or sample framing — which registries were scanned, whether internet-exposed servers were selectively discoverable (a bias toward the least-secure population), or how 'critical endpoint' was defined. This is the same critique the corpus already levels at a near-identical set of figures in a sibling piece.
Read next: The primary vulnerability-scan reports themselves (e.g. Adversa AI, Backslash Security, or similar MCP-server audits) to check sampling methodology directly.
incompleteThe piece never reconciles its two central claims: that the protocol is durable because it keeps fixing real production problems (statelessness, Tasks, MCP Apps, hardened auth), and that governance/security hasn't caught up. It doesn't say whether the same production-pain-drives-spec-revision mechanism will eventually close the security gap too, or whether security requires a categorically different fix (the enterprise-side controls it prescribes) that the protocol itself will never supply.
Read next: Coverage of the Agentic AI Foundation's governance roadmap or MCP registry vetting process, to see whether the security gap is being addressed at the protocol/ecosystem level or pushed entirely onto individual adopters.
incompleteThe claim that tool-description quality should be 'tested against how an agent actually behaves' is asserted as a one-line prescription with no worked method — no automated tool-selection eval suite, A/B methodology, or regression-testing process for descriptions is described, despite the article's own argument that description changes are now load-bearing for behavior.
Read next: Practitioner writing on MCP tool-description evals or agent tool-selection benchmarks.
uninformedThe article doesn't engage non-MCP or MCP-adjacent approaches to the same underlying problem — e.g. two-stage tool routing, progressive tool discovery, or retrieval-based tool selection — that try to reduce reliance on a natural-language-only description as the disambiguation mechanism, treating 'write better descriptions' as the only lever available.
Read next: Corpus material on agent tool management and dynamic/progressive tool discovery, for alternatives to natural-language-only tool descriptions.
illogicalThe durability argument treats 'adoption scale + a spec that keeps changing to fix real problems' as evidence of maturity, but a spec needing its largest revision in two years to fix core mechanics (stateful sessions, an auth model not yet aligned to OAuth 2.1) could equally be read as evidence of early-stage instability. The same underlying facts support two different readings, and the piece adopts the favorable one without acknowledging the alternative.
Read next: None required structurally, but see the corpus's own unresolved falsifiability question about MCP's durability wager.

Closes gaps elsewhere

The Interfaces Are Arriving · g3 — Directly performs the engagement the gap says was missing: immediately after presenting adoption-scale evidence (registry size, SDK downloads, cross-vendor uptake) as a durability signal, this piece pivots to 'Governance hasn't caught up' and explicitly instructs treating MCP 'skeptically, and with the controls in place before the agent gets access' regardless of scale — i.e. it argues, in the same breath as the adoption numbers, that scale is not evidence of safety and should not be read as such. This is the missing analytical move the gap identifies as absent.

MCP Is Not Just Another API Standard

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Closes gaps elsewhere

Related documents