Badges
A badge is an image an operator can embed once and leave alone. Ours is designed so that leaving it alone is safe — it shows when we last completed an observation, so a stale one is visibly stale rather than quietly wrong.
What it shows, and what it never shows
Never a bare number. A badge carrying only a score gives a reader no way to tell a fresh figure from a two-year-old one, and it keeps looking authoritative long after it stops being true. Every badge shows the date we last verified the endpoint, on its face.
No badge carries an issuance number. There is no sequence, no “#001” and no ordering of any kind — not for anyone. A number implying primacy is a permanent public identifier, and it would have to be minted before anything needed it. Adding a sequence later is easy; un-numbering badges already embedded across the internet is not.
Samples
These are rendered by the same code the endpoint runs.
A claim proved at the domain apex.
A claim proved on a different domain from the endpoint’s own — the mismatch is recorded in the badge metadata rather than smoothed over.
A server operated by an affiliated entity. The disclosure is on the badge itself.
No verified claim. A refusal is still a readable image.
Embedding one
The badge for an endpoint lives at its record slug:
https://mcpverify.ai/api/badge/~7baimarket_host~7d/mcp.svgIn Markdown, link the image to the record page so a reader can reach the evidence in one click:
[](https://mcpverify.ai/server/~7baimarket_host~7d/mcp)How to check a badge
Fetch the badge URL directly. This is the verification path, and it has to be stated rather than assumed: an <img> embed renders the picture and discards everything else, so the identifiers below are invisible to a reader looking at a README. Requesting the SVG itself — in a browser tab, or with curl — returns the same file with its <metadata> intact.
Inside it are the snapshot, the leaf and the chain entry the record belongs to:
curl -s https://mcpverify.ai/api/badge/~7baimarket_host~7d/mcp.svg | grep -A20 '<metadata>'Take the chain_gist_id to Verify the chain and check the published entry yourself. Nothing on this site has to be trusted to do that.
What those identifiers prove — and what they do not
The badge is chain-anchored, not cryptographically signed. There is no signing key, no published verification key and no signature to check. What it carries are pointers into a public record, and a reader verifies against that record rather than against our word. Saying otherwise would name a stronger property than exists.
- These identifiers show that the record is committed to a published merkle root.
- They do NOT prove this image came from us — anyone can copy an SVG and edit it.
- They do NOT prove the record describes the server this badge appears next to.
The second and third limits are the ones worth sitting with. Anyone can copy an SVG and change the date in it, and nothing in this design prevents that — what it gives a reader is a cheap way to check the real record instead of believing the picture. If that ever needs to be stronger for a particular buyer, a signature can be added on top of the anchoring; it is not a replacement for it, and we have not minted a key ahead of a use for one.
Affiliation
Any endpoint operated by an entity affiliated with us carries a visible affiliation note on the badge itself, not only on its record page — the badge is the surface that travels. Those endpoints are excluded from every ranking and from any aggregate presented as independent evidence.
Nothing here is issued for a real server
The badge endpoint refuses to issue for any real endpoint while this notice is up, and it now refuses for every endpoint on this site. That is the designed behaviour rather than a new restriction: the refusal was always keyed on the endpoint itself rather than on a build setting, precisely so that the arrival of real records could not quietly start issuing badges. Real records have now arrived, and every badge refuses.