State of MCP server security, September 2026

Key findings

Most MCP servers are fine. The problem is concentrated in one place: remote servers that leave their tools open. A package runs on your machine with your permissions, so its code matters most. A remote server runs on someone else's, so who can call it matters most, and that is where the grades fall.

Grades

Every server is graded A to F on six public components: code, live reliability, tool poisoning, sign-in, maintenance and publisher identity (the rubric). Any critical finding is an F.

• AGrade A3,603 · 57%
• BGrade B1,404 · 22%
• CGrade C1,194 · 19%
• DD (hidden from default search)62 · 1.0%
• FF (blocked at the gateway)70 · 1%

Remote servers and sign-in

4,472 of the graded servers have a remote endpoint, run by 1,944 publishers. We connected to each one the way any MCP client does, asked for its tool list, and never called a tool. By listing:

• Open, lists write tools686 · 15%
• Open, read-only tools2,545 · 57%
• API key in a header248 · 6%
• Other sign-in enforced164 · 4%
• OAuth752 · 17%
• Did not answer77 · 2%

Counted by listing, the registry is lopsided: 2 publishers account for 2,032 of the 4,472 remote listings, mostly near-identical servers. That is why the headline counts publishers, each once: 371 of 1,944 have at least one open endpoint with write tools.

"Write tools" means a tool whose name says it creates, sends, updates, deletes, posts, pays, runs or deploys something, or whose description opens with that action. An open endpoint that lists one lets anyone with the URL use it the way your agent does. Some of these servers check a key inside each call, and some are public on purpose, like demos. The number describes what anyone can see from outside, not abuse we observed.

What's in the packages

For 1,809 servers we downloaded the published npm or PyPI package and read the code with pattern rules. We never ran it. 45 packages (2%) have at least one high-risk pattern.

• eval / new Function used150 · 8%
• npm install lifecycle script present55 · 3%
• subprocess with shell=True46 · 3%
• Shell command built from a string (injection risk)44 · 2%
• Heavily hex-escaped string (obfuscation)6 · 0.3%
• Network call to a raw IP address2 · 0.1%

A pattern is a signal, not proof. eval inside a bundled library counts the same as eval in the server's own code, and a shell command built from a string is only dangerous when a tool argument reaches it. That is why every finding on a server's safety page shows its evidence.

Secrets and tool poisoning

Secrets. 2 servers publish a Google API key in shipped code, and both look like keys meant to be public (a Firebase web key and a browser key that Chrome DevTools ships). That rule counts as medium and asks the publisher to check the key's restrictions. No AWS, GitHub, OpenAI, Stripe, Slack or private keys turned up in shipped code.

Tool poisoning. We checked the tool descriptions of 3,337 servers for instructions aimed at the model: override phrases, hidden instruction blocks, "don't tell the user", requests to read credential files or send your data to an outside URL. None were flagged. Separately, 261 servers have a tool description over 2,000 characters, which is where hidden instructions tend to live.

What we got wrong first. Our first pass flagged 19 servers in these two checks. 18 were false alarms: redaction code that contains sample keys, PEM parsers that look for a key header, placeholders like <secret>, and security tools that quote "ignore previous instructions" to detect it. The last one was a public-style Google key, which is why that rule is now medium. Three more false alarms turned up in servers scanned later (a description of companies that "act as a platform", Persian text that needs a joiner character, and a security tool's test corpus) and were fixed the same way. Each case is now a test, and every affected server was regraded before publishing. We also tightened what counts as a write tool after "pay-per-call" in a search tool's description was read as a payment.

The code rules got the same treatment. SQLite's db.exec is not a shell, copying the environment to start a child process is not dumping it, an install hint printed for the user is not curl | sh, and a private IP address is not a hidden host. A command built only from a process id cannot be injected, and a pattern quoted in a comment, a type file or a security tool's own rules is not the pattern running. That took the packages with a high-risk pattern from 1 in 9 in the first pass to 1 in 40.

Packages vs remote

Remote-only servers roughly match packages on A grades, but far more of them land at C (25% against 10% for npm packages), almost always because of sign-in. Counted by listing, so the two bulk publishers weigh heavily in the remote rows.

By category

Categories with at least 40 graded servers. Each name links to the ranked list.

What to do

If you pick servers for a team

• Prefer remote servers with OAuth. With an open endpoint, assume anyone with the URL has the same tools you do.
• Read the safety page before you add a server. It lists every finding with its evidence: search any server.
• Keep write tools behind approval in your client, and pin package versions so a new release is a decision, not an update.

If you publish a server

• Put OAuth or at least an API key in front of any tool that changes something.
• Keep tool descriptions short and plain. Long descriptions look like hiding places.
• List your source repository. 1,155 servers don't, and nobody can check what they can't see.
• Find your listing, read your findings, and add the grade badge to your README. Fix something and it is rescanned on your next release.

Method and limits

• Source. Every server in the official MCP registry: 33,192 listings. 6,333 were graded when these numbers were taken. The scan queue takes the newest listings first, so this is the most recently published slice of the registry, not a random sample.
• When. The latest scan of each server, all taken on 19 September 2026 with scanner 0.1.5 to 0.1.9. The later versions only remove false alarms, and every server they touched was rescanned.
• Remote endpoints. One initialize and one tools/list, as any client sends. No tool was called and nothing was written anywhere.
• Packages. Downloaded from npm or PyPI and read as text. Never installed, never run.
• Automated. Every number here comes from rules, not people. Rules have false positives, so each finding is published with its evidence and any grade can be appealed.
• Independent. No grade, ranking or badge on mcp.market is for sale.

Use this data

Quote any number on this page, with a link back to it. Suggested citation: mcp.market, "State of MCP server security, September 2026", mcp.market/research/state-of-mcp-security-september-2026.