When Not to Use an MCP.

MCP (Model Context Protocol) is an open-source standard — created by Anthropic and now governed as an open protocol — that lets AI applications connect to external data sources, tools, and services through a single standardized interface. The official analogy is "USB-C for AI apps": one protocol, many compatible systems, no bespoke glue code per integration. The current stable specification (2025-11-25) defines three architectural roles: Hosts (LLM applications like Claude Desktop), Clients (connectors embedded in hosts), and Servers (services exposing data or capabilities). The MCP layer handles capability negotiation and session lifecycle, freeing the host model from needing to know how each tool works internally. What practitioners learn after shipping their first MCP integration: the USB-C analogy is accurate in one underappreciated direction — USB-C carries power, data, and video over the same cable, which is exactly why you don't use it when all you need is audio.

MCP is the protocol that lets an AI model talk to external tools without bespoke integration code for each one. Where REST APIs require a custom client for every service, MCP defines a single "shape" that any compatible server exposes — so the AI host learns one interface instead of many. In practice: you configure MCP servers in a JSON file, restart your client (e.g. Claude Desktop), and the host discovers their capabilities automatically. That automatic discovery is what separates MCP from a standard API call — and it's also the source of the overhead. Practitioners who've used both know the "simple" version is accurate up to the moment you hit latency-sensitive paths or multi-tenant auth, at which point the simplicity inverts.

MCP solves three integration problems: the N×M tool-integration matrix (N AI apps × M data sources each needing custom code), the lack of dynamic tool discovery (static function lists can't adapt as tool capabilities change), and the absence of a standard for bidirectional, stateful communication between an AI host and external services. The core win is that a model can discover what an MCP server can do at runtime, rather than having every capability pre-enumerated at build time. Those three problems are real — but they are only problems if your workload actually has them. If your AI application talks to one or two well-defined APIs with stable schemas, MCP's N×M solver is solving a problem you don't have. The integration overhead is the price of a dynamic capability you're not using.

MCP is a protocol specification, not a framework — the distinction matters because it shapes what you're actually adopting. A framework gives you a runtime and constrains your architecture; a protocol defines message format and session semantics, leaving implementation to SDK authors. The stable spec (2025-11-25) defines JSON-RPC 2.0 message format, stateful connection lifecycle, and capability negotiation — not how you build servers or host applications. SDK implementations exist in multiple languages (TypeScript, Python, Go), each making different tradeoffs. In practice, teams adopting MCP are adopting a specific SDK's opinionated implementation of the protocol, not a clean protocol primitive — which means "MCP overhead" includes both the protocol's inherent cost and the SDK author's choices.

MCP is not basically an API — it is a session protocol layered on top of transport mechanisms (stdio, Streamable HTTP), and the difference is the source of most "when not to use it" decisions. REST APIs are stateless request-response; MCP connections are stateful sessions with capability negotiation, bidirectional messaging, and lifecycle events. A REST API call completes independently of any prior call. An MCP session maintains state across calls — which is necessary for multi-step agent orchestration but adds session management, connection lifecycle, and sticky-routing overhead to every deployment. If your use case is "call a tool, get a result, done," you are using a stateful session protocol to do a stateless job. The analogy: it's not that MCP is complex, it's that you're carrying session weight you're not spending.

An MCP server is not just an API — it is a capability-exposing service that speaks the MCP protocol, which means it handles session establishment, capability advertisement, and bidirectional JSON-RPC messaging rather than simple HTTP request-response. The structural difference: an API endpoint responds to requests it was built to answer; an MCP server tells the client what it can do at runtime, and the client decides which capabilities to invoke. That runtime discovery is what makes MCP useful for dynamic multi-agent orchestration — and what makes it expensive for simple integrations where the capabilities are fixed and known at build time. A practitioner who has wrapped an existing REST API in an MCP server quickly discovers they've added a session layer to a stateless service: all cost, no benefit from the stateful model.

Skip MCP when any of three architectural conditions apply: your path is latency-sensitive and tool invocation overhead is on the critical path; your tool set is static and known at build time, making dynamic discovery pointless; or your deployment is single-provider (one LLM vendor, one tool surface) where native function calling outperforms a cross-protocol layer. These are not complexity signals — a sophisticated, high-volume workload can still be the wrong fit for MCP if it is latency-sensitive or single-provider. The trap practitioners fall into: reading "when not to use MCP" as "when your use case is too simple." It isn't. It's when the capabilities MCP provides — dynamic discovery, stateful sessions, bidirectional communication — are not capabilities your architecture actually needs. If you're not using the feature, you're paying its cost as overhead.

Use MCP when your workload requires dynamic tool discovery across multiple providers, stateful session context that persists across tool calls, or interoperability across LLM clients (Claude, ChatGPT, Copilot) without bespoke glue per client. Skip it when your tool set is static, your path is latency-sensitive, or you're locked to a single LLM vendor where native function calling is simpler and faster. The decision boundary is: "Do I need the session layer, or am I building it because it's the default recommendation?" Most teams reaching for MCP in 2026 are doing so because it's prominent in the ecosystem — not because they've verified they need stateful multi-tool orchestration. The correct first question is not "how do I use MCP?" but "what does MCP give me that a well-designed REST client doesn't?"

The four production pitfalls are: session lifecycle management (connections require sticky routing or stateless-core upgrades; the 2026-07-28 RC introduces a stateless protocol core to address this but it is not yet stable), auth surface expansion (remote servers require OAuth 2.1, adding an authorization flow where a direct API token would have sufficed), latency overhead on the session handshake and capability negotiation, and ecosystem lock-in risk if MCP is not the protocol your target LLM clients standardize on. The pitfall most teams don't anticipate: the security surface of MCP is materially larger than a direct API call — the postmark-mcp incident, where a malicious server BCC'd outbound emails to an attacker-controlled address, is the canonical production example of what happens when tool trust is misconfigured. Each pitfall is solvable, but each requires active architectural work — they are not defaults you get for free.

MCP's inefficiency is a direct consequence of its session model: every tool invocation carries the overhead of JSON-RPC 2.0 framing, session state maintenance, and capability negotiation — costs that are invisible in low-frequency orchestration but accumulate in high-frequency or latency-sensitive paths. The session model is what makes MCP powerful for multi-step agent workflows, and it is also the irreducible source of the overhead. You cannot remove the session overhead without removing the stateful capability — the two are the same thing. Teams reporting MCP latency problems are typically running it on paths better served by a direct HTTP call: the tool is called once, the result is returned, and the session machinery added nothing but cost.

The right reason not to use MCP is not that it's too complex — it's that the capabilities it provides are capabilities you don't need. MCP earns its overhead when you need dynamic tool discovery, cross-client interoperability, or stateful multi-step orchestration; when you need none of those, you're financing a session protocol for a stateless job. The secondary reason: MCP's 2026 trajectory introduces a protocol-level inflection point. The 2026-07-28 RC introduces a stateless protocol core as a breaking change — existing deployments with sticky-routing assumptions need migration work. Betting on MCP today means inheriting that migration in 2026. Whether that's acceptable depends on your integration's 12-month horizon, not on how complex your current use case is.

MCP's structural disadvantages are: stateful session overhead on every transport layer (Streamable HTTP production challenges are explicitly acknowledged in the 2026 roadmap), auth complexity that exceeds direct API token patterns for remote deployments (OAuth 2.1 required, SSO described as "the least defined" enterprise readiness priority), latency on tool invocation that is architectural rather than configurational, and ecosystem dependency risk in a protocol that is still undergoing breaking changes. The disadvantage that receives the least attention: MCP's enterprise auth story is unfinished. The 2026 roadmap explicitly labels SSO and gateway behavior as "the least defined" of the four priorities. If your integration requires enterprise SSO today, MCP does not have a stable answer — you are building on a spec gap.

Use MCP when your capability needs to be available across multiple LLM clients — Claude, ChatGPT, Copilot — without per-client integration work; use skills (platform-native function definitions) when you're locked to a single client where the native calling convention is faster, simpler, and better documented. The practical rule: if your agent runs in one ecosystem, the ecosystem's native calling convention wins; if your agent needs to run in many, MCP's interoperability premium pays off. The calculation shifts in 2026 as Copilot, ChatGPT, and Apple Intelligence each develop parallel tool-calling surfaces — at that point, "skills" means something different on each platform, and MCP's single protocol begins to justify the overhead for multi-platform deployments.

MCP is unnecessary when your integration is static (fixed tools, known at build time), single-provider (one LLM, one tool surface), and latency-sensitive — three conditions that each individually make the session overhead costly and unjustified. The pattern where MCP is clearly unnecessary: a single Claude API call that invokes one well-defined tool, returns a result, and terminates — that is a function call, not a multi-step orchestration, and it doesn't need a session protocol. The trap: MCP is heavily featured in Anthropic's documentation, which creates a gravity toward it even for use cases where a direct API call is faster and more maintainable. Unnecessary MCP adoption is the most common source of the overhead complaints practitioners report — not MCP being poorly designed.

Use MCP over a direct API when three conditions hold simultaneously: the set of available tools needs to change at runtime without client redeployment, the integration must work across multiple LLM clients, and the latency overhead of session establishment is acceptable given your performance budget. If even one of those conditions doesn't hold, a direct API is almost always simpler and faster. The often-missed case where MCP wins clearly over direct API: agent pipelines where the host model needs to interrogate what a server can do before deciding what to call — the runtime discovery capability is the protocol's genuine competitive advantage over a static API client. Outside that scenario, the advantage narrows rapidly.

Use MCP when your workload has all three of the following: tools that change or expand over time (making dynamic discovery valuable), a need to share the integration across multiple LLM clients or teams (making interoperability worth the protocol overhead), and a performance budget that accommodates the session-layer latency. The simplest heuristic: if you're building for one client, one tool surface, and a static capability set, you don't need MCP — you need a well-designed function call. MCP's genuine use case is the integration-platform scenario: a team building data access, search, or workflow capabilities that multiple AI products should be able to use, where the cost of per-client integration exceeds the cost of MCP overhead. For most greenfield projects, that threshold isn't crossed until you have multiple LLM clients in production.

Teams moving away from MCP are not moving away because MCP is bad — they are moving to ecosystem-native alternatives because those alternatives require less infrastructure for their specific deployment. The primary defection paths: native function calling for single-vendor deployments (no session layer, no separate server infrastructure), direct HTTP tool APIs for latency-sensitive paths (no session overhead), and Google's A2A protocol for cross-agent orchestration scenarios. The signal in the PAA surface is not disillusionment — it's practitioners learning what MCP is actually optimized for after they've deployed it, then routing simpler workloads to simpler protocols. The practitioners who aren't moving away are those building multi-client, multi-tool, dynamic orchestration pipelines — the exact scenario MCP was designed for.

MCP is still relevant in 2026 — the current stable spec (2025-11-25) is active, Anthropic and the broader community are iterating, and a major release candidate (2026-07-28) is in process with breaking changes that address known production pain points. The nuanced answer: MCP is relevant, but it is not stable enough for teams to build on without reading the 2026 roadmap and the RC timeline. The stateless protocol core introduced in the 2026-07-28 RC is a breaking change for existing Streamable HTTP deployments that rely on sticky routing. If you're evaluating MCP today for a 12-month integration horizon, "is it relevant?" is the wrong question — "is the version I'm targeting still the spec my clients will support when I ship?" is the right one.

The 2025-11-25 spec is the current stable version — it is not out of date, but it is under active successor development. The 2026-07-28 RC introduces a stateless protocol core as a breaking change, meaning the session model that defines the current stable spec is being replaced before it has reached full ecosystem maturity. For teams using the stdio transport in local deployments, this is low-disruption. For teams using Streamable HTTP with sticky routing in production, the RC introduces a migration. "Out of date" isn't the right framing — "in active transition" is more accurate, and the implications depend entirely on your transport layer and deployment architecture.

Anthropic did not abandon MCP — they are the protocol's stewards and are actively developing the 2026 roadmap and the 2026-07-28 release candidate. What Anthropic has done is move MCP toward governance maturation: Working Groups, a contributor ladder, and a roadmap with explicitly deferred priorities (SSO, gateway behavior labeled "least defined"). The signal practitioners should read from the roadmap is not abandonment — it is that Anthropic is building MCP for the open-standard long game, which means governance processes will now slow certain decisions that previously moved fast. If your deployment depends on SSO or enterprise gateway behavior being fully specified, Anthropic's prioritization tells you clearly: that answer isn't coming from the core spec in 2026.

MCP is not deprecated. The 2025-11-25 stable spec is active, Tier 1 SDK support is current, and a release candidate for the next version (2026-07-28) is in development. The precise answer to "is MCP deprecated?" is no — but the honest answer is that no protocol this young, undergoing a breaking-change RC, should be treated as stable infrastructure for a 12-month integration horizon without actively tracking the spec transition. The deprecation question in the PAA surface reveals what practitioners actually need: not reassurance that MCP exists, but a framework for deciding whether the version they're targeting will be the version their ecosystem converges on. That's a different question, and it has a less clean answer.

The industry is not moving away from MCP — it is diversifying around it. ChatGPT supports MCP as a client; Visual Studio Code, Cursor, and Claude Desktop all ship MCP support; the 2026 roadmap reflects active investment. What the PAA surface actually shows is that practitioners are discovering that other protocols (A2A, native function calling, direct HTTP) serve specific scenarios better — and they're routing those scenarios accordingly, rather than treating MCP as universal. The "moving away" framing is a misread of the signal: it's not defection from MCP, it's portfolio rationalization. Teams that deployed MCP for everything are now using it for the subset of workloads it's actually optimized for.

Nothing has replaced MCP — but three alternative protocols serve scenarios where MCP is suboptimal: Google's Agent-to-Agent (A2A) protocol for cross-agent task delegation and orchestration; native function calling (in ChatGPT, Claude, Copilot, Gemini) for single-ecosystem deployments where the vendor's calling convention outperforms a cross-protocol layer; and direct HTTP tool APIs for latency-sensitive paths where the session overhead is unacceptable. These are not MCP replacements — they are defection paths for specific scenarios. A2A and MCP are increasingly being described as complementary: A2A for agent-to-agent communication, MCP for agent-to-tool communication. The practitioner who treats them as substitutes is solving the wrong architecture problem.

A2A is not dead — Google's Agent-to-Agent protocol is an active specification developed alongside MCP, not a competing replacement. A2A is designed for agent-to-agent communication (delegating tasks between autonomous agents), where MCP is designed for agent-to-tool communication (connecting an agent to a data source or service). The "A2A vs MCP" framing in the PAA surface reflects practitioners trying to choose between them, when the architecturally correct answer for complex multi-agent pipelines is often: use A2A for inter-agent delegation and MCP for each agent's tool connections. A2A's 2026 status is active development; it is not deprecated, not abandoned, and not a failed alternative — it is a complementary protocol that addresses the part of the agent orchestration problem MCP was not designed to solve.

Use MCP instead of direct HTTP when you need runtime capability discovery, a session context that spans multiple tool calls, or interoperability across LLM clients that all speak the MCP protocol. Use direct HTTP when none of those apply and latency on the critical path matters. The honest comparison: HTTP is stateless, universally supported, carries no session overhead, and integrates with any auth model without protocol-level changes — it is the right default for tool integrations that don't need MCP's stateful session model. The case for MCP over HTTP is not that it's simpler — it is that it solves a coordination problem (multiple agents, multiple tools, dynamic discovery) that direct HTTP requires bespoke code to solve. If you don't have that coordination problem, HTTP wins on simplicity, latency, and auth footprint.

MCP is not faster than a direct API call for individual tool invocations — the session layer, JSON-RPC framing, and capability negotiation add overhead that a direct API call does not carry. MCP's performance advantage is not per-call speed; it is reduction in total integration code across many tool types, which translates to developer velocity, not runtime latency. For high-frequency or latency-sensitive paths, a direct API consistently outperforms MCP on individual call latency. MCP closes the gap in scenarios where the alternative is maintaining bespoke integration clients for many different tools — the overhead of the protocol is lower than the overhead of the integration sprawl it replaces. Practitioners who report "MCP is slow" are typically measuring per-call latency against a direct API baseline — a comparison that correctly identifies MCP's cost but misses what MCP is trading that cost for.

Remote MCP servers use OAuth 2.1 as the standard authorization protocol — this is the specification's answer for authenticating connections from MCP clients to external servers. Local stdio-based MCP connections (e.g. Claude Desktop with local servers) do not require OAuth — the trust boundary is the local machine, and no network-level auth flow is needed. The OAuth requirement is transport-dependent: Streamable HTTP remote deployments require it; stdio local deployments do not. Teams moving from local to remote MCP deployment discover this boundary the hard way — the local config that worked with zero auth complexity suddenly requires a full OAuth 2.1 implementation for production remote deployment. Understanding the transport determines the auth surface, and most articles conflate them.

MCP requires OAuth only for remote HTTP server connections — local stdio connections have no network auth requirement. The practical threshold: if your MCP server runs on the user's machine and Claude Desktop connects via stdio, OAuth is not in scope; if your MCP server is hosted remotely and accepts connections from multiple clients, OAuth 2.1 is required by the spec and the 2026-07-28 RC includes "authorization hardening" as a key change. The enterprise readiness gap: the 2026 roadmap explicitly describes SSO and gateway behavior as "the least defined" of the four priorities, meaning the enterprise auth story is still being specified as of 2026. Teams with enterprise SSO requirements who deploy remote MCP servers today are building on an incomplete spec — that is the informed version of "avoid MCP when security is non-negotiable."

MCP does not mandate only OAuth — local stdio connections operate without network-level auth, and the Extensions Framework introduced in the 2026-07-28 RC allows implementations to negotiate auth approaches via reverse-DNS IDs. But for remote Streamable HTTP deployments, OAuth 2.1 is the current spec-defined standard, and alternative auth patterns (API keys, JWT-only flows) are not first-class in the protocol. The practical implication: if your organization requires a non-OAuth auth pattern for remote server connections (e.g. mTLS, API key, service account token), you are outside the spec's primary design surface and will be working against the grain of the protocol's auth assumptions. That is a valid deployment choice — but it requires explicit awareness, not just a "security is non-negotiable" heuristic.

OAuth and JWT are not alternatives — JWT is a token format; OAuth is an authorization framework that uses JWT as one of its token representations. The correct comparison is OAuth versus simpler token patterns (static API keys, session tokens): OAuth adds token lifecycle management, refresh flows, and delegated authorization scopes that static tokens don't provide, at the cost of implementation complexity. MCP's move toward OAuth 2.1 for remote server auth is a choice to inherit that complexity — client registration, authorization endpoints, refresh token handling — in exchange for the security model of delegated, revocable, scoped access. Teams that have managed OAuth in distributed systems find the overhead manageable. Teams that haven't managed it before discover MCP's security surface is not "API key plus HTTPS" — it's a full authorization infrastructure problem.

JWT (JSON Web Token) is a token format used to assert claims between parties; SSO (Single Sign-On) is an authentication pattern where one login session grants access to multiple services. In the MCP context, these are different layers of the same enterprise auth problem: JWT is how MCP remote servers can represent and verify access claims; SSO is the enterprise identity system that issues those claims — and the 2026 roadmap explicitly labels SSO integration as "the least defined" enterprise readiness priority. The operational implication: if your enterprise deployment requires SSO (employees authenticating to MCP-connected tools via corporate identity), you are dependent on a spec priority that Anthropic has acknowledged is unresolved for 2026. That is a concrete dependency gap, not an abstract security concern.

MCP supports both HTTP and HTTPS as transport options for Streamable HTTP deployments — the protocol does not enforce HTTPS at the spec level. In practice, any remote MCP server handling real data or tool calls should use HTTPS; the 2026-07-28 RC's "authorization hardening" changes make the HTTPS assumption more explicit in the security model. The stdio transport (used by Claude Desktop for local server connections) does not use HTTP at all — it communicates over standard input/output streams on the local machine. Teams discovering this distinction after deployment often find their threat model assumptions need updating: local stdio connections have a fundamentally different attack surface than remote HTTPS connections, and the auth requirements differ accordingly.

MCP can and should use HTTPS for remote Streamable HTTP deployments — there is nothing in the protocol that prevents it, and the 2026-07-28 RC's authorization hardening changes assume it. The spec gap is not whether MCP supports HTTPS — it's that MCP's enterprise security story (SSO, audit trails, gateway behavior) remains underspecified as of the current stable spec, meaning HTTPS alone does not give your deployment the enterprise auth posture competitors compare against when recommending against MCP for sensitive workloads. HTTPS secures the transport channel. It does not address OAuth client registration, token revocation, SSO integration, or the audit trail requirements that enterprise deployments require. MCP practitioners who conflate "HTTPS enabled" with "production-secure" have missed the auth surface that lives above the transport layer.

HTTPS is unambiguously safer than HTTP for any network-exposed MCP deployment — TLS encryption prevents in-transit interception of JSON-RPC messages and auth tokens. But in the MCP security threat model, transport encryption is not the primary risk surface: tool misconfiguration (the postmark-mcp breach vector), OAuth client trust model failures, and prompt injection via MCP tool outputs are the attack surfaces that HTTPS does not address. The practitioner framing: "Is my remote MCP server on HTTPS?" is a prerequisite check, not a security posture. The deeper question is whether your tool approval model, OAuth client registration, and output validation are configured correctly — because those are the surfaces where MCP's production security failures have actually occurred.

Use an MCP server when you need your AI agent to access external data, call external tools, or orchestrate multi-step workflows across multiple services — and when you want that access to work consistently across different LLM clients without per-client integration code. The specific case where MCP wins clearly: a team building a data access layer that Claude Desktop, ChatGPT, and a Cursor extension all need to use — one MCP server, three compatible clients, zero per-client integration work. The use case that does not justify an MCP server: a single Claude API integration that calls one well-defined tool, runs in one environment, and has stable capabilities. That is a function call. MCP Scraper practitioners using the PAA harvest tool to feed live SERP data to agents find MCP valuable precisely when the data sources change frequently — dynamic discovery earns its overhead when the tool surface is itself in motion.

MCP is hyped because it solves a real problem — the integration fragmentation that every AI developer hits when trying to connect models to external data — and because Anthropic shipped it with broad adoption momentum across Claude Desktop, VS Code, ChatGPT, and Cursor simultaneously. The honest version: MCP's hype is proportionate to the size of the problem it addresses, but the hype cycle has driven adoption into use cases where the protocol's overhead is not justified by the capability it provides. The downstream effect: "when not to use MCP" is a top PAA question because practitioners adopted MCP first and discovered its limitations second. The hype brought them to the protocol; the experience taught them where it fits. That sequence is the source of every "when not to use it" article in the SERP — including this one.

MCP is not going to replace APIs — it is a protocol that connects AI agents to APIs, not a substitute for them. The architectural relationship: MCP servers typically wrap existing REST APIs, exposing them through a standardized interface that AI clients can discover and call; the underlying REST API still exists and still serves non-AI consumers. The framing "MCP replaces APIs" is a category error: REST APIs define what a service can do; MCP defines how an AI agent discovers and calls what a service can do. The two layers serve different integration audiences and will coexist. What MCP may reduce over time is the need for bespoke AI-to-API client code — not the API itself, but the integration glue between the AI and the API.

An MCP server is a runtime-discoverable interface designed for AI agents; a REST API is a stateless endpoint designed for any HTTP client. The key difference: an API requires the client to know what endpoints exist at build time; an MCP server advertises its capabilities to the client at runtime, letting the AI agent adapt to what the server offers without redeployment. That runtime discovery is the entire value proposition — and the entire source of overhead. If the capabilities are fixed and known at build time, a direct API is simpler, faster, and requires less infrastructure. MCP earns its complexity when the tool surface is dynamic, multi-provider, or needs to be shared across LLM clients that can't all be updated simultaneously when capabilities change.

MCP is not the new HTTP — HTTP is MCP's transport layer for remote deployments, not a legacy protocol MCP replaces. The more accurate framing: MCP is to AI agent tool-calling what REST conventions were to web APIs — a set of patterns and constraints that standardize how a class of integration problem gets solved, without replacing the underlying network protocol. The "MCP is the new HTTP" claim, circulating in developer communities, overstates MCP's scope and understates HTTP's permanence. What MCP standardizes is the AI-to-tool connection layer — a meaningful abstraction for multi-agent, multi-tool orchestration. It does not touch routing, content negotiation, caching, load balancing, or any of the HTTP primitives that the rest of the web's infrastructure depends on. The 2026 roadmap explicitly states: "We are not adding more official transports this cycle."

Microsoft supports MCP in Visual Studio Code via the GitHub Copilot integration — VS Code is listed as a confirmed MCP-supporting client alongside Claude Desktop, Cursor, and MCPJam. This makes Microsoft's tooling a viable MCP client, meaning MCP servers built for Claude Desktop are reachable from VS Code's Copilot without additional integration work — a concrete example of the cross-client interoperability that justifies MCP's overhead. The practitioner implication for the "when not to use MCP" decision: if your target deployment includes VS Code Copilot users and Claude Desktop users, MCP's cross-client value is real and measurable. If your deployment is Claude-only, the Copilot compatibility has no current value and the overhead is pure cost.

Zapier's MCP integration is not governed by MCP's open-source specification — Zapier's pricing and MCP access tier are determined by Zapier's own product terms, not the protocol's open-source status. The broader point: MCP the protocol is open-source and free to implement; MCP the ecosystem includes commercial products (Zapier, Notion, and others) that expose MCP-compatible servers under their own pricing models. The distinction matters for the "when not to use MCP" decision: adopting MCP does not mean free access to all MCP-compatible services — it means your agent can speak the protocol, not that the services behind it are free. Practitioners who assume "open protocol = free ecosystem" discover commercial MCP servers apply standard SaaS pricing to the tools they expose. PAA data from MCP Scraper's harvest confirms Zapier MCP pricing is one of the top ecosystem questions practitioners are actively researching — check Zapier's current pricing page for authoritative terms.