HISTOR is a query-only MCP server for a public transparency log of MCP tool definitions.
histor_changes: list the newest observed tool-definition changes at remote MCP endpoints, including added/removed/modified tools, newly appeared external addresses, and links to full diffs.
histor_check: submit an endpoint or registry name plus the tools/list you received or its MTL/1 digest; get a signed verdict on whether HISTOR observed the same set, since when, earlier sets, WARDEN pattern matches, and optionally contribute a public digest count.
histor_server: retrieve HISTOR’s observation record for one endpoint or all endpoints of a registry name, including digest, tool count, first/last observed, unchanged-since time, change count/status, and links.
It queries the public log over stdio without crawling or storing locally; --local or histor mcp can serve your own log from HISTOR_DATA_DIR.
It reports what was advertised. It does not call tools or claim that a server is safe.
Enables HISTOR to run and analyze npm packages that provide MCP servers in a sandbox, observing their tool definitions and behavior, including up to 15 tool calls with canary arguments.
Enables HISTOR to run and analyze PyPI packages that provide MCP servers in a sandbox, observing their tool definitions and behavior, including up to 15 tool calls with canary arguments.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@histor verify the tool definitions my client received for the fetch server"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
🔄 Synced from the AI-Factory monorepo (append-only history). Pull requests are welcome — merged PRs are imported back and re-synced here. Issues · Pull requests
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
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.
Related MCP server: Hive Radar MCP
flowchart LR
R["Official MCP registry<br/>~21k servers"] --> C["Crawler<br/>server/discover + 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" .-> MReads every remote endpoint in the official registry: server/discover, then tools/list (legacy servers use initialization)
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 discovery and tools/list (legacy initialization when needed), 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.
Remote checks run independently of the daily registry/package cycle. The default target interval is six hours; endpoints with at least two observed changes in the last seven days are checked every 30 minutes. These are scheduling targets: host limits, failures and queue capacity can make actual gaps longer. Intermediate states can still be missed. See remote polling operations for configuration and measured intervals.
Release changes and upgrade notes: CHANGELOG.md.
MCP 2026-07-28: modern and legacy compatibility.
Local upgrade brief: choose your dependencies and workflows, compare saved observations, and get a retest checklist.
From this source directory, run python3 -m histor upgrade-brief --watchlist examples/upgrade-brief/watchlist.json --out-dir ../output/histor-upgrade-brief-example/en (Python 3.11+).
Reports and checklists support --lang ru|en|es|fr|zh (default en).
See the guide and reproducible synthetic example, available in five languages.
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. Each count is split into names, descriptions and input schemas; every change carries its cost diff (/api/v1/changes/<id>/cost), and histor tool-cost check runs the same count in a package's CI and fails a release that makes the list heavier: docs/tool-list-cost.md.
Watch the servers you use. https://histor.modelmarket.dev/feed.xml?watch=<id>,<id> is a feed of the changes of up to 100 servers you follow; /api/v1/changes?watch=…&after=<cursor> is the same for a program, oldest first, resumable. Teams can have each change pushed, signed, to Slack or their own endpoint: docs/watch.md. Registries, scanners and rating services: docs/data-feed.md.
Download the data. Once a week 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 a number, give the version DOI of the snapshot it was counted on (each archived snapshot has its own, listed on the datasets page); doi:10.5281/zenodo.23512759 stands for all of them and opens the newest.
Public payer evidence. The histor payer-audit command (since 0.4.1) checks Base USDC
receipts and exports sourced behavioural indications while retaining payment totals and unknown
cases. It needs no production database or wallet: docs/payer-audit.md.
pip install aimarket-histor # the package is aimarket-histor — "histor" on PyPI is an unrelated project
histor audit https://histor.modelmarket.dev # verify the public log's tree heads and proofs; needs no keys or database
uvx aimarket-histor # MCP server over stdio against the public log: histor_changes, histor_check, histor_serverPython 3.11 or newer. histor audit is the first command to run: it checks the live log the way a
stranger should, without trusting HISTOR (docs/log.md).
In an MCP client (Claude Code, Cursor, …): { "mcpServers": { "histor": { "command": "uvx", "args": ["aimarket-histor"] } } } —
three tools that ask the public log; nothing is crawled or stored locally. aimarket-histor --local
(or histor mcp) serves your own log from HISTOR_DATA_DIR instead. Listed in the official MCP registry as
io.github.alexar76/histor.
After connecting, ask: “Use histor_server with endpoint npm:mongodb-mcp-server.
Show the last observation, the number of tools, and the link to its HISTOR record.”
Substitute your own npm: or pypi: package, or
look it up in the browser.
To run your own log from source:
git clone https://github.com/alexar76/histor && 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 -dSchema changes are numbered migrations (python -m histor migrate up|status), applied before the
service listens; see docs/operations.md.
# Is what my client received what HISTOR observed at that endpoint? Three lines that run as
# written: take a listed server, send its endpoint and tool list to /check, read the signed answer.
# With your own client, replace the second line by the endpoint and the tools/list result it received.
H=https://histor.modelmarket.dev/api/v1
S=$(curl -sS "$H/servers?limit=1" | jq -r '.servers[0].id')
curl -sS "$H/servers/$S" | jq '{endpoint: .server.endpoint, tools: .tools}' > received.json
curl -sS "$H/check" -H 'Content-Type: application/json' -d @received.json | jq '.verdict, .target.page'
# 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 format itself (leaf input, tree, signed head, verification rule) is specified in docs/spec/transparency-log.md with normative vectors in test-vectors/. The internals are in docs/architecture.md.
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 sidecarThe 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.
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.
Component | Role |
checks tool definitions at connect time, on the client | |
HISTOR | remembers what servers advertised, publicly |
admits a capability at publish time on a Hub | |
lists | |
the signed document format every label uses |
MIT — see LICENSE. Part of the AIMarket ecosystem.
The newest tool-definition changes HISTOR observed at remote MCP endpoints in the official registry: which tools were added, removed or modified, any outside address (host, e-mail, IP) that newly appeared, and a link to each full diff.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It discloses what data is observed and returned (changes, newly appeared outside addresses, diff links) and implies a read-only monitoring operation. However, it does not explicitly state that it is side-effect-free, whether authentication or rate limits apply, or how the diff links should be used.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately names the core resource and then enumerates the returned information. Every clause contributes to understanding the tool's output, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description does explain the key return values (added/removed/modified tools, outside addresses, diff links). However, it omits any explanation of the optional 'limit' parameter and provides no usage or safety context. It is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description never mentions the single 'limit' parameter. While the parameter name is somewhat self-explanatory, the description adds no meaning about what is being limited (e.g., number of changes returned) or how the limit interacts with the results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific resource ('tool-definition changes HISTOR observed at remote MCP endpoints') and enumerates the exact output categories (added/removed/modified tools, new outside addresses, diff links). It is clear what the tool returns. It does not explicitly differentiate itself from the sibling tools histor_check and histor_server, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to use this tool, when not to use it, or which alternative tools exist. There is no guidance about prerequisites or intended scenarios. Usage must be inferred entirely from the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an MCP endpoint (or registry name) and the tools/list you received, or its MTL/1 digest. Returns, signed: whether HISTOR observed the same set there, since when, earlier sets, the WARDEN pattern matches for it, and the stored advisory classifier verdict if HISTOR has one (any language; one model's opinion, not a log label). Says what was advertised, never that a server is safe.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | or the server's registry name | |
| tools | No | the tools array of the tools/list result you received | |
| endpoint | No | the MCP endpoint URL | |
| contribute | No | add (endpoint, digest, day) to a public count | |
| toolSetDigest | No | or its MTL/1 tool-set digest (sha256-…) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that the response is signed, what each returned element is (observation status, since-when, earlier sets, WARDEN matches, advisory classifier verdict), and critically sets expectations with 'one model's opinion, not a log label' and 'Says what was advertised, never that a server is safe.' It omits permission/auth or rate-limit behavior, so it stops short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The response shape is front-loaded ('Send ... Returns, signed: ...') and each sentence adds content rather than padding. It is dense with domain jargon (MTL/1, WARDEN, HISTOR) but not wasteful, and the caveats are appropriately placed at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description correctly compensates by enumerating what comes back, including the signed-history components. For a flexible-arity lookup tool with no required parameters, this is nearly complete; only the sibling-routing and auth/limit context are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there are no required parameters, so the schema already documents name, tools, endpoint, contribute, and toolSetDigest. The description reinforces the alternate input forms (endpoint/registry name vs tools/list vs digest) but adds no syntax or format detail beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete operation: send an MCP endpoint/registry name plus a tools/list (or its digest), and get back HISTOR's recorded history for that set. That is a specific verb-plus-resource, clearly a lookup/verification tool. It does not, however, differentiate itself from the sibling tools histor_changes or histor_server, leaving the agent to infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the input contract ('Send an MCP endpoint ... and the tools/list you received, or its MTL/1 digest'), which tells the agent when the tool is applicable. But there is no explicit when-to-use/when-not guidance, and no comparison against histor_changes or histor_server to route the agent between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
HISTOR's observation record for one MCP endpoint (or every endpoint of a registry name): tool-set digest, tool count, first pinned, last observed, unchanged since, change count and last status, with links to the full record and its labels.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| endpoint | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the entire behavioral burden. It enumerates returned fields, which is useful, but says nothing about read-only nature, permissions, pagination, or result limits. An agent cannot tell from this text whether calling it is safe or bounded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with scope stated first and the return-field enumeration after the colon. Dense but every clause carries information; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because no output schema exists, the field enumeration usefully covers what comes back, and the scope clause covers both parameters loosely. However, usage routing, permissions, and pagination behavior are absent, leaving gaps an agent would hit in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% across two parameters, so the description must compensate. The parenthetical does map the two usage modes onto the parameters, implying 'endpoint' selects one endpoint and 'name' is a registry name spanning endpoints, but it never gives formats, IDs, or whether both can be combined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource ('HISTOR's observation record') and its scope ('one MCP endpoint or every endpoint of a registry name'), plus an enumerated field list that makes the tool's output concrete. It never states the verb (retrieve) explicitly nor distinguishes itself from histor_changes/histor_check, so an agent must infer the boundary from the field list alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of the sibling tools histor_changes or histor_check as alternatives. The parenthetical about endpoint vs. registry name implies two usage modes but does not tell the agent which to pick or when.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
histor_changeshistor_checkhistor_serverScored across 3 tools
Each tool targets a distinct aspect of MCP endpoint observation: a global recent-changes feed, a verification check against a supplied tools list, and a stored per-endpoint record. The check and server tools overlap somewhat in returning historical observation details, but the need to supply a digest versus retrieving a record distinguishes them.
All three tools share the consistent 'histor_' prefix followed by a single noun/verb, with no mixing of styles (e.g., histor_changes, histor_check, histor_server). The pattern is predictable and readable.
Three tools is well-scoped for a focused, read-only history/monitoring service, with each tool covering a distinct workflow (recent changes, verification, record lookup). No bloat or thinness.
The surface covers the core read-only operations: global change feed, endpoint record retrieval, and verification of a supplied tools list. Minor gaps exist—no direct per-endpoint change listing or endpoint/registry enumeration tool—but agents can work around these via the global changes feed or record links.
Independent trust scores, tool surfaces and change history for MCP servers.
Trust, freshness, policy, and discovery layer for public MCP servers.
Read-only MCP server checks and quote verification, free and keyless; results signed and publicly lo
Check MCP servers and packages against an independent, anchored record before you trust them.
