Build a small inventory of public promises
After launch, record where users can discover and install the server. Store the directory URL, external listing or PR reference, current package or endpoint, version where applicable, and the owner who can correct it. Include installation examples in your own docs.
This inventory can be a plain file in your release repository. It does not need to contain access tokens or personal account recovery details. Its purpose is to answer which public instructions may become wrong when a release changes.
- Identity: display name, registry name, repository owner, and source URL.
- Connection: package command or remote endpoint, transport, and minimum runtime.
- Access: required account, authentication method, and permission scopes.
- Evidence: latest date checked, safe test result, and a concrete public reference.
Use meaningful release triggers
Review listings when you rename a package, move a repository, replace an endpoint, change required configuration, add write capabilities, or drop a supported client. These changes alter a user’s installation or permission decision. A typo fix to an internal comment usually does not.
Compare the previous and next release from the perspective of someone following an old directory page. Can they still install it? Will they connect to the intended service? Will a newly requested permission surprise them? Resolve those issues before announcing broad availability.
Test the artifact referenced by each installation path
A remote deployment and a package release can drift even when they share source code. Test the exact command copied from the listing against the released package. Separately test the public endpoint and its authentication behavior. Record versions and dates so later debugging can distinguish a stale listing from a server regression.
For a plugin or bundle, test the packaged artifact rather than only its source repository. An omitted configuration file can break installation even when the underlying server still runs in development.
# Review the release changes that can affect public setup.
git diff PREVIOUS_TAG..NEW_TAG -- package.json server.json README.md
# Also inspect your actual endpoint/configuration and bundle files.
# Replace both tag placeholders before running.Update each target through its supported path
Do not assume every directory refreshes itself from your repository. A registry release, an edited Markdown PR, a claimed Glama record, and a revised hosted publishing configuration have separate control paths. Open the current destination instructions before making changes.
MCP Server List executes a checked, authorized launch and follows its supported provider results using bounded verification. It does not silently republish every later release or promise indefinite uptime monitoring. A changed artifact needs fresh eligibility checks and a newly reviewed scope. Existing listing corrections may require the publisher’s own supported management flow; do not presume a new submission is an update API.
Handle identity and ownership changes deliberately
A repository transfer can change who has access to a publishing namespace or listing-management account. Before the transfer, identify each control plane: GitHub ownership, package publishing, domain verification, directory claims, and secret management. Transfer or replace access through each service’s documented process.
Avoid silently reusing an old publisher identity for unrelated software. Explain legitimate moves in your release notes and retain redirects where appropriate. Check that links and badge destinations still point to the intended project after the change.
Close the loop with public evidence
After a correction, open the public page in a clean session and follow its install path. Record the final URL and what you verified. A submitted edit or support request remains pending until the visible record changes.
If a destination is no longer a fit, remove it from the next launch plan and explain the obsolete entry where the platform allows. Cursor Directory’s move toward plugins illustrates why a historical directory list should be treated as a starting point for investigation. Maintain fewer accurate records before adding more places to find an outdated command.
In the saved launch, keep the distinction between a provider request, accepted contribution, downstream ingestion and verified listing. A terminal attention state is useful evidence of an unresolved boundary, not a reason to replace it with a reassuring success label. Reconcile that boundary before buying another execution set.
Sources and scope
Primary documentation checked 2026-10-29. The workflow advice is MCP Server List’s editorial guidance; each destination controls its own current requirements and review.