A plain-English explainer of the Model Context Protocol — what an MCP server actually is, how it works under the hood, which clients support it today, and where it fits next to REST APIs and function-calling.
An MCP server is a small service that exposes tools (and optionally resources and prompts) to AI clients over the Model Context Protocol — an open standard, published by Anthropic in November 2024, for connecting language models to external systems.
Once an MCP server is connected to an MCP-compatible client (Claude Desktop, Cursor, Windsurf, an agent framework), the model running in that client can list the server's tools and call them during a task. The server handles the actual work — hitting a database, calling an API, reading the file system — and returns a structured result the model can reason over.
If REST APIs are how applications talk to services, MCP is how language models talk to services. The same way "USB-C" is sometimes used as a shorthand for the protocol, the point is that any compliant client can plug into any compliant server without a custom integration in between.
An MCP server is a tool-provider for AI clients. It advertises a list of callable tools over JSON-RPC 2.0, and any MCP-compatible client lets its model invoke them — no per-tool integration code required.
Before MCP, every "AI app + tool" pairing was bespoke. If you wanted Claude to read your Linear issues, ChatGPT to query your Postgres database, and Cursor to call your internal CI, you wrote three different integrations — different SDKs, different message shapes, different ways to describe arguments to the model.
MCP collapses that into one specification. Tool authors write one MCP server. Client authors implement MCP once. Anything compliant on one side talks to anything compliant on the other. The benefits stack up quickly:
tools/list and gets back self-describing tool definitions with JSON Schema input shapes.That last point matters: MCP is not a Claude-only thing. Anthropic published the spec, but it is open, model-agnostic, and adopted across multiple vendors' clients.
At its core, MCP is JSON-RPC 2.0 messages going back and forth between a host (the app the user is using — e.g. Claude Desktop), an embedded client (the host's MCP machinery), and one or more servers.
A typical session looks like this:
initialize; the server replies with its protocol version (the current spec date is 2024-11-05) and the capabilities it supports (tools, resources, prompts, sampling, etc.).tools/list. The server returns each tool's name, description and input JSON Schema.tools/call with the tool name and arguments. The server runs the operation and returns content the model can read (text, JSON, images).That is essentially the whole picture. The model never sees the JSON-RPC frames; it sees the tool catalog as available functions and the call results as content it can quote and reason over.
An MCP server can speak two transports today. stdio is for local servers — the client spawns the server as a subprocess and they exchange JSON-RPC over stdin/stdout. SSE (Server-Sent Events) is for remote servers — the client opens a long-lived HTTP connection and the server streams responses back. A newer "streamable HTTP" transport is being adopted across clients; behaviour varies by client version, so check your client's docs.
MCP adoption has moved quickly. The list below covers the most common clients at time of writing — exact feature parity (remote URL vs. stdio bridge, OAuth flows, resource support) varies by client version, so treat specifics as a starting point and confirm against your client's docs.
claude_desktop_config.json (Settings → Developer → Edit Config). Native support for both local stdio servers and, in recent versions, remote servers.~/.cursor/mcp.json or via Settings → MCP. Supports stdio and remote SSE.~/.codeium/windsurf/mcp_config.json.For all of them, the configuration shape is similar: a mcpServers map keyed by server name, with either a command + args (for stdio servers) or a remote url with optional headers (for SSE / streamable HTTP). When a client does not yet support remote URLs directly, the community mcp-remote npm helper bridges a remote SSE endpoint to stdio.
MCP is often discussed alongside REST APIs and the function-calling features of model providers (OpenAI tools, Anthropic tool use, Gemini function calling). They are related but solve different problems.
| Surface | What it is | Who's the consumer | Best for |
|---|---|---|---|
| REST API | HTTP endpoints described by docs/OpenAPI. | Application code that you write. | Backend services, batch jobs, deterministic pipelines. |
| Function-calling | Per-request "tools" array you pass to a model's chat API. | A single app talking to a single model. | One app where you control both the prompt and the tool list at request time. |
| MCP server | Standalone server that advertises tools over JSON-RPC. | Any MCP-aware AI client. | Reusable, multi-client tool packages; agentic and IDE workflows; remote tool catalogs. |
In practice they compose. A team will often have a REST API as the source of truth, an MCP server that wraps that REST API for AI clients, and function-calling tool definitions inside a custom agent that points at the same backend. MCP is the layer that makes tools portable across AI clients.
Because an MCP server can do real work — read files, send emails, charge cards — its security model matters. The spec is intentionally minimal so deployments can match their threat model; common practices in production servers include:
Authorization: Bearer <key> header, set in the client's MCP config.For example, PDF4's PDF MCP server authenticates with API keys prefixed pdfa_mcp_ — separate from web-session credentials, revocable independently, and credit-metered per key. Most remote MCP servers follow a similar pattern.
To make the abstraction concrete: PDF4's PDF MCP server is one example of a domain-specific MCP server. It speaks the standard MCP handshake at /mcp/sse, advertises PDF tools like pdf_to_markdown, ocr_pdf, extract_data and summarize_pdf via tools/list, and runs them when the client sends tools/call. Plug it into Claude, Cursor, Windsurf or n8n and the connected model can read and transform PDFs without any custom glue code. If you want to dig into how AI agents use this kind of server in practice — RAG ingestion, tool-use patterns, the matching REST API — the PDF tools & API for AI agents guide and the API docs go deeper.
MCP stands for Model Context Protocol. It is an open standard, originally published by Anthropic in November 2024, that defines a common way for AI clients (chat apps, IDEs, agent frameworks) to discover and call external tools and data sources. Instead of bespoke integrations for every tool, an AI client can speak MCP to any MCP server and get the same tool-discovery and tool-calling behaviour.
An MCP server is a service that implements the server side of the Model Context Protocol. It advertises a list of tools (and optionally resources and prompts) via JSON-RPC methods like tools/list and tools/call. An MCP-compatible client connects to the server, lists its tools, and lets the underlying language model invoke them during a task. The server can be local (stdio) or remote (SSE / streamable HTTP).
Anthropic introduced the Model Context Protocol in November 2024 as an open specification. The spec, reference servers and SDKs are published at modelcontextprotocol.io, and adoption now spans clients from multiple vendors — Claude Desktop, Cursor, Windsurf, Zed and others.
No. MCP is model-agnostic. The protocol describes how a client and a server exchange messages; the client decides which language model converts tool calls to actions. Any client that implements MCP — regardless of which model it ultimately uses — can talk to any MCP server.
Most MCP clients read a small JSON config file listing the servers to start. For a local server you typically add a command and args; for a remote server you point at its SSE URL and pass an Authorization header. After updating the config and restarting the client, the server's tools appear and the model can call them. See your client's MCP docs for the exact file location.
A REST API is a transport-and-conventions layer for HTTP endpoints; the consumer must know each endpoint, its parameters and how to call it. MCP is a meta-layer designed for language models: the server advertises tools with input schemas, and the client/model picks which one to call at runtime. They are complementary — many MCP servers wrap an existing REST API and expose it as MCP tools.
The Model Context Protocol itself is an open specification with permissively licensed SDKs and reference servers, so the protocol is free. The underlying service a specific MCP server wraps may have its own pricing — for example, a hosted PDF MCP server may meter tool calls — but that is the service's pricing, not the protocol's.
PDF4's MCP server is a working, hosted example: connect it to Claude, Cursor or Windsurf and your agent gets 30+ PDF tools the moment the client restarts.