What a score measures, how it is computed, and — as importantly — what it does not claim.
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.
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.
Every tool is read as one of read, write, send, delete or
pay, and every classification records its basis:
| declared | The server annotated the tool readOnlyHint or
destructiveHint. These annotations are written by the server being described. The MCP specification states
clients must not treat them as trusted, and neither does this index. |
| inferred | Derived from a recognised verb in the tool's name or description. |
| assumed | No annotation and no recognised verb. Recorded as a
write, the more cautious reading, and shown as assumed. |
Where a server sets both hints on one tool, the destructive reading is used.
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.
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.
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.
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.