Methodology
Every score in this directory comes from the same 19 deterministic rules run over a server's published tools/list payload. No LLM is involved at any point, so the same surface always produces the same score, and any two people can reproduce it.
What we read, and what we never do
A scan sends exactly two MCP requests: initialize and tools/list. It never invokes a tool, never reads a resource, and never sends a real credential. Servers behind OAuth are recorded as awaiting a snapshot and are excluded from the index rather than authenticated against.
Snapshots come from one of three places, in order: a public Streamable HTTP endpoint; a locally spawned stdio process given placeholder environment variables, which is usually enough for a server to list its tools; or a snapshot file its maintainers have sent us. Where none of those work, the server keeps a page but no score.
How the score is built
Each rule belongs to one of six categories. A finding above info severity deducts that rule's weight from its category, capped per rule so one noisy check cannot empty a category. The category score is 100 − deductions, floored at zero. The composite is the unweighted mean of the six categories, which is why a surface can be excellent at naming and still score poorly overall.
Letter grades are presentation only: A is 90 and above, B is 80, C is 70, D is 60, F below that. They never feed back into the number. Every rule is documented individually, including its weight and its configurable thresholds.
Token footprint
The headline number is the serialized size of the whole tools/list array, counted with the o200k_base encoding. It is approximate: a client may reformat the payload, and different model families tokenise differently. It is still the right order of magnitude for the cost you pay on every turn, because that payload is injected into context before the user says anything.
What this does not measure
This is a static analysis of a published interface. It says nothing about whether a server is secure, whether its tools work, how fast they are, whether the vendor is reputable, or whether the surface suits your particular workflow. A high score means the surface is legible to a model. A low score means an agent is more likely to pick the wrong tool — not that the product is bad.
We also do not measure anything that requires calling a tool, because we do not call tools. Behaviour, correctness, and rate limits are all outside what a tools/list payload can tell you.
Freshness
Scans run weekly. A result is only rewritten when the tool surface or the engine version actually changed, so the date on a page is the date its content last differed — not the date a job happened to run. When a scan fails, the previous successful result stays published and the page says when it was captured.
The most recent change across the directory was 2026-09-17.
Corrections, re-scans and removal
Every server page carries a maintainer box. Use it to request a re-scan, send a corrected snapshot, or ask for the page to be taken down. Removal requests are honoured without argument and without asking why. Corrections are applied on the next scan and the page shows the new capture date.
Reproducing a score yourself
The same engine that produces these pages is on npm and runs locally:
npx mcp-surface-lint https://example.com/mcpnpx mcp-surface-lint --stdio "npx -y some-mcp-server"npx mcp-surface-lint snapshot.json --jsonRule documentation, including thresholds, lives at one page per rule.