Model Context Protocol (MCP) explained: what it is, how it works, and how to build a server

Every useful AI assistant eventually hits the same wall: the model is smart, but your work lives somewhere it cannot reach. Your tickets are in Jira, your files in Google Drive, your data in Postgres. Before MCP, connecting an AI app to each of those meant a custom integration, rebuilt again for every other AI app you wanted to use.

The Model Context Protocol fixes that by giving every AI app and every system one shared way to talk. This guide explains what MCP is, how MCP servers and clients work, where it is already used, the security questions to ask, and how to build a working MCP server yourself.

What is MCP in AI?

MCP is an open-source standard for connecting AI applications to external systems. In the words of the official documentation (opens in a new tab), it lets apps like Claude or ChatGPT connect to data sources, tools and workflows so they can access key information and perform tasks.

The docs compare MCP to a USB-C port for AI. Before USB-C, every device needed its own cable. Before MCP, every pairing of an AI app and a system needed its own connector. With a shared standard, a system only needs one MCP server to work with every compatible app, and an app only needs to support MCP once to reach every server.

A short history of MCP

• November 2024: Anthropic announced MCP (opens in a new tab) as an open standard, releasing the specification, SDKs, local server support in the Claude desktop apps, and open-source servers for Google Drive, Slack, GitHub, Git, Postgres and Puppeteer.
• 2025: Adoption spread beyond Anthropic. ChatGPT, Gemini, Microsoft Copilot, Cursor and Visual Studio Code all added support.
• December 2025: Anthropic donated MCP to the Agentic AI Foundation (opens in a new tab), a fund under the Linux Foundation co-founded with Block and OpenAI. At that point there were more than 10,000 active public MCP servers and over 97 million monthly SDK downloads across Python and TypeScript.
• July 2026: Protocol version 2026-07-28 made MCP stateless, so every request carries the information needed to handle it. That makes remote servers simpler to scale.

How MCP works: hosts, clients and servers

MCP uses a client-server design with three participants, described in the architecture overview (opens in a new tab):

• MCP host: the AI application the user works in, such as Claude Desktop, Claude Code or VS Code.
• MCP client: a connector inside the host. The host creates one client for each server it connects to, and each client keeps a dedicated connection.
• MCP server: the program that provides context and capabilities, such as a GitHub server, a database server or a file system server.

Servers can run in two places. A local server runs on your own machine and talks to the host over standard input and output (the stdio transport), which is how a file system server works. A remote server runs on the internet and uses the Streamable HTTP transport, usually with OAuth sign-in, which is how hosted servers from services like Sentry work. Either way, the messages themselves use JSON-RPC 2.0.

What an MCP server exposes

A client discovers what a server offers by calling list methods such as tools/list, then calls a tool with tools/call. Each tool describes its inputs with a JSON Schema, which is how the model knows what arguments to pass. Servers can also ask the user for more information mid-task through a client feature called elicitation, for example to confirm an action.

One request, start to finish

1. You ask your AI app: "Open an issue for the login bug we discussed."
2. The host already knows, from tools/list, that the connected GitHub server has a create_issue tool and what fields it needs.
3. The model decides to call that tool and drafts the title and description.
4. The host sends a tools/call request through the GitHub client, usually after asking you to approve it.
5. The server calls GitHub's API, creates the issue and returns the result, which the model uses to reply with the link.

What MCP is used for

• Coding assistants that read your repository, run tests, open pull requests and check error trackers.
• Personal assistants that read your calendar, email and notes. The MCP docs give the example of agents that access Google Calendar and Notion.
• Enterprise chat that queries several internal databases in one conversation.
• Workflow automation: chaining tools from different systems, such as reading a support ticket, checking the customer's account and drafting a reply.
• Design to code: the docs mention Claude Code generating a web app from a Figma design through MCP.

MCP is a big part of why AI is shifting from answering questions to doing work. Tools are what turn a model into an agent, a difference we explain in agentic AI vs generative AI.

Advantages of MCP

• Build once, use everywhere. A single MCP server works with every compatible AI app.
• Less custom glue code. Developers stop rewriting the same integration for each assistant or framework.
• Switch models freely. Because the protocol is model-agnostic, you can change AI providers without rebuilding your integrations.
• Discoverable capabilities. Apps learn what a server can do at run time, so new tools appear without app updates.
• A large ecosystem. Thousands of existing servers cover common tools, so you often only need to install one.
• Open governance. MCP is managed under the Linux Foundation rather than by a single vendor.

MCP vs APIs, plugins and Skills

MCP does not replace APIs; most MCP servers call an existing API behind the scenes. What MCP adds is a standard description of that API's capabilities that any AI app can understand. Compared with the app-specific plugin systems that came before it, MCP is shared across vendors.

It also pairs well with Claude Skills. MCP gives an AI access to a system. A Skill teaches it how to do a task well with that access, such as your team's rules for writing release notes.

MCP security: what to watch for

Connecting an AI app to real systems means mistakes and attacks can have real effects. The specification's security best practices (opens in a new tab) cover the main risks:

• Untrusted local servers. A local server runs with your user's permissions, so a malicious one can read files or run commands. The spec requires clients to show the exact command and get your approval before adding a server through one-click setup.
• Over-broad permissions. Tokens with sweeping scopes increase the damage if they leak. The spec recommends starting with minimal scopes and asking for more only when a tool needs them.
• Token passthrough. Servers must not accept tokens that were not issued for them, a shortcut that breaks audit trails and security controls.
• Server-side request forgery. A malicious remote server can try to make a client fetch internal URLs, so clients should require HTTPS and block private network addresses.

How to build an MCP server

The official build a server tutorial (opens in a new tab) covers Python, TypeScript, Java, Kotlin, C#, Ruby and more. Here is the shortest useful version in Python, using the MCPServer class from the official SDK. It exposes one tool that counts words in a piece of text.

1. Set up the project

uv init word-tools
cd word-tools
uv add "mcp[cli]"

2. Write the server

from mcp.server import MCPServer

mcp = MCPServer("word-tools")


@mcp.tool()
def count_words(text: str) -> str:
    """Count the words and characters in a piece of text.

    Args:
        text: The text to analyze
    """
    words = len(text.split())
    return f"{words} words, {len(text)} characters"


if __name__ == "__main__":
    mcp.run(transport="stdio")

The SDK turns the function's type hints and docstring into the tool definition automatically. One rule catches almost everyone: a stdio server must never write to standard output, so no print() calls. Stdout carries the protocol messages, and stray output corrupts them. Log to stderr instead. We ran this exact server against version 2.3 of the Python SDK: listing tools returns count_words, and calling it with "hello there MCP world" returns "4 words, 21 characters". If you are following an older tutorial, note that SDK 2.x renamed FastMCP to MCPServer.

3. Connect it to Claude Desktop

Open claude_desktop_config.json (on macOS in ~/Library/Application Support/Claude/, on Windows in %AppData%\Claude\), add the server under mcpServers, and restart the app:

{
  "mcpServers": {
    "word-tools": {
      "command": "uv",
      "args": ["--directory", "/ABSOLUTE/PATH/TO/word-tools", "run", "server.py"]
    }
  }
}

Ask Claude to count the words in a paragraph and it will offer to call your tool. From here, swap the word counter for something useful: a lookup in your internal database, a call to your company's API, or a search over your documentation. The MCP Inspector (opens in a new tab) lets you test tools without an AI app in the loop.

Limitations of MCP

• Quality varies. Anyone can publish a server, and many community servers are thin wrappers with little error handling or security review.
• Too many tools hurt. Connecting dozens of servers floods the model with tool descriptions and makes it pick worse. Connect what a task needs.
• It moves fast. The 2026-07-28 version changed core mechanics such as statelessness and deprecated features like sampling, so older tutorials and servers may not match the current spec.
• It is plumbing, not judgment. MCP gets an AI to your systems. Whether it uses them well still depends on the model, the prompt and your guardrails.

The bottom line

MCP has become the default way to connect AI applications to the rest of your software. For most people that means turning on ready-made connectors in the apps they already use. For developers it means writing one server per system instead of one integration per app. Start with read-only tools from trusted sources, keep approvals on for anything that writes, and build your own server when an internal system has none. For more on the models and agents that use MCP, browse our AI guides.