Changelogs

Changelogs

Every listing that has changed gets a changelog at /servers/<name>/changelog, with one page per kind of change under it. The registry-wide changelog shows the latest changes across all listings.

What is recorded

Kind	Source	Recorded as
server.json	official registry sync	each publisher-controlled field, old → new: version, title, description, URLs, package, environment variables, licence, icon
Tools	prober	names added and removed
Prompts	prober	names added and removed
Resources	prober	names added and removed
llms.txt	document fetcher	lines added and removed; the file appearing or disappearing
AGENTS.md	document fetcher	lines added and removed; the file appearing or disappearing

A document shared by many listings is recorded once and shown on every listing that points at it.

What is not recorded

A changelog that reports our own bookkeeping as the publisher's activity is worse than none, so these are deliberately left out:

• First sight. A listing's first import, or a file's first fetch, is a baseline, not an event.
• Tools changing from declared to probed. That is our knowledge improving, not the server changing.
• Lists at the 500-item cap. When a server with 1,000 resources adds one, another falls off the end of what we keep, which would look like a removal that never happened.
• Our own re-processing of data that did not change upstream.
• Outages. A timeout or a 5xx keeps what was known. An outage is not a removal.

Why polling and not webhooks

A GitHub webhook needs admin rights on the repository, or a GitHub App its owner installs. Neither exists for the tens of thousands of repositories in the registry, and websites serving llms.txt offer no webhooks at all. So every source is polled on a schedule.

Polling is cheap because it is conditional: an unchanged file answers 304 Not Modified with no body. A GitHub App could later offer publishers instant updates as an opt-in, but it could never replace polling for everyone else.