Transparency log · MCP tool definitions
Your AI client trusts the tool descriptions an MCP server sends it — and a server can change them after you approved it. HISTOR keeps a public, signed record of what every remote MCP server in the official registry advertised, and tells you the day it changed.
Remote endpoints: it lists tools and never calls one. Registry packages: bounded canary calls run inside the isolated sandbox. It never says a server is safe — it tells you what was said, and when.
WebGL is unavailable here. The picture is the log itself: each label is a leaf, leaf hashes climb a Merkle tree, and a signed tree head seals the root.
What HISTOR is for
When you connect an MCP server, its tool descriptions go straight to the model as instructions. A server can pass your review with harmless descriptions and change them next week — one added sentence is all a prompt injection needs, and most clients never ask you again.
Every day HISTOR reads what each remote (streamable-HTTP) endpoint in the official MCP registry advertises, fingerprints it, signs what it saw and appends it to a log that can only grow. When a server's definitions change, the change gets a date and a diff.
Look up any server before you trust it. Paste what your client received and learn whether everyone else sees the same thing. Follow changes in a feed, or put a badge in your README. Every answer is signed, so you can verify it instead of believing it.
io.github.duckframework/duckframework-mcp · https://duckframework.com/mcp
Official Duck Framework MCP server for AI-assisted development and project scaffolding.
fetch_ai_guide — Fetch an official Duck Framework AI guide.
Use this after get_ai_guides() to retrieve the full guide content for
AI-assisted Duck Framework development.
Always read the relevant guide before generating code instead of relying
on memory.get_ai_guides — List available Duck Framework AI guides.
Use this to discover available guides before fetching one with
fetch_ai_guide().
Returns guide identifiers and their descriptions.get_blueprint_locations — Explain where Duck Framework blueprints can be located.
Describes the supported blueprint layouts and when each organization
approach is appropriate.get_blueprint_structure — Return the standard internal structure of a Duck Framework blueprint.
Use this before generating a new blueprint or adding files to an existing
one to understand where components, pages, templates, automations, and
views belong.get_component_api — Look up a built-in Duck Framework component API.
Returns the confirmed import path, container type, and supported keyword
arguments for a component without requiring the full HTML components guide
to be loaded.
Use this before using any component that has not already been confirmed.
Returns close-name suggestions when the component does not exist.get_project_structure — Return the standard Duck Framework project directory structure.
Use this before creating or modifying projects to understand where files
and directories belong.lint_component_code — Check Duck Framework component or page code for common mistakes.
Detects known patterns such as incorrect component imports, invalid page
imports, incorrect Heading usage, leading-underscore method names, and
separator comments.
This is a pattern check for known issues, not a complete correctness
validator. An empty result only means no known issues were detected.
Run this on generated component c …list_doc_categories — List all Duck Framework documentation categories and their pages.
Use this when browsing available documentation without a specific
search query.plan_feature — Analyze a Duck Framework feature request and create an implementation plan.
Returns relevant documentation to read and a suggested order of operations
before writing code. Use this before implementing non-trivial Duck
Framework features.reindex_docs — Rebuild the Duck Framework documentation index.
Crawls the live documentation sitemap for a given version and merges
the result in: curated tags/summary/category are preserved, new pages
are added, and pages no longer in the sitemap are removed.
Requires the admin scope.scaffold_blueprint — Scaffold a new Duck Framework blueprint.
Generates a blueprint structure containing blueprint.py, views.py, and
optional UI, template, and static directories following the documented
Duck blueprint conventions.
Returns generated file contents and the settings configuration needed to
register the blueprint. This tool does not write files.scaffold_project — Scaffold a new Duck Framework project.
Returns the required CLI commands and generated file contents for
supported features with confirmed APIs. Unsupported features return
documentation guidance instead of generated code to avoid guessing
framework APIs.
This tool does not write files. It only returns generated content for the
calling client to add to the user's project directory.search_docs — Fuzzy-search the Duck Framework documentation.
Use this whenever the correct documentation page for a feature is
unknown. Returns ranked matches containing title, URL, category,
summary, and relevance score.The signed observations, every earlier tool set and a diff of each change: this page with scripts on, or /api/v1/servers/6c05aff53b6f7f7c.
Read → digest → label → append → sign → compare
Six steps, every one of them checkable by someone who does not trust HISTOR. The only thing you have to take on faith is that the observation happened when the label says it did — and the log makes it impossible to change that story afterwards.
Remote endpoints in the official MCP registry: initialize, then tools/list, drained across every page; no tool is called, and private addresses are refused before the connection opens. npm and PyPI packages: installed and started in the sandbox described below, with no route out.
The tool set is reduced to name, description, input and output schema, sorted by UTF-16 code units and hashed over its RFC 8785 canonical form. Anyone holding the same tools gets the same digest — which is what makes a comparison possible.
Four MTL/1 methods, one signed AWR/2 document each: what was observed, what the WARDEN pattern set matched, whether the definitions changed since the last label, and whether the name is on a threat list. No score, ever.
Every label becomes a leaf of an RFC 9162 Merkle tree: leaf hash = SHA-256(0x00 ‖ JCS(label)). The label you download is the leaf input, so you can recompute its hash yourself.
After each crawl HISTOR signs a tree head: the size and the root. Keep yesterday's head; ask for a consistency proof to today's; if anything was removed or rewritten, the proof fails.
Each day a continuity label compares the new digest with the last one. Equal: "unchanged since". Different: a change, with the date and a per-tool diff. A client that checks what it received adds the view no crawler has.
Where an npm or PyPI package is run
A package observation is true for these conditions, and no others. Every package page names the exact image it ran in and any configuration it was given.
Linux x86_64, inside gVisor (runsc): the package talks to a kernel written for sandboxing, not to the host's. An unprivileged user, no capabilities, a read-only root.
npm packages in histor-node:22, PyPI packages in histor-python:3.12: the official node:22-bookworm-slim and python:3.12-slim images plus bash, git, Python 3 or Node 22 and a Java 21 runtime — never Docker — built when a sandbox host is installed. A package whose Requires-Python excludes 3.12 runs on histor-python:3.13 or 3.14; one that requires a newer Node runs again on histor-node:24. The exact image a package ran in is on its page.
npm with --ignore-scripts, then the install scripts in a traced stage of their own. PyPI: wheels only — a package that ships only source is reported, never built.
No route out. Every name the package looks up resolves to HISTOR's own traps, which record what was sent and forward nothing. A server that needs the internet to start shows that here.
None are real. Decoy credentials sit in HOME and a decoy .env in the working directory. A variable the package says it needs gets a placeholder; where the placeholder was sent is recorded.
512 MB of memory, one CPU, 64 MB of /tmp. 360 s to install, 150 s to start and answer; up to 15 tools called once each with canary arguments, 8 s per call.
Only names: required variables its registry entry declares or that it printed when it exited, and a start argument such as serve when its usage text offers one. Never a value from anyone else.
The profile HISTOR implements forbids the words safe, secure, audited, certified, approved and trusted. Here is why, in the terms of what the log can and cannot show.
A pattern match is a reason to read a definition, not a finding. Three of the four methods can never return fail. There is no score to rank by, because no score HISTOR could compute would mean what a reader takes it to mean.
Labels are about advertised text. A remote endpoint's source is never read and its tools are never invoked; a package runs only in the sandbox, against nothing real. A server can keep identical definitions and behave differently for real users; the log cannot see that, and says so inside every label.
A version bump changes definitions too. A change is shown as a date and a diff, in amber, never red. What you do with it is yours: re-read, re-approve, or pin the old digest.
An npm or PyPI server is observed under the test conditions above: Linux, no internet, placeholder keys. One that needs Windows, a real account or the network may show fewer tools or none; its page says why it exited.
Today one party runs the log. A second observer on another network is the next step, and any AIMarket hub can run one. Until then, what the key proves is who said it — not that it is true.
Endpoints that require authentication answer 401 to everyone without a key, including HISTOR. They are counted and listed as not observed, never dropped from the numbers.
For clients, registries and server authors
Before your agent trusts a server, send the tools it received. The answer is signed by the log's did:key and names the tree head it was given under.
curl -sS https://histor.modelmarket.dev/api/v1/check \
-H 'Content-Type: application/json' \
-d '{"endpoint":"https://example.com/mcp","tools":[ …tools/list result… ],"contribute":true}'
# -> {"type":"histor.check/v1","match":"same"|"different"|"previously-observed"|…,
# "observed":{"unchangedSince":"…","changes":0}, "patternScan":{…}, "signature":{…}}
# README badge for your server
[](https://histor.modelmarket.dev/s/<id>)
# Atom feed of every observed change
https://histor.modelmarket.dev/feed.xml
No. The server list is the log's index: every remote endpoint in the official MCP registry, with what HISTOR could observe about it. Nothing here is for sale and nothing is ranked by quality.
No, and it never will. It tells you what a server advertised, whether that changed, and which published patterns matched the text. Whether to trust the server is your decision — HISTOR makes sure you decide on the same facts as everyone else.
Most remote MCP endpoints require a login (they answer 401 to anyone without a key), some use the legacy SSE transport or need per-user values in the URL, and some are simply down. They stay on the list with the reason, so the numbers never hide them.
Open the Check tab, paste the server's endpoint and the tools/list result your client received, and press Check. You get back, signed, whether HISTOR observed the same definitions — or different ones, or an older set.
Find your endpoint on the Servers tab, open it, and copy the Markdown snippet under the facts. The badge shows the date your definitions were pinned or last changed, and links to the full history.
You do not have to. Every label and every tree head is signed with one published key; the Log tab proves in your browser that the log only grew; and the command-line auditor does the same from any machine. What remains is that one operator runs it today — a second, independent observer is the next step.
Looking things up, the badges, the feed and /check are free. HISTOR also offers histor.check@v1 to the AIMarket Hub, so agents can reach it through the market.
Once a day: initialize, notifications/initialized and tools/list — never a tool call, never a redirect followed, at most two connections per host, from a User-Agent that starts with histor/. To be left out, open an issue on the histor repository with your endpoint or host; it is then listed as not observed (operator-opt-out), with the reason, rather than silently dropped. Labels already in the log stay: the log only grows.