registry

Summary Need metadata correction for an already-published server version: Server: Version: Current registry payload (latest) shows stale metadata: : : Desired values: : : Repro / Evidence 1. Verify current registry payload: 2. Attempted direct publish via after auth: 3. Response: So this appears to require a maintainer-side metadata correction/override for an existing version. Request Please advise whether metadata for an existing published version can be corrected, and if yes, apply the above website/description update for . Thanks.

Guidance for Deploying MCP Registry in Enterprise Environments We are exploring how to run an internal MCP Registry inside our enterprise environment. After reviewing the ecosystem vision, it appears the project offers: 1. The MCP Registry spec, and 2. An official registry app intended for the public MCP registry. When evaluating the official app for internal use, we noticed few public-registry assumptions that don’t align with typical enterprise setups, for example: Uses public npm registry instead of internal Artifactory/Nexus Expects GitHub URLs to be instead of GitHub Enterprise Runs DB schema migrations on startup, which many enterprises restrict Because of this, running the app internally would require changes that feel like maintaining a fork — something we’d like to avoid. Looking for Advice / Recommendations 1. What approach do you recommend for enterprises wanting a private MCP registry? Build a separate implementation based on the spec? Or customize and deploy the official registry app internally? 2. Are there plans to publish an official Docker image with configurable endpoints (DB connection, package registry, Git provider, etc.) to support enterprise deployments? 3. More broadly, what is the project’s vision for enterprise MCP registries? Understanding this would help us align with the intended ecosystem direction. Thanks for your work on MCP and appreciate for any guidance you can share.