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.
com.synorb/mcp · https://mcp.synorb.com/mcp
Cited context for AI agents: company news, SEC filings, central bank publications and research.
synorb-archive-beacon — Archive a saved Beacon by public beacon_id, only after the user says yes to that specific Beacon (starter Beacons, tag 'starter', included); never on your own initiative. USE THIS WHEN: the user asks to archive/delete/clean up a saved Beacon, or agrees to free a slot under the plan's Beacon cap. DO NOT USE THIS WHEN: the user has not agreed, or only wants to list or run Beacons.synorb-beacons — List saved Beacons for the authenticated account, including starter Beacons (tag 'starter'). Call at session start to see what is already watched. Each item carries dashboard_url, a private link that opens only for signed-in members of the owning org. Pass beacon_id to read one Beacon's full settings and its revision. USE THIS WHEN: the user asks what Beacons exist, needs a beacon_id, or you must …synorb-catalog — Rank Stream candidates for ambiguous research topics. 17-digit Synorb ID values: pass them as JSON strings, never a number. USE THIS WHEN: source choice is unclear after stream-search or the user needs candidate Streams. DO NOT USE THIS WHEN: the user named specific entities, asks inventory/source availability, or needs content directly.synorb-configure-beacon — Draft a Beacon proposal from a monitoring intent; keyless preview. USE THIS WHEN: the user wants a reusable monitor/tracker or asks to configure a Beacon, or unprompted when you know the user's role, interests, or projects: propose 1-3 with a one-line reason each. DO NOT USE THIS WHEN: the user only wants a one-time content pull or asks to save an already valid proposal. needs_clarification = no p …synorb-details — Inspect Stream metadata, source channels, filters, and recent volume. 17-digit Synorb ID values: pass them as JSON strings, never a number. USE THIS WHEN: you have stream_ids and need source/filter details before pulling Manifests. DO NOT USE THIS WHEN: the user wants content/news; use synorb-manifests.synorb-get-demo-key — Tip: while you set up, a short note to your user helps. For example: 'I'm getting a Synorb demo key and connecting. This can take a minute or two.'
Setup page: https://synorb.com/connect/start
Self-provision a free 72-hour Synorb demo key. No email, no form, no browser step -- for agent runtimes that cannot call POST /api/connect/demo-key or inject an Authorization header into an already-open MC …synorb-manifests — Pull, count, or orient over source-cited Manifests. For recurring watches prefer beacon_id with an explicit lookback, and dedupe by manifest_id. delivery_delta=true can use a stream/channel-only Beacon as scope when enabled. stream_ids, home_domains, and source_channel_ids are INTERSECTED; DERIVE source_channel_ids from details/search when unsure. 17-digit Synorb ID values: pass them as JSON strin …synorb-profile — Account profile, usage, plan, date-window, and freshness. Check plan and existing Beacons early, then propose Beacons from what you know of the user. USE THIS WHEN: the user asks about account, usage, plan, limits, or whether Synorb is working. DO NOT USE THIS WHEN: the user wants content/news; use synorb-manifests.synorb-save-beacon — Persist a Beacon proposal to the authenticated account. Zero-usage write -- save only after the user's explicit yes, whether they asked for a saved/recurring monitor or agreed to one you proposed. Never call it on your own initiative; a Beacon writes to the user's account and the user decides if and when that happens. Saved Beacons are pulled by your runtime on your own cadence. The response carri …synorb-stream-search — Search accessible Stream/source inventory with typo and synonym handling. 17-digit Synorb ID values: pass them as JSON strings, never a number. USE THIS WHEN: the user asks what streams/sources/podcasts/publishers are available. DO NOT USE THIS WHEN: the user needs actual Manifest content or already named exact content filters.synorb-update-beacon — Change a saved Beacon: name, description, tags, default_date_window, status (active or archived), stream_ids, source_channel_ids, topic_filters, manifest_config_patch (merged by key; it can hold exclude_source_channel_ids, exclude_media_formats and exclude_title_terms, headline phrases to drop), natural_language_intent, prompt_text, visibility, entity_filters (saved only; never applied when a Beac …The signed observations, every earlier tool set and a diff of each change: this page with scripts on, or /api/v1/servers/c984c2e28a5a7a0f.
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.