Skip to content

Record what changes about each MCP server, and publish changelogs - #74

Merged
lbesecker195 merged 1 commit into
mainfrom
feat/change-history
Oct 1, 2026
Merged

lbesecker195 merged 1 commit into
mainfrom
feat/change-history

Conversation

@lbesecker195

Copy link
Copy Markdown
Owner

Closes #73.

The sync re-reads server.json every six hours and the prober re-asks each remote server what it exposes. Both overwrote what they found, so nothing remembered what changed. This keeps the difference and publishes it.

Pages

  • /servers/:ns/:name/changelog — every recorded change, grouped by day
  • /servers/:ns/:name/changelog/:kind — tools, prompts, resources or server-json alone
  • /changelog — the latest 100 changes across the registry, each linking into its listing

Like every other silo, a page exists only once there's something on it: no history redirects to the listing; a kind the listing has none of redirects to its changelog. The listing header links changelog · N only when N > 0. All three are in the sitemap (changelogs-N.xml, and /changelog in pages.xml).

What is recorded

  • server.json: taken from the sync's own changeset, restricted to fields the publisher controls (title, description, version, transport, URLs, package, env vars, license, status, icon), stored as old → new.
  • tools / prompts / resources: set differences between two probes, kept in the server's own order.

What is deliberately not recorded

A changelog that reports our bookkeeping as the publisher's activity is worse than none:

Not recorded Why
first sight a baseline, not an event
declared tools → probed tools our knowledge improving, not the server changing
prompt/resource lists from before 24 Sep those probes never asked; "empty" meant "not asked"
any list at the 500-item cap a server adding one item pushes another off our end — a removal that never happened
sync(reapply: true) changes how we read upstream, not what was published
a probe whose write failed the change is written only after the row it describes

A database check constraint enforces that every change is about exactly one subject — a listing now, a document URL once llms.txt/AGENTS.md land in the follow-up.

Cadence

Probes now recur every 7 days rather than 14, so a changelog is at most a week behind its server: ~3,000 endpoints a day against a scheduler that can ask ~28× that.

Tests: 207 passing on three seeds, including integration through a real probe batch and a real sync.


Pages affected:

🤖 Generated with Claude Code

The sync re-reads server.json every six hours and the prober re-asks each
remote server what it exposes. Both overwrote what they found. This keeps
the difference.

- /servers/*/changelog, per-kind pages under it, and a site-wide
  /changelog; each exists only once there is something on it
- server.json changes are taken from the sync's own changeset, so only
  fields the publisher controls are reported, as old -> new
- Probe changes are set differences, kept in the server's order

Most of the rules are about what is not a change: first sight, declared
tools giving way to probed ones, prompt lists from before prompts were
asked for, lists at the 500-item cap (where one addition would read as a
removal), and the sync's re-apply runs. A change is written only after the
row it describes, so it can never record a state the listing never reached.

Probes now recur weekly instead of fortnightly.

Closes #73

---

Pages affected:

- [MCP server changelog](https://ai.mcpharbor.dev/changelog) -- new tools, prompts and versions across the registry.
- [MCP Harbor](https://ai.mcpharbor.dev/) -- registry home and search.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@lbesecker195
lbesecker195 merged commit cebdc0a into main Oct 1, 2026
1 check passed
@lbesecker195
lbesecker195 deleted the feat/change-history branch October 1, 2026 11:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Changelogs: record what changes about each MCP server

1 participant