Repository navigation
Idea: link each server to its observed tool-change history #1681
Description
The registry is a metadata catalog and leaves enrichment to sub-registries and clients. I maintain heldfast (Apache-2.0), which reads every server in the official registry (about 9,700 npm packages and 19,700 hosted endpoints), keeps each tool definition it was shown, grades each change, and seals each day. First-week report: https://github.com/rufat325/heldfast/blob/v0.2.3/docs/FIRST-WEEK.md
Two thirds of the registry is hosted, so there is no package to scan, and what those servers tell agents can change without a release. Idea: a sub-registry or client links each server to its observed change history, from an open feed.
Questions: (1) Is this useful? (2) Should it live outside the registry, as a sub-registry or community project? (3) Which fields would make it easy to consume, for example server name and version mapped to a digest history?
Separately, if GitHub's registry would rather consume a supported feed than link to an open one, I can provide that.
Activity
kaspermuutra-dotcom commentedon Oct 20, 2026
Useful idea, and it fits naturally with #1706. On question (3), the fields: server name plus version mapped to a digest of the canonicalized
tools/listoutput (names, schemas, annotations), with the observation timestamp and the observer's identity, would let a client answer "has what this server tells agents changed since I approved it?" without trusting any one observer. Including annotations in the digest matters: a tool flipping toreadOnlyHint: trueis exactly the kind of change a user should hear about.Kasper
rdimitrov commentedon Oct 23, 2026
Consolidating this tool-surface/history proposal into #82. I linked it there with the specific proposal preserved, including the distinction between publisher-attested fingerprints and externally observed change history. Canonicalization, dynamic/auth-dependent tools, annotations and verification semantics still need a design decision; this closure does not adopt a format or claim implementation.