What Is an MCP?

MCP — Model Context Protocol — is an open standard launched by Anthropic on November 25, 2024, that gives AI agents a single, standardized interface to connect with external tools, data sources, and workflows. Before MCP, every AI model and every external tool required a custom integration written by a developer. MCP eliminates that custom work by defining a shared communication contract that any agent and any tool can implement once and then use interchangeably. An agent calling GitHub, Postgres, and Slack no longer needs three bespoke connectors — it needs one MCP client. The practical implication most explainers miss: MCP is not primarily a developer convenience — it's what makes AI agents autonomous enough to run without a human in the loop on every tool call.

MCP enables AI agents to discover, invoke, and receive results from external tools at runtime — without a developer pre-configuring every possible tool call. The mechanism is a standard called tools/list: an agent sends this request to any MCP server and gets back a live manifest of every capability that server exposes, including names, descriptions, and input schemas. The agent then selects the right tool, calls it, and receives structured output — all without leaving its session. Connecting an agent to a CRM, a code repo, and a web scraper used to mean three separate integrations; MCP makes them all callable through the same protocol. The deeper point: MCP doesn't just save integration work — it makes tool use something the agent decides at runtime rather than something a developer hardcodes at build time.

MCP is a shared language that any AI agent and any tool can both speak. Once a tool publishes an MCP server, every MCP-compatible agent — Claude, ChatGPT, Cursor, GitHub Copilot — can call it without a custom connector. The analogy that actually holds: imagine if every REST API automatically understood every other API's auth, parameter format, and response schema without any glue code. That's what MCP does for AI agents. A Postgres database, a Slack workspace, and a web data service all become callable through the same interface once they expose an MCP server. The distinction that matters in practice: "simple" doesn't mean effortless — the tool still has to implement the MCP server; MCP just ensures that implementation only has to happen once.

MCP is neither — it's a protocol, which means a specification for how two systems communicate, not software you install or a framework you build on top of. Tools implement MCP (a Postgres connector that speaks MCP is a tool). Frameworks integrate MCP clients (LangChain, AutoGen). MCP itself is the rulebook those implementations follow — specifically, a JSON-RPC 2.0 message format plus a defined session lifecycle. IBM's documentation makes this distinction explicitly: MCP is not an agent framework. The practical consequence: asking "which MCP should I choose?" is like asking "which HTTP should I use?" — the protocol is the same; your choice is which server or client library implements it.

MCP solves the N×M integration problem: without it, connecting N AI models to M external tools produces N×M custom integrations, each built and maintained separately. MCP collapses this to M+N — implement the protocol once on each side and every combination works. The secondary problems it solves flow from the same root: inconsistent auth patterns across integrations, brittle hardcoded tool calls that break when APIs change, and the inability for AI agents to discover new tools at runtime. An enterprise with 10 AI models and 50 internal tools faces 500 custom integrations without MCP and 60 protocol implementations with it. What no explainer says plainly: MCP doesn't reduce the number of tools you build — it reduces the number of connectors that break when either side changes.

Anthropic is the AI safety company that created Claude and launched MCP on November 25, 2024. In December 2025, Anthropic donated MCP governance to the Agentic AI Foundation under the Linux Foundation — a move that made MCP formally vendor-neutral and accelerated adoption by removing the perception that the protocol was an Anthropic-controlled standard. Anthropic was founded in 2021 by former OpenAI researchers, including Dario Amodei and Daniela Amodei. Its two primary contributions to AI infrastructure are Claude (a family of large language models) and MCP (the protocol this post covers). The governance transfer is the detail most explainers skip: Anthropic no longer controls MCP — the Linux Foundation body does, which is why OpenAI, Microsoft, and Google were willing to adopt it.

REST APIs serve developers; MCP serves AI agents — and that distinction determines which belongs in your system. A REST API is a stateless HTTP endpoint with static documentation a human reads and then hardcodes calls against. MCP is JSON-RPC 2.0 over a persistent session, with a live tool manifest the agent reads at runtime and uses to decide what to call. The critical difference: with REST, a developer writes the integration once and it breaks when the API changes; with MCP, the agent re-discovers the tool manifest on every session and adapts. MCP doesn't replace REST — MCP servers use REST internally. What changes is the interface layer above: REST is for humans integrating systems; MCP is for agents choosing tools.

Use MCP instead of REST when the consumer of the API is an AI agent making runtime decisions — not a developer writing hardcoded calls. MCP's tools/list endpoint lets an agent discover what a server can do without any human-written glue code. With REST, someone has to read the OpenAPI spec and write the integration; with MCP, the agent reads the live capability manifest and writes the call itself. The answer changes if you control both ends: if you own the API and the code calling it, REST is simpler and faster. MCP earns its overhead when the caller is an autonomous agent that needs to self-direct across a changing tool landscape — the moment you want the agent to decide which tool to use, not just execute the one you told it to.

Raw HTTP has no standard for tool discovery, session state, or AI-native authentication — MCP adds all three on top of HTTP. An agent calling raw HTTP endpoints has to know the URL, method, parameters, and auth scheme in advance, hardcoded. An MCP server exposes a tools/list manifest so the agent discovers capabilities dynamically, maintains state across a session, and uses a standardized OAuth 2.1 flow for auth rather than each API's bespoke scheme. The practical failure mode of raw HTTP at scale: when the tool landscape changes — a new endpoint, a deprecated parameter — every hardcoded HTTP call breaks silently; MCP's session-level capability manifest surfaces changes the agent can adapt to. Building on raw HTTP for agents is not wrong at toy scale — it fails at production scale when the number of tools grows past what any developer can maintain manually.

MCP and Zapier solve adjacent problems with different audiences. Zapier automates workflows between apps for non-technical users; MCP is a protocol for AI agents to call tools programmatically. Zapier's model is: a human configures a trigger-and-action workflow once; Zapier runs it. MCP's model is: an AI agent discovers available tools at runtime and decides which ones to call. The two are not mutually exclusive — Zapier built MCP support on top of its library of 9,000+ apps and 30,000+ actions, meaning an AI agent with an MCP client can now reach every Zapier-connected app without the human workflow-configuration step. The practitioner nuance: Zapier MCP is useful when you want AI agent access to Zapier's app coverage without building individual MCP servers for each app.

GitHub Copilot is an AI coding assistant that now operates as an MCP client — MCP is the protocol Copilot uses to reach external tools, not a competitor to Copilot. The relationship: Copilot is software running in VS Code or a browser; when Copilot needs to call an external tool (a Jira ticket, a GitHub repo, a web search), it does so through MCP. Before MCP, Copilot's tool integrations were custom connectors maintained by Microsoft. With MCP, any tool that publishes an MCP server becomes callable by Copilot without Microsoft writing a dedicated integration. The distinction developers miss: evaluating "MCP vs. Copilot" is a category error — Copilot is an adopter of MCP, not an alternative to it.

An LLM is the reasoning engine — the model that reads input, generates text, and makes decisions. MCP is the protocol that gives that engine hands. Without MCP (or a comparable integration layer), an LLM can only work with what's in its context window — text and pre-loaded data. With MCP, the LLM can call tools at runtime: retrieve a live database record, execute a search query, write a file, trigger a workflow. Claude 3.5 Sonnet reasoning about a customer support ticket is an LLM at work; Claude calling a CRM to retrieve the customer's history mid-conversation is MCP at work. The frame that matters: LLMs decide; MCP acts. A sophisticated AI agent needs both.

MCP uses JSON-RPC 2.0 as its message format, but calling it "just JSON" misses the protocol. JSON-RPC 2.0 defines the envelope — request IDs, method names, parameters, error codes. MCP adds on top of that a defined session lifecycle: initialization handshake → capability negotiation → tool discovery → tool calls → termination. JSON alone specifies none of that structure. The distinction matters when debugging: a malformed MCP session isn't a JSON syntax error — it's a lifecycle state error, which requires understanding the protocol's state machine, not just validating JSON. The practitioner test: if your MCP server returns valid JSON but ignores the initialization handshake, every MCP client will reject it — not because the JSON is wrong, but because the protocol contract is broken.

No — and this is the highest-value misconception in the MCP ecosystem. MCP has 300+ clients as of March 2026, including ChatGPT, GitHub Copilot, VS Code, Cursor, Windsurf, AWS Bedrock, Google Gemini, and JetBrains IDEs. Anthropic created MCP but donated its governance to the Agentic AI Foundation under the Linux Foundation in December 2025, making it a vendor-neutral standard no single company controls. OpenAI formally adopted MCP in March 2025 — four months after Anthropic launched it. The practical implication for developers: an MCP server you build today is reachable by Claude, ChatGPT, and GitHub Copilot without any modification — write the server once, serve every major agent platform.

Yes — OpenAI formally adopted MCP in March 2025 and added MCP support to ChatGPT apps in September 2025. OpenAI's adoption removed the last credible argument that MCP was a Claude-exclusive or Anthropic-controlled standard. When OpenAI adopted MCP, the protocol had an estimated 22 million monthly SDK downloads; by March 2026 that figure reached 97 million. ChatGPT is now one of more than 300 MCP clients — meaning any MCP server you build is natively callable from ChatGPT without any OpenAI-specific integration work. The sequence developers should know: Anthropic launched → OpenAI adopted → Microsoft integrated → Google followed — MCP's cross-vendor adoption happened in under 18 months.

Yes — Microsoft integrated MCP into GitHub Copilot, Visual Studio Code, and Copilot Studio. The GitHub Copilot extension in VS Code is among the most widely used MCP clients in the developer tooling ecosystem. Microsoft's adoption matters structurally: it brought MCP into enterprise environments at scale, since VS Code and GitHub Copilot are standard tooling in most engineering organizations. The consequence for MCP server builders: publishing an MCP server means your tool is callable from VS Code's AI features — the IDE that runs on more developer machines than any other. Microsoft's integration also means MCP is no longer a decision individual developers make; it's a platform decision that enterprise engineering teams inherit from their tooling.

Apple has not made a public MCP announcement as of May 2026. The honest answer is: unknown, but structurally likely. MCP clients that run on Apple platforms — Claude Desktop, VS Code, Cursor — are in wide use on macOS. If Apple builds agentic AI features into iOS or macOS, adopting MCP would give it instant interoperability with every existing MCP server ecosystem rather than requiring Apple to build a proprietary tool integration standard from scratch. The precedent: every other major AI platform that initially appeared absent from MCP (OpenAI, Microsoft, Google) has since formally adopted it. The practitioner read: Apple's silence is not a rejection — it's the gap between enterprise announcement cycles and protocol adoption reality.

Yes — Zapier MCP is included on all Zapier plans, including the Free tier, at no additional cost. There is no separate product SKU. The only cost is task consumption: each MCP tool call uses 2 tasks from your existing Zapier task quota. A developer on Zapier's free plan can connect an AI agent to Zapier's 9,000+ app library and 30,000+ actions today, using their existing task allocation. The nuance that changes the math: "free" means no incremental charge, not zero cost — if an agent makes 500 MCP tool calls in a month, that consumes 1,000 tasks from your quota. High-volume agent workflows will exhaust free-tier quotas quickly and require a paid plan.

Skip MCP when your system is developer-to-API rather than agent-to-tool. If a human developer is writing the integration code, REST is simpler and adds no session-management overhead. Skip MCP when you control both ends of the integration and don't need runtime discovery — if you own the calling code and the tool, you already know what the tool does; the tools/list handshake is unnecessary overhead. Skip MCP when latency is the primary constraint — persistent sessions add round-trip initialization costs that stateless REST calls don't. Skip MCP when your AI use case is inference-only: if the model generates text without calling any external system, MCP adds complexity with zero benefit. The practitioner test: if a human could write the integration code once and it would never need to change, use REST.

The most common friction points are auth complexity, debugging difficulty, and server quality variance. MCP has no native authentication — developers must implement OAuth 2.1 with PKCE themselves, and the gap between "runs locally" and "ships securely to production" is where most MCP projects stall. Debugging is harder than REST because persistent sessions have lifecycle state: a broken MCP connection isn't a failed HTTP request — it's a state machine that failed at initialization, capability negotiation, or mid-session, and the error may not surface clearly. The 10,000+ public MCP servers have wildly inconsistent quality — some are maintained production services; many are experimental projects with no uptime guarantees. "Moving away" overstates it: developers who understand MCP's limits ship successfully; the ones who expected plug-and-play get surprised by the operational requirements.

A2A — Google's Agent-to-Agent protocol — is not dead, but it has not achieved the ecosystem density MCP has. MCP and A2A address different layers: MCP handles tool access (an agent calling an external capability); A2A handles agent coordination (one agent delegating a task to another agent). They are complementary, not competing. The adoption gap is real: MCP has 97 million monthly SDK downloads and 300+ clients as of March 2026; A2A's ecosystem is smaller by every public measure. The honest framing: A2A is the correct protocol for multi-agent orchestration problems; MCP is the correct protocol for tool-calling problems. A developer who needs both can use both — and the most sophisticated agent architectures will.

No — MCP wraps APIs rather than replacing them. MCP servers use REST APIs internally; they expose MCP above and call REST below. The correct model: REST remains the implementation layer; MCP becomes the interface layer that AI agents interact with. This isn't a philosophical position — it's how production MCP servers are built. An MCP server for Stripe doesn't replace Stripe's REST API; it wraps it, adding the tools/list manifest and session management that AI agents expect. The question developers should ask instead: not "will MCP replace REST?" but "at which layer does MCP belong in my stack?" — the answer is always above your existing APIs, never instead of them.

Copilot critics object to Microsoft's pricing model, data training practices, and the perception that Copilot is a productivity layer rather than a reasoning upgrade. Common complaints include the cost per seat relative to perceived productivity gains, concerns about code written in Copilot being used to train future models, and the view that Copilot autocompletes rather than reasons. These criticisms are entirely separate from MCP — MCP is the protocol Copilot uses to reach external tools; it doesn't change Copilot's pricing, training data policies, or reasoning depth. The relevant clarification for developers evaluating both: being against Copilot doesn't mean avoiding MCP — every other major AI platform (Claude, ChatGPT, Cursor) also uses MCP and has none of Copilot's specific controversies.

MCP supports two transport layers: stdio for local in-process communication and HTTP with Server-Sent Events (SSE) for remote connections. Local MCP servers — the kind that run on a developer's machine alongside Claude Desktop — use stdio, which is faster and simpler because the agent and server are in the same process space. Remote production MCP servers use HTTP/SSE, which enables cross-network communication but requires TLS since MCP has no native encryption layer. Most production MCP servers use the HTTP transport — it's what makes an MCP server callable from any agent on any machine. The choice isn't either-or: a single MCP server implementation can support both transports, but most developers building for production start with HTTP/SSE.

MCP supports both, but the spec explicitly recommends HTTPS for any remote server — and running an MCP server over plain HTTP in production is a security vulnerability, not a configuration choice. MCP does not natively enforce encryption; TLS must be configured by the developer. The risk is concrete: MCP sessions carry tool call parameters and responses over a persistent connection — plain HTTP exposes that entire session to interception. Local development over localhost HTTP is acceptable (the connection doesn't leave the machine); any server exposed over a network must use HTTPS. The gap most teams hit: MCP tutorials run over HTTP for simplicity; developers copy that configuration to production and ship an insecure server without realizing the protocol never warned them.

MCP standardizes OAuth 2.1 with PKCE for authentication in remote server connections — but this is not built into the base protocol. OAuth support was added to the MCP spec after initial launch, when real-world adoption revealed auth as the most common production gap. Implementing it requires developers to configure an OAuth 2.1 server, handle PKCE flows, and manage token refresh — none of which MCP handles automatically. Local MCP servers running over stdio typically require no auth because they run in a trusted local environment. Remote servers require auth, and OAuth 2.1 with PKCE is the spec-recommended approach. The practitioner reality: "MCP supports OAuth" means MCP defines how OAuth should work in its context — it doesn't mean your MCP server has OAuth until you build it.

An MCP server looks like an API from the outside but differs in three structural ways. First, it exposes a standard capabilities manifest via tools/list — a traditional API has static docs; an MCP server has a live, machine-readable manifest the agent queries at runtime. Second, it maintains session state across multiple calls within a connection — REST APIs are stateless by design; MCP sessions are stateful. Third, it uses JSON-RPC 2.0 rather than REST conventions — request/response patterns, error codes, and method naming all follow JSON-RPC semantics, not HTTP verb conventions. Calling an MCP server and calling a REST API look superficially similar from a network perspective; they're architecturally different contracts that break in different ways when misused.

Nothing has fully replaced Power Automate — it remains Microsoft's enterprise workflow product and continues to serve the structured, if-then automation use cases it was built for. What MCP and AI agents are taking from Power Automate is the dynamic, decision-driven tier of automation — tasks that require reasoning, not just routing. Power Automate routes data between systems based on rules a human writes; an MCP-connected agent can decide which tools to call, handle edge cases without pre-written rules, and adapt to inputs that a static workflow would reject. Routing a support ticket to the right queue is Power Automate's domain; reading the ticket, checking the customer's history, drafting a response, and escalating if needed is where MCP-connected agents outperform static workflow tools. The transition isn't replacement — it's a shift in which automation problems belong in which category.

Google has invested significantly in Anthropic across multiple rounds, but the exact ownership percentage is not publicly disclosed. Reports indicate Google invested $300 million in a 2023 funding round and participated in subsequent rounds. The precise ownership stake — including whether it is or was 14% — has not been confirmed in any public filing. What is confirmed: Google Cloud and Anthropic have a partnership that includes MCP integration into Google's Gemini models and Google Cloud services. The relevant fact for MCP evaluation: Google's investment in Anthropic did not prevent Google from independently adopting MCP — both Google Gemini and Google Cloud services are listed among MCP clients, and adoption was driven by the protocol's open governance under the Linux Foundation, not by equity relationships.

MCP is best understood as a layer above APIs, not a replacement for them. Saying MCP is basically an API is like saying HTTP is basically a phone call — technically there's a connection, but the architectural purpose is different. Traditional APIs serve developers who know what they want to call and write the call in advance. MCP serves AI agents that discover what's available at runtime and decide what to call dynamically. The difference shows up at scale: an API breaks when you add a new endpoint that no existing code knows to call; an MCP server's tools/list response automatically surfaces the new capability to every connected agent on the next session. MCP Scraper is an example of what this makes possible — a web data tool built not for developers to integrate manually, but for AI agents to discover and call directly, the way MCP was designed to work.