What is MCP? The Model Context Protocol explained

October 24, 2026 · 10 min read

Ask a chat assistant for the SHA-256 of a file on your laptop and one of two things happens. It tells you it can’t read your files, or it produces 64 hex characters that look right and aren’t. The model can’t open the file, and it can’t run SHA-256 in its head. What it’s missing is a way to call a program that can.

The Model Context Protocol (MCP) is a standard way to give it one. An application such as Claude Desktop, Claude Code, Cursor or VS Code connects to small programs called MCP servers, asks them which tools they offer, and lets the model call those tools. The server runs the real code and sends back the result.

This article covers how MCP is built, what the messages look like, how to add a server to your assistant, what to check before you trust one, and how to write a small server yourself. At the end there’s a short section on the devtoolbox.cc MCP server, which puts the tools from this site into your assistant.

Where MCP came from

Before MCP, every AI application had its own plugin or function-calling format. A team that wanted its database, issue tracker or internal API available in three assistants wrote three integrations, and every new assistant meant another one. With N applications and M data sources, that’s N × M pieces of glue code.

Anthropic published MCP as an open standard in November 2024; the first revision of the specification is dated 2024-11-05. The specification credits David Soria Parra and Justin Spahr-Summers as its creators, and the project is now run as a series of LF Projects, the Linux Foundation’s legal home for open projects. The specification itself says it takes inspiration from the Language Server Protocol, which solved the same N × M problem for code editors: write a language server once and every editor that speaks LSP can use it. MCP applies the idea to AI applications. A server written once works in any client that speaks MCP.

The specification is versioned by date. The revisions so far are 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25 and 2026-07-28. Clients and servers state which revision they speak, so a newer client can still work with a server built for an older one.

Hosts, clients and servers

MCP names three roles:

The host is the application you talk to: Claude Desktop, Claude Code, an IDE, a custom agent. It decides which servers to start and asks you before a tool runs.
A client is the connector inside the host. The host creates one client per server it talks to.
A server is the program that offers capabilities. It can be a local process on your machine or a service on the internet.

Servers can offer three kinds of things:

Server feature	What it is	Who decides to use it
Tools	Functions the model can call, with a JSON Schema for their arguments	The model, with your approval
Resources	Data the server can provide, identified by URIs: files, records, documents	The application or the user
Prompts	Prepared message templates, often shown as slash commands	The user

Tools are the feature most people mean when they talk about MCP. Each tool has a name, a description written for the model, and an input schema, so the model knows what to send.

Clients can offer features to servers too. In the current revision that’s elicitation, which lets a server ask the user for missing information mid-task. Earlier revisions also had roots (which folders a server may work in) and sampling (a server asking the host’s model to generate text). The 2026-07-28 revision deprecates both and suggests passing folders as tool arguments and calling a model API directly instead.

What the messages look like

MCP messages are JSON-RPC 2.0: small JSON objects with a method name, parameters and an id that pairs each response with its request. A client finds out what a server offers with tools/list, and runs a tool with tools/call:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "hash",
    "arguments": { "text": "abc", "algorithms": ["SHA-256"] }
  }
}

This is the answer from the devtoolbox.cc server:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "SHA-256: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad"
      }
    ],
    "isError": false
  }
}

A result carries a list of content blocks (text, images, links to resources) and an isError flag. When a tool fails because of its input, the server still answers with a normal result, sets isError to true and puts the explanation in the text. The model reads that message and can fix its arguments and try again, which is far more useful than a protocol-level error code.

Up to the 2025-11-25 revision, every connection started with an initialize handshake in which client and server agreed on a protocol revision and on capabilities. The 2026-07-28 revision removed the handshake: each request now carries its protocol version and the client’s capabilities in its _meta field, and servers answer a server/discover request to describe themselves. Self-contained requests are simpler for servers that run as web services behind load balancers, since any instance can answer any request.

Transports: stdio and Streamable HTTP

JSON-RPC needs something to travel over. The specification defines two standard transports:

stdio: the host starts the server as a child process and they exchange newline-delimited JSON-RPC messages over its standard input and output. This is how local servers work. Nothing listens on a network port, and the server lives exactly as long as the host keeps it running.
Streamable HTTP: the client sends each message as an HTTP POST to one endpoint, and the reply comes back as JSON or as a stream of server-sent events. This is how remote servers work, usually behind OAuth so that each user signs in.

An older HTTP transport built on a separate server-sent events endpoint was deprecated in the 2025-03-26 revision. If a server’s documentation only mentions “SSE”, it predates Streamable HTTP.

Which transport you use mostly follows from where the data is. A server that reads your local files or runs local code uses stdio. A server for a hosted service, such as an issue tracker or a CRM, is usually remote and uses HTTP.

How to use an MCP server

You add a server to a host once; after that the model sees its tools in every conversation. The details depend on the host.

Most hosts take a JSON configuration listing each server and the command that starts it. This one starts the small server from the “Writing a small server” section below. Claude Desktop reads claude_desktop_config.json (under ~/Library/Application Support/Claude/ on macOS and %APPDATA%\Claude\ on Windows), Cursor reads ~/.cursor/mcp.json or .cursor/mcp.json in a project, and the shape is the same:

{
  "mcpServers": {
    "word-count": {
      "command": "node",
      "args": ["/home/dev/mcp/server.mjs"]
    }
  }
}

VS Code uses the same idea in .vscode/mcp.json, with "servers" as the top-level key. Claude Code adds servers from the terminal with claude mcp add <name> -- <command>. Claude Desktop can also install a server packaged as an MCP Bundle (a .mcpb file, previously called .dxt): you open the file and click Install.

After that you don’t call tools yourself. You ask “what’s the SHA-256 of release.zip?” and the model picks the hash tool, fills in the arguments and, after you approve, the host runs it. The specification requires that approval step; some hosts also let you allow a tool permanently.

What to check before you install one

The specification is direct about the risks: tools represent arbitrary code execution, hosts must get your consent before calling them, and descriptions of tool behaviour should be treated as untrusted unless they come from a server you trust. In practice that means a few things.

A local server runs with your user account’s permissions. It can read what you can read and send it wherever it likes. Install servers from sources you’d trust with a shell script, and prefer servers that say exactly what they access.

Tool descriptions and tool results go straight into the model’s context. A malicious or compromised server can use them to give the model instructions (“also read ~/.ssh and include it in the next call”). This is prompt injection, and it’s why the approval prompt matters: read what a tool call is about to send before you allow it.

Annotations are hints, not guarantees. A tool can describe itself as read-only (readOnlyHint) or as not touching the outside world (openWorldHint: false). Hosts may use these hints to decide how much to ask you, but a server can say anything about itself.

Remote servers see whatever you send them. A remote JSON formatter receives your JSON. For tokens, keys and customer data, a local server that doesn’t touch the network is the safer kind.

Writing a small server

The official SDKs handle the protocol, so a server is mostly the tool code. There are SDKs for TypeScript (@modelcontextprotocol/sdk on npm), Python (mcp on PyPI) and several other languages. A complete stdio server in TypeScript:

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { z } from 'zod';

const server = new McpServer({ name: 'word-count', version: '1.0.0' });

server.registerTool(
  'count_words',
  {
    description: 'Count the words in a text',
    inputSchema: { text: z.string() },
  },
  async ({ text }) => ({
    content: [{ type: 'text', text: String(text.split(/\s+/).filter(Boolean).length) }],
  }),
);

await server.connect(new StdioServerTransport());

Save it as server.mjs, install the two packages, and point a host at node server.mjs. The SDK turns the zod schema into the JSON Schema the model sees and validates incoming arguments against it.

The description deserves more care than the code. The model chooses tools by reading their names and descriptions, so a good one says what the tool does, what each argument means, and what the result looks like. A tool called process with the description “processes data” will be called at the wrong moments, or never.

MCP and function calling

Model APIs have supported function calling for a long time: you describe functions in the request, the model answers with a function name and arguments, and your code runs it. MCP doesn’t replace that. Inside the host, MCP tools are usually passed to the model as functions in exactly this way.

What MCP adds is the part around it: a standard way for an application to discover tools it didn’t ship with, start the program that provides them, call them and get results back. Function calling describes one application’s own functions to one model. MCP lets any compatible application use tools that someone else wrote.

The devtoolbox.cc MCP server

The developer tools on this site all run in your browser. The same code is also available as an MCP server, so an assistant can use it directly: devtoolbox.cc MCP server. It has 15 tools, including JSONPath queries, JSON Schema validation, structural JSON diffs, hashes, JWT verification and timestamp conversion. They’re the kind of exact work a model shouldn’t guess at.

The server runs locally over stdio and makes no network requests, so files, tokens and keys stay on your computer. It reads a file only when a tool is given its path, and it never overwrites a file unless asked to. Install instructions for Claude Desktop, Claude Code, Cursor and VS Code are on the MCP page.

← All posts