MCP Compatibility Matrix: What Actually Works in 2026

57% of vendors with MCP servers won’t tell you which plan you need to access it, and that opacity is just one variable in the MCP compatibility matrix you’re about to navigate. The protocol has hit 475 million monthly SDK downloads, but the ecosystem is fragmented in ways that make “MCP-compatible” a misleading claim for most production deployments. I’ve pulled together the actual compatibility data—client support, spec versions, plan gates, and gateway requirements—so you can stop guessing and start building.

How many vendors ship an MCP server, and what does it cost?

The adoption numbers are real, but they’re not as clean as the marketing suggests. According to AI Builder Marketplace’s research, 74 of 425 business-software vendors ship a first-party MCP server—that’s 17.4% of the market. In the GTM space specifically, The GTM Directory’s September 2026 check found 459 of 960 tools (48%) publish their own MCP server. Those are the vendors who’ve actually done the work. The rest are either waiting or claiming compatibility through third-party bridges.

The cost question is where the matrix gets messy. Of those 74 vendors with MCP servers, 42—57%—state no plan, tier, or price anywhere in their own documentation. That’s not a rounding error. The same research found that 13 vendors include MCP on every plan including free, 10 require any paid plan, and 9 gate it behind a specific higher tier. Miro and Freshservice require Enterprise, while Similarweb requires a subscription with API access. Tenable needs a Tenable One license. If you budgeted assuming MCP came free with your seat, those are the surprises waiting in your renewal invoice.

The CRM space shows the pattern clearly. Aliteq’s comparison of seven CRMs found that Attio and Pipedrive work on every plan, Twenty lists on Pro and up, and Salesforce requires Enterprise Edition or above. Close and HubSpot name no minimum plan on their MCP pages. Freshsales has no MCP server at all. The takeaway: “MCP-compatible” doesn’t tell you if you can actually use it without upgrading.

When you factor in subscription costs, the numbers get uglier fast. A 50-developer team deploying Sourcegraph Cody for code intelligence MCP would spend $8,400/year on subscriptions alone—that’s 50 developers times the $14/month midpoint, times 12 months—before token costs and gateway fees. Sverklo’s comparison matrix shows Cody at $9–19 per developer per month, and that’s just one server in a stack that might include GitHub, Context7, and a browser automation tool. The token tax is real, and it scales with every poorly scoped tool definition.

Which MCP clients support which protocol features?

The protocol may be standard, but client implementation is not. Claude Desktop, Cursor, and VS Code Copilot each support a different subset of features, and that difference determines whether your server works everywhere or only in one environment. The compatibility matrix from DEV Community breaks it down clearly: Claude Desktop supports resources, prompts, sampling, and OAuth; Cursor supports only partial SSE/HTTP and OAuth with no resources, prompts, or sampling; VS Code Copilot supports partial resources and SSE/HTTP with no prompts, sampling, or OAuth.

That fragmentation matters for server authors. If your server depends on sampling—where the server asks the client to run an LLM call—it’s a Claude Desktop exclusive. If it uses resources or prompts as the primary interface, Cursor and VS Code users won’t see them. The safe core is tools: every client supports tools/list and tools/call. Build around those, and your server works everywhere. Build around the optional features, and you’re shipping a Claude-only product.

Here’s the practical breakdown:

Feature	Claude Desktop	Cursor	VS Code Copilot
stdio transport	✓	✓	✓
SSE/HTTP transport	✓	partial	partial
resources	✓	✗	partial
prompts	✓	✗	✗
sampling (server→client LLM)	✓	✗	✗
OAuth auth flow	✓	partial	partial

The table shows why “MCP-compatible” needs a qualifier. A server that works in Claude Desktop might fail silently in Cursor if it relies on resources for context loading. A server that uses OAuth won’t work in VS Code without a workaround. Test against every client you claim to support, because the protocol standard doesn’t guarantee feature parity.

Version compatibility adds another layer. SonarQube’s community forum confirms their MCP server requires at least SonarQube Community Build 25.1 and is backwards compatible with that version, but they won’t guarantee future compatibility. That’s a pattern: most vendors document a minimum version, few promise forward compatibility. If you’re connecting an MCP server to a system you also upgrade regularly, pin your server version and test after each system update.

How does the 2026-07-28 spec change server compatibility?

The current protocol revision, MCP 2026-07-28, moves MCP to a stateless core with authorization hardening and a formal twelve-month deprecation policy. That’s a breaking change for any server relying on the old session model. The dated revisions are 2025-03-26, 2025-06-18, 2025-11-25, and 2026-07-28—a 2026-03-26 revision does not exist, despite being quoted in some migration guides. If you’re reading a guide that references it, the guide is wrong.

The stateless shift removes the initialize handshake and session management. Previously, a server would issue an Mcp-Session-Id header that pinned the client to a specific instance. Now every request carries its own identity and capability information inline. That simplifies horizontal scaling—you can put MCP servers behind a round-robin load balancer without sticky sessions—but it increases per-request payload size and shifts the security boundary. The session previously contained blast radius by pinning a client to one server instance; stateless requests require every server in a pool to validate identity independently.

The twelve-month deprecation policy is the part that matters for your migration timeline. Roots, Sampling, Logging, and the old HTTP+SSE transport are all deprecated but remain in the spec until at least July 2027. That gives you runway, but it doesn’t mean you can ignore the changes. Our guide to the July 2026 stateless spec changes covers the unplanned migration work most teams face, and the operational costs often match or exceed self-hosted expenses for mid-market teams.

The token tax is another compatibility variable. Seven popular coding servers add roughly 41,000 tokens before the first prompt. If you’re building a cost-sensitive integration, that overhead determines whether MCP is viable or whether you should use direct REST calls for deterministic workflows and reserve MCP for agentic discovery, as covered in MCP vs GraphQL hybrid architectures.

When do you need an MCP gateway instead of a direct connection?

The protocol was designed to eliminate middleware, but enterprises now require gateways to manage identity, audit, and cost control. VDF.ai’s gateway comparison confirms that enterprises require MCP gateways for identity consolidation, tool allow-lists, and audit logs. That’s a recentralization the standard didn’t anticipate, and it’s where the governance vacuum becomes a budget line item.

A gateway sits in front of your MCP servers and decides which agent may call which tool, under whose identity, with what rate limit, and with what audit record. Without one, every MCP server handles its own authentication, and your security team has no single pane of glass to revoke access or investigate anomalies. With one, you get OAuth consolidation, per-user identity propagation, and structured audit logs—but you also add latency, cost, and another vendor to manage.

The security reality is that MCP itself lacks identity propagation, tool budgeting, and structured errors. Those gaps fall to the server or the gateway behind it. That’s an extreme case, but it illustrates the pattern: the protocol is a standard, but production safety depends on the implementation layer you build or buy around it, as detailed in the PostgreSQL MCP server security check.

Choose a gateway when you have more than five servers, more than twenty users, or any regulatory requirement for audit trails. Skip it for solo development, proof-of-concept work, or environments where the agents only read public data. The decision usually comes down to whether you need to answer “who did what, when” after an incident. If you do, the gateway is non-negotiable.

How do you build your own compatibility matrix?

Start with your actual stack, not the vendor’s marketing page. List every system your agents need to touch, then check three things for each: does the vendor publish an MCP server, which plan includes it, and which clients support the features you need? The first question has a binary answer. The second requires reading pricing docs—or finding silence, which is its own answer. The third means testing against Claude Desktop, Cursor, and VS Code if you have users on all three.

The tradeoff framework is straightforward. Protocol simplicity favors direct connections and minimal servers; enterprise readiness favors gateways, allow-lists, and audit logs. Open access favors vendors who include MCP on every plan; vendor control favors those who gate it behind enterprise tiers. Client portability favors servers built on tools/list and tools/call only; feature depth favors servers that use resources, prompts, and sampling—but only if your client supports them.

The 12 gateways currently selling “MCP governance” will consolidate to 3–4 within 18 months. The surviving vendors will be those who treat the gateway not as a proxy but as an identity and policy boundary. The current race to the bottom on allow-lists and rate limits will differentiate on structured errors and audit semantics instead. Choose your gateway today with that consolidation in mind—pick the one whose data model matches your audit requirements, because switching costs will be high once you’re logging production agent traffic.

The safe assumption is that MCP is not included with your seat. Verify before you budget, test against every client you support, and build the gateway layer before you need it for compliance. The protocol is still young enough that early architectural decisions lock you in for years.