Who Can Reach Your MCP Server, and How You Decide

An MCP server is a door into your material. Whatever you connect to it, an AI client can ask for and receive.

That is the entire point, and it is also the reason the interesting question is not "is it secure" but something more specific: who can open this door, and what is behind it? Those are two separate decisions, you make both of them, and this post is about making them deliberately.

Start by deciding what is behind the door

Before any setting, decide what the server is for.

A server built from published documentation holds material that is already public. Anyone reading the docs site can read the same words. There is nothing to protect, and a public server is the simplest thing that works.

A server built from a private repository, an internal runbook, a contract, or an operations handbook is a different object entirely. It holds material that exists because it was not published. That server needs to be private, and the rest of this post is mostly about what private means in practice.

The useful habit is to keep those two kinds of server separate. Mixing public documentation and internal notes on one endpoint means the whole thing inherits the stricter requirement, and you lose the ability to hand the public one to anyone who asks.

What a private server actually refuses

A private server requires an access token, and the refusal happens earlier than people expect.

When a request arrives without a valid token, the server does not answer any part of it. It does not introduce itself, it does not list the tools it offers, and it does not say what its content is about. A list of tool names is itself a description of what you indexed, so a server that refuses to run a search while happily reporting that it has a tool called search_payroll_policies has not really refused anything.

A request for a server owned by another account is answered as though the server does not exist, rather than as a permission error. There is no way to confirm from the outside that a given server is there.

Tokens are scoped, revocable, and shown once

Each access token belongs to one server. A token that reaches your deployment guide cannot be pointed at your billing runbook, so handing one to a contractor grants exactly the access you intended and nothing adjacent to it.

The plaintext token is shown once, at the moment you create it, and is not recoverable afterwards. You can create several, name them for where they are used, and revoke any one of them on its own. That is what makes a token per client or per person practical: when a laptop is replaced or somebody leaves, you revoke the one token rather than rotating a shared secret and reconfiguring everyone.

Connecting a private repository sets the server private for you

If you add a private GitHub repository as a source, the server becomes private and stays that way while that source is connected.

The decision is made from GitHub's own answer about the repository, not from anything your browser sent. That distinction matters more than it sounds: if the setting were taken from the page you filled in, then a request that simply claimed the repository was public would be enough to index private code into an open server.

You cannot switch that server back to public while the private source is attached. To publish it, disconnect the private source first, which is a deliberate step rather than a toggle you can reach by accident.

Disconnecting a source removes the content, not just the link

When you disconnect a source, the indexed pages go, and so do the copies that are less obvious: the cached results of recent searches, and the stored excerpts that the analytics dashboard shows you.

Those last two are the ones worth knowing about, because they hold real text rather than a reference to it, and removing the source alone would leave them readable. The cleanup runs before the source itself disappears, so if any part of it fails, the source stays visible instead of reporting a clean removal over content that is still there.

Deleting your account stops every one of your servers answering immediately, not at the end of a grace period. The endpoints go quiet on the next request, and the account itself is removed afterwards.

Content you retrieve does not stay forever

Every request to your server is recorded so the dashboard can show you what people are asking. That record can include the question and a short excerpt of the passage that was returned.

What is kept	For how long
Question text and returned excerpts, free tier	90 days
Question text and returned excerpts, paid analytics	395 days
Request records: timing, tool used, success	395 days
Cached search results	5 minutes

On the free tier the text is removed at 90 days while the timing and usage figures stay to day 395, so your usage history survives without the questions and excerpts sitting there for a year.

The part worth knowing about links you paste

Every source starts as a URL you typed, and the server fetches it on your behalf. That is a capability worth being careful with, and it is handled at the level of the address rather than the text of it.

Before fetching, the destination is resolved and checked, and internal addresses are refused. Redirects are followed one hop at a time and each new destination is checked the same way, because a perfectly ordinary looking link that redirects somewhere internal is the normal way this kind of check gets beaten. When a redirect crosses to a different host, credentials are dropped rather than forwarded, so a token meant for one service is never handed to another.

Decide it against your own policy

Here is the short version to take to whoever owns your security requirements.

Use a public server for content that is already published. Documentation, public repositories, marketing material. The simplest setup is the right one.

Use a private server with a token per client for anything internal. Private repositories, runbooks, handbooks, contracts. Name each token where it is used so revoking one is a decision rather than an investigation.

Keep the two kinds of server apart. One endpoint per audience is easier to reason about than one endpoint with a policy attached.

Check the client as well as the server. Retrieved passages pass through whichever AI tool called you, and that tool has its own data handling. Your review covers both, and only one of them is us.

If you are evaluating MCP Studio against a formal policy, security and data handling is written for that: what is enforced, what is retained and for how long, where independent assurance currently stands, and which requirements we do not meet today. The private servers guide covers token creation and client configuration, and adding sources covers how each source type is handled.