HISTOR

HISTOR (ἵστωρ, “the one who knows because they saw”) — a public transparency log of MCP tool definitions
What every remote MCP endpoint in the official registry advertised · when it changed · signed, appended, auditable

English · Русский · Español · Français · 中文

WARDEN quality cycle: MOMUS → AI-Factory → SKOPOS → shared node agent → deployment.

Live: histor.modelmarket.dev · Landing: alexar76.github.io/histor · Capabilities: histor.check@v1 · histor.server@v1 · histor.changes@v1 · Port: 9490

The problem, in one paragraph

An MCP server can pass your review with harmless tool descriptions and change them later — a new sentence in a description is all a prompt injection needs, and your client will pass it to the model without asking you again. MCP has no content addressing for tool definitions, the official registry verifies namespaces rather than contents, and a scanner on your laptop sees only what the server shows your laptop. HISTOR is the missing public memory: it records what each server advertised, signs it, and tells anyone who asks whether what they received is what everyone else is seeing.

What it does

flowchart LR
    R["Official MCP registry<br/>~21k servers"] --> C["Crawler<br/>initialize + tools/list<br/>never a tool call"]
    C --> D["MTL/1 digest<br/>RFC 8785 + SHA-256"]
    D --> L["Four signed labels<br/>AWR/2 · did:key"]
    W["WARDEN sidecar<br/>published pattern set"] --> L
    L --> M["Merkle log<br/>RFC 9162"]
    M --> S["Signed tree head<br/>after every crawl"]
    M --> API["Desk · API · badge · Atom feed"]
    CL["Your client"] -- "tools it received" --> K["/api/v1/check"]
    K -- "signed: same · different · seen before" --> CL
    K -. "opt-in digest count" .-> M

• Reads every remote endpoint in the official registry: initialize, then tools/list drained across pages. No tool is called, nothing is installed or executed, private addresses are refused before a connection opens.
• Also reads a short list of popular remote servers the registry does not carry (histor/curated.json, DeepWiki among them), under HISTOR's own namespace urn:awr:mtl:1:registry:histor.modelmarket.dev/curated, so no label claims a registry listing. When such a server publishes to the registry, the registry's listing replaces ours.
• Runs npm and PyPI packages — the servers people start locally with npx or uvx — in a sandbox: installed without running their code, started under gVisor with decoy credentials and no route out, read with initialize + tools/list, then up to 15 tools called once with canary arguments, inside the sandbox. gVisor's own trace says what the package did — programs started, names looked up, decoys opened — at install, at startup and when its tools were called. Completed observations are cached per published version; incomplete observations are retried; a new version that changes what its tools tell the model is a change in the log, like any endpoint's.
• Digests the tool set exactly as MTL/1 defines it — name, description, input and output schema, UTF-16 code-unit order, RFC 8785.
• Signs four kinds of label, each a standalone AWR/2 VerificationVerdict: what was observed, what the WARDEN pattern set matched, whether the definitions changed since the previous label, and whether the name is on a threat list.
• Appends every label to an RFC 9162 Merkle log and signs a tree head after each crawl, so a consistency proof shows the history was only ever appended to.
• Answers /check: send the tools your client received; get back, signed, whether HISTOR observed the same set at that endpoint, an earlier one, or none.

What a label does not say

The profile forbids the words safe, secure, audited, certified, approved and trusted, and so does this README. A pattern match is a reason to read a definition, not a finding. Three of the four methods can never return fail; the fourth (continuity) fails only in the mechanical sense that two digests differ. No source is read, no package resolved, no behaviour observed. A change is shown as a date and a diff, never as an accusation. Details: docs/labels.md.

What a tool list costs. A client resends every connected server's tool list with each model request. Over the 18,204 packages and 16,170 remote servers in the log, a list's median is about 1,300 tokens, the 90th percentile about 8,000, and 31 packages list over 100,000: docs/tool-list-cost.md.

Download the data. Once a month the log's whole view is published as files at histor.modelmarket.dev/datasets/: every listed server, every tool set it showed, every recorded change and the WARDEN scans. The files are JSON Lines (gzip) with a manifest signed by the log's key; the compilation is CC BY 4.0. Each snapshot's README lists the fields and loads in pandas or DuckDB (histor/dataset.py). Also on Hugging Face; to cite: doi:10.5281/zenodo.23512759.

Quick start

cd histor
npm ci --prefix scanner                     # the WARDEN sidecar (node >= 20)
uv sync --extra dev --project .
HISTOR_CRAWL_LIMIT=40 uv run --project . python -m histor crawl   # observe 40 endpoints
uv run --project . python -m histor serve   # desk + API on :9490 (SQLite under ./data)

For a local MCP client or Glama, run python -m histor mcp. It exposes histor_changes, histor_check and histor_server over stdio using the local log. It opens no HTTP port and starts no crawl; use the separate crawl command above to populate a fresh log. See Glama build settings.

Production runs on Postgres, and HISTOR_PROFILE=prod refuses to start without it:

HISTOR_POSTGRES_PASSWORD=… HISTOR_OPERATOR_TOKEN=… HISTOR_PUBLIC_BASE=https://histor.example \
  docker compose -f docker-compose.yml -f docker-compose.postgres.yml up -d

Schema changes are numbered migrations (python -m histor migrate up|status), applied before the service listens; see docs/operations.md.

Ask the log

# Is what my client received what HISTOR observed at that endpoint?
curl -sS https://histor.modelmarket.dev/api/v1/check -H 'Content-Type: application/json' \
  -d '{"endpoint":"https://example.com/mcp","tools":[ …the tools/list result… ]}'

# The signed tree head, and a proof that today's log extends yesterday's
curl -sS https://histor.modelmarket.dev/api/v1/log/sth
curl -sS "https://histor.modelmarket.dev/api/v1/log/proof/consistency?first=1000&second=1200"

Every endpoint is in docs/api.md. How to audit the log without trusting HISTOR is in docs/log.md. The internals are in docs/architecture.md.

Tests

make test          # unit tests; set HISTOR_TEST_DATABASE_URL to run each storage test on Postgres too
make integration   # real sockets: a loopback registry and MCP servers, uvicorn, the real WARDEN sidecar

The tests and coverage badges above are measured by CI on every Pages deploy and read through shields.io, and the log badges read the live service, so every number there is current.

ERC-8004 identity

HISTOR is ERC-8004 agent 96683 on Base, registered on 2026-10-01 in the canonical IdentityRegistry 0x8004A169…a432 and owned by the AIMarket operator wallet 0x1218ff36…Ad0a. Its registration file lists the web page, the hosted histor-check endpoint and the did:key that signs every label, so a label's signature can be tied back to the registered agent. Transactions and how to check them: ERC-8004 identities.

Where it sits

License

MIT — see LICENSE. Part of the AIMarket ecosystem.