Tool Protocols in 2035: Two Axes, Four Scenarios, and What Would Falsify Them

Two questions, not one converged stack

Most writing about where AI tool protocols end up by 2035 is a single-track story dressed as foresight. One version has the Model Context Protocol, or something recognisably descended from it, becoming the one wire format every agent and every tool speaks, the way TCP/IP or HTTP eventually became unremarkable plumbing everyone assumed. Another has today’s proliferation continuing indefinitely: every vendor keeps its own tool-calling format, every marketplace keeps its own listing rules, and “interoperability” stays a slide in a keynote rather than a property of the running system. Both are coherent. Neither is more than a preference dressed as a forecast, because the evidence available in August 2026 does not discriminate cleanly between them — and, as this article will show, it does not even ask a single question.

The honest alternative is scenario analysis, with a specific discipline: name the smallest number of drivers that are both consequential and genuinely uncertain, cross them, state the mechanism behind each resulting cell, and commit in advance to the observations that would identify which cell the field is in and the observations that would rule a cell out. Done properly it produces no favourite — that is the intended output, not a failure to reach one.

This article uses two axes. Axis A asks whether the layer connecting agents to tools converges on a small number of neutral, cross-vendor standards, or keeps fragmenting into incompatible, vendor-specific mechanisms even as overall adoption of some protocol grows. Axis B asks whether a tool’s safety and provenance become a certified, independently checkable property — something a registry, a client, or a regulator can verify rather than merely read — or remain fundamentally empirical: discovered through red-teaming, incident reports, and best-effort review, with no verifiable bound behind any single listing. Two frequently asked related questions — whether tool marketplaces and registries develop real trust and reputation systems, and whether tool protocols converge with existing API description standards such as OpenAPI — are treated below as readouts of these two axes rather than independent drivers, an argument made explicitly rather than assumed.

The documented present

Fact. The protocol most associated with this question has just changed who owns it, and the change points toward neutral governance rather than away from it. On 9 December 2025 Anthropic donated the Model Context Protocol to a newly formed Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI, with backing from Google, Microsoft, AWS, Cloudflare, and Bloomberg; Anthropic framed the move as keeping MCP “open-source, community-driven and vendor-neutral,” and stated that day-to-day governance would not change, with maintainers continuing “to prioritize community input and transparent decision-making” ^[2]. A protocol’s original author giving up sole ownership to a body its own competitors co-fund is a real convergence signal, not a marketing gesture.

Fact. Independent, cross-vendor technical adoption of that same protocol is already real rather than aspirational. OpenAI’s own Agents SDK documentation describes MCP as “an open protocol that standardizes how applications provide context to LLMs,” comparing it to “a USB-C port for AI applications,” and documents support for five distinct server transports, from hosted execution to local subprocess servers ^[13]. Google Cloud’s own December 2025 announcement extends MCP support across Google Maps, BigQuery, Compute Engine, and Kubernetes Engine, arguing that “for AI to truly be an ‘agent’ … it needs more than just intelligence; it needs to reliably work with tools and data,” and pairs that adoption with its own Model Armor defence layer aimed specifically at indirect prompt injection ^[15]. Two labs that compete on almost everything else independently building support for the same wire protocol, for the same function, is the clearest evidence Axis A’s convergent end can currently point to.

Fact. But convergence has been happening layer by layer, not into one universal protocol, and the same nine-month window produced two further, separately governed standards for two different functions. Google’s Agent2Agent protocol, for coordination between agents rather than between an agent and a tool, was donated to the Linux Foundation on 23 June 2025 with more than one hundred supporting companies including AWS, Cisco, Microsoft, Salesforce, SAP, and ServiceNow; the Linux Foundation’s own executive director framed the move as ensuring “the long-term neutrality, collaboration and governance that will unlock the next era of agent-to-agent powered productivity” ^[3]. Separately, the Agentic Commerce Protocol, for agent-mediated purchase rather than either of the above, was co-developed by Stripe and OpenAI and announced on 29 September 2025 as an open standard that companies not working with Stripe can still adopt using their own payment providers ^[14]. Three protocols, three functions, three separate governance efforts, inside one season — evidence that the field is consolidating within layers while continuing to add new layers.

Fact. Where a protocol for describing an API already existed, the newer tool-invocation layer has not replaced it so much as sat on top of it, and the fit is imperfect. The OpenAPI Initiative has operated as an “open source, technical community” under the Linux Foundation building “a vendor-neutral, portable and open specification for providing technical metadata for REST APIs” since well before agentic tool calling existed ^[12]. Tooling now exists to generate a working MCP server directly from an OpenAPI document, and vendor documentation for that tooling describes the two as deliberately layered rather than competing, with the OpenAPI file remaining “the single source of truth” that the generated MCP server stays synchronised to ^[16]. The same documentation is candid about the seam: automatic conversion is only as good as the source document, because “AI agents need more context than human developers to use APIs effectively,” and a thinly documented endpoint leaves the model to fill the gap by, in the vendor’s own words, confidently making things up ^[16]. OpenAPI describes what an endpoint accepts. It was never written to describe what an agent should infer about intent, side effects, or trust — which is exactly the extra layer MCP tool descriptions carry, and exactly where Axis B begins.

Fact. On the trust side, the protocol’s own specification is explicit that it does not supply what a registry or a client would need to verify a tool’s safety claim. The current specification states plainly that “MCP itself cannot enforce these security principles at the protocol level,” and instructs that “descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server” ^[1]. That is not an oversight discovered by outside critics; it is the protocol’s own normative text, describing the limits of what it guarantees.

Fact. The registry built to make tools discoverable inherited exactly that gap. The official MCP Registry launched in preview on 8 September 2025 as “an open catalog and API for publicly available MCP servers,” built from entries maintainers self-report, and its own documentation states it “does not provide data durability guarantees or other warranties” ^[4]. An independent audit published in December 2025 found the registry’s actual data dominated by duplication rather than genuine catalogue growth — roughly 64.7 million server entries resolving back to only 1,691 unique underlying packages — and concluded that the registry has so far solved discovery rather than trust, writing that “the existence of a curated, security-first sub-registry will be the deciding factor in its adoption” ^[5]. A catalogue that is easy to list in and hard to verify is the empirical branch of Axis B in its current, unresolved form.

Fact. That gap is being actively exploited rather than sitting theoretical. A benchmark purpose-built to test it found a poisoned tool description succeeding against the OpenAI o1-mini model 72.8% of the time, and found that across every model tested, refusal was rare — the best-defended model in the study, Claude 3.7 Sonnet, refused fewer than 3% of the poisoned calls, which the authors read as showing existing safety alignment is “ineffective” against this specific attack class ^[9]. A larger, independent census went further: the first large-scale security survey of the live MCP ecosystem analysed 12,230 tools across 1,360 real servers and concluded the ecosystem is “rife with real-world exploitable gadgets and diverse attack methods” ^[8]. And the exposure is not confined to research settings. In September 2025, a malicious npm package named postmark-mcp — a clone of a legitimate email-sending tool — shipped fifteen clean releases before quietly adding one line that secretly copied every outgoing email to an outside address; Koi Security, which found it, called the backdoor “embarrassingly simple” while noting it “perfectly demonstrates how completely broken this whole setup is” ^[7]. By June 2026 Microsoft was still describing this as a live, general pattern in production systems, warning that a tool’s description can be edited after approval and propagate without re-review, because “MCP mixes instructions and data in the same place” ^[6].

Fact. The certified branch of Axis B is not purely hypothetical either; it has a real, narrow technical frontier, and the frontier’s own results describe its limits honestly. A July 2026 theoretical paper on certified runtime safety for tool-using agents shows that a deterministic pre-execution gate “enforces exactly the nonempty safety policies whose good prefixes its register model recognizes” — a hard ceiling, not a a tuning problem — while a statistical alternative combining a Neyman-Pearson threshold with conformal calibration can instead produce “a finite-sample marginal certificate.” The same paper shows the two do not simply compose: once a gate’s own blocking decisions start changing what an agent proposes next, “static scores and ungated trajectories need not identify the closed-loop frontier,” and separately, that “bounded representation attacks add a robustness margin, so benign calibration alone does not transfer” ^[10]. That is real, checkable progress on what a certified tool-safety guarantee could look like, in the same document as a precise account of exactly where such a certificate stops applying.

Fact. The tension between convergence and fragmentation is not only visible in press releases; it is explicit in the peer-reviewed literature, argued as a still-open fight rather than a settled trend. A position paper accepted at the 2026 International Conference on Machine Learning states that “current solutions in this field are all built in isolation, and we are rapidly heading toward a landscape of fragmented, incompatible ecosystems,” and proposes a four-part minimal-interoperability framework — messaging, interaction, state, and discovery — that it calls “the first but critical step toward interoperable agentic systems” before fragmentation becomes entrenched ^[11]. Researchers arguing in 2026 that interoperability still needs to be won, rather than reporting that it already has been, is itself evidence about which way the field is currently leaning.

Why these two axes, and why registries and OpenAPI are not a third and fourth

Axis A is consequential because its two ends imply different economics for everyone building on top of this layer: convergence means a tool built once can be reached by any conforming agent regardless of vendor, the way MCP already lets OpenAI’s and Google’s independently built systems reach the same servers ^{[13, 15]}; fragmentation means every integrator keeps paying a translation tax indefinitely, rebuilding the same capability once per ecosystem. It is uncertain because the evidence points both ways inside the same eighteen months: the Agentic AI Foundation’s neutral governance and the shared multi-vendor SDK support both show real convergence at the tool-invocation layer specifically ^{[2, 13]}, while the near-simultaneous, separately governed launches of Agent2Agent and the Agentic Commerce Protocol show the same period adding new, incompatible layers rather than consolidating existing ones ^{[3, 14]}.

Axis B is consequential because it decides whether a claim that a tool is safe to call can be checked by anyone other than the party making the claim — the entire distance between an independently audited error bound and a self-reported registry entry with, in its own operator’s words, no durability guarantee ^[4]. It is uncertain because the evidence points both ways in the same period: a formal theory of certified runtime safety for tool-using agents shows genuine, checkable progress is possible today, not merely aspirational ^[10], while a purpose-built benchmark and an independent large-scale census both show the field’s actual current practice failing against the simplest version of the attack, at rates as high as 72.8%, with refusal below 3% even from the best-tested model ^{[9, 8]}.

A convenient way to see what a resolved Axis B would actually require is to write the registry’s listing decision as a threshold rule. Let $\hat\epsilon(s)$ be an estimate of the probability that a listed tool or server $s$ behaves differently from what its description claims once it is actually invoked, and let $\epsilon_{\max}$ be the error tolerance a registry operator or a downstream client is willing to accept. A defensible rule is

Both clauses have to hold. The MCPTox and Parasites-in-the-Toolchain results are, in effect, unaudited-but-measured estimates of $\hat\epsilon(s)$ for today’s ecosystem, and they are far above any $\epsilon_{\max}$ a reasonable operator would set ^{[9, 8]}. The official registry currently supplies neither clause — it does not estimate $\hat\epsilon(s)$ for its entries, and it explicitly disclaims warranting them ^[4]. Plugging today’s numbers into the rule above collapses every entry to “unverified,” regardless of how confidently a listing describes itself, which is precisely why whether tool marketplaces and registries develop real trust and reputation systems is not a third axis. It is Axis B, asked about the discovery layer specifically, and it does not have independent content beyond asking again whether that axis resolves toward certified or stays empirical.

Whether tool protocols converge with OpenAPI is, likewise, not a fourth axis but Axis A asked about which shape convergence would take if it happens. OpenAPI already is a vendor-neutral, vintage, widely adopted description standard ^[12], and automated generators already turn its documents into working MCP servers ^[16] — so one resolution of Axis A’s convergent end is that the industry standardises by reusing that existing description layer wherever possible, treating MCP-style protocols as thin runtime wrappers. The other resolution keeps a persistent, AI-specific semantic layer distinct from OpenAPI, because MCP’s tool descriptions, annotations, elicitation, and now asynchronous task extensions all carry behavioural and trust information that a REST-endpoint description was never built to express ^{[1, 16]}. Either answer is a specific case of Axis A converging; what would make it a genuinely separate axis is if the two questions could move independently, and nothing in the evidence above suggests they can.

Four scenarios toward 2035

Crossing the two axes gives four cells. None is named as the likely outcome; each is named for the instrument in this article’s own room that best captures its logic.

Scenario one: The Master Gauge — protocols converge, trust is certified

Mechanism. The layer-by-layer convergence already visible today — MCP stabilising for tool invocation under the Agentic AI Foundation, a comparable pattern for agent-to-agent coordination under Agent2Agent’s Linux Foundation governance, and further function-specific layers like the Agentic Commerce Protocol each settling into their own reference implementation ^{[2, 3, 14]} — continues until each function has one dominant, neutrally governed standard rather than several competing ones. In parallel, formal-verification techniques of the kind sketched in current certified-runtime-safety research mature from a narrow theoretical result into deployed practice, and registries begin publishing independently audited error bounds rather than self-reported claims, closing the gap the $\text{Trust}(s)$ rule above currently leaves open ^{[10, 4]}.

Horizon. Recognisable convergence and early certification signals by 2029–2030; a stabilised reference layer with attached, audited trust infrastructure plausible by 2035.

Assumptions. The economic pull toward one standard per function outweighs the incentive for any single vendor to maintain a proprietary alternative; a standards body or accreditor is willing to fund and maintain independent auditing of registry entries rather than stopping at self-report.

Observable indicators. First, two or more major agent platforms converge on describing tool invocation using the same protocol as their primary mechanism, not merely as one supported option among several native formats. Second, a registry publishes independently audited safety or provenance scores for a meaningful share of its listings, distinct from self-reported annotations. Third, formal-verification methods in the line of current certified-runtime-safety research are cited in production system documentation as routine practice rather than research demonstration.

Disconfirmation. Falsified if, by 2031, major platforms still rely on materially incompatible primary tool-invocation mechanisms with no shared standard, or if no registry of meaningful scale has published independently audited trust scores, as opposed to self-reported annotations.

Scenario two: The Common Fixture — protocols converge, trust stays empirical

Mechanism. The same interoperability pressure drives convergence on shared, neutrally governed wire protocols as in scenario one, but the trust side stalls: formal-verification research keeps running into the closed-loop and representation-transfer limits current work already documents ^[10], and independent registry auditing never becomes economically attractive enough to displace self-report ^{[4, 5]}. Tool poisoning at something like today’s rates — a benchmark success above 70% against an unhardened model, refusal in the low single digits even from a hardened one ^[9] — becomes an accepted operating cost rather than a solved problem, discovered case by case the way the postmark-mcp backdoor was discovered rather than prevented ^[7].

Horizon. Recognisable by 2029–2030; a stable configuration plausible through 2035.

Assumptions. The interoperability value of a shared protocol is large enough to justify itself even without anyone being able to certify what runs over it; the cost of independently auditing registry entries at scale keeps outrunning the willingness of any single party to pay for it.

Observable indicators. First, the same cross-vendor protocol convergence described in scenario one. Second, no registry of meaningful scale moves beyond self-reported trust signals. Third, security research continues documenting successful tool-poisoning and supply-chain incidents against the converged protocol at a similar or growing rate, without a corresponding drop tied to a specific certification mechanism.

Disconfirmation. Falsified if independently audited trust scores achieve adoption across two or more major registries by 2031 — that would indicate the world is in scenario one instead.

Scenario three: The Certified Families — protocols fragment, trust is certified

Mechanism. No single protocol wins broadly across functions, because the same forces already visible today — a tool-invocation protocol, a separate agent-coordination protocol, and a separate commerce protocol, each launched independently within one season ^{[2, 3, 14]} — keep multiplying rather than consolidating as new categories of agent action emerge. But within each family, certification does mature: a commerce-specific protocol builds its own audited safety regime suited to payment risk, an industrial-control-specific protocol builds an entirely different one suited to physical risk, and neither transfers to the other, echoing the closed-loop, domain-scoped character that current certified-runtime-safety theory already predicts a workable certificate would have to have ^[10].

Horizon. A recognisable divergence-with-certification pattern by 2030–2032; stable by 2035.

Assumptions. Certification cost is justified only within functions where the consequence of a bad tool call is severe enough to bear it; the functions that clear that bar differ enough from each other that a shared reference protocol does not emerge even after each is separately certified.

Observable indicators. First, two or more function-specific protocols — commerce, agent coordination, tool invocation, or a further category not yet named — each develop independent, structurally incompatible certification schemes. Second, tooling built for one certified family fails to transfer to another without substantial rework. Third, the position-paper argument for a shared minimal interoperability layer ^[11] continues to be published as an open call rather than cited as an achieved standard.

Disconfirmation. Falsified if a single certification scheme is adopted across two or more structurally different functions without requiring incompatible protocols — that would push the world toward scenario one instead.

Scenario four: The Loose Set — protocols fragment, trust stays empirical

Mechanism. The same fragmentation drivers as scenario three hold, but no function builds a certification regime either, because the cost of formal certification never gets justified anywhere: registry-scale auditing stays too expensive relative to how fast new tool categories appear, and the closed-loop limits current theoretical work already names keep formal guarantees narrow ^[10]. The field keeps doing what the evidence above already shows it doing in 2026 — a registry dominated by duplicated, unaudited self-report ^[5], a benchmark showing poisoned descriptions succeeding more often than not against an unhardened model ^[9], and periodic, individually discovered supply-chain incidents of the postmark-mcp kind ^[7] treated as one-off news rather than as evidence of a systemic gap. This scenario’s leading indicator is not a future event; it is the documented present described above, continuing.

Horizon. Close to today’s baseline; recognisable as the stable case by 2028 if none of the trends above accelerate; could persist largely unchanged through 2035.

Assumptions. New tool-using functions keep appearing faster than any standardisation or certification effort can absorb them; self-reported, unaudited registries continue being accepted as sufficient for adoption, consistent with the current registry’s own explicit disclaimer of warranty ^[4].

Observable indicators. First, no cross-vendor tool-invocation standard achieves the convergence thresholds defined in scenarios one and two. Second, no certification scheme for tool safety or provenance achieves multi-registry adoption in any function by 2032. Third, independent security research continues to find tool-poisoning success rates and supply-chain incidents at a similar order of magnitude to today’s, without a clear downward trend tied to a specific governance change.

Disconfirmation. Falsified if either protocol convergence or certification adoption is observed at the thresholds defined in scenarios one through three — either observation would move the world out of this cell.

What all four share, and the possibility neither axis names

Three things hold across every cell, and are the safest things to build engineering practice on regardless of which one obtains. First, some form of empirical red-teaming survives in all four, including the certified ones — even a certified gate needs continuous adversarial testing to catch drift and novel attack shapes, exactly as current certified-runtime-safety theory itself concedes that closed-loop behaviour and representation shifts can silently move a system outside a certificate’s original scope ^[10]. Certification adds a floor; it does not remove the need to keep testing above it. Second, the OpenAPI-versus-distinct-layer question is a narrower and more separable technical detail than Axis A itself, and can plausibly settle on its own regardless of which cell the invocation-protocol question lands in ^[16] — a converged protocol built as a thin wrapper over reused API description, or one that keeps a persistent AI-specific semantic layer, is compatible with any of the four cells above. Third, none of the four requires a capability plateau or a discontinuity in what agents can actually do; each is compatible with tool-using capability continuing to grow at whatever pace the underlying models allow, because the axes describe infrastructure and governance maturity, not the rate of technical progress.

The four scenarios share a blind spot too, worth naming rather than hiding. All four assume gradual movement along the paths traced above. A large enough shock would not fit cleanly into any of them: a single, publicly attributed incident on the scale of the postmark-mcp backdoor, but against infrastructure serious enough to force emergency, binding certification requirements overnight rather than the gradual audit adoption scenario one traces ^[7]; a genuine breakthrough that solved the closed-loop and cross-domain transfer limits current certified-runtime-safety theory documents, making certification suddenly cheap and general rather than narrow and function-scoped ^[10]; or one of today’s three separately governed protocols — tool invocation, agent coordination, commerce — absorbing the other two outright rather than each maturing in parallel, collapsing three layers into one faster than any scenario above assumes ^{[2, 3, 14]}. Any of these would move both axes at once, abruptly, rather than along the gradual paths each scenario traces.

Three predictions, stated separately from the scenarios

Prediction one. Horizon: end of 2028. At least one major MCP-compatible registry or client will begin publishing an independently produced trust or safety signal for listed servers — distinct from self-reported annotations — regardless of which scenario the field otherwise tracks toward, because the gap between the registry’s current disclaimer of warranty and the scale of documented poisoning incidents has become too visible to leave unaddressed ^{[4, 9]}. Assumption: at least one organisation with the resources to run independent audits at registry scale concludes the reputational or liability exposure of not doing so exceeds the cost of doing it. Indicator: a published, dated registry or client feature that labels or scores entries using signals not supplied by the entry’s own maintainer. Disconfirmed if by the end of 2028 every major registry still relies exclusively on self-reported or community-flagged data with no independently produced signal in production.

Prediction two. Horizon: end of 2029. The number of separately governed, function-specific tool and agent protocols with meaningful multi-vendor adoption will grow rather than shrink from today’s count of three, because new agent-usable functions keep emerging faster than any single protocol’s scope naturally extends to cover them, consistent with tool invocation, agent coordination, and commerce each arriving as separate efforts within one nine-month window ^{[2, 3, 14]}. Assumption: no single foundation or vendor achieves the scope to absorb multiple functions under one governance umbrella before 2029. Indicator: a count, at each year’s end, of distinct multi-vendor-adopted protocols addressing different agent-tool or agent-agent functions. Disconfirmed if by the end of 2029 the count has fallen to two or fewer through consolidation rather than risen through the addition of new functions.

Prediction three. Horizon: end of 2030. Formal-verification research for tool-calling agents will report evaluation across more than one materially different tool domain, moving beyond the single-domain, closed-loop-limited scope current work explicitly documents, regardless of which scenario the field otherwise tracks toward ^[10]. Assumption: research investment in agent-specific formal verification continues at roughly its current trajectory rather than being abandoned as impractical. Indicator: a published paper, system card, or product document citing certified or formally bounded tool-call safety coverage across multiple, materially different domains rather than one narrow demonstration. Disconfirmed if by the end of 2030 published formal-verification work for tool-using agents remains confined to single-domain demonstrations comparable in scope to current work.

What to take away

The refusal to name a favourite among these four is the substantive claim, not a hedge around one. In August 2026 the evidence is genuinely split on both axes at once: a protocol’s own author giving up sole governance to a foundation its competitors co-fund sits beside two further, separately governed protocols launched for two other functions in the same nine months; a formal theory of certified runtime safety that makes real, checkable claims about what can be guaranteed sits beside a benchmark showing a poisoned tool description still succeeding against an unhardened model close to three times out of four; and a registry built to solve discovery, doing that job well enough to accumulate tens of millions of entries, still carries its own operator’s explicit disclaimer that none of it is warranted. Anyone reporting a confident single future for tool protocols and interoperability in 2035 is reporting which of these four they would bet on, not what the current record shows. The more useful and less satisfying discipline is the one this article tried to practise throughout: know which signal to watch, and have said in advance, on the record, what each one finding would mean.