An MCP tool definition is not documentation. It is text the client hands to a model as trusted instruction: the tool name, the description, the input schema. A server can pass review with a harmless description on Monday and add one sentence on Friday. That is why scanners exist, and why a public log of what each server advertised is useful.
HISTOR is one such log. It reads the tool list of every remote MCP server in the official registry, pins a digest, and publishes a weekly open dataset. The tool text is then run through WARDEN, a static scanner with a two-tier rule table: block means "no plausible benign reading in a tool definition", and advise means "legitimately appears in honest tool definitions" — reported, never blocking.
We pulled the 2026-11-09 snapshot to see what the tiers actually catch at registry scale.
| Measure | Value |
|---|---|
| listed servers in the snapshot | 103,271 |
| tools across them | 985,200 |
servers answering ok on the last probe | 37,146 (36.0%) |
| servers with ≥1 block finding | 1,085 (1.1%) |
… of which are live (ok) | 572 (1.5% of live servers) |
| tools on those live blocked servers | 51,655 (7.6% of tools on live servers) |
| servers with ≥1 advise finding | 21,298 (20.6%) |
| servers with exactly one block finding | 615 (371 of them live) |
Two things stand out. The block tier is rare — about one server in ninety-five, and one in sixty-five among live servers. The advisory tier is normal — one server in five. That split is the whole design: a rule that blocked on a credential noun as a schema field would refuse one server in five and be switched off, so it reports instead.
The block tier also concentrates. 1,085 servers carry the blocks, but the tools on just the live ones are 7.6% of every tool a client could be reading. Blocks are not spread thin; they sit on large, mostly crypto-and-infrastructure toolkits. Ranked by count, the top of the list is wallet, SSH, cipher and signing servers — a category where asking for a key is the point of some tools and never the point of a well-designed one. A rough keyword pass over name and description (wallet, key, sign, seed, crypto, ssh, cipher, vault, encrypt) matches 22% of the blocked set; the rest are ordinary tools with an unlucky sentence.
A block-tier finding is not a verdict of malice. It says: this definition contains a pattern with no benign reading. At registry scale that sentence fails in two directions, and we have hit both in the last two days.
One rule blocks on \bseed[_\s-]?phrase\b|\bmnemonic\b. In EVM terminology a mnemonic is the opcode's human name — PUSH1, MLOAD. Our opcode lookup tool described itself as returning "hex, mnemonic and description", which is the standard phrasing, and it was blocked. Rewording it to "opcode name" cleared it. A disassembler in the registry that says the same thing today is still blocked, and so is a BIP-39 tool that legitimately computes checksums.
The guards in that scanner are real and specific — a match is exempted when it is quoted, in an enum of an output schema, or part of a longer hyphenated identifier. A bare output noun in "returns A, B and C" is none of those. We reproduced it against the published package, wrote the four cases up, and filed alexar76/warden#14 upstream.
The second block on our own server was not a false positive. One of our endpoints declared a wallet private key as a call input — the caller was meant to send the key so the service could sign for them. That is exactly the pattern the rule exists to catch, and it is a design mistake: the key travels over the wire to a server that has no business holding it, and an access log records request URLs. We are removing the input; the replacement returns an EIP-191 message hash for the caller to sign locally, and the hash is all the service ever needed to compute.
block is a static rule's opinion about a definition's text, not a statement that a server is malicious; the scanner never calls a tool. The keyword pass is a rough split of 1,085 rows, not a classification. And a block count says nothing about whether anyone uses the server — only 36% of the registry answered ok on its last probe, and the rest were install failures, auth walls, dead tunnels or robots disallows.advise, and it is not a defect.The tiers are the interesting part. A scanner that blocks everything is turned off; one that blocks nothing is decoration. One in ninety is a rate a registry can actually act on — provided the errors in both directions stay visible.
Data: HISTOR open datasets (CC BY 4.0), snapshot 2026-11-09, file servers.jsonl.gz, 103,271 rows. Scanner: WARDEN ruleset v19 as vendored by HISTOR. The reproduction for the mnemonic rule is alexar76/warden#14.