15,465 public MCP servers, none vetted: what to check before you install one
OX Security found no marketplace vetting across 15,465 public MCP servers, so a developer's checklist for installing them safely is worth knowing.
The short version
- OX Security examined 15,465 publicly indexed MCP servers and found no marketplace vetting.
- Some servers sat on expired domains or were hosted behind consumer tunnels.
- A server's tool descriptions and results flow into the model's context, where hidden instructions can ride along.
- Advice: check the publisher, use read-only tokens, scope per project, pin versions.
- Keep human confirmation on anything irreversible, such as sending, deleting, paying or publishing.
Why it matters
Connecting an AI agent to outside tools is becoming routine, and each connection is a trust decision. The risk is not only malicious software but also text that quietly steers your agent. A short checklist and a habit of minimal permissions cover much of the danger.
What OX Security found
MCP, the Model Context Protocol, is a standard way to connect AI agents to tools and data. It has been compared to USB-C: one plug that fits everything. As dev.to reported in a post summarising the research, it caught on, and thousands of servers now exist.
This month, security firm OX Security looked at 15,465 publicly indexed MCP servers. It found that no marketplace vetted any of them. Some servers were running on domains that had expired, and some were hosted through consumer tunnels, which are ordinary services that expose a home or personal machine to the internet.
Anyone can list a server and anyone can install one. The post's author puts it bluntly: an MCP server is code your agent trusts, so adding one resembles adding a software dependency that can run commands, not installing a browser extension.
Why this is worse than a bad package
A rogue package from a code library typically does its damage when you build or run your software. A rogue MCP server gets something more valuable: the agent's attention.
The words a server uses to describe its tools are fed directly into the model's context, the text the model reads before deciding what to do. Those descriptions can carry instructions. The author's example is a description telling the model to read a private key folder and attach it to a request.
What a tool returns is also fed in. A web page or database record can hide injected text that the model may treat as a command. Meanwhile the agent making the call often already has access to your files, your terminal and your other connected tools.
The consequence is that you do not need to run anything obviously malicious. Letting the wrong words into the model's context can be enough.
Four questions before you install
The checklist starts before anything is installed:
- Who publishes it? A company running a server for its own service is a different bet from an outsider's wrapper around someone else's API.
- Is the domain still theirs? OX found expired domains, so confirm the address points to the organisation you think it does.
- What do the tool descriptions say? A description should explain the tool to a person. If it reads like orders aimed at the model, walk away.
- Local or remote? A local server runs on your computer with your own permissions. A remote one sees every piece of data you send it.
Configure for the smallest blast radius
When you set a server up, the guiding idea is least privilege: give it only the access its job needs. If a server just has to read issues in a project tracker, do not hand it a token that can delete repositories. Read-only tokens are the default choice wherever they exist.
Scope matters too. A server added for one project should live in that project's settings, not in your global configuration where every session inherits it.
Finally, keep a human in the loop for actions you cannot undo: sending, deleting, paying and publishing. The author's rule of thumb is to let reads proceed automatically but never writes.
Maintenance and the wider lesson
After installation, pin the version you reviewed. A remote server can alter its tools after you approved it, so re-read the tool list whenever it updates. Remove servers you no longer use; unused ones still add to what the model reads and to what an attacker could reach.
The author adds a smaller, personal example. Several comments on the blog this month were long, polished technical replies in another language, each linking to the same site selling an agent tool. A human rarely reads comments to the end, but an agent told to summarise the discussion would read everything.
The takeaway is that any text an agent can read counts as input, and if the agent can act on it, a stranger's text becomes a set of instructions. MCP simply widens the channel. The post's closing advice is to treat servers like dependencies: know who wrote each one, grant the narrowest access that works, and keep a human click in front of anything irreversible.
What to watch
- Whether any marketplace or registry starts vetting MCP servers.
- Whether agent tools add clearer warnings when a server's descriptions contain model-directed instructions.
Try it
Open your agent's MCP settings, list every server installed, and remove any you do not use. For the rest, check the publisher and whether the token is read-only.
Sources and links
- Reportingdev.to: the article we sourced
Liked it? Say why
Add a line for other readers.
No account needed. We never show your email. Comments with links, ads or abuse are held and not shown. Your comment shows after a quick check.
Listen to the AI Wire headlines
Listen to the AI WireListen to our daily AI shows every morning: on your commute, in the shower, wherever you are
Listen to the daily showsFirst reported by dev.to · Read the original. Written by the SI Agent News Desk from the reporting above.Written with AI from the source above. Every number is checked against the source. Spot a mistake? Corrections.
