When Not to Use an MCP.

MCP (Model Context Protocol) is an open standard that solves the N×M integration problem — the combinatorial explosion that happens when M AI models each need custom connectors to N external tools. Before MCP existed, connecting three AI models to ten tools required up to thirty custom integrations; MCP standardizes the interface so any compliant model can call any compliant server without custom work. The official description is "like a USB-C port for AI applications" — a single standardized connector that replaces a sprawl of proprietary cables. The current stable specification (2025-11-25) is built on JSON-RPC 2.0, defines three roles (Hosts, Clients, Servers), and is supported across Claude, ChatGPT, Visual Studio Code, and Cursor. The question to ask before adopting MCP is not "what is it" but "do I have an N×M problem worth solving at the protocol layer" — if you have one model and one tool, you don't.

MCP is the standardized language that lets an AI model ask an external tool to do something — and get a structured answer back — without either side needing to know how the other was built. Think of it as a universal remote control for AI agents: instead of each AI building its own custom remote for each device it wants to control, MCP gives every device a standard input jack and every remote a standard output plug. In practice, an MCP server exposes a list of "tools" (callable functions) with descriptions the AI model reads. The model decides which tool to call and passes structured arguments; the server executes the operation and returns a result. What makes this worth a protocol is that the model doesn't need to be rewritten when the tool changes, and the tool doesn't need to be rewritten when a new AI model is added. A practitioner who has shipped MCP integrations will tell you the simplification is real at scale — and essentially invisible for single-tool, single-model use cases.

MCP solves two structural problems that emerge when AI systems grow beyond a single model connected to a single tool: the N×M connector problem and the capability-discovery problem. The N×M connector problem is architectural: without a standard, every new AI model requires custom integration code for every tool it needs to call — the cost scales multiplicatively, not additively. The capability-discovery problem is subtler: before MCP, a model had to know at design time exactly what an external tool could do; with MCP, the server advertises its capabilities dynamically at session start, so the model can adapt to whatever tools are available. Both problems are irrelevant when you have one model and one tool with a stable interface — which is why "what problems does MCP solve" is also the correct frame for "when not to use MCP." If neither problem applies to your current system, the protocol layer adds overhead without payoff.

MCP manages the full lifecycle of a tool-calling session between an AI model and an external server: capability negotiation at connection, tool invocation during the session, and structured result delivery back to the model. The stateful session is MCP's defining feature — unlike a REST API call where each request is independent, an MCP session maintains context across multiple tool calls, so the model can use the output of one tool as the input to the next without the orchestration living inside the model itself. In concrete terms: when a Claude instance connects to an MCP server, the server first sends a list of available tools with descriptions. Claude reads those descriptions, decides which tool to call, sends a structured JSON-RPC request, and receives a structured result. The session stays open so Claude can call additional tools without re-authenticating or re-negotiating capabilities. For single-tool, single-call integrations, this session overhead is pure cost.

MCP is a protocol — not a tool, not a framework, and not a library. A protocol defines the rules for how two parties communicate; it does not prescribe how either party is implemented, which is what makes MCP portable across AI models and tool servers built in different languages and architectures. The practical consequence is that calling MCP a "framework" is a category error that leads to wrong architectural expectations: frameworks come with opinions about structure, abstractions, and project layout. MCP has none of those — it defines message formats, session lifecycle, and capability negotiation only. If you need a framework to build MCP clients or servers, you use an SDK (Anthropic provides SDKs for Python and TypeScript); the SDK is the framework layer on top of the protocol. The distinction matters when evaluating adoption cost: you're not adopting a framework with its opinionated structure, you're implementing a protocol that can live inside whatever structure you already have.

An LLM (Large Language Model) is the AI system that reasons and generates text; MCP is the protocol that tells the LLM how to interact with external tools. The relationship is one-directional: LLMs use MCP — MCP does not use or require an LLM. An LLM without MCP can only work with information it was trained on and whatever appears in its context window. An LLM with MCP can call external servers to retrieve current data, execute code, query databases, and take actions in other systems — then incorporate those results into its reasoning. MCP adds the tool-use capability; the LLM supplies the reasoning about when and how to use those tools. The confusion between MCP and LLM typically indicates someone comparing a capability (tool-calling) with the system exercising that capability (the model) — the correct comparison is MCP vs. function calling (another tool-use mechanism built into model APIs), not MCP vs. LLM.

MCP is relevant in 2026 and its durability signal is stronger than at any prior point — but the relevance is conditional on use case in a way no competitor article acknowledges. The strongest durability signal is cross-vendor adoption: ChatGPT, Microsoft Copilot, and Apple Intelligence have all shipped MCP support, meaning no single company can deprecate or replace the protocol unilaterally without breaking their own integrations. The 2026 MCP roadmap confirms active governance investment — transport scalability, enterprise readiness, and a governance working group are all in-flight. What no competitor article acknowledges is that relevance and fitness-for-your-use-case are orthogonal: MCP can be a durable protocol standard and still be the wrong choice for a specific latency-sensitive or single-tool integration. The practitioner question is not "is MCP relevant" but "is the problem MCP solves the problem I have" — and the ecosystem signal helps answer the first; the architecture of your integration answers the second.

MCP is not deprecated — the current stable specification is 2025-11-25 and a 2026-07-28 release candidate has been published with significant transport and extensibility improvements. A protocol with an active release candidate, multi-vendor adoption across competing platforms, and an official 2026 governance roadmap is the opposite of deprecated. The question surfaces in search because MCP's early adoption phase produced a large number of low-quality MCP servers that have been abandoned — which creates confusion between "MCP servers being deprecated" and "MCP the protocol being deprecated." Individual MCP servers deprecate; the protocol has not. The 2026 roadmap explicitly lists "governance maturation" as a priority, including a contributor ladder and working groups — infrastructure you only invest in for a protocol you intend to be running for years.

The defection signal in the PAA surface is real, but it is use-case-specific rather than a wholesale ecosystem move. Practitioners are moving away from MCP for specific workloads — particularly latency-sensitive single-tool integrations — because the protocol overhead (tens to hundreds of milliseconds per invocation) is architectural and cannot be tuned away, making direct REST calls or native function calling the correct choice for those scenarios. A second, smaller defection is organizational: teams that adopted MCP early for simple automation use cases discovered that a shell script or cron job does the same work with zero protocol overhead. What the PAA questions signal is not that MCP is failing but that a correction is underway — the early hype surface over-applied MCP to integrations that never needed a protocol layer. The result is practitioners who correctly concluded MCP was wrong for their use case, but incorrectly generalized that conclusion into "MCP is wrong."

The industry is not moving away from MCP — the industry is stratifying MCP adoption by use case, which looks like defection from the outside. The stronger indicator of industry trajectory is that Google's A2A protocol, the most credible competitor to MCP's ecosystem coordination role, is positioned as complementary rather than competing: A2A handles agent-to-agent coordination while MCP handles agent-to-tool connections. Apple Intelligence, Microsoft Copilot, and ChatGPT are all shipping MCP support in 2026 — the set of vendors who would benefit most from a competitor to MCP being viable are the vendors most committed to it. The search question "is the industry moving away from MCP" is itself a signal: it reflects practitioners who have seen real-world MCP failures (security incidents, performance overloads) and are trying to determine whether those are early-adoption edge cases or signs of structural protocol weakness. They are edge cases.

Nothing has replaced MCP as the dominant agent-to-tool protocol standard as of 2026 — the closest alternative is native function calling within single-provider ecosystems, but that solves a narrower problem than MCP addresses. Google's A2A (Agent-to-Agent protocol) is the most commonly cited replacement candidate, but it operates at a different layer: A2A coordinates between AI agents, MCP connects agents to tools — a system can and does use both simultaneously. Direct REST API calls are a legitimate alternative when portability and multi-tool orchestration are not requirements — but REST does not replace MCP at the protocol layer, it replaces the use cases where MCP was never the right choice. The practical state in 2026: MCP owns agent-to-tool protocol, A2A owns agent-to-agent coordination, and native function calling owns single-provider single-tool integrations. Three layers, three tools — none replacing the others.

Anthropic has not abandoned MCP — Anthropic transferred MCP governance to an independent multi-vendor body specifically to prevent it from being an Anthropic-controlled protocol that competitors would be reluctant to adopt. The governance transfer is the strongest evidence of long-term commitment: Anthropic gave up unilateral control of the specification precisely to make it a durable industry standard rather than a proprietary Anthropic tool. The 2026 roadmap lists enterprise readiness, transport evolution, and governance maturation as the four active priorities — all of which require continued investment, not abandonment. Claude Desktop remains the reference MCP client implementation and Claude Code ships with built-in MCP client support. The "did Anthropic abandon MCP" question in the PAA surface reflects early-stage ecosystem anxiety, not observable evidence.

MCP is not out of date — the 2025-11-25 stable specification is the current standard, and a 2026-07-28 release candidate introduces stateless protocol core and an official extensions framework that addresses the scalability limitations practitioners have identified as MCP's most significant architectural constraint. The 2026-07-28 release candidate's stateless protocol core — eliminating session headers so any MCP request can land on any server instance — directly resolves the sticky-routing problem that makes MCP difficult to scale horizontally, which is the primary architectural criticism of the protocol in production deployments. A protocol with an active release candidate in flight is current by definition. What is out of date are many of the MCP tutorials and server implementations published in 2024 and early 2025, before the 2025-11-25 stable spec — the protocol has evolved and most existing guides have not.

MCP is not outdated as a protocol, but specific MCP implementations and architectural patterns from 2024 are legitimately obsolete. The stateful session model in the 2025-11-25 spec — which requires sticky routing for horizontal scaling — is being replaced in the 2026-07-28 release candidate by a stateless protocol core that any load balancer can route without coordination. Production teams that built MCP infrastructure against the 2024 draft spec and are running into horizontal scaling constraints are experiencing real architectural debt, not protocol obsolescence. The correct frame: the underlying standard is evolving to fix known weaknesses; the teams whose infrastructure is "outdated" are those who built against pre-stable versions and have not migrated. The release candidate's ten-week Tier 1 SDK window means that SDK-based implementations will be straightforward to update; custom protocol implementations will require more deliberate migration work.

A2A (Google's Agent-to-Agent protocol) is not dead — it is active and positioned as complementary to MCP, not competing with it. A2A handles coordination between AI agents (one agent dispatching tasks to another); MCP handles agent-to-tool connections (an agent calling a file system, database, or web API) — a well-architected multi-agent system uses both protocols simultaneously, with A2A orchestrating at the agent layer and MCP connecting each agent to its tools. The "is A2A dead" question in the PAA surface reflects the same protocol-survival anxiety as the MCP trajectory questions — practitioners are trying to determine which protocol bets are safe. The practical answer is that A2A and MCP are not competing for the same layer, so the question of which one "wins" is a category error. The correct question is whether your system has agent-to-agent coordination needs (A2A) and agent-to-tool needs (MCP) — most agentic systems have both.

MCP uses OAuth 2.1, but only for remote server deployments — local stdio transports require no OAuth at all. The critical clarification that no competitor article makes is that MCP mandates Authorization Code flow with PKCE, not the simpler client credentials flow that many backend developers default to when implementing OAuth for service-to-service communication. The distinction matters because client credentials (service account tokens) are easier to implement and widely used for API authentication, but MCP's security model requires the delegated-authorization pattern that Authorization Code + PKCE provides. Teams building MCP servers for the first time who reach for client credentials because they're familiar with it from other service-to-service auth implementations will find their implementation non-compliant. Budget the Authorization Code + PKCE implementation time explicitly — it is not optional for remote deployments.

MCP requires OAuth 2.1 only for remote server deployments — the stdio transport used for local (same-machine) integrations has no OAuth requirement. This transport-conditional auth requirement is the single most important implementation detail for any team evaluating MCP adoption cost: if your use case is a local MCP server running on the same machine as the client, OAuth is not in scope; if your use case is a remote server that any compliant client connects to over the network, OAuth 2.1 with Authorization Code + PKCE is mandatory, not optional. The practical implication: a solo developer building an MCP server for personal use with Claude Desktop faces zero auth overhead. An engineering team building a shared MCP server for multi-user remote access faces a full OAuth 2.1 implementation — dynamic client registration, PKCE, token storage, refresh flows, and the security hardening that the postmark-mcp breach demonstrated is necessary even for internal tools.

MCP's remote transport requires OAuth 2.1 — it does not support API key authentication, JWT bearer tokens issued by internal services, or session cookie authentication at the protocol level. Local stdio transports bypass the auth layer entirely, so "MCP only supports OAuth" is accurate for remote deployments and irrelevant for local ones — but teams who discover this constraint after committing to a remote deployment architecture will find there is no protocol-compliant workaround. Some MCP server implementations add custom API key handling at the application layer on top of the protocol, but this is a non-standard extension, not a supported alternative. The MCP 2026 roadmap identifies SSO integration as an "enterprise readiness" priority that is currently the "least defined" — meaning enterprise-grade auth patterns beyond basic OAuth 2.1 are still unresolved at the specification level. For teams whose auth infrastructure is built around SAML, LDAP, or internal JWT issuers, the current MCP auth model requires a dedicated translation layer.

MCP supports multiple transports — HTTP (with Server-Sent Events for streaming), stdio, and WebSockets — and is not exclusively HTTP-based. The stdio transport runs over standard input/output streams with no network layer, making it suitable for local integrations where HTTP would add unnecessary complexity; the HTTP + SSE transport is the standard for remote deployments. The current stable specification (2025-11-25) defines Streamable HTTP as the remote transport, but the 2026 roadmap identifies "transport evolution and scalability" as a top priority because Streamable HTTP has documented production challenges with horizontal scaling. The 2026-07-28 release candidate addresses this by introducing a stateless protocol core that removes the sticky-routing constraint that makes Streamable HTTP difficult to scale across multiple server instances.

MCP requires HTTPS for all remote server deployments — HTTP is only valid for stdio local transports where no network layer is involved. The requirement is not optional: a remote MCP server operating over plain HTTP exposes all tool descriptions, tool arguments, and tool results in plaintext — and because tool descriptions are processed as instructions by the AI model, plaintext transmission of tool descriptions is a prompt injection surface that attackers can exploit at the network layer. The practical consequence: any MCP remote server that accepts HTTP connections without TLS should be treated as misconfigured by default, not as a valid "internal-only" deployment. Internal networks are not a substitute for transport encryption when the payloads include AI model instructions. HTTPS enforcement is deployment infrastructure, not application code — but it is the first verification any MCP deployment should make before exposing a server to any client other than localhost.

MCP is built on JSON-RPC 2.0 — a protocol for remote procedure calls encoded as JSON messages — but the JSON encoding is a transport detail, not what MCP is. What distinguishes MCP from "just a JSON API" is the stateful session lifecycle and capability negotiation: a JSON API call is stateless (each request is independent); an MCP session is stateful (the server advertises capabilities at connect time, and both parties maintain session state across multiple tool invocations). The confusion is understandable because an MCP message looks like a JSON API payload — it has a method, params, and result field. The difference is in what those fields encode: not CRUD operations on resources, but tool invocations within a capability-negotiated session. Practitioners who have built REST APIs find MCP's JSON encoding familiar; the session model is what requires the conceptual adjustment. If the session model isn't providing value for your use case, you likely don't need MCP.

Use MCP over a direct API when two conditions are true simultaneously: your agent needs to orchestrate multiple distinct tools within a single session, and portability across AI models matters. The decision flips to direct API the moment either condition drops: a single-tool integration has no session state to manage across calls, so MCP's stateful session is overhead without benefit; a locked single-provider deployment has no portability requirement, so MCP's cross-model compatibility is irrelevant. The latency constraint is the third variable: MCP adds tens to hundreds of milliseconds per invocation at the protocol layer — this overhead is architectural and cannot be mitigated by simplifying the MCP server implementation. If your integration must complete in under 200ms end-to-end, that overhead may consume your entire latency budget before the tool does any work. The correct three-question test: Does the agent need multiple tools in one session? Does the integration need to survive a model change? Can the use case tolerate MCP's protocol overhead? All three "yes" answers justify MCP; any single "no" answer warrants a direct REST call.

Use MCP instead of direct HTTP when your agent needs capability negotiation — discovering at runtime what an external system can do rather than hardcoding the API surface at design time. Dynamic capability discovery is MCP's primary architectural advantage over direct HTTP: an MCP server tells the client what tools it has; a REST API requires the client to know the endpoint structure before the first call. For integrations where the tool set is stable and known at design time, this advantage vanishes — and direct HTTP is simpler to implement, easier to debug, lower latency, and requires no protocol-layer auth overhead. The honest comparison: MCP earns its complexity overhead when you are building a system where the set of available tools may change without redeploying the client, or where the same client code must run against multiple different MCP servers. For everything else, a typed REST client with an OpenAPI spec gets you there faster with fewer moving parts.

MCP cannot replace REST APIs — they solve different problems at different layers of the stack, and the scenarios where MCP is the right choice are a subset of what REST handles, not a superset. REST is a stateless request-response architecture for accessing and manipulating resources; MCP is a stateful session protocol for AI agents to discover and invoke external capabilities — the two solve adjacent, not identical, problems. Most MCP servers are built on top of REST APIs: the MCP server wraps an existing REST endpoint, translates the AI model's structured tool call into an HTTP request, and returns the response. Replacing REST with MCP would be replacing the underlying API with the wrapper — the opposite of the correct architecture. The practical frame: REST is how systems talk to each other; MCP is how AI agents talk to systems. Both layers persist in a well-architected agentic system.

MCP is slower than a direct API call for the same operation — the protocol overhead adds tens to hundreds of milliseconds per invocation, and this is architectural, not a tuning problem. The latency penalty comes from three sources that cannot be optimized away: the capability negotiation handshake at session start, the JSON-RPC message serialization and deserialization on each tool call, and the transport layer overhead of the SSE or HTTP streaming connection. A direct REST API call bypasses all three overhead sources. The correct question is not "is MCP faster" but "does MCP's value — stateful sessions, capability negotiation, cross-model portability — justify the latency overhead for my use case." For batch processing, multi-step orchestration with long-running tools, and integrations where tool results feed into subsequent tool calls, the session value justifies the latency cost. For a single deterministic lookup that must complete in under 150ms, direct REST is the only viable choice.

MCP will not replace APIs — it will add a protocol layer on top of APIs for agentic use cases, in the same way HTTP did not replace TCP but became the dominant application-layer protocol for web traffic. The analogy to HTTP is instructive: HTTP standardized how clients and servers communicate over the web without replacing the underlying TCP infrastructure; MCP standardizes how AI agents communicate with tool servers without replacing the underlying REST APIs those servers expose. The realistic 2026 scenario: most services will continue to expose REST APIs as their primary integration surface; a growing subset will additionally expose MCP servers for agentic clients that need dynamic tool discovery and stateful sessions. Both surfaces coexist in the same infrastructure. The practitioners who will be caught out are those treating "API" and "MCP server" as mutually exclusive choices rather than as different interfaces to the same underlying capabilities.

MCP is not the new HTTP — it is more accurately the new Language Server Protocol: a specialized standard for a specific client-server relationship (AI agent to tool server) that solves the N×M connector problem for one class of software interaction. HTTP is a general-purpose application-layer protocol used by virtually every networked application; MCP is purpose-built for agentic AI tool-calling, a narrower use case that shares HTTP as its transport but is not a replacement for it. The "MCP is the new HTTP" framing (cited by some practitioners) is a claim about trajectory and ubiquity, not architecture. For that claim to be true, MCP would need to become as universal as HTTP — meaning every networked service exposes an MCP interface alongside its HTTP interface. The 2026 roadmap suggests this is aspirational rather than imminent, and it is not a reason to adopt MCP for integrations where the HTTP layer is already sufficient.

MCP and Zapier solve similar problems — connecting applications — but at fundamentally different layers: Zapier connects applications through predefined human-authored automation flows; MCP connects AI agents to tool servers so the agent can decide at runtime what to call and in what sequence. The defining difference is autonomy: a Zapier workflow is static — a human defined "when X happens, do Y"; an MCP integration is dynamic — the AI model reads available tools and decides what to call based on its reasoning about the current task. For teams currently using Zapier for deterministic automations, the decision calculus is straightforward: if the automation logic is well-defined and human-designed, Zapier or a direct API integration is simpler and cheaper to operate. MCP becomes relevant when you need the AI model to be the decision-maker about which tools to invoke — not when you need to connect two services and have already decided what should happen.

MCP is a protocol; Copilot (Microsoft) is an AI assistant product that has adopted MCP as one of its tool-calling mechanisms. The distinction matters because "switching from MCP to Copilot" is a category error — Microsoft Copilot uses MCP to connect to external tools, so Copilot and MCP are complementary, not competing choices. The relevant comparison for practitioners is between MCP (the open protocol) and Copilot's native function calling (Microsoft's proprietary tool-calling mechanism within their AI ecosystem). Native Copilot function calling is simpler to implement for Microsoft 365 integrations and carries no MCP protocol overhead — but it is locked to Copilot and does not port to Claude, ChatGPT, or other AI models. MCP-wrapped tools used by Copilot can also be used by any other MCP-compliant client. For organizations already standardized on Microsoft 365 and committed to Copilot, native function calling is the faster path; for organizations wanting to hedge across AI providers, MCP is the portability layer.

Skip MCP when any one of three conditions is true: your agent needs a single deterministic call to one endpoint; your integration is locked to one AI provider with no planned model migration; or your use case cannot tolerate tens to hundreds of milliseconds of added per-invocation latency. The conditions are independent — any single one is sufficient to disqualify MCP, because each one removes the specific value MCP provides: multi-tool session management, cross-model portability, and acceptable latency overhead respectively. The postmark-mcp breach illustrates the fourth disqualifying condition: an MCP integration where tool descriptions are sourced from untrusted external inputs without sanitization. Tool descriptions are processed as instructions by the AI model — an attacker who controls a tool description controls the model's behavior within that session. The correct frame is not "MCP is too complex" but "MCP adds overhead to a problem I don't have" — the complexity is justifiable when the problem is real, unjustifiable when it is not.

The three verified production pitfalls of MCP are latency accumulation, auth under-implementation, and tool description injection — and all three share the same root cause: adopting MCP before understanding which parts of its architecture are the cost you pay and which are the value you receive. Latency accumulation is the most common: MCP's per-invocation overhead compounds across multi-tool sessions — a five-tool session with 100ms overhead per call adds 500ms of protocol latency before any tool does substantive work, which is unacceptable in user-facing interactions. Auth under-implementation is the most dangerous: the postmark-mcp breach demonstrated that an MCP server with incomplete OAuth hardening can be silently hijacked — in that case, malicious BCC instructions were injected via tool descriptions, turning a legitimate email server into an exfiltration channel. Tool description injection is the most architecturally novel: because tool descriptions are processed as model instructions, any untrusted input that reaches a tool description field is a prompt injection vector, not a data sanitization problem.

Use MCP when multi-tool orchestration, cross-model portability, and tolerable latency all align; skip MCP when any one of those conditions is absent. The decision is binary for each condition: MCP's stateful session adds no value without multiple tools; MCP's cross-model portability is irrelevant if you are locked to one provider; and MCP's latency overhead is architecturally non-negotiable — there is no MCP implementation that avoids it for latency-sensitive use cases. The practical test: if your integration can be described as "call this one endpoint with these arguments and return the result," MCP is the wrong choice regardless of how many MCP servers exist in the ecosystem. If your integration requires the AI model to discover what tools are available, call multiple tools in sequence, and adapt its plan based on intermediate results — that is the use case MCP was built for. SuperAGI's production overload incidents confirm that high-frequency MCP orchestration requires deliberate capacity planning; the protocol overhead is not free at scale.

MCP is inefficient for use cases where its architecture provides no benefit — the inefficiency is not a defect in the protocol but a mismatch between the problem MCP solves and the problem being applied to it. The specific source of inefficiency is the stateful session model: establishing a session, negotiating capabilities, maintaining connection state, and handling JSON-RPC message framing all add overhead that a stateless direct REST call does not incur — and that overhead delivers no value when the integration is a single deterministic call that does not need session state or capability negotiation. The 2026-07-28 release candidate's stateless protocol core addresses one dimension of this inefficiency — removing session headers so any server instance can handle any request — but does not eliminate the per-invocation JSON-RPC overhead. The practitioner frame: measure actual per-invocation latency in your environment before standardizing on MCP; the "tens to hundreds of milliseconds" figure is a reported range, and your actual overhead depends on transport, server implementation, and network topology.

The three strongest reasons not to use MCP are: the integration does not require a stateful multi-tool session; the auth implementation complexity is unjustified for the use case; and the team has not audited tool description inputs for injection risk. The auth implementation reason is particularly underweighted in current discourse: implementing OAuth 2.1 with Authorization Code + PKCE correctly — including token storage, refresh flows, and the security hardening that prevents the postmark-mcp breach pattern — requires deliberate engineering investment that is not in scope for a simple tool integration. Teams that underestimate this and ship MCP servers with incomplete auth hardening produce a worse security posture than a well-implemented direct API with a static token, because MCP's tool description attack surface is novel and not covered by standard web application security checklists. The correct question before adopting MCP is not "can we make this work" but "does the value of stateful multi-tool orchestration and cross-model portability justify the implementation overhead of correct OAuth 2.1 and tool description sanitization."

Use MCP when three architectural conditions align: the agent needs to orchestrate multiple distinct tools within a single session, the integration must remain portable across AI models or providers, and per-invocation latency of tens to hundreds of milliseconds is acceptable for the use case. The highest-value MCP use case in 2026 is a multi-model agentic system where different AI models handle different sub-tasks and each needs access to a shared set of tools — MCP's cross-model portability means the tool servers are written once and callable by Claude, ChatGPT, and Copilot without rewriting integration code for each provider. A secondary strong signal is development tooling: AI-assisted coding assistants that need access to file systems, terminals, databases, and documentation simultaneously are the use case that MCP's stateful session and capability negotiation were designed for. Claude Desktop and Cursor's MCP adoption are leading indicators of the use case MCP wins — not generic automation, but agentic development environments where tool orchestration complexity is genuinely high.

The architectural disadvantages of MCP (the Model Context Protocol, not MPC the economic term) are four: latency overhead, auth implementation cost, horizontal scaling constraints, and the tool description injection attack surface. The most practically significant disadvantage for production systems is that MCP's current stable specification requires sticky routing for horizontal scaling — stateful sessions must land on the same server instance, which prevents standard load balancer behavior and requires session-aware routing infrastructure that teams building simple REST services have never needed before. The 2026-07-28 release candidate addresses this with a stateless protocol core, but that spec is a release candidate, not the stable version — teams building production systems on the current stable spec (2025-11-25) must design for sticky routing now and plan for migration when the new spec stabilizes. The tool description injection attack surface is the least-understood disadvantage: because AI models process tool descriptions as instructions, any input path that reaches tool description fields is a security boundary requiring the same sanitization discipline as SQL injection or XSS attack surfaces.