What is an MCP server?
An MCP server is a program that exposes tools — functions an AI model can call — over the Model Context Protocol, so an agent can read your database, hit your API or drive a browser without anyone writing custom glue code for that specific pairing. It runs either as a local process on your machine or as a remote HTTP endpoint, and any MCP-speaking agent can connect to it. The reason the protocol exists is combinatorial. Before it, every agent needed a bespoke integration with every tool: N agents times M tools, all written by hand and all breaking independently. MCP turns that into N + M — a server is written once and works with anything that speaks the protocol. That's a genuinely good piece of engineering, and it explains why the ecosystem grew as fast as it did. I build token-reduction tooling, so my interest is narrower than most write-ups on this: what a server costs once it's connected. That part is almost never mentioned in the install instructions, and it's the part that shows up on your bill every month.How does an MCP server actually work?
The agent connects to the server, asks what tools it offers, and the server replies with a manifest — a machine-readable list of every tool, its parameters and its description. From then on, that manifest travels with your conversation. The flow, in order:- Connect. Over stdio for a local process, or HTTP for a remote endpoint. (SSE still works but HTTP is now the preferred remote transport.)
- Discover. The agent requests the tool list. The server returns schemas describing each tool.
- Advertise. Those schemas are placed in the model's context window — because a model cannot call a tool it hasn't been told exists.
- Call. When the model decides a tool fits, it emits a call, the server executes it, and the result comes back into the conversation.
@-mention pointing at a file, an issue, a schema) and prompts that surface as slash commands. Support varies — each server chooses what to implement — but resources in particular are worth knowing about, because pulling one specific thing is cheaper than describing a search.
What does an MCP server cost you?
Every connected server's tool definitions are re-sent to the model on every turn, so a server you never invoke still charges you for as long as it stays connected. This is structural, not a bug: it's how the model knows the tools exist. Here I have to be straight, because this is where most articles start inventing numbers. Almost no vendor publishes what their manifest costs. Third-party estimates for popular servers circulate widely and contradict each other by tens of thousands of tokens — which tells you they measured different versions under different conditions rather than establishing a fact. I won't repeat them as though they were. What you can get is scale, from what vendors do publish. GitHub's official MCP server ships 20 toolsets and exposes 56 read-only tools before you count the write ones. Every one of those tool schemas is advertised to the model on every turn unless you narrow the set. You don't need a token figure to see that a manifest of that size, re-sent across a thirty-turn session, is not a rounding error — and GitHub, to its credit, lets you cut it down (more on that below). So measure rather than guess. Two readings tell you nearly everything:- Tool count. Manifest size scales with the number of tools and how verbose their schemas are. A server exposing 40 tools is not in the same weight class as one exposing 4.
- Context before you type. Open a fresh session, check what's already occupying the window, connect the server, restart, and compare. The difference is that server's real price on your setup, at its current version.
Are MCP servers worth it, then?
Often yes — but the honest answer is that it depends on the ratio between what a server saves you and what it charges you every turn. A server earns its place when it replaces work that would otherwise cost more. A database server that answers a schema question in one call beats an agent reading six migration files to infer the same thing. A browser server that fetches clean page content beats it pulling raw HTML. In both cases the manifest cost is repaid by tokens not spent elsewhere. A server loses its place when it sits idle. The trial costs nothing; the forgetting costs on every turn, silently, forever. This is the single most common waste I see — people connect a server to try it, it works, they move on, and it quietly taxes every session for months. Two habits fix most of it. Keep servers scoped to the project that needs them rather than installed globally, and audit what's connected occasionally. If you haven't invoked a server this week, it isn't earning its manifest.Can you keep the tools without paying for the idle ones?
Yes — by deferring the manifest, so tool definitions are sent when a tool is actually called rather than pre-loaded on every turn. That's lazy MCP loading, and it's a structural fix rather than a discipline you have to remember. The manual version is hygiene: connect what this session needs, disconnect the rest, prefer project scope over global. It works, and it depends on you doing it every day — which is exactly the kind of consistency that erodes under a deadline. Tokenade closes that gap by loading MCP tool definitions lazily inside Claude Code, Cursor, Codex, Copilot and Windsurf, since the manifest problem is identical everywhere. It also compresses what noisy tools return, which is the other half of the MCP bill — a tool that answers with 8,000 tokens of JSON costs you on every subsequent turn too. It's source-available under MIT, so you can read exactly what it does to your context before trusting it with a session.How do you choose which servers to run?
Start from the task, not from the list. The ecosystem is large and most of it is irrelevant to any given project, so the useful question is "what does this repo need me to reach?" rather than "what's popular?". A short heuristic that has held up for me:- Prefer few tools over many. Ten terse tools can cost less than four with sprawling schemas, but as a first approximation, a smaller surface is a smaller bill and a smaller chance the model picks the wrong tool.
- Prefer resources over tools for read-only lookups. Referencing a specific resource pulls one thing; a tool call describes a search.
- Prefer project scope. A server that follows you into every repository is paying rent in projects that never use it.
- Re-audit after adding. The moment to check
/contextis right after connecting something, while the before-and-after is still meaningful.
.mcp.json, secrets and connection states.
What goes wrong (anti-patterns)
Installing servers globally by default. It's the convenient choice and the expensive one. Every project pays for every tool you have ever connected. Connecting a server "to try it" and never disconnecting. The cost is recurring and invisible; there's no line item that says "the server you forgot". Trusting third-party manifest-size figures. They contradict each other because they measured different versions. Measure your own — it takes two minutes. Judging a server by tool count alone. It's a proxy, not a measurement. Verbose schemas on few tools can outweigh terse schemas on many. Treating a big context window as permission. A 1M-token window doesn't make manifests free; it just removes the forcing function that used to keep you tidy. You still pay for what you put in it.Frequently asked questions
What is an MCP server in simple terms?
It's an adapter. On one side it speaks the Model Context Protocol, which any compatible AI agent understands; on the other it does something useful — queries a database, calls an API, controls a browser. Because the agent-facing side is standardised, one server works with every agent that speaks MCP, instead of needing a custom integration per pairing.Do I need an MCP server to use an AI coding agent?
No. Agents work fine with their built-in abilities — reading files, running commands, editing code. MCP servers extend that reach to systems the agent can't otherwise touch. They're an addition with a running cost, not a prerequisite, and starting with none is a perfectly reasonable default.Are MCP servers safe?
They run with whatever permissions you give them, so the honest framing is that an MCP server is code you're choosing to trust, like any dependency. Local servers run on your machine with your access; remote ones receive whatever you send them. Project-scoped configs are typically gated behind an approval prompt for exactly this reason — pulling a branch shouldn't silently wire a new server into your session.Do MCP servers work with agents other than Claude?
Yes — that's the point of a shared protocol. A server written for one host generally works in another, though hosts differ in configuration format and in which optional parts of the spec they implement (resources and prompts especially). The per-turn manifest cost carries over unchanged, which is why reducing AI coding agent token usage is agent-agnostic advice.How many MCP servers is too many?
There's no fixed number, because cost depends on schema size rather than server count. The practical test is whether you invoked each one recently. If a server hasn't been called this week, it's charging you every turn for capability you aren't using — disconnect it and reconnect when the need returns. Reconnecting takes seconds and loses nothing.What's the difference between MCP tools, resources and prompts?
Tools are functions the model calls to do something. Resources are data it references directly, usually with an@-mention, to read something specific. Prompts are pre-written workflows the server exposes as slash commands. Tools always cost manifest space; resources and prompts are optional capabilities that not every server implements.
See also:
- MCP (Model Context Protocol) — the protocol itself, in one page.
- GitHub MCP server: setup and what it costs — the heaviest common server, and how to load a slice of it.
- Claude Code MCP: how to set it up — transports, scopes,
.mcp.json, secrets. - Best Claude Code MCP servers, ranked by real cost — which ones earn their overhead.
- Lazy MCP loading — the structural fix for idle manifests.
- Token-efficient MCP tool use — cutting schema and output cost.
Ranked #1 on the Token-Harness Optimizer Leaderboard.
Tokenade ranks #1 in the Token-Harness Optimizer Leaderboard — an end-to-end benchmark of agent token optimizers measured on real coding sessions. Set it up once, it works on every prompt. Works with Claude Code, Cursor, Codex, Copilot & more.