MCP (Model Context Protocol) explained

What the Model Context Protocol is, why Anthropic created it, how clients and servers talk, and where to use it in production.

The Model Context Protocol (MCP) is an open standard for wiring LLM clients to external tools, data sources, and prompts. Anthropic introduced it in late 2024 with a specification, reference servers, and SDKs in TypeScript and Python. Since then, Claude Desktop, Cursor, Windsurf, Cline, Continue, and other AI clients have shipped MCP support. You can think of MCP as 'USB-C for AI integrations': one protocol, many clients, many servers.

The problem MCP solves

Before MCP, every LLM application had its own custom integration layer. A plugin written for one chatbot would not run in another. Teams rebuilt the same adapters — search, file access, GitHub, databases — once per product. MCP replaces that with a single wire format, so any conforming client can talk to any conforming server.

The three primitives

An MCP server exposes capabilities to a client in one or more of three shapes:

Tools — callable functions the model can invoke, typed with a JSON Schema. Example: query_kb, list_documents, create_issue.
Resources — named pieces of context the client can read, addressed by URI. Example: file://design-spec.pdf, db://users/42.
Prompts — parameterised prompt templates the server advertises. Example: 'summarize-quarterly-report' with a 'quarter' argument.

How the wire protocol works

MCP uses JSON-RPC 2.0 over one of three transports: stdio (for local desktop integrations), streamable HTTP (for remote servers), and — in earlier drafts — HTTP+SSE. Sessions begin with an initialize handshake that exchanges protocol versions and capabilities. The client then lists tools, resources, and prompts, and calls them as needed. Servers can also push notifications, such as 'resources/list_changed' when the underlying data moves.

// A minimal tool call, JSON-RPC 2.0
{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "query_kb",
    "arguments": { "kb": "policies", "q": "refund window" }
  }
}

Local vs remote servers

A local stdio server runs as a subprocess on the user's machine. It is trivially secure — no network surface — and ideal for filesystem and shell tools. A remote HTTP server runs somewhere on the internet, usually behind OAuth or an API key. Remote servers are the right choice for SaaS integrations: one deployment serves every customer.

Authentication

The spec recommends OAuth 2.1 with PKCE for remote servers that hold user data. The client obtains an access token, attaches it as an Authorization header, and the server validates it on every request. For developer tools, long-lived API keys are also common; they are simpler but give up the revocation and scoping benefits of OAuth.

When to build an MCP server

Your users already live inside an MCP-aware client (Claude Desktop, Cursor, Windsurf).
The integration is valuable across clients — you do not want to write one plugin per app.
Your data has structure: searchable records, typed endpoints, or parametric prompts.
You want a standard way to expose auth, rate limits, and tool schemas.

When not to

If your integration is a one-off chatbot button or a webhook fired from a form, MCP is overkill. MCP shines when an AI assistant needs to reason about when and how to use your tool, and when the interaction is ongoing rather than single-shot.

3meel's MCP surface

3meel gives each account a personal MCP endpoint. The server exposes tools for listing knowledge bases, querying them, uploading documents, and managing memory. Any MCP-compliant client can connect with an API key or OAuth. Configuration is usually a single JSON block pasted into the client's settings.

Start free