What is MCP? The Model Context Protocol, explained

What is MCP?

The Model Context Protocol (MCP) is an open standard that lets AI applications connect to external data and tools through one common interface. Instead of building a custom integration for every model and every system, you implement MCP once — and any compliant AI client can discover and use those capabilities at runtime.

If you think of AI models as extremely capable brains with no hands, MCP is the standard set of hands: a universal way for any model to read a data source (a "resource") and do something (call a "tool") without a bespoke integration for every model and every service. The comparison that stuck across the industry is USB-C for AI. Before a universal port, every device shipped its own connector and every accessory needed an adapter; after it, anything plugs into anything. MCP plays the same role for AI context: one port, any model, any data source.

The practical upshot is portability. Connect a capability once and it works with the model you use today and the model you switch to next year. A tool server written for Claude works unchanged with ChatGPT, Gemini, Cursor, or a custom agent. That is why we describe BusinessMCP as model-agnostic infrastructure — your tools belong to you, not to whichever lab is winning this quarter.

Anthropic introduced and open-sourced MCP in November 2024, and within roughly a year every major AI lab had adopted it. Even if you never write a line of protocol code, MCP is worth understanding, because it now defines how AI agents reach the systems your business runs on.

The N×M integration problem

MCP exists to kill a specific piece of engineering waste. Before it, every AI assistant spoke its own tool dialect — one lab had plugins, another had its own function-calling format, a third had "extensions" — and every data source needed a separate connector for each of them. With M AI applications and N systems to connect, the industry was on the hook for M × N bespoke integrations, each fragile, each maintained by whoever needed it that week, and each thrown away when a model or vendor changed.

A standard protocol collapses that multiplication into addition. Each AI application implements MCP once as a client; each system implements it once as a server; everything interoperates. M × N becomes M + N.

Without MCP:  4 AI apps × 6 systems = 24 custom integrations to build and maintain
With MCP:     4 MCP clients + 6 MCP servers = 10 implementations, all compatible

This is the same move that made the web work (HTTP), made email work (SMTP), and made language servers work in every code editor (LSP — an explicit inspiration for MCP). Standards win when the pain of pairwise integration outgrows the cost of agreeing on a contract. For AI tooling, that point arrived in 2024.

How MCP works

Under the hood, MCP is a small, boring protocol — which is a compliment. Messages are JSON-RPC 2.0: plain JSON objects with a method name, parameters, and an id to match responses to requests. There are three roles. A host is the AI application the user actually touches — Claude, ChatGPT, Cursor, an IDE, a custom agent runtime. The host embeds one or more MCP clients, each of which maintains a stateful, one-to-one connection to an MCP server — the process that exposes capabilities and does the real work against your systems.

A connection has a defined lifecycle. It opens with an initialize handshake in which the two sides agree on a protocol version and declare what they support (capability negotiation). The client then discovers what the server offers — tools/list, resources/list, prompts/list — and receives, for every capability, a name, a human-readable description, and a typed input schema. From then on the conversation is use: the model picks a tool, the client calls it, the server executes and returns a result. Servers can also push notifications, such as "my tool list changed."

In practice, every interaction follows the same four beats:

• Discovery — the client asks the server "what can you do?" and receives a list of tools and resources, each with a name, description, and typed input schema.
• Selection — the model reads those descriptions and decides which tool fits the user's request.
• Invocation — the client calls the tool with structured arguments.
• Result — the server runs the work and returns a structured result the model can reason over.

On the wire, a tool call is as plain as this:

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "get_analytics",
    "arguments": { "range": "30d" }
  }
}

Because the schemas are self-describing, the agent needs no prior knowledge of your systems. It learns what is available at connect time, which is exactly what makes MCP feel less like an integration and more like plugging in a device.

Tools, resources and prompts

Servers expose three primitives, each with a different answer to "who decides when this is used?"

Tools are functions the model can call — "create a task", "get analytics for the last 30 days", "send an email". Each declares a JSON schema for its inputs so the model can supply valid arguments. Tools are model-controlled: the model decides, mid-conversation, that a tool fits the task and calls it. They are how an agent acts.

Resources are addressable data the model can read — a contact record, a metrics snapshot, a document. Resources are identified by URI (for example businessmcp://snapshot) and returned as structured content. They are application-controlled: the host chooses what to load into context. They are how an agent reads.

Prompts are reusable templates the user invokes — think slash commands like "weekly growth review" or "funnel audit" that expand into a well-crafted starting prompt, optionally pulling in server data. They encode workflows the server author knows are useful, so users do not have to rediscover them.

The protocol also defines client-side capabilities a server can request — sampling (ask the host's own model to complete something), roots (learn which directories or scopes it may operate in), and elicitation (ask the user a structured question mid-task) — but tools and resources do the overwhelming majority of the work in production.

Architecturally, a hosted MCP server sits between the agent and your real systems. It authenticates the caller, enforces which tools are allowed, executes the work against your connected services, and returns a clean result. That middle layer is where governance lives: authentication, per-tool permissions, rate limits, and an audit trail of every call.

AI agent  →  MCP client  →  MCP server  →  your tools & data
          ←              ←              ←

Transports: stdio and streamable HTTP

The protocol layer is transport-agnostic; the spec defines two standard ways to move the JSON-RPC messages.

[stdio](/guides/remote-vs-local-mcp) runs the server as a local subprocess of the host, exchanging messages over standard input and output. It is trivially simple, has no network surface, and inherits the user's local credentials — ideal for personal, single-user tools like "an MCP server for my local filesystem" or a CLI wrapped for Claude Desktop. Its limits are equally clear: the server must be installed on every machine, and it cannot serve a team.

Streamable HTTP is the transport for remote, hosted servers. The server exposes a single HTTP endpoint that accepts POSTed JSON-RPC messages and can stream responses back over server-sent events when a call produces incremental output. It was introduced in the March 2025 revision of the spec, replacing the original two-endpoint HTTP+SSE transport, and it deliberately supports both stateless deployments (serverless-friendly: every request self-contained) and stateful sessions. Anything multi-user, anything behind a URL, anything an external agent should reach — that is streamable HTTP, behind HTTPS.

The good news for developers: transports are an initialization detail. The tools and resources you register do not change when you swap stdio for HTTP — see how to build an MCP server for working code with both.

Authentication for remote servers

A local stdio server can lean on the operating system for security. A remote server cannot — it is a URL on the internet holding credentials to your systems, and the spec treats it accordingly.

For HTTP transports, MCP defines an authorization framework built on OAuth 2.1. The MCP server acts as an OAuth resource server: it publishes protected-resource metadata (at /.well-known/oauth-protected-resource) telling clients where to obtain tokens, clients complete a standard OAuth flow with the authorization server, and every subsequent request carries a Bearer access token which the server validates. The June 2025 spec revision tightened this further, using resource indicators (RFC 8707) so a token issued for one server cannot be replayed against another.

In practice, many production deployments also support the simpler machine-to-machine pattern: a long-lived API key sent as a Bearer token. BusinessMCP does both — your endpoint authenticates every request with an mcph_* key and publishes the standard /.well-known/oauth-protected-resource metadata — and layers per-key scoping on top, so a key can be restricted to an allowlist of tools and data classes. Whatever the scheme, the rule is absolute: never expose an unauthenticated MCP server. It is an API into your business.

From launch to de-facto standard

MCP went from announcement to industry default unusually fast, and the dates matter because they explain why the ecosystem looks the way it does.

• November 2024 — Anthropic introduces and open-sources MCP: the spec, SDKs, and a first wave of reference servers. Early adopters include Block and Apollo, with developer tools like Zed, Replit and Sourcegraph building support.
• Early 2025 — the community ships hundreds, then thousands, of servers: databases, SaaS products, browsers, dev tools. "Is there an MCP server for X?" becomes the default question.
• March 2025 — OpenAI announces MCP support across its Agents SDK, with ChatGPT and the API to follow. The moment a rival lab adopted it, MCP stopped being an Anthropic technology and became an industry standard.
• April 2025 — Google DeepMind confirms MCP support for Gemini models and SDKs. Microsoft ships support across Copilot Studio and announces native MCP support in Windows.
• September 2025 — an official MCP Registry launches in preview, giving clients a standard place to discover servers.
• December 2025 — Anthropic donates MCP to the Linux Foundation, moving the standard under neutral, open governance.

By 2026, MCP is simply the assumed answer to "how does an AI agent connect to a system?" — the way HTTP is the assumed answer to "how does a browser fetch a page?" For anyone deciding how to make their business AI-accessible, that de-facto status is the point: build to MCP and you inherit every compatible client, present and future.

MCP vs. a plain API

An honest framing: MCP does not replace your API — it usually wraps one. A REST or GraphQL API is designed for developers who read documentation at build time and write code against fixed endpoints. MCP is designed for models that discover capabilities at runtime: the schema, the description of when to use each tool, and the invocation contract all travel with the connection, so no human has to hard-code anything. If you already have a clean API, an MCP server over it is often a thin layer — and if an AI agent is the consumer, that layer is the difference between "works with one vendor's function-calling format" and "works with every MCP client." For the full comparison — when a plain API is the better choice, what MCP adds, and what it costs — see the dedicated MCP vs API guide.

Why it matters for a business

Most companies do not need to build an MCP server so much as they need their business to be one. Your customer data lives in a CRM, your traffic in analytics, your spend in ad platforms, your money in Stripe. An AI agent that can only see one of those is guessing. An agent that can see all of them, through one endpoint, can actually answer "which campaign drove our most valuable customers last quarter?"

MCP is the standard that makes that unification safe. Instead of handing an agent raw database credentials, you expose a curated set of tools with scoped permissions and a full log of what was called. You get the leverage of an agent with the control of an API.

There is also a strategic angle. Because MCP is vendor-neutral, exposing your business through it is not a bet on any one AI company. The endpoint you stand up today serves Claude, ChatGPT and Gemini alike — and whatever ships next.

How BusinessMCP uses MCP

BusinessMCP is managed MCP hosting that turns your whole company into a single, AI-ready data platform. You connect your tools, databases, ad platforms and Stripe revenue and install one tracking script; we unify everything into one hosted MCP server plus a business-intelligence dashboard.

You consume it two ways from one codebase:

• The cloud app — analytics, CRM, SEO, social and ads reporting, where you work with an AI Assistant that has full business context, every connected tool, and every major model.
• Your own [MCP endpoint](/guides/expose-your-business-as-an-mcp-endpoint) — the same unified data and the entire Assistant toolset exposed securely to any external agent via a Bearer mcph_* key at /api/mcp.

The endpoint is a full implementation of the protocol, not just a tool list: it serves tools (analytics, CRM, SEO, ads, revenue, enrichment, web research and more), resources (a live business snapshot, your playbooks, workspace memory), and prompts (ready-made workflows like a weekly growth review or funnel audit). High-impact actions such as sending email are approval-gated — the agent drafts, you approve — every call is logged, and per-key access policies control which tools and data classes an external agent can touch.

Both surfaces are backed by the same connectors and the same first-party analytics spine, so the numbers your dashboard shows are the numbers an agent sees.

Getting started

You do not have to understand the protocol to benefit from it. The fastest path is the Quickstart: install the tracking script, connect a tool or two, and grab your endpoint. To connect an assistant, see Connect Claude, GPT & Gemini. If you want to go deeper on the standard itself, read MCP best practices; if you need a bespoke server for a proprietary system, how to build an MCP server walks through the code; and for the other half of the picture — the agents that consume all this — start with What are AI agents?.