MCP has crossed the threshold where everyone references it and a surprising number of people cannot say what it actually is. Since I ship an MCP server as part of route.tools, I have explained this enough times to have a compact version. Here it is, plus the one architectural opinion I hold strongly: you want fewer MCP servers than you think.
What MCP actually is
The Model Context Protocol is a standard for connecting LLM applications to external capabilities. An MCP client (Claude Desktop, an IDE assistant, your own agent) connects to an MCP server, asks “what can you do?”, and gets back a machine-readable list of tools with names, descriptions, and input schemas. The model can then invoke those tools, and the server executes them and returns results.
The key word is protocol. Before MCP, every agent framework had its own tool-definition format, and every tool integration was bespoke glue between one framework and one API. MCP standardizes the handshake: any compliant client can use any compliant server without either knowing about the other in advance. It is USB for model tooling, and like USB, the payoff is boring interoperability rather than any single flashy feature.
An MCP server is just a program that speaks this protocol and fronts some capability: a database, a filesystem, a SaaS product, or in our case a router across tool API providers.
Local vs remote servers
MCP servers come in two deployment shapes, and the difference matters more than the docs make it sound.
Local servers run on your machine as a subprocess, talking to the client over stdio. They are the right shape when the capability is inherently local: your filesystem, your git repos, your running Docker daemon. The costs are operational: you install them, you update them, every machine that needs the capability needs the process, and each one is software you now maintain. Config drift across a team’s laptops is real.
Remote servers are services you connect to over HTTP. Nothing to install, nothing to update, one URL and an auth token. The capability lives server-side, so it is the same capability from your laptop, your teammate’s laptop, and your production agent. For capabilities that are already remote (which is every third-party API), a local MCP server is a strange middleman: a process on your laptop whose whole job is calling someone else’s cloud.
My rule of thumb: local for local things, remote for everything else. The MCP docs cover how ours connects, and it is remote for exactly this reason: search and scraping already live in the cloud, so the server should too.
The case for fewer servers
Here is the opinion. The emerging default is one MCP server per vendor: a search server, a scraping server, a parsing server, and so on. Nine capabilities, nine servers. I think that pattern is wrong for most people, for three compounding reasons.
Context window cost. Every tool a client connects gets its tool definitions injected into the model’s context on every request. Names, descriptions, JSON schemas. Nine vendor servers, each exposing several tools with verbose schemas, can quietly eat a meaningful slice of your context before the conversation starts. That is tokens you pay for on every single model call, and context the model must attend to. Fewer, better-shaped tools are cheaper and, in my experience, get invoked more accurately: a model choosing between 9 clearly distinct tools makes better calls than one choosing among 40 overlapping ones.
Auth and configuration sprawl. Nine servers means nine keys, nine config entries, nine things to rotate and revoke, and nine failure points at startup. Anyone who has watched a client hang because one of its servers stopped responding knows this is not hypothetical. Every server you add is a dependency in the load path of every conversation.
Redundancy belongs below the protocol. If your search MCP server fronts exactly one search vendor, then when that vendor rate-limits you, your agent’s search tool is simply broken. The model cannot fail over; it just sees errors. Provider redundancy is infrastructure, and it belongs underneath the tool interface, not delegated to the model’s judgment about which of three search tools to try next.
This is the design argument behind our server: one remote MCP server exposing 9 tools, one per category (search, scrape, parse, image, video, speech, transcribe, embed, code). The model sees one clean tool per job. Underneath each tool, the router picks among providers, retries failures across up to three of them, and skips providers whose error rate crosses 30% over five minutes. The model never needs to know Serper from Brave; it asks for a web search and infrastructure handles the rest. One connection, one key, nine capabilities, roughly thirty providers behind them.
When many servers is still right
To be fair to the other pattern: if you need deep vendor-specific features that a normalized tool hides, a dedicated server for that vendor makes sense. Same if the capability is local, or if you are building a tightly-scoped agent where one vendor’s tool is the product. Consolidation wins for the general toolbelt; specialization wins at the edges. Most setups I see would do well with one consolidated server plus one or two specialists, not nine peers.
If you want to try the consolidated shape, the quickstart gets the server connected in a few minutes, and the routing docs show how to steer what happens beneath the tools.