Product 1 Aug 2026 · 5 min read

What is an MCP server, and what can it actually reach?

The protocol is small and the explanations are long. Here is the whole idea, plus the half most write-ups skip: what installing one gives it access to, and how to find that out before you do.

MR mcprush team · The people who run the gateway

A model can write a convincing paragraph about your database and cannot read a row of it. MCP — the Model Context Protocol — is the wire between the two: a server declares a list of tools, the client shows that list to the model, and when the model picks one the client sends the call and puts the answer back into the conversation. That is the whole of it. Everything else written about MCP is a consequence of those three sentences.

Which is why "what is MCP" is the least interesting question in the room. The interesting one is what does this particular server get to touch once I install it — and the protocol has remarkably little to say about that.

The shape of one call

Before anything else, it helps to see where a call goes and who is standing in the middle of it. A local server is your client talking to a process on your own machine. A remote one has somebody in between — a gateway — and what that somebody does is the difference between an integration you can audit and one you cannot.

The same call, both shapes. The dashed path is a local server: no hop, and nowhere for a log, a ceiling or a revocation to live.

Nothing in the protocol requires the middle box, and plenty of good setups do not have one. But every capability people ask for after their fifth install — "which of these did what last week", "stop this loop before it costs anything", "revoke this one integration without rotating everything" — lives in that box or lives nowhere.

A server is a list of tools, and a tool is a promise

When a client connects, the server answers with its tools. Each one carries a name, a description the model reads, a schema for the arguments, and — in practice, not in the specification — a reach: the set of things in the world it can touch.

A tool called search_docs reads. A tool called create_issue writes to something outside the conversation. The protocol does not distinguish between them. There is no field for it, no flag, and no convention that survives contact with two different publishers. Nothing in an MCP handshake tells you which of the tools you just granted can send an email.

A middling server, split by reach. Six tools, and two of them decide the entire risk of the install.

The protocol tells you what a server offers. It has never told you what accepting the offer costs.

That gap is the single most useful thing to understand about MCP. Whatever you install from, the surface should be readable before you install rather than after. Where it is not published, you are being asked to trust something you cannot see — and that is a fair thing to hold against it, whoever is publishing.

Where it runs changes what is possible

Two shapes, and they are not variations on one thing:

Local. The client starts the server as a process on your machine and talks to it over stdio. It runs as you, with your files, your environment variables and your network. There is no hop and no third party — and no gateway either, which means no call log, no allowance, and no honest way for anybody to sell you a subscription to it.
Remote. The server runs on its publisher’s infrastructure and the client reaches it over HTTP. Somebody has to hold the credential, count the calls, and decide what happens when a key leaks. That somebody is either you or a gateway.

The performance gap between them is real and smaller than people expect: a local process saves you a network hop, and the thing you are usually waiting for is the upstream API the server itself calls. Which server you picked matters more than where it runs.

What installing one actually does

Strip away the wrapper and every install is the same three steps: write an entry into a JSON file your client reads, obtain a credential if the server needs one, and — for a remote server behind a gateway — record which account the calls belong to. The first step is the one people picture. The second is the one that goes wrong.

npx mcprush@latest add <server>
npx mcprush@latest add <server> --client cursor

One shape of it. Every catalogue and every client has its own wrapper around the same three steps.

The credential is worth being precise about, because "connect your GitHub" hides arrangements that are nothing like each other:

Three ways to hold the same grant, and three very different answers to “what happens when this leaks”.

Written out as a table, the four arrangements differ in exactly one column, and it is the last one:

What you granted	Where the secret lives	Revoking it means
OAuth, brokered by a gateway	With the gateway, never on your disk	Revoke one integration; nothing else changes
OAuth, held by the client	In the client’s own store, per machine	Revoke per machine, and remember every machine
An API key in a config file	On disk, and in whatever syncs that file	Rotate the key, then find everything using it
Nothing at all	—	Uninstall

The third row is where the incidents are, and not because API keys are bad — because a long-lived secret in a file ends up in more places than the person who pasted it can name.

That is the arrangement. The sequence is the other half — what happens between typing the command and the first call working:

The four steps, and the one of them that fails without saying so.

The grant is the step worth slowing down on. It happens once, in a browser tab, and what it leaves behind is either a token somebody else holds on your behalf or a secret sitting in a file on your disk — and the file is the version that turns up in a backup two years later.

What actually lands in your client’s config, and which line decides what a leak costs.

The version you read is not the version you will run

This is the part almost nobody checks. You install a server, you read its tools, you are satisfied. Six weeks later the publisher ships a release that adds a tool — and unless something stands between you and that release, the new tool is simply live in your agent’s hands.

Ask what your setup does here. The honest answers are "nothing" for a plain client config, and "the install has to accept the new capability before it can be used" for a gateway that gates releases. There is no middle option where it works out on its own.

Four things worth checking, in order

Which tools write. Read the reach, not the description. A description is marketing copy that the model happens to obey.
Where it runs. Local means it runs as you, with everything you have. That is fine, and it is not nothing.
Who holds the credential. Brokered OAuth, a key on your disk, or nothing at all — and if it is a key, where that file gets synced.
What happens on the next release. If the answer is "it just starts working", you approved a publisher rather than a capability.

None of those four are in the protocol, and all four decide what a bad afternoon looks like. Any catalogue, registry or README worth installing from should answer them without you having to ask.