MCP servers are the new APIs

Twenty years ago, a business that wanted software to work with it published an API. It was a deliberate act: decide what outsiders may read and change, describe it, put authentication in front of it, run it somewhere reliable, and accept that it is now part of the product. Businesses that did it well became platforms. The rest became integrations someone else maintained.

The same decision has arrived again, for a different caller. Agents do not read API documentation and write client code. They discover tools, read their descriptions, and call them. The Model Context Protocol is the format in which a business now describes what an agent may do with it. Within a few years, an MCP surface will be as ordinary as a REST API, and the companies that treat it as infrastructure will be the ones agents can actually use.

The protocol has become infrastructure

MCP is no longer one vendor's experiment. On 9 December 2025, Anthropic donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI, with Google, Microsoft, AWS, Cloudflare and Bloomberg supporting it. At that point there were more than 10,000 active public MCP servers and more than 97 million monthly SDK downloads across Python and TypeScript, and clients including ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code supported the protocol (Anthropic). An official registry for public servers launched in preview on 8 September 2025 (MCP blog).

The specification itself has matured in the way infrastructure specifications do. Versions are dated by the last backwards-incompatible change. The current revision is 2026-07-28, which followed 2025-11-25 (MCP versioning), and it adopted a formal feature lifecycle with a minimum twelve-month deprecation window.

The latest revision is written for operators

The 2026-07-28 changes read like a list of lessons from running servers at scale (changelog):

• Protocol-level sessions and the Mcp-Session-Id header are gone from the Streamable HTTP transport, and the initialisation handshake is removed. Every request carries its protocol version and client capabilities. A server that needs state across calls mints an explicit handle and passes it as an ordinary argument.
• Servers must implement server/discover, which advertises supported versions, capabilities and identity in one request.
• List results carry ttlMs and cacheScope, so clients and shared intermediaries know what they may cache, and servers should return tools in a deterministic order.
• Requests carry standard headers naming the method and target, and trace context propagation follows OpenTelemetry conventions.
• On authorisation, clients must validate the issuer in authorisation responses where it is present, must key stored credentials by issuer and never reuse them with a different authorisation server, and dynamic client registration is deprecated in favour of client ID metadata documents.

A stateless protocol with explicit caching, routable headers and traceable requests is one you can put behind a load balancer, scale horizontally and observe. That is the protocol telling you how it expects to be hosted.

The incidents have been about hosting, not the idea

The early security record of MCP is instructive because almost none of it is about models misbehaving. It is about servers and clients being run carelessly.

In July 2025, JFrog disclosed CVE-2025-6514, rated CVSS 9.6, in mcp-remote, a widely used proxy that let local clients reach remote MCP servers. A malicious server could return a crafted authorisation endpoint that the client passed to the operating system unsanitised, leading to arbitrary command execution on Windows (JFrog). In June 2025, Asana took its MCP server offline after finding a flaw in a tenant isolation check that could expose one organisation's data to users of another; it estimated around 1,000 customers were affected (BleepingComputer).

The specification's own security best practices read like a hosting checklist. MCP proxy servers must obtain per-client consent to prevent confused deputy attacks. Servers must not accept tokens that were not issued for them, which forbids passing a user's upstream token straight through. Clients deployed on servers must guard against server-side request forgery during OAuth discovery, including requests to cloud metadata endpoints. Servers must not use sessions for authentication. Scopes should start minimal and be elevated only when a privileged operation is first attempted.

None of this is exotic. It is the same discipline that public APIs needed: authentication, tenant isolation, input validation, egress control and least privilege. What changes is the caller. An agent will try every tool you expose, follow every URL a server hands it, and do so at machine speed.

Why every business will publish one

The argument for an MCP surface is the same as the argument for an API, sharpened. If agents are going to book, buy, file, query and pay on behalf of people, they will do it through whatever surface is available. A business that publishes a well-scoped MCP server decides what agents may do and on what terms. A business that does not will be reached anyway, through screen scraping, brittle browser automation or a third party's unofficial wrapper, with none of the controls.

Most businesses already have the raw material. An OpenAPI document describes operations, parameters and authentication. Turning it into agent tools is mostly a matter of choosing which operations to expose, describing them well and deciding which of them change state. The hard part is not the translation; it is running the result as a governed service.

What this means for CTOs

Treat your MCP surface as a product interface with an owner, not a demo. Expose a deliberate subset of operations, mark which ones read, write or destroy, and put authorisation in front of each according to its effect. Use OAuth with tokens issued to your server and nobody else's. Isolate tenants in the server, not just in the database behind it. Build to the stateless revision so the server can scale and be observed like any other HTTP service, and log every call with enough context to answer who did what on whose behalf.

On the consuming side, assume that some servers your agents meet will be malicious. Validate every URL a server hands you, refuse dangerous schemes, never open them through a shell, and restrict outbound network access from the processes that run tools.

Where Praecise fits

Praecise Cloud provides compute, MCP servers and backends for agents, on hardware Praecise owns: built from source, placed behind the edge, supervised and reversible. Teams deploy agents, MCP servers, apps and data there with no infrastructure of their own to run. Praecise Harness, the open-source framework (Apache-2.0), connects to any MCP server by URL or spawned, turns any OpenAPI document into tools, supports OAuth 2.1 with resource indicators and PKCE, and serves each app as an MCP server among its other interfaces. Its guard.ts decides in code which tool calls an app actually makes, with effects declared as read, write or destructive.