If you are building an LLM application that needs to talk to your filesystem, your database, your repository, or an internal API, you have two ways to wire that up. One: write a bespoke integration inside your app. Two: connect to an MCP server that already speaks to that data source. MCP — the Model Context Protocol — is the open standard for the second path.

What MCP actually is

Anthropic announced and open-sourced MCP in November 2024. The pitch is direct: most LLM applications spend an embarrassing amount of effort re-implementing the same integrations (read files, query Postgres, search Google Drive, hit a web API). MCP defines a small protocol that any client and any server can speak, so the integrations stop being bespoke.

The mechanics:

  • An MCP server exposes some combination of resources, tools, and prompts.
  • An MCP client (typically the LLM application) connects to one or more servers and lets the model use what they expose.
  • Communication is JSON-RPC over a transport — usually stdio for local servers, HTTP/SSE for remote ones.

The official site, spec, and SDKs live at modelcontextprotocol.io and github.com/modelcontextprotocol.

The three capability surfaces

An MCP server can expose any combination of three things:

Resources — read-only data that the model can read for context. The retrieval side. A filesystem MCP server might expose every file under a path as a resource. A Postgres server might expose tables and views. Resources have URIs and content types and can be browsed before being fetched.

Tools — callable operations the model can invoke. The action side. Same shape as classic function calling, but discovered via the protocol rather than hard-coded in the app. A GitHub MCP server might expose tools like create_pull_request or comment_on_issue.

Prompts — reusable templates the host application can fetch and use. Less used in production today than resources and tools, but useful for shipping curated prompt patterns alongside the data they apply to.

That triple — resources, tools, prompts — is the entire user-facing surface of the protocol.

Why it exists

Two practical wins:

One integration, many apps. Write an MCP server for your internal API once. Every MCP-aware client — your Claude desktop app, your IDE, your custom agent — can use it. Without MCP, you write that integration once per app.

Decoupling host from data. The model and the host application do not need to know the specifics of every data source. They speak MCP; servers handle the specifics. New data sources show up as new servers, not as new code paths in every app.

A practical example: if your team wires an MCP server for your internal documentation, every engineer's IDE, every chat client that supports MCP, and every CI bot can read those docs through the same protocol. Add a new doc source by adding a new server, not by patching every app.

Adoption

By mid-2026, MCP support is in:

  • Anthropic's Claude desktop and API ecosystems (the launch surface).
  • Multiple IDE integrations and AI-coding tools.
  • Major frameworks and orchestration libraries that target multi-provider setups.
  • A growing public registry of MCP servers — filesystem, GitHub, Postgres, Drive, search, etc.

The protocol is genuinely cross-vendor. A model running on any provider can use MCP-exposed tools through a client that speaks the protocol; the model itself does not need to "support MCP" in the same way it supports tool use. The host application does the bridging.

Where MCP and function calling meet

Concretely: the host application uses MCP to discover what tools and resources are available. It then registers those tools with the model using the provider's normal tool-use API (function calling on OpenAI, tool use on Anthropic, function calling on Gemini). When the model emits a tool call, the host routes the invocation through MCP back to the server.

Two layers, doing different jobs:

  • MCP — how the host discovers, configures, and routes to external capabilities.
  • Function calling / tool use — how the model selects and invokes them.

They are complements. Most production LLM applications in 2026 will use both, in that order.

Where to read the actual protocol

If you build an agent that touches more than two external systems in 2026, MCP is worth a serious look before you wire your third bespoke integration.