Two MCP logs matched 23 tools. Five days later, every name had changed.

Compare the latest saved entries for one MCP server and you get zero tool names in common. Compare the observations from the same evening and all 23 tool fingerprints match.

We maintain HISTOR, a transparency log for the tool definitions MCP servers advertise. We wanted to see whether an independent observer could corroborate one of our observations. We picked LEGION-tlog because it publishes a timestamp and a SHA-256 fingerprint for each tool. Those fingerprints let us compare individual definitions even when the logs use different formats for their records. LEGION developer documentation

What the two logs saw

The server was com.aiapplyd/aiapplyd. We compared the tool name, description and input schema using LEGION’s canonicalization rule for per-tool fingerprints. All times below are UTC in 2026. HISTOR server history · LEGION server record

The October 24 observation is easy to misread if you only look at counts. Both sets contain 23 tools, but a client using the earlier names would have to account for the name changes. The matching suffixes give you a way to line up the names. Whether the tools behave the same would take a separate test.

The evidence tells us when HISTOR first recorded the new set and which earlier version LEGION corroborated. It leaves open why the archived LEGION response had no later entry. In particular, the time of an observation and the time a server actually changed can differ.

Replay the check offline

Download the offline replay bundle.

With the case bundle unpacked, run this from its directory using Node.js 22.

node replay.mjs > replay-output.json
diff -u result.json replay-output.json

An empty diff means the replay reproduced the saved result. The script uses Node’s standard library and the bundled records, keys, signed tree heads (STHs) and inclusion proofs. It performs three checks.

1. LEGION-tlog. Verify the signing key against the pinned root key, verify the Ed25519 signatures on leaf 29030 and its STH, and recompute the path to the signed root of the 50,578-leaf Merkle tree.
2. HISTOR. Verify the STH and the three signed MTL/1 labels against HISTOR’s pinned did:key. Verify their inclusion in the 1,564,894-leaf Merkle tree and recompute the tool set digest bound to each label.
3. Comparison. Recompute the per-tool fingerprints from the authenticated HISTOR tool sets and compare them with the fingerprints in the LEGION record. The output lists names unique to either side and any shared names whose definitions differ.

The signed HISTOR label for the 40-tool set dates to October 31. The November 2 read time comes from snapshot metadata. The replay verifies inclusion under the bundled tree heads. Checking consistency across other tree heads or the behavior of the server would require separate evidence.

For a tool-pinning workflow, the case suggests a concrete diagnostic. When two logs disagree, put the observation timestamps next to the fingerprints and look for an earlier matching tool set. That can turn a generic mismatch into a dated, inspectable change.

We maintain HISTOR. AI assistance was used for the analysis, the replay code, the illustrations and the writing.