Methodology

What a score measures, how it is computed, and — as importantly — what it does not claim.

What is measured

Each score is computed from one input: the server's response to the MCP tools/list request. No tool is ever invoked. Nothing is inferred from source code, documentation or runtime behaviour.

This means a score describes declared capability. It says what a server tells clients it can do. It does not say what the server actually does, whether it does it well, or whether it has ever caused harm.

Why most servers score as they do

The MCP specification provides no field in which a server can declare a cap, an expiry, a revocation mechanism or an audit requirement for a tool. A tool is either exposed or it is not. As a result, every tool on every server is recorded as uncapped, non-expiring, unrevocable and unlogged. This is a property of the protocol, not a judgement about any particular server's authors. Where a finding applies to every tool, its page says so.

How each tool is classified

Every tool is read as one of read, write, send, delete or pay, and every classification records its basis:

Where a server sets both hints on one tool, the destructive reading is used.

Destructive is not irreversible. In MCP, destructiveHint marks a tool that may make destructive changes rather than only additive ones — an update that overwrites, for instance. It does not say the change cannot be undone. A tool read from that annotation is shown as destructive, and its issue says it was annotated destructive, never that it is irreversible. For scoring it carries the same weight as a delete, which is the cautious reading.

Money. A tool is read as pay when its name or description refers to moving money — a charge, refund, payment, payout, purchase or withdrawal — and its name does not begin with a lookup verb such as get, list or search. That second condition is what keeps list_refunds and get_payment reading as lookups rather than as money moving. Money is checked before annotations: a tool named refund_order that declares itself read-only is still read as pay, and the page says the annotation was not trusted over its name. Indexing a server's money actions describes what its agent can do; the index itself holds, moves and settles no money.

Known limitation. The delete class covers removal-like verbs — archive, close, cancel, remove, revoke — and not all of those are permanent. An archived channel can usually be restored. The index therefore errs toward overstating irreversibility rather than understating it. A maintainer who believes a specific tool is misclassified can dispute it through the right of reply below, and the correction is published with the record.

Known limitation — money. The money rule reads words, not intent, and errs in both directions. It overstates: update_payment_method is read as pay though changing a card on file moves nothing, and charge_battery is read as pay though it concerns electricity. It understates: a paid subscription created by subscribe_user is not recognised, because "subscribe" names a newsletter as often as a plan. Maintainers can correct a misreading through the right of reply.

How the score is computed

Each tool contributes an action weight — read 0.15, write 0.5, send 1.2, delete 1.5, pay 2.0 — multiplied by the fraction of applicable controls it lacks (cap, expiry, revocation, audit trail, human approval for irreversible actions, and a dollar limit for money actions — a cap on the number of payments does not bound their amount). These are summed into a mass m, and:

exposure = round( 100 × (1 − e^{−m / 8}) )

The curve rises with dangerous, ungoverned capability and flattens as it grows, so that a very large server cannot pin the scale and servers of different sizes can still be compared. A server whose every tool is fully governed scores zero regardless of how many tools it has.

Bands are descriptive: Low exposure below 15, Moderate 15–39, Elevated 40–69, High exposure 70 and above.

Stack blast radius

The stack check looks at the servers in one config together. A tool counts as bringing outside content in when its name contains one of these words, as a whole word part: fetch browse browser scrape crawl navigate webpage web_search search_web read_url get_url open_url url_content page_content read_email get_email list_emails search_emails read_inbox rss. Only names are read, because a name is what a server declares. The tools it could reach are those classified above as send, delete or move money. When a config has both, the check lists both sides; it does not claim any particular tool will be misused.

What a score is not

Not a certification. Not a penetration test. Not a vulnerability report. Not a statement that software is safe or unsafe, and not an estimate of the likelihood that anything goes wrong. Two servers with the same score can differ enormously in how carefully they are built.

Where records come from

Every server in the official MCP registry is read once a week. A server with a public endpoint is asked, without signing in, to list its tools: a handshake and one tools/list request, one host at a time. A server that ships only as a package is read by running the exact version the registry names in an isolated container — no network, a read-only file system, no privileges and only placeholder credentials — and asking it the same question. npm packages are installed with their install scripts disabled, PyPI packages from prebuilt wheels only, and container images are pinned to the digest their tag resolved to. A given package version is read once, and again when a new version is published. Each page states which of these produced its record.

Some PyPI servers were written for an earlier major version of the MCP SDK and stop before listing their tools when installed against the current one. Such a package is tried once more with the SDK held at the earlier version, and its page says so.

An endpoint that does not list its tools is not scored. What it returned instead, and the date that began, is recorded on the unanswered ledger; most ask for sign-in. The date a server was first listed is the date the registry published it, as the index first recorded it, and is not revised afterwards. The date on a server's page is the date its current manifest was first recorded: it stays the same through every later check and moves only when the manifest changes, at which point the earlier record is kept in the page's history.

Which servers a page names

The homepage names the hundred servers with the highest declared exposure, and the directory lists every server in the same order. New this week lists servers first listed in the last seven days, newest first and then by declared exposure, and names at most three per publisher so that one publisher registering many servers cannot fill it; the rest are counted on the page and have their own pages. These rules apply to every publisher alike.

The index as data

Every listing is also published as index.json: the slug, name, exposure score, band, declared tool counts by action, and the endpoints, packages and container images each record was retrieved from. It is the same data these pages are built from, so a tool on your own machine can match a server it sees locally to its listing without scraping a page. Changes are in the changelog feed, newly registered servers in the new-server feed, and every endpoint that did not list its tools in unanswered.json.

Right of reply

Anyone maintaining a listed server can submit its current tools/list response. It is re-scored and dated. Corrections are published alongside the original record rather than replacing it, so the history stays readable.