--- title: What is MCP (Model Context Protocol) description: MCP is the open protocol that lets every AI app connect to every external tool through a single standard. Here is what it is, how it works, and why it matters for operators. author: FractionalSkill ---

What is MCP (Model Context Protocol)

Every AI tool you use today has the same problem. It lives in a box. Claude Desktop can read your conversation. Cursor can read your codebase. But neither can reach into Linear, Slack, your CRM, or the dozen other tools where your actual client work happens.

Until recently, the only way to bridge that gap was one-off integrations. Each app built its own connector to each service, in its own format, with its own quirks. If you wanted three AI apps to talk to five external tools, someone had to build fifteen separate integrations. That approach breaks down fast.

MCP, the Model Context Protocol, is Anthropic's answer. It's an open protocol that standardizes how AI applications connect to external tools and data sources. Build a connection once, and it works in every app that supports the standard.

The USB-C analogy

The MCP documentation uses a comparison that makes this click immediately. MCP is like USB-C for AI apps.

Before USB-C, every device had its own port. Your phone used one cable, your laptop used another, your headphones used a third. You carried a bag of adapters. Each manufacturer made their own connector and everyone suffered for it.

USB-C replaced all of that with a single standard port. One cable works with every device that supports it. The manufacturer builds USB-C support once, and every accessory in the world becomes compatible.

MCP does the same thing for AI applications. Instead of each app building custom integrations for each service, MCP gives them all a universal connector. An MCP server built for Slack works in Claude Desktop, Cursor, Windsurf, and any other app that supports the protocol. No rebuilding required.

Build once, use anywhere. That is the entire premise. One integration standard replaces the mess of custom connectors that would otherwise be required as AI tools multiply.

> Why this matters for your practice. You're probably using two or three AI-powered tools already. Maybe Claude Desktop for research and Cursor for code. Without a standard like MCP, every tool integration you set up is locked to one app. With MCP, a Linear server you configure once works across all of them. That means less setup, less maintenance, and more consistency across your workflow.

How the architecture fits together

MCP has three layers. Each one has a specific role, and they connect in a predictable pattern.

┌─────────────────────────────────────────────────────┐
│                   HOST APPLICATION                   │
│             (Claude Desktop, Cursor, etc.)           │
│                                                      │
│   ┌──────────────┐  ┌──────────────┐                │
│   │  MCP Client  │  │  MCP Client  │    ...         │
│   └──────┬───────┘  └──────┬───────┘                │
└──────────┼─────────────────┼────────────────────────┘
           │                 │
           ▼                 ▼
    ┌──────────────┐  ┌──────────────┐
    │  MCP Server  │  │  MCP Server  │
    │  (Linear)    │  │  (Slack)     │
    └──────┬───────┘  └──────┬───────┘
           │                 │
           ▼                 ▼
    ┌──────────────┐  ┌──────────────┐
    │   Linear     │  │    Slack     │
    │   API        │  │    API       │
    └──────────────┘  └──────────────┘

Host applications are the AI-powered apps you already use. Claude Desktop, Cursor, Windsurf, Claude Code. These are the programs where you interact with an LLM. The host app's job is to provide MCP client support so it can connect to servers.

MCP clients live inside the host application. They handle the connection between the app and each MCP server. When Claude Desktop connects to a Linear server and a Slack server, it's running two separate MCP clients internally, one for each server.

MCP servers are the integration layer. Each server exposes a bundle of tools, resources, and prompts that the client can access. A Linear MCP server might expose tools like "create issue," "list issues," and "update status." A Slack MCP server might expose "send message," "read channel," and "list channels."

The external services themselves, Linear, Slack, GitHub, Google Drive, are unchanged. The MCP server sits between your AI app and the service's API, translating requests into a format the protocol understands.

> The practical result. You can plug as many MCP servers as you want into a single host application. One Cursor session could be connected to Linear for project management, GitHub for version control, and a custom server for your client's internal database. The LLM inside Cursor decides which tools to call based on what you ask it to do.

MCP clients vs MCP servers

These two terms appear constantly in MCP documentation. Here is the distinction, laid out plainly.

Clients consume. Servers provide. The client is the plug. The server is the outlet. You don't build clients unless you're developing an AI application from scratch. For operators, the work is in setting up and configuring servers.

One thing that catches people off guard: not every client supports every server feature. MCP servers can expose tools, resources, and prompts. But each host application chooses which of those features to implement. Claude Desktop currently supports all three. Cursor only supports tools. This means a prompt template you build into an MCP server will work in Claude Desktop but won't appear in Cursor.

That gap is closing. MCP launched in November 2024, and adoption is moving fast. As more clients implement the full feature set, the discrepancies shrink.

> What to focus on first. Tools are supported by virtually every MCP client today. If you're building or configuring MCP servers for your practice, start with tools. They give you the broadest compatibility across apps right now.

Why MCP matters for operators

The protocol is still young. But the trajectory is clear, and it's worth paying attention to if you run client engagements across multiple tools.

Standardization reduces setup time. Every MCP server you configure works across every app that supports the protocol. Configure a GitHub MCP server once and it's available in Claude Desktop, Cursor, and Claude Code simultaneously. No duplicate work.

Open source servers are multiplying. The community already includes official servers from companies like Stripe and community-built servers for dozens of popular tools. Browsing the server list in the MCP documentation reveals integrations for file systems, databases, browser automation, project management tools, and more. Many of these are free to install and configure.

The architecture scales with your stack. If you manage three client engagements, each with their own project board, shared drive, and communication channel, MCP lets you wire all of those into your AI tools. The LLM decides which tools to call based on your request. You don't switch between apps to pull context from each one.

Authentication and remote hosting are coming. Right now, most MCP servers run locally on your machine. The MCP roadmap includes remote server support with OAuth authentication. When that ships, companies will be able to host official MCP servers on their own URLs. Connecting to Slack's tools could be as straightforward as adding a URL to your client config and authenticating once.

The bottom line is practical. MCP turns your AI tools from isolated assistants into connected operators that can reach across your entire toolset. The protocol handles the plumbing. Your job is deciding which connections matter for your workflow.

> Where to go from here. If you're ready to set up your first MCP server, the next guide in this series walks through installation and configuration step by step. Start with one server for a tool you use daily, get familiar with the pattern, and expand from there.