Every MCP server you connect starts spending context before you type a word. A few earn it back with real reach into your tools. The rest sit in the window eating tokens. Here is how I decide which servers get a slot.
Connecting everything is not free
The bill arrives at session start. When your agent boots, every connected server hands over its tool list: names, descriptions, parameter schemas. All of it lands in the context window before you have asked for anything. You pay whether you call a single tool or none.
The failure mode is connecting everything. Ten servers, just in case, each one resident in every session, while the actual work touches one tool from one of them. The agent gets slower at picking tools, the window gets smaller for the work, and nothing on the dashboard tells you why.
So the question is not which servers are good. Most of them are fine at what they do. The question is which servers earn a permanent slot in your window, and that is a cost question before it is a quality question.
How to read a server's real cost
Three checks, before any list. Run them on anything you are about to connect.
Count the tools at load. Open the server's tool list and count what it registers the moment it connects. Five focused tools is a different bill than forty. A big catalog is not automatically bad, but you should know the number before it is sitting in every session.
Check whether tools defer or sit resident. The better clients now load tool schemas on demand: the server announces names, and the full schema arrives only when the agent reaches for it. If your client supports that, a wide server gets much cheaper. If everything loads resident, the whole catalog rides along all day.
Read one tool response. Call the server's most common tool once and look at what comes back. Some servers return the field you asked for. Some return the entire object graph with metadata, timestamps, and half the API surface. Chatty responses are a per-call tax on top of the per-session one, and they compound in long agent runs.
Pretty much every server sells itself on capability. None of them advertise the size of the bill. These three checks are how you read it anyway.
The servers that earn the slot
Five that hold a slot in my own stack, grouped by the job each one does. Every URL and figure below was checked on July 24, 2026, the day I drafted this. Star counts are stated as the repo pages display them. The two official hosted servers have no star count to cite, so none is invented for them.
Design handoff: Figma MCP. The official server pulls variables, components, and layout data straight into the coding agent, and the newer write tools push content back to the canvas. This is the server behind my design-to-code loop: I make the design calls in Figma, then hand the agent the connection to detail every spec and state from the file. https://developers.figma.com/docs/figma-mcp-server/
Planning layer: Notion MCP. The official hosted server, OAuth setup, reads and writes pages and databases. If your plans, briefs, and trackers live in Notion, this is the difference between an agent that works from your actual system of record and one that works from your memory of it. https://developers.notion.com/docs/mcp
Browser hands: Playwright MCP. Structured, deterministic browser control from Microsoft, 31.5k stars. The agent drives a real browser through the accessibility tree instead of screenshots, which keeps the responses lean for what browser work costs. https://github.com/microsoft/playwright-mcp
Automation routing: n8n MCP. The community server by czlonkowski, 22.3k stars. It lets the agent build and trigger n8n workflows, which makes it the bridge between agent judgment and the automations you already run. Wide tool catalog, so it benefits most from a client that defers schema loading. https://github.com/czlonkowski/n8n-mcp
Web ingestion: Firecrawl MCP. The official Firecrawl server, 7.0k stars. Scraping and search that comes back as clean markdown the agent can use directly, instead of raw HTML it has to burn tokens cleaning. https://github.com/firecrawl/firecrawl-mcp-server
Five servers, five different jobs, no overlap. That is the shape of a stack that earns its context. I have not benchmarked the exact token load of each one on every client, and anyone quoting universal numbers is guessing past their data. Run the three checks on your own client and trust that reading.
The ones that just eat the window
The skip patterns matter more than any skip list, because they apply to servers this post never names.
Servers that duplicate what the agent already does. File operations, shell commands, fetching a public web page. Your agent ships with those. A server that re-wraps them adds schema weight and a second way to do the same thing, and the agent now has to choose between them on every call.
Heavy schemas wrapped around thin APIs. If the underlying service does one thing, the server should register a few tools, not thirty variations with overlapping parameters. Catalog width should track service depth. When it does not, you are paying resident context for optionality nobody uses.
Single-tool servers that should have been a script. If the job is deterministic, the same input producing the same output with no mid-task judgment, write the script and let the agent run it. A server earns the protocol when the agent needs to decide things against it mid-task, not just execute.
The decision rule
One line, and it travels: a server earns a slot when the jobs it covers per session outweigh the context it costs per session, and it gets disconnected the week that stops being true.
Connect on demand, not by default. The slot is rented, never owned, and the rent is due at every session start.
The checklist
I keep the three checks and the skip patterns as a one-page server evaluation checklist, updated as clients change how they load schemas. It goes out with The Production Layer, my newsletter at timurtek.com, alongside the repo list that pairs with this post.
Your context window is the one resource every server bills against. Read the bill before you sign.
