Is this MCP server safe? How to check before you connect.

The Model Context Protocol (MCP) lets an AI agent call tools and data through servers. A server can read files, query a database, send a message or move money, with whatever access you give it. The specification is plain about it: tools represent arbitrary code execution and must be treated with caution, and a person should understand what each tool does before allowing it (Security and Trust & Safety ↗).

There are a lot of servers to choose from. Marklode counted the official public MCP registry and found 45,156 distinct servers. 13,383 of them, 29.6%, list no public source repository. That does not make them unsafe. It means that for almost three in ten of the servers in the registry, you can’t read the code before you run it.

Source · Marklode MCP registry census, October 2026 recount · as of 2026-10-17 VERIFIED

1. Check A Can you read the source?

   Find the source repository the registry listing names and open it. Then check that the package or image you are about to install is built from that repository, under the same name and publisher. Code you can read is not proven safe, but code you can’t read can’t be checked at all.

   Look for

   • A repository named in the listing, and a package that points back to it.
   • A licence, a README that says what each tool does, and readable code for the tools you will use.

   Warning signs

   • No repository, or one that holds nothing but a README.
   • A package name close to a well-known server’s, from a different publisher.

2. Check B Who keeps it, and are they still keeping it?

   A registry name starts with the publisher’s namespace, then a slash, then the server. Ask whether that namespace belongs to the people whose service the server connects to, or to someone else. Then look at the repository’s recent commits and releases, how issues are answered, and whether it says how to report a vulnerability.

   Look for

   • A publisher you can tie to a person or organisation that answers for the code.
   • Recent releases, answered issues and a security policy.

   Warning signs

   • A server for a company’s product, published under a namespace that has nothing to do with that company.
   • A repository nobody has touched in a long time, with security reports left unanswered.

3. Check C What can it reach?

   Read the tool list and mark every tool that writes, deletes, sends or pays. A local server runs on your machine with the same privileges as the client that launched it, so it can usually reach whatever you can. The specification recommends running local servers in a sandbox, with restricted access to the file system and the network, and granting more when it is needed and not before (local MCP server compromise ↗).

   Look for

   • Tools that do one job each, with plain descriptions.
   • A way to run it in a container, or to limit it to one folder or one account.

   Warning signs

   • A tool that runs any shell command, or reads any file, with no way to narrow it.
   • A description that says a tool just reads while its code writes. The specification tells clients to treat tool annotations as untrusted unless the server is trusted (Tools ↗).

4. Check D How does it talk to your agent?

   The specification defines two standard transports (Transports ↗). With stdio, your client launches the server as a program on your machine: what matters is the exact command it will run, which a client offering one-click setup must show you in full before it runs it. With Streamable HTTP, the server is a network service: it should use HTTPS and authenticate every connection, and one running on your own machine should listen on localhost and check the Origin header of each request, which stops a web page from reaching it through DNS rebinding (Streamable HTTP, security ↗).

   Look for

   • A launch command you can read end to end, with a named version.
   • For a remote server: HTTPS and a proper sign-in, never an open endpoint.

   Warning signs

   • A setup command that chains other commands, pipes a download into a shell, or asks for administrator rights.
   • A local HTTP server listening on every network interface, or one that still uses the older HTTP+SSE transport, which the specification has deprecated.

5. Check E Which permissions and tokens does it ask for?

   A stdio server usually takes its credentials from environment variables; a remote server should use the OAuth flow the specification describes (Authorization ↗). Either way, give it its own credential with the narrowest scope that does the job. A server must not accept tokens that were not issued for it, and must not pass a client’s token on to another service; access tokens never go in a URL.

   Look for

   • A short, specific list of scopes, with more asked for when a tool needs it.
   • A key you can create just for this server, and revoke without breaking anything else.

   Warning signs

   • Wildcard or full-access scopes requested up front.
   • Instructions to paste your personal admin token, or to put a token in a query string or a tool argument.

6. Check F Will you run the same version tomorrow?

   Install a named version, or a container image by its digest, and write it down. A launch command with no version can pick up a different release the next time it starts, and you would be running code nobody has checked. A server’s tool list can also change while you are connected (Tools ↗), so treat a new or changed tool as a new review.

   Look for

   • Tagged releases with notes, and a changelog you can read before you upgrade.
   • A pinned version in your client’s configuration, for example package@<version>.

   Warning signs

   • Setup that tells you to always run the latest.
   • A release that adds tools or permissions with no note saying why.

Alongside the six checks, it helps to know what the registry says. Type the server’s registry name into Marklode’s checker. It looks the name up in Marklode’s index of the official MCP registry and answers from the listing: whether the server is there, who published it, whether the listing names a source repository, and a score built from those facts.

Real, there, means listed. It is not a verdict on the code: a listed server can still be careless or hostile, and an unlisted one can be fine. The checker answers part of checks A and B for you; the rest is yours.

• They can’t prove a server is safe. Open-source code can be hostile, and a well-kept project can ship a compromised release.
• They can’t see what happens after you connect. A server that passed every check can still return text that tries to steer your agent, which is why the specification tells clients to validate tool results before passing them to the model (Tools ↗).
• Marklode’s checker and the census cover the official public MCP registry and nothing else, so a server listed somewhere else won’t be found there. The six checks still apply to it.
• They don’t replace a gate. For any action that can’t be taken back, put a person or a rule in front of it: see human approval in the checklist, and how to stop an agent doing something twice.

1. MCP specification, revision 2026-07-28: Security and Trust & Safety ↗
2. MCP specification: security guidance (local server compromise, token passthrough, scope minimisation) ↗
3. MCP specification: Transports ↗
4. MCP specification: Streamable HTTP, security ↗
5. MCP specification: Authorization ↗
6. MCP specification: Tools ↗
7. The MCP registry census and Field Note 03, on what the count does and doesn’t say