What Is an MCP Server? How It Works, With a Real Example
An AI assistant can write you a flawless summary of a GitHub repository — as long as somebody pastes the repository into the chat first. On its own it cannot open a URL, call an API, or read a row out of your database. The model is capable. It is just sealed off from everything that changed since it was trained.
An MCP server is what breaks that seal. It is a small program that sits between an AI application and some external system, and describes what that system can do in a format the model reads at runtime. Connect one, and the assistant can fetch, filter, and act on live data instead of guessing from memory.
This guide covers what an MCP server is, how the protocol works underneath, and what one looks like doing real work. The worked example throughout is the Anysite MCP server — the one we build — so every tool name, command, and response shape below is something you can actually run.
What Is an MCP Server?
An MCP server is a program that exposes tools, data, and prompts to an AI application through the Model Context Protocol. The AI application asks the server what it can do, then calls those capabilities on demand — so one integration works across Claude, ChatGPT, Cursor, and every other MCP client.
The Model Context Protocol is an open standard, first published by Anthropic in November 2024. Its documentation describes MCP as a standard for connecting AI applications to external systems, and reaches for a hardware analogy: think of it as a USB-C port for AI applications. One shape of plug, many devices on either end.
That analogy is worth taking literally, because it explains the whole design. A USB-C port does not know what is on the other end. It negotiates: what are you, what can you do, what should I call you. An MCP server answers exactly those questions, in a schema any client can parse.
The practical consequence is that MCP servers are not written per assistant. A server built for Claude works unchanged in Cursor, in VS Code, in ChatGPT. That portability is the entire point.
Why MCP Exists
Before MCP, every pairing of an AI application and a data source needed its own integration. Ten assistants and ten data sources meant a hundred bespoke connectors, each maintained separately, each breaking separately.
Anthropic's launch announcement on 25 November 2024 named the problem plainly: models were being kept behind information silos, with every new data source demanding its own custom implementation. MCP replaces that pile of one-off connectors with a single protocol both sides already speak.
The adoption curve since then is unusual for a protocol released by one vendor:
- April 2025 — Google DeepMind's Demis Hassabis confirmed MCP support for Gemini models and SDKs.
- December 2025 — Anthropic donated MCP to the newly formed Agentic AI Foundation under the Linux Foundation, co-founded with Block and OpenAI, with AWS, Bloomberg, Cloudflare, Google, and Microsoft among the platinum members.
- At the time of that donation — more than 10,000 published MCP servers, per the Linux Foundation, and roughly 97 million monthly SDK downloads, per the protocol's own blog.
The current specification is versioned 2025-11-25 and is maintained in the open. For anyone deciding whether to build against MCP, the governance change matters more than the download count: a protocol under a neutral foundation is a protocol you can plan around.
How an MCP Server Works
The three participants
MCP defines a client-server architecture with three named roles. The architecture documentation is precise about which is which, and the terms get mixed up constantly:
| Role | What it is | Example |
|---|---|---|
| MCP host | The AI application that coordinates one or more clients | Claude Desktop, Cursor, VS Code |
| MCP client | A connector inside the host that maintains one dedicated connection | The connection object Claude Desktop creates for Anysite |
| MCP server | The program that provides the capabilities | mcp.anysite.io |
One host runs many clients — one per server. Connect Anysite and a local filesystem server to the same Claude Desktop and you have one host, two clients, two servers.
The two layers
Underneath, MCP splits into a data layer and a transport layer. The data layer is JSON-RPC 2.0: request, response, notification, plus lifecycle and capability negotiation. The transport layer is how those messages travel.
There are two transports, and the choice determines where a server can live:
- stdio — the server runs as a local process on your machine and talks over standard input and output. No network hop, no auth to configure.
- Streamable HTTP — the server runs somewhere else and talks over HTTP, with optional Server-Sent Events for streaming. This is what makes a hosted server possible, and the protocol recommends OAuth for obtaining tokens.
The three primitives
A server can expose three kinds of thing. Most servers in the wild use only the first:
- Tools — functions the model can invoke to do something: query a database, call an API, write a file.
- Resources — data the application can read for context: a file's contents, a schema, an API response.
- Prompts — reusable templates that structure an interaction, like a system prompt or a set of few-shot examples.
The sequence, step by step
Here is what actually happens between the moment you connect a server and the moment data lands in your conversation.
1. Initialize. The client sends an initialize request carrying a protocol version and its own capabilities; the server replies with its version and capabilities. If no mutually compatible version exists, the connection ends here. This is why a client from 2025 and a server from 2026 can still talk.
2. Discover. The client calls tools/list. The server returns each tool's name, human-readable title, description, and a JSON Schema for its inputs. Because this is a runtime call rather than a compile-time contract, a server can change what it offers without anyone reinstalling anything.
3. Register. The host merges tools from every connected server into one registry and hands it to the model. From the model's side there is no distinction between servers — just a set of available actions.
4. Select. Mid-conversation, the model decides a tool is needed and emits a call. This is the step the tool descriptions exist for: a vague description produces a wrong selection.
5. Execute. The client sends tools/call with the tool name and arguments matching the input schema. The server does the work — authentication, rate limits, retries, parsing — and returns a content array.
6. Return. The result goes back into the conversation as context. The model reasons over real values rather than recalled ones.
7. Stay current. If the server's tool list changes, it sends a notifications/tools/list_changed message. The client re-reads the list. No polling, no restart.
What an MCP Server Looks Like in Practice
The theory above is short. The interesting part is what a server chooses to expose, because that decision sets the ceiling on what the model can do with it.
The obvious approach is one tool per operation. Our first version did exactly that: 61 named tools, one for each endpoint. It worked, and it had two problems that got worse with scale.
First, every tool definition loads into context at the start of every conversation. Sixty-one schemas cost roughly 17,000 tokens before anyone asked a question. Second, with dozens of similarly named tools the model regularly picked the wrong one.
Version 2 inverted the design. Instead of one tool per endpoint, five meta-tools that reach every endpoint — including ones that did not exist when you connected. Startup context dropped to about 1,000 tokens, and coverage went from 61 endpoints to all of them.
| Tool | What it does |
|---|---|
discover | Lists the endpoints available for a platform and the parameters each accepts |
execute | Calls an endpoint; returns the first page of results plus a cache_key |
get_page | Pages through a cached result set without issuing a new request |
query_cache | Filters, sorts, and aggregates cached results server-side |
export_data | Downloads the full cache as JSON, CSV, or JSONL |
A full request, start to finish
Say you want the most-starred Python projects mentioning the Model Context Protocol, and you want the list in a spreadsheet. In the chat you would just ask for that. Underneath, four calls run.
Step 1 — find out what exists.
discover("github", "repos")
Returns the endpoint names and parameter schemas for GitHub repositories — /api/github/repos, /api/github/repos/search, /api/github/repos/contributors, and the rest of the 16 GitHub endpoints. The catalog is read from the live OpenAPI spec at startup, so endpoints added last week appear here without a client update.
Step 2 — fetch.
execute("github", "repos/search", {"q": "model context protocol", "sort": "stars"})
Returns the first page plus a cache_key. The complete result set is now held server-side for seven days. Note what did not happen: no GitHub token, no OAuth flow, no rate-limit headers to handle.
Step 3 — narrow it, without paying for it in context.
query_cache(cache_key,
conditions=[{"field": "language", "op": "=", "value": "Python"}],
sort_by="stars",
sort_order="desc",
limit=20
)
Twenty records come back. The rest stay in the cache. This is the difference that matters at scale: filtering 200 results down to 20 in the model's context costs you all 200; filtering them server-side costs you 20.
Step 4 — take it with you.
export_data(cache_key, "csv")
Returns a download URL, valid for the same seven days as the cache. JSON and JSONL work the same way.
Four calls, one sentence of input, and nothing about GitHub was hard-coded anywhere. Swap "github" for "reddit", "youtube", or "crunchbase" and the shape is identical — that is what the five-tool design buys.
MCP Server vs REST API: What Actually Differs
An MCP server is not a replacement for an API. It is usually a layer over one. The distinction is who reads the documentation and when.
| REST API | MCP server | |
|---|---|---|
| Who reads the docs | You do, before you write code | The model does, at runtime |
| Adding a source | New client code per service | Appears in the existing tool set |
| Where filtering happens | In your code, after the response lands | Server-side, before results reach context |
| Credentials | One key per service, held in your app | One connection, negotiated once by the host |
| Portable across AI apps | No — bespoke per assistant | Yes — any MCP client speaks it |
| Best for | Deterministic pipelines you control | Agents deciding what to fetch as they go |
The honest verdict: if you know in advance exactly which calls to make and in what order, a REST API is simpler and cheaper to reason about. If the sequence depends on what the previous answer contained, MCP is the better fit, because the decision moves to the model.
Most teams end up with both. Anysite ships the same catalog two ways — as an MCP server for agents and conversational work, and as a REST API for scheduled pipelines. Same sources, same endpoints, different interface to the same data.
Local vs Remote MCP Servers
Both are "MCP servers" — the term refers to the program that serves the capabilities, not to where it runs. But the two deployments solve different problems.
Local servers use the stdio transport and run as a process on your machine. The host launches them. They are the right answer for anything that should never leave your laptop: your filesystem, a local database, a private repository. They also serve exactly one client, since they are one process per connection.
Remote servers use Streamable HTTP and run on someone else's infrastructure. They serve many clients at once, get updated without you reinstalling, and handle credentials centrally. Anysite is a remote server for this reason: the endpoint catalog changes weekly, and nobody should have to reinstall anything to see a new source.
The trade-off is real and worth stating: a remote server means your queries reach a third party. That is a reasonable trade for public web data and a bad one for your private files. Most setups run several of each.
How to Connect an MCP Server
Three clients, three shapes of the same operation. All of them take under a minute.
Claude Desktop connects over OAuth, which means no API key ever touches a config file. Under Settings → Connectors → Add Custom Connector, paste the server URL and authorize once in the browser:
https://mcp.anysite.io/mcp
One setting is worth changing while you are there: under Settings → Capabilities → Tool access, choose "Tools already loaded" so the five meta-tools stay in context rather than being fetched per turn.
Claude Code takes a single command:
claude mcp add --transport sse anysite \
"https://api.anysite.io/mcp/direct?api_key=YOUR_KEY"
Then claude mcp list confirms the server is connected.
Cursor takes a config block in ~/.cursor/config.json:
{
"mcpServers": {
"anysite": {
"url": "https://api.anysite.io/mcp/direct?api_key=YOUR_KEY",
"transport": "sse"
}
}
}
Type /mcp in Cursor and the tools appear. Any client implementing MCP over SSE works the same way — including no-code runners like n8n, where the automation canvas is the client.
To confirm a connection is live in any of them, ask the assistant what MCP tools it currently has. If discover, execute, get_page, query_cache, and export_data come back, you are connected.
Frequently Asked Questions
What does an MCP server do?
An MCP server does two things: it publishes a list of capabilities the AI application can read at runtime, and it executes those capabilities when the model asks. Everything else — authentication, rate limits, pagination, parsing — happens inside the server, so the model only ever sees a named tool and a typed result.
How does an MCP server work under the hood?
It speaks JSON-RPC 2.0 over either standard input/output or HTTP. The client opens with an initialize request to negotiate protocol version and capabilities, calls tools/list to discover what exists, then calls tools/call to run one. The server can also push a notification when its tool list changes, and the client re-reads it.
What is an MCP server used for in AI?
Anything the model cannot do from memory: reading live web data, querying a database, filing a ticket, running a build. The Anysite MCP server is used for the first of those — it gives an assistant on-demand access to 400+ sources and 2,000+ endpoints, from repositories and reviews to filings and social posts.
Do I have to build my own MCP server?
Only if you are exposing your own internal system. For public and third-party data, connecting an existing server is faster and there is nothing to maintain. Building your own makes sense when the data lives behind your firewall or the actions are specific to your product.
Is an MCP server the same as an API?
No. An API is the underlying interface; an MCP server is a runtime wrapper that makes one or many APIs discoverable and callable by a model. Anysite ships both — the same catalog is available as an MCP server for agents and as a REST API for pipelines you write yourself.
What does an MCP server cost?
Open-source servers you run locally cost only the compute. Hosted servers usually charge for the data behind them. Anysite MCP plans are flat, starting at $30 a month for every tool and every source, with a 7-day free trial and no per-request meter.
The Short Version
An MCP server turns a model that can only reason about its training data into one that can go and look. The protocol handles discovery, so the model finds out what is available at runtime instead of being told in advance; the server handles credentials, pagination, and parsing, so none of that reaches the conversation.
That design is now under neutral governance at the Linux Foundation, with more than 10,000 published servers behind it. Whatever you connect, the integration you write once keeps working across clients.
If the system you want to reach is live web data — repositories, marketplaces, reviews, filings, business profiles, social posts — the Anysite MCP server covers 400+ sources and 2,000+ endpoints through those five tools, on flat plans from $30 a month. Connect it in about a minute and ask your assistant for something it could not answer yesterday.
Start for free — 7-day trial, full plan access.