For server operators
If you run an MCP server
What your server’s page shows and where each fact comes from, how to tell us when something is wrong, and what we never do.
What this site is, and what it is not
ProtocolProbe is a free directory of MCP server facts. Every server in the official MCP registry has a page of facts read from public records, each with its source and the date we checked it. It is not a security rating, and we do not publish security-check outcomes for named servers. We call no server’s tools for anything shown on this site (the one dated exception, a check of our self-test command, is described on the security page).
Your server’s page
Its address is /mcp/servers/<namespace>/<name>, under the exact registry name. What it shows, and where each fact comes from:
- The registry entry (official MCP registry): name, description, version, status, where it runs (a package, a remote address or both) and the repository link.
- The package (npm or PyPI): its licence, whether the version the registry lists exists and is not withdrawn, downloads, and an npm build attestation.
- The repository (GitHub): whether the link opens, stars, the last push, whether it is archived, and a SECURITY.md.
- Known advisories (OSV.dev, npm audit): in the listed version and in its resolved dependency tree.
- The tool list, for servers we opened in a read-only session: the tools it declares, in the publisher’s own words. No tool was called. Some labels, such as the topic or what a tool does, are an AI model’s reading, marked as such; nobody has checked them by hand.
Every fact on the page shows the date it was checked.
How it is kept current: a daily job pulls the registry list and records what changed on Changes. For servers that are new or have a new version, it reads their npm or PyPI, OSV and GitHub facts and updates their pages the same day. It also corrects a registry status or status message that changed without a new version (for example, an entry marked deprecated). A few parts for those servers (the topic and pricing, the AI reading of the tool list, and the tool list of a package) need a separate, larger job that we start by hand; until it has added them, the page marks them as pending. Download counts, stars and other facts of servers that did not change are read again in a fuller refresh; the most recent one is dated 2026-10-24 (fact re-checks).
If something is wrong
Write to hello@protocolprobe.com. The link opens an email with the subject Server page: <namespace/name> and a short template:
Server name (namespace/name):
What is wrong:
A public link that shows it: What happens next: we re-check the fact from the public record. A confirmed mistake on our side is fixed and listed in the corrections log.
Our facts come from public records, so a fact that is wrong at the source is changed at the source, and our page follows after we next read it. For a registry entry, the registry’s documentation says that published metadata cannot be changed and that a new version updates it (Versioning published MCP servers); the daily job reads new versions. For npm, PyPI or GitHub, change the package or repository itself.
README badge
Each server page has a badge for your README in its Sources and corrections section, with the Markdown to paste. It shows the server’s record-check count, for example 7 of 8 record checks met: facts from public records, no tool called. It is not a security rating or a pass. It links to the server’s page and updates after each data reload. How the count works: record checks.
Record checks
Nine yes-or-no questions answered from public records only (how each one is answered). Met and not met are counted; a check that does not apply, or that our lookup could not read, is listed and never counted. On a server page, each check that is not met shows a line, What changes this check, with what the check reads or what the official documentation says changes it, and one link to that documentation where there is one.
Run the checks yourself
npx protocolprobe-selftest --i-own-this-server --stdio node ./your-server.jsThe self-test command runs the checks in our test engine against a server you run yourself: one started by a command on your machine, or your own Streamable HTTP server at a URL, after a one-time proof that you control that exact URL (--url). It prints what it finds. Results stay on your computer: nothing is sent to us, and there is no account. In CI, --fail-on-finding fails the job (exit code 5) when a check needs attention, and --sarif writes a SARIF 2.1.0 file, the format GitHub code scanning reads (in CI).
What we never do
- Call a server’s tools for anything shown on this site.
- Publish a security-check outcome for a named server.
- Paying us does not change a listing, a record check, a ranking or its order. Rankings come from public numbers (downloads, stars, record checks) the same way for every server.
- Anything paid is labelled as paid, and kept apart from the facts.
The rules are on the methodology page and apply to everyone; mistakes go in the corrections log. More on the About page.
Money and independence
Today the site has no ads, no sponsors and no paid placements, and it asks nothing of its users. If we add income later, it would come from sources like clearly labelled advertising, sponsorship of the newsletter, or services for server publishers, never from the people who read the directory.
We will update the About page, and the privacy and terms pages, before any of that changes.
Who runs it
ProtocolProbe is run by Team Sultan, a small independent team. You can reach us at hello@protocolprobe.com.