Servers Changes Log Check Why How it works GitHub

Transparency log · MCP tool definitions

Every MCP server's tools, on the record.

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 public MCP server advertised, and tells you the day it changed.

Read-only: it lists tools and never calls one. It never says a server is safe — it tells you what was said, and when.

DRAG TO ORBIT
SIM

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.

Registry endpoints
last crawl
Tool sets pinned
current
Changes
last 7 days
Labels in the log
all time
Last signed tree head
UTC

What HISTOR is for

Tool descriptions are instructions. They should not change behind your back.

The problem

A server can change what your model reads

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.

What HISTOR does

It keeps the public record

Every day HISTOR reads what each public MCP server in the official 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.

What you get

A second pair of eyes you can check

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.

Who it is for

People who use MCP serversin Claude, Cursor or any client — check a server before you connect it, and again when it changes.
Agent builderswhose agents connect to servers on their own — call /check before trusting a tool set.
Registries and directoriesthat want more than stars and download counts — show when a listing's tools last changed.
Server authorswho want to show a stable, documented history — add the badge, and every change you ship is dated in public.

Four words used on this page

Tool definitions
The name, description and input schema of each tool a server offers — the text your model reads.
Pinned
HISTOR has recorded a fingerprint (digest) of the exact definitions it saw, so any later change is detectable.
Label
One signed statement about one observation: what was seen, what matched, whether it changed. Anyone can verify it offline.
Signed tree head
The log's signed summary after each crawl. Comparing two of them proves nothing was deleted or rewritten in between.

Read → digest → label → append → sign → compare

How the log works

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.

01

Read

For every remote endpoint in the official MCP registry: initialize, then tools/list, drained across every page. No tool is ever called; no code is installed or run. Private addresses are refused before the connection opens.

02

Digest

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.

03

Label

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.

04

Append

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.

05

Sign

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.

06

Compare

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.

What a label does not say

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.

Not a safety rating

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.

Not the code

Labels are about advertised text. No source is read, no package is resolved, no tool is invoked. A server can keep identical definitions and change its behaviour; the log cannot see that, and says so inside every label.

A change is not an accusation

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.

Remote servers only — for now

Local stdio servers exist only when someone runs them, and HISTOR runs nothing. They become visible through clients that check the digest they received and choose to contribute it.

One operator, one key

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.

Behind a login, unseen

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

Use it

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
[![MCP tool defs](https://histor.modelmarket.dev/badge/<id>.svg)](https://histor.modelmarket.dev/s/<id>)

# Atom feed of every observed change
https://histor.modelmarket.dev/feed.xml
WARDENchecks definitions at connect
HISTORremembers what was advertised
THEMISadmits at publish
Hublists histor.check@v1
AWRthe signed format

Questions

Is this a marketplace listing?

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.

Does HISTOR tell me a server is safe?

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.

Why are so many servers "not observed"?

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.

How do I check a server I already use?

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.

How do I get a badge for my server?

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.

Why should I trust HISTOR itself?

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.

What does it cost?

Looking things up, the badges, the feed and /check are free. HISTOR is also listed on the AIMarket Hub as histor.check@v1, so agents can call it through the market.