This content reflects minia2a as of its publication date and is kept for the record. Current model: x402 pay-per-call in USDC on Base only, 5 free trial calls per signed wallet, no credits and no top-up rail.

1,085 of 103,271 MCP servers carry a block-tier finding — what a static scanner sees

November 14, 2026 · data snapshot 2026-11-09

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.

The numbers

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.

Two ways a block is wrong

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.

1. The word is the domain's vocabulary

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.

2. The pattern is real and so is the mistake

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.

What this article is not claiming. 103,271 rows is one registry snapshot from one week, not all of MCP. 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.

What a server author should take from it

1. Run the scanner on your own definitions before a client does. Both tiers are pure functions of text you control; there is no runtime to test.
2. Never declare a wallet key as a call input. Sign locally. A tool that accepts a key is one log line away from a leak, and every scanner in this space will block it.
3. Keep advisory hits. A password-hashing tool has to receive a password. That is advise, and it is not a defect.
4. Watch the nouns that mean something else in your domain. If your field is crypto, opcode names, seed generation or key derivation, expect static rules to misread you until someone writes a guard — and say so upstream with a minimal reproduction rather than silently rewording in private.

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.

← All posts

Originally published at minia2a.uk.