The Model Context Protocol, and why its adoption curve matters for payments

The Model Context Protocol is the open specification that lets an AI agent discover a tool, call it, and read back a structured result, using the same interface whether that tool is a filesystem, a search index or a payments API. It's a small idea that has moved fast: Anthropic published the spec in November 2024, and by March 2026 the software development kits implementing it were being pulled roughly 97 million times a month, up from about 100,000 at launch. This piece explains what the protocol actually standardises, why the growth curve looks the way it does, and the one thing it deliberately does not do, which is decide whether a given tool call is safe.

What the Model Context Protocol actually standardises

Before this existed, wiring an agent up to outside capabilities meant writing bespoke glue for each one: a connector for a calendar, another for a database, another for a payments provider, none of it portable to a different agent framework without a rewrite. Model Context Protocol replaces that with a shared contract. A client asks a server "what can you offer?" and gets back a list of tools, resources and prompts, each described precisely enough that a model can reason about calling them the same way it reasons about anything else sitting in its context window.

Three roles do the work. The host is the application containing the agent: a chat product, an automation, a coding assistant. The host embeds one or more clients, and each client holds exactly one connection to exactly one server. The server doesn't know or care which host is on the other end of that connection; it only has to speak the protocol correctly.

That separation is the actual point. A single host can run five clients side by side, wired to five different servers, and the model reasons across all of them without the application author writing a single line of bespoke integration code for any one of them.

Why the growth curve looks the way it does

A specification is only as useful as what adopts it, and here the adoption has been unusually broad rather than narrow. Google's Agent2Agent effort, OpenAI's Agents SDK, Microsoft's Copilot Studio and Salesforce's Agentforce all shipped Model Context Protocol support within thirteen months of the original release, according to coverage tracking the ecosystem's growth through mid-2026. That's a different pattern from most agent-framework standards, which tend to stay locked inside the vendor that proposed them.

Anthropic donated the specification to the Linux Foundation in December 2025, moving governance from a single company's roadmap to a standards body with Anthropic, OpenAI, Google, Microsoft and Block as founding steering members. Independent server counts vary by how you count them, unsurprisingly for something this decentralised: a pull from the official registry's API in May 2026 recorded 9,652 latest server entries, while a GitHub topic search the same month returned nearly 16,000 repositories tagged as MCP servers. Whichever number you trust, the shape is the same: thousands of published integrations, most of them read-only, spanning filesystems, search engines, ticketing systems and common SaaS tools.

Table: the Model Context Protocol's adoption trajectory, drawn from the sources cited above.

Where the protocol stops, deliberately

Here is the part worth sitting with. Model Context Protocol standardises discovery and calling. It has nothing to say about whether a particular tool call should be allowed to happen. That's not an oversight; a protocol that tried to encode every caller's risk tolerance would be unworkable, so the specification leaves authorisation, rate limiting and business logic entirely to whoever builds the server and whoever builds the host.

The practical effect is that a server's tool descriptions are just text, and that text lands in the model's context exactly the way a user's message does. The model treats it as something to reason about and, often, as instructions to follow. A malicious or merely careless server can put a hostile instruction inside a tool's own docstring, and the moment a host connects to it, that instruction is sitting in context before the model ever calls a single tool. Security researchers named this tool poisoning, and OWASP's MCP-specific Top 10 now ranks it third among the risks the ecosystem has to design around, alongside prompt injection carried through tool metadata generally.

"A tool description is text that goes into the model's context the same way a user's message does. Most teams spend weeks worrying about prompt injection from a hostile web page and give zero thought to the server they installed with npx -y last Tuesday, which can say whatever it wants."

the Spend7 engineering team

That distinction between reading and acting is where the stakes actually diverge. A poisoned description on a documentation-search server costs you a wasted call, maybe a leaked file path. The same poisoning on a server holding a payment credential, or one whose tool can authorise a transfer, is a different category of problem, because the thing being poisoned is the decision to spend money, not the decision to fetch a paragraph.

A worked example: the same tool, two designs

Say an agent needs to pay a vendor through an x402-style settlement. One design puts the actual payment inside an MCP tool the model can call directly: pay(merchant, amount), executed the instant the model decides to invoke it. The second design puts a risk check behind the tool, not the payment itself: the tool returns an allow, flag or deny verdict against caps that live outside the model's reach, and only an allow lets the caller proceed to settlement.

The difference matters because an MCP tool is, by construction, something a model can choose not to call. That's fine for a search tool, where skipping it just means a worse answer. It's a poor design for the only thing standing between an agent and an unauthorised payment, because "the model chose to call the safety check" is not a guarantee you can build a control around. The second design puts the enforcement in code the agent cannot route around; the tool call becomes informative, and the actual gate sits in the calling application.

Common pitfalls

Treating every server as read-only by default. Check the tool list before connecting anything. A transfer, delete or pay tool changes what you're actually exposing your agent to, and the protocol gives you no warning label for it.

Auto-updating a third-party server without review. An MCP server that updates itself is a block of text sitting inside your model's context that can change its own content on its own schedule. Pin the version and diff before you bump it, the way you would for any other dependency with write access to your supply chain.

Assuming the tool call is the control. Nothing in the protocol stops a model from declining to call a tool it was meant to call, or calling it with arguments nobody expected. Where a decision genuinely has to be enforced, it belongs in code the agent cannot opt out of, not in an optional tool sitting alongside everything else in its toolbox.

Skipping discovery output in review. The tool names and descriptions a server returns are exactly as reviewable as any other third-party dependency's source, and most teams read neither the first time they wire one in.

Where this leaves a team building on it

None of this is an argument against adopting the protocol; the adoption numbers above make the case for themselves, and reusing a well-maintained server beats writing bespoke glue for the tenth time. It's an argument for reading the fine print on the one category of tool that changes the calculus: anything that can move money, delete data or take an action with a real-world consequence outside your own sandbox. For a plain-English walkthrough of that specific server type, see what an MCP server actually is and where the risk sits, and for the payment case specifically, how to wire a payment MCP server in without handing the model the keys covers the pattern from the worked example above in full.

If your agents already hold payment credentials through this kind of integration, the same reasoning applies to defending against prompt injection aimed at a payment-capable agent: the fix sits in architecture, not in trusting the model harder. And if you're deciding what an agent should be allowed to spend in the first place, regardless of which protocol carries the call, Spend7's spend-limit tooling is built for exactly that layer, sitting underneath the integration rather than inside it.

FAQ

What is the Model Context Protocol in simple terms?

An open specification that lets an AI application discover and call external tools, read external data and reuse prompt templates through one consistent interface, rather than through a different bespoke integration for every data source or API. Anthropic published it in November 2024; by mid-2026 it had become the de facto way agent frameworks wire up outside capabilities.

Who maintains the Model Context Protocol now?

Anthropic wrote the original specification and donated stewardship to the Linux Foundation in December 2025, alongside major contributors including OpenAI, Google, Microsoft and Block. Governance now runs as a standards body rather than a single vendor's roadmap, which is part of why competing frameworks converged on it instead of shipping their own.

Is the Model Context Protocol secure by default?

No, and it was never designed to be. The protocol standardises discovery and calling; it says nothing about what a given tool should be trusted to do. A server's tool descriptions load straight into the model's context as text the model treats as instructions, which is how tool poisoning works, and nothing in the spec stops a tool from acting on every call it receives.

Do I need MCP if I'm only calling one API?

Probably not. The protocol earns its cost when an agent needs to reach several tools across frameworks, or when you want a capability, like a payment risk check, to be reusable by whichever agent runtime a team picks next. A single hard-coded API call is simpler, and there's no shame in leaving it that way until reuse actually shows up.

What's the difference between an MCP tool and an MCP resource?

A tool is a function the model can call with arguments and get a result back, an action. A resource is read-only data the host pulls into context, more like a file handed to the model than a button it presses. The distinction matters because a tool that changes state, sends something, books something, pays for something, carries a different risk profile than a resource that only informs.

Sources

• Model Context Protocol specification: the protocol's own documentation and SDK list.
• Linux Foundation: Model Context Protocol donation, December 2025: governance transfer and founding steering members.
• OWASP GenAI Security Project: MCP Top 10: the tool-poisoning ranking referenced above.