What problem does this solve?
server.json tells MCP clients how to install Codebase Memory, but it does not expose the selection facts an agent needs when comparing code-intelligence servers: whether it can run unattended, where it runs, which concrete tool functions it provides, and which local or persistent side effects consumers should account for.
This matters especially for Codebase Memory because it is a local stdio server that builds and maintains a persistent codebase knowledge graph. Those are useful, differentiating facts, but today an agent or catalog has to infer them from prose and source code.
Proposed solution
Would you be open to a small PR that adds publisher-reviewed ASM selection metadata under the MCP Registry's existing publisher-provided container?
_meta.io.modelcontextprotocol.registry/publisher-provided.asm
I would keep the change limited to server.json (plus the existing release version updater only if required), with:
- exact MCP tool/function names;
- stdio/local invocation and setup facts;
- explicit persistent-index / filesystem side effects and approval boundaries;
- source provenance and
self_reported status;
- no invented pricing, SLA, or universal quality score.
There would be no runtime/API change, new dependency, external CI action, partnership claim, or claim of independent verification. The card would be checked against both the MCP Registry schema and asm-protocol==0.6.0 before submission.
Reference shape: ASM producer adoption package.
If this scope is acceptable, I can prepare the focused, signed-off PR for maintainer review. If the project prefers a different field boundary, I would use that before writing code.
Alternatives considered
- A separate sidecar manifest would avoid touching
server.json, but it would be harder for MCP Registry consumers to discover and keep version-aligned.
- Scraping the README/source at selection time is less deterministic and leaves side-effect interpretation to each client.
Confirmations
What problem does this solve?
server.jsontells MCP clients how to install Codebase Memory, but it does not expose the selection facts an agent needs when comparing code-intelligence servers: whether it can run unattended, where it runs, which concrete tool functions it provides, and which local or persistent side effects consumers should account for.This matters especially for Codebase Memory because it is a local stdio server that builds and maintains a persistent codebase knowledge graph. Those are useful, differentiating facts, but today an agent or catalog has to infer them from prose and source code.
Proposed solution
Would you be open to a small PR that adds publisher-reviewed ASM selection metadata under the MCP Registry's existing publisher-provided container?
I would keep the change limited to
server.json(plus the existing release version updater only if required), with:self_reportedstatus;There would be no runtime/API change, new dependency, external CI action, partnership claim, or claim of independent verification. The card would be checked against both the MCP Registry schema and
asm-protocol==0.6.0before submission.Reference shape: ASM producer adoption package.
If this scope is acceptable, I can prepare the focused, signed-off PR for maintainer review. If the project prefers a different field boundary, I would use that before writing code.
Alternatives considered
server.json, but it would be harder for MCP Registry consumers to discover and keep version-aligned.Confirmations