Most people ask whether an MCP server is popular. Fewer ask what its tools are allowed to do once an agent connects.
I read the tool list of every MCP server I could open in the official registry, and counted what the tool descriptions say each tool does. No tool was called, anywhere.
The numbers
Registry list of 2026-10-27: 51,168 servers. I opened a live, read-only session with 25,335 of them and read the tool lists of 23,655 servers (385,096 tools).
A server is counted under every kind it has a tool of, so the rows overlap and do not add up to 23,655.
| What a tool's description says it does | Servers |
|---|---|
| reads or searches | 20,019 |
| creates or changes data | 6,437 |
| sends messages | 2,696 |
| runs code or commands | 1,540 |
| moves money (payment or financial) | 850 |
| controls a browser or desktop | 481 |
| manages infrastructure | 125 |
Looking at what each server mainly works on instead: 8,710 only answer questions and touch nothing outside themselves, 4,072 work on accounts and data in outside web services, 1,978 on files and code on the machine they run on, and 756 on money, payments or trading.
How to read these numbers
- These are an AI model's reading of each tool description, not a test. Two differently worded runs had to agree on a label, otherwise it was left out. Nobody checked the labels by hand. On my own spot checks the tool kind agreed 93.8% of the time between the two runs.
- A description is a claim by the publisher. "Moves money" means the description says so. It does not mean the tool works, or that it is safe or unsafe.
- I called no tool. Not one. Connecting only lists what the server offers.
- Not every server could be read. 25,833 of the 51,168 were not opened: 15,434 by the server's own choice (it needs a key or sign-in), 1,799 because of a defect in the package, 2,117 because of my own limits, 6,483 for a cause I could not determine. These counts say nothing about them.
Why this matters if you build agents
An agent with a payments tool and a "send message" tool in one session is a different risk from one that only searches. The registry's required fields are a name, a description and a version, so a listing alone does not tell you which of these a server has. Reading the tool list does.
A practical use: before you add a server to an agent, look up which kinds of tool it has, and give the agent only what the task needs.
Browse it yourself
Each list opens the servers with that kind of tool, each with its source and the date it was read:
- Moves money
- Runs code or commands
- Controls a browser or desktop
- Sends messages
- Any tool that changes something
Method and corrections: protocolprobe.com/methodology and protocolprobe.com/corrections. The same data is in a free API (no key) and a citable dataset: protocolprobe.com/docs/cite.
I built ProtocolProbe. If a label looks wrong to you, tell me in the comments and I will check it.
Top comments (2)
What I take from this is that a registry listing says little about blast radius, while the tool list shows which capabilities an agent would get, with 850 servers claiming a money moving tool among them. Since the labels come from descriptions, the interesting gap is between what a tool claims and what it actually does, for example a tool described as read only that still triggers a signing or approval call underneath. A small sample where the label was checked against the real behavior of the tool would show how far the descriptions can be trusted.
Agreed, and that gap is the main limit of this data. The labels are an AI reading of the publisher's description, nothing more. Two differently worded runs had to agree on a kind (93.8% agreement). A spot check by another AI, not a person, matched 131 of 149 kinds. I did not compare any label with what a tool really does, because I call no tools on servers I don't own.
One related thing I did measure, in an earlier sandbox run (2026-10-04, 80 packages, before I stopped calling tools): a few tools that a name-based check treated as read-only still made outbound network requests. So your example is real, at least for names. The only version of the check I'd run is with the server operator's consent, on their own server. npx protocolprobe-selftest does that locally; the labels on the site stay descriptions.