Connectors vs MCP Servers: What the July 2026 Spec Changed About Buying Integration

What actually changed on 28 July 2026

The headline change is that the protocol core went stateless. The old handshake, where a client called initialize and then carried a session identifier in a header for the rest of its life, is gone. Each request now carries its own protocol version, client identity and capabilities. That sounds like plumbing, and it is, but it is the specific piece of plumbing that made remote MCP servers expensive to operate. A server that previously needed sticky sessions, a shared session store and a gateway smart enough to read request bodies can now sit behind an ordinary round-robin load balancer.

Two companion changes point the same direction. Gateways can route on new Mcp-Method and Mcp-Name headers without parsing JSON, and tool listings became cacheable: responses to tools/list and its siblings now carry a ttlMs and a cache scope, so a client does not have to re-enumerate every available tool on every run. Taken together, these are the changes you make when you expect a lot of traffic rather than a lot of experiments.

The authorization work matters more for buyers. Dynamic Client Registration, the mechanism by which a client could obtain an OAuth client identifier without a human ever registering it, was formally deprecated in favour of Client ID Metadata Documents. Clients must now validate the issuer under RFC 9207 before redeeming a code, credentials are bound to the authorization server that issued them, and clients are required to send RFC 8707 resource indicators so a token is scoped to the specific resource it was requested for. In plain terms: it is now considerably harder for a token minted for one system to be replayed against another. That was the single most uncomfortable property of the earlier design, and it was the reason a lot of security teams refused to approve remote MCP at all.

The release also drew a line around stability. An extensions framework was formalised, long-running Tasks moved out of the experimental core into a named extension, and deprecations arrived with committed support windows — a minimum of twelve months for Roots, Sampling and Logging, and a one-year offramp for the legacy HTTP and server-sent-events transport. Published exit ramps are what distinguish something you can budget against from something you can only pilot.

Why this is a buying question, not a protocol question

It would be easy to read all of that as an engineering story. It is not, because the platform vendors have already priced it in. Gartner expects 75 percent of API gateway vendors and 50 percent of iPaaS vendors to ship MCP features by 2026, and the major integration platforms are visibly getting there: SnapLogic, Workato and MuleSoft have all released production MCP capabilities, and Zapier exposes its catalogue of more than 9,000 applications to external models through an MCP endpoint, so a model can call actions across that catalogue without a workflow being drawn in advance.

That convergence is the important signal. Nobody with a real connector catalogue is treating MCP as a threat to be resisted; they are treating it as another front door to the same building. Which means the buyer question is no longer which technology wins. It is: for this specific process, in this specific system, which door do I pay to walk through, and who is on the hook when the lock changes? If you want the protocol itself explained from first principles rather than from the buying side, our plain-English guide to the Model Context Protocol covers the mechanics.

Route 1: the connector catalogue you already pay for

This is the incumbent, and it is still the correct default for most organisations. You buy an automation platform — Zapier, Make, Power Automate, Workato, n8n, any of a dozen others — and the platform maintains the authentication, the field mappings and the endpoint churn for every application in its catalogue. When your CRM vendor deprecates an API version, somebody else's engineering team absorbs it. You find out because nothing broke.

The cost is shape, not just size. These platforms meter consumption, and the meter is where the surprises live. Zapier's Professional tier starts around 29.99 dollars a month for 750 tasks and has been repriced three times since 2022. Make positions its Core tier near 12 dollars. Power Automate sells a premium standalone plan at roughly 15 dollars per user per month, with process mining as a separate line closer to 150 dollars per user per month. None of those numbers is the problem on its own. The problem is that an agent that decides for itself how many calls to make turns a predictable per-task bill into a variable one, and the platform's pricing model was designed before anything in the loop got to make that decision.

• Choose it when the process is known, the path is stable, and the systems involved are mainstream enough to be in the catalogue.
• Avoid it when your core system is niche or homegrown, or when the volume makes per-task pricing worse than running your own runtime.
• The real risk is accumulated dependency: hundreds of business rules encoded in one vendor's console, in a format that only that console reads.

Route 2: a remote MCP server from a vendor

The second route is to consume an MCP server that somebody else hosts — typically the vendor of the system you want to reach, or your integration platform acting as a front for many systems at once. You point your agent at a URL, complete an OAuth flow, and the model can discover and call the available tools at runtime.

What the July specification changed here is mostly operational and mostly in your favour. A stateless server is cheaper for the vendor to run and less likely to fall over under load, cacheable tool listings mean your agent is not paying to re-enumerate a catalogue on every invocation, and the authorization hardening means your security review has real answers to give. Issuer validation and resource-bound tokens are the difference between a workable review and a rejected one.

The trade is that you have handed the decision of which action to take to a model. That is the point of the route, and it is also its failure mode. A connector-based workflow does what you drew. An agent with tool access does what it infers, and the inference is influenced by everything it reads along the way — including content returned by the tools themselves. That is not a hypothetical concern, and it is worth reading alongside our guide to prompt injection in production automation before you grant write access to anything.

Route 3: an MCP server you build and host yourself

The third route is to wrap your own systems — the internal order database, the legacy scheduling tool, the pricing logic nobody has ever successfully exported — behind a server you control. This is where the stateless change pays the largest dividend, because the operational burden that made self-hosting unattractive in 2025 has genuinely dropped. You can run it like any other stateless HTTP service.

This is also the only route that makes your competitive advantage callable. A connector catalogue can reach Salesforce; it cannot reach the quoting rule your business spent eleven years refining. If that rule is the thing an agent needs to consult, somebody has to expose it, and that somebody is you.

The cost is ownership in the full sense. You maintain the tool definitions, you handle authorization, you decide what happens when a model calls a destructive tool with plausible-looking arguments, and you carry the upgrade work when the specification moves again. The twelve-month deprecation windows make that work schedulable rather than urgent, which is a meaningful improvement, but it does not make it free.

Route 4: no integration at all, and a browser instead

The fourth route skips the integration layer entirely. If a system has no API worth using — and a great many systems in logistics, healthcare administration, insurance and local government still do not — you can put an agent in front of the same web interface a human would use, and let it log in, navigate and fill the form.

This used to be economically awkward, because driving a full Chromium instance per session is expensive. Cloudflare's Kitesurf, launched on 6 August 2026, is a direct attack on that cost: an agent-first browser runtime built in Rust and WebAssembly that runs in V8 isolates on Workers, uses three to seven times less CPU and memory than Chromium for common agent tasks like screenshots and HTML extraction, passes more than 235,000 Web Platform Tests, and exposes a Chrome DevTools Protocol endpoint that existing Puppeteer, Playwright and MCP clients can drive unchanged. It is not the only entrant, but it is the clearest signal that the browser is being treated as infrastructure for software rather than a place people look at pages.

The honest assessment is that this route is a last resort that has become a respectable last resort. You are automating against a user interface that can be redesigned on a Tuesday with no changelog and no deprecation window. Use it for the systems you cannot reach any other way, price the maintenance accordingly, and do not let it become the default because it demos well.

The four routes compared

The cost nobody puts in the business case

The comparison above is incomplete without the supply chain, because routes two and three both inherit a dependency graph that has been under sustained attack throughout 2026. Academic work surveying more than 1,800 deployed MCP servers found that over 30 percent contained at least one exploitable vulnerability. That is not a long tail of hobby projects; it is roughly one in three of what is publicly running.

The incidents are instructive because none of them looked broken. A malicious package impersonating the transactional email provider Postmark worked exactly as advertised as an email-sending server, while silently blind-copying every message it sent to an attacker-controlled address. A typosquatted package named mcp-server-github intercepted installs intended for the official package and posted hostname, working directory, environment details and platform information to a remote endpoint on every install. The surrounding ecosystem has been no calmer: the widely used axios package, with over 100 million weekly installs, was compromised on 31 March 2026 through a hijacked maintainer account.

Then there is the injection problem, which is structural rather than incidental. When tool output is fed back to a model as context, the output becomes an instruction channel. Testing against prompt-injection-via-tool-output scenarios found even the strongest commercial agents failing roughly half the time, following the malicious instruction more often than ignoring it. No specification revision fixes this, because it is not a transport bug. It is what happens when the thing deciding what to do next also reads whatever the last tool returned.

Lock-in has moved, and most buyers have not noticed

The consolidation of the last two years makes this urgent. Salesforce completed its acquisition of Informatica in November 2025, putting CRM, agents and enterprise data management under one roof. Automation Anywhere bought Aisera the same month for its pre-built agentic solutions across IT service management, HR and customer service. The top of the integration market is now fewer, larger platforms than it was, and each of them would very much like to be the layer your agents speak through.

The defence is not to avoid vendors. It is to stop letting three separable things get bundled into one subscription: the description of what your business can do, the credentials that let something do it, and the runtime that executes it. Keep tool definitions in your own repository. Keep credentials in your own secret store. Then the runtime becomes a component you can swap, rather than the place your operating model lives. Our guide on avoiding automation vendor lock-in goes further on the contractual side of that, particularly around data export and exit terms.

A decision rule that will outlast the next revision

Specifications will keep moving. The useful thing is a rule that does not depend on which one is current. Work through these in order, and stop at the first one that fits:

1. Is the path fixed and known? If the sequence of steps does not change from run to run, use the connector catalogue. You do not need a model to choose something that is already decided, and you should not pay tokens for the privilege.
2. Does the choice of action genuinely vary? If the right next step depends on content a human would have to read, that is the case for tool access. Start with a vendor-hosted server for a system you already trust, and keep the first deployment read-only.
3. Is the logic yours and material? If the knowledge an agent needs lives in your own systems and is part of why customers choose you, host your own server. Nobody else will build that tool, and exposing it is the actual work.
4. Is there no interface at all? Only then reach for a browser agent, and budget for maintenance as an ongoing line rather than a one-off build.
5. Whichever you chose, where is the deterministic gate? Every irreversible action — a payment, a deletion, an outbound message to a customer — gets a check that does not involve a model. This is the one rule that applies to all four routes.

Most organisations will end up running two or three of these at once, and that is the correct outcome rather than a sign of indecision. The mistake is not mixing routes. The mistake is picking one because a vendor announcement made it feel inevitable, and then discovering eighteen months later that your entire operating model is expressed in a format only one company can read.

FAQ

What actually changed in the 28 July 2026 MCP specification?

It was the largest revision since the protocol launched in November 2024, and it was mostly an operations release. The protocol core went stateless, dropping the initialize handshake and the session header, so a remote server can sit behind an ordinary round-robin load balancer. Gateways can route on the new Mcp-Method and Mcp-Name headers without parsing the request body, and tool listings became cacheable through a ttlMs field. On the security side, Dynamic Client Registration was deprecated in favour of Client ID Metadata Documents, issuer validation under RFC 9207 became mandatory before a client redeems a code, and clients must now send RFC 8707 resource indicators so a token is bound to the server it was minted for.

Does MCP replace an iPaaS or a connector catalogue?

No, and the vendors are not behaving as though it will. Gartner expects 75 percent of API gateway vendors and 50 percent of iPaaS vendors to ship MCP features by 2026, which is convergence rather than displacement. MCP is a protocol for exposing callable tools to a model. An integration platform is the thing that holds multi-tenant credentials, retries a failed step, sequences work across systems and writes an audit trail. Most teams end up using MCP for the real-time actions an agent chooses at runtime and their existing platform for scheduled and batch work.

Which route should a small business pick first?

Start with the connector catalogue you already pay for. It is the only route where someone else absorbs the cost of an upstream API change, and for the majority of business processes the agent is not the hard part. Add a remote MCP server from a vendor you already trust when you have a genuine case for the model choosing which action to call, rather than following a path you designed. Build and host your own server only when the tool you need does not exist and the process is core to how you make money.

How risky are third-party MCP servers in practice?

Risky enough to warrant a review step. Academic work surveying more than 1,800 deployed MCP servers found that over 30 percent carried at least one exploitable vulnerability. Real incidents include a package impersonating the transactional email service Postmark that worked correctly while silently blind-copying every message to an attacker address, and a typosquatted mcp-server-github package that posted hostname, working directory and environment details to a remote endpoint on install. The wider npm supply chain has been a live problem all year, including the compromise of axios on 31 March 2026 through a hijacked maintainer account.

What is an agent browser and when does it beat an integration?

It is a browser runtime built to be driven by software rather than a person, so an agent can log in, navigate and fill forms on a system that has no usable API. Cloudflare launched Kitesurf on 6 August 2026, running in V8 isolates on Workers, using three to seven times less CPU and memory than Chromium for common agent tasks and exposing a CDP endpoint that existing Puppeteer, Playwright and MCP clients can drive. It beats an integration only when there is no integration to buy, because the interface you are automating against can change without warning or notice.

How do I avoid locking myself into whichever route I choose?

Separate the three things that usually get bundled: the description of what your business can do, the credentials that let something do it, and the runtime that executes it. If your tool definitions live in your own repository and your credentials sit in your own secret store, swapping a runtime is an afternoon of work. If both live inside one vendor console, you are paying that vendor for the privilege of keeping your own process definitions.

Is the protocol stable enough to build against now?

More stable than it was, and with published exit ramps. The July release formalised an extensions framework and moved long-running Tasks out of the experimental core into a named extension. Deprecations now come with committed support windows: Roots, Sampling and Logging carry a minimum twelve-month window, and the legacy HTTP plus SSE transport was given a one-year offramp. That is enough predictability to build against, provided you treat any MCP server you did not write as a dependency you have to re-check, not a fixture.