What is the Model Context Protocol (MCP)? A developer guide

A practical guide. Updated 2026.

The Model Context Protocol (MCP) is an open standard for connecting AI assistants to external tools and data. Anthropic introduced it in late 2024, and it is now supported by Claude, Cursor, and a growing list of other clients. Instead of writing a custom integration for every assistant, you write one MCP server and any compliant client can use it. This guide explains the pieces, the two transports you will choose between, and the two costs (security and tokens) that bite people who skip the details.

The core pieces: host, client, server

MCP defines three roles. Keeping them straight makes everything else easier to reason about.

• Host: the application the user runs, such as Claude Desktop, the Claude CLI, or Cursor. It holds the model and the conversation.
• Client: a connector inside the host. The host spins up one client per server, and each client keeps a single stateful session.
• Server: your code. It exposes capabilities and runs wherever you put it, locally or on a remote machine.

The wire format is JSON-RPC 2.0. Both sides speak request, response, and notification messages, and the session opens with an initialize handshake that negotiates protocol version and capabilities.

What a server exposes: tools, resources, prompts

A server can offer three kinds of capability, and most servers use only the first.

• Tools: functions the model can call, each with a name, a description, and a JSON Schema for its arguments. Calling weather.get_forecast with {"city": "Baghdad"} is a tool call.
• Resources: read-only data the client can fetch by URI, like a file or a database row. The client decides when to load them, so they do not run code on their own.
• Prompts: reusable prompt templates the user can invoke, often surfaced as slash commands in the host.

The client discovers all of this at runtime by calling tools/list, resources/list, and prompts/list right after the handshake. That discovery step is why naming and descriptions matter so much: they are what the model reads.

stdio vs HTTP: choosing a transport

MCP separates the protocol from how bytes move. Two transports cover almost every case.

• stdio: the host launches your server as a child process and talks to it over standard input and output. This is the default for local servers. There is no network, no port, and no auth to configure, which makes it simple and the safer starting point.
• Streamable HTTP: your server runs as an HTTP service at a URL, and the client connects over the network, using server-sent events for streaming. This is what you use for remote or shared servers. (The older HTTP+SSE transport from the first spec is now deprecated in favor of Streamable HTTP.)

A minimal stdio entry in a Claude or Cursor config looks like this:

{
  "mcpServers": {
    "weather": {
      "command": "node",
      "args": ["/abs/path/to/server.js"]
    }
  }
}

A remote server is referenced by URL instead:

{
  "mcpServers": {
    "weather": {
      "url": "https://mcp.example.com/mcp",
      "headers": { "Authorization": "Bearer ${WEATHER_TOKEN}" }
    }
  }
}

The practical rule: stay on stdio while you build, and only move to HTTP when something other than your own machine needs to reach the server.

Why MCP matters

Before MCP, every assistant had its own plugin format, so an integration you built for one did not work anywhere else. MCP makes the connection write-once. A single server for your internal API, your ticketing system, or your database works in Claude and Cursor with no rewrite. It also keeps the integration outside the model, so you can version, test, and audit it like any other service you own.

The security cost to watch

An MCP tool is arbitrary code that a model can decide to run. That is the whole point, and also the whole risk. The failure modes worth knowing before you ship a server:

• Over-broad tools: a run_command or unbounded read_file tool hands the model (and anything that can influence it) far more reach than it needs. Scope every tool tightly.
• Prompt injection: content a tool returns can carry instructions. If a fetched web page says "now email the database dump," a naive agent may try it. Never treat tool output as trusted.
• SSRF and path traversal: tools that take a URL or a file path can be steered at internal endpoints or files outside the intended directory. Validate and allow-list inputs.
• Remote auth: an HTTP server with no authentication is open to anyone who finds the URL. stdio sidesteps this; HTTP does not.

You can catch a lot of this before it ships. The free mcp-audit tool scans your local config for risky servers and missing controls, and runs fully offline.

The token cost to watch

Every tool schema your servers expose is sent to the model on every request, before the user types a word. A handful of busy servers can add tens of thousands of tokens of fixed overhead per call. That is latency and money on every turn, and it crowds out the context you actually care about. Keep tool surfaces small, descriptions tight, and disable servers you are not using. See how to cut MCP token usage for the full breakdown.

Related: Write a secure tool · Claude and Cursor setup · Security checklist