Repository navigation
Publish rejects correct mcpName as stale/mismatched — npm registry confirms it's correct #1525
Description
GitHub username: lelu-auth
Organization: Lelu-ai
Namespace: io.github.Lelu-ai/lelu-mcp
Repository: https://github.com/Lelu-ai/lelu
NPM package: lelu-mcp
Environment: mcp-publisher 1.8.1
What happened
mcp-publisher publish consistently rejects the server with a 400, claiming the published npm package's mcpName doesn't match server.json's name — but it does, verified directly against the npm registry API multiple times over several hours (including across a full session restart).
Error: publish failed: server returned status 400: {"title":"Bad Request","status":400,"detail":"Failed to publish server","errors":[{"message":"registry validation failed for package 0 (lelu-mcp): NPM package ownership validation failed. Expected mcpName 'io.github.Lelu-ai/lelu-mcp', got 'io.github.lelu-ai/lelu-mcp'"}]}
Note the casing: expected io.github.Lelu-ai (capital L, the real org name), but the registry reports it "got" io.github.lelu-ai (lowercase) — even though the npm package has never had the lowercase value published.
Verification that npm's own data is correct
$ curl -s https://registry.npmjs.org/lelu-mcp/0.0.34 | jq .mcpName
"io.github.Lelu-ai/lelu-mcp"
$ curl -s https://registry.npmjs.org/lelu-mcp | jq '.["dist-tags"].latest, .versions[.["dist-tags"].latest].mcpName'
"0.0.34"
"io.github.Lelu-ai/lelu-mcp"
0.0.34 was published with the correct capital-L mcpName from the start (we caught and fixed a casing mismatch between our org name Lelu-ai and an earlier lowercase lelu-ai namespace before ever publishing this version). There is no version of lelu-mcp on npm that has ever published the lowercase io.github.lelu-ai value as mcpName — grepping the full version history confirms this.
Reproduction timeline
- Published
lelu-mcp@0.0.34withmcpName: "io.github.Lelu-ai/lelu-mcp" mcp-publisher publish→ 400, "got 'io.github.lelu-ai/lelu-mcp'" (lowercase)- Waited ~20 minutes, retried → same 400, byte-identical error
- Session restarted (unrelated), more time passed (at least an hour total)
- Retried again → same 400, byte-identical error
This strongly suggests the registry caches npm package metadata (specifically mcpName) somewhere in its publish-validation path, keyed in a way that doesn't invalidate on new publishes and doesn't expire within at least an hour.
Ask
Could someone check whether there's a stale cache entry for lelu-mcp on the registry side, and if so, clear it? Happy to provide more detail (org permission checks, PAT scopes, etc.) if useful — we already worked through the org-namespace permission requirements documented in #1468 / #1383 / #1435, this is a separate issue after permissions were confirmed correctly granted (the 403 became a 400 once the token carried io.github.Lelu-ai/* correctly).
Activity
sronix commentedon Aug 18, 2026
I do not think this is caused by stale registry-side npm metadata.
The validator fetches the exact version named in packages[].version. The current validation path does not cache npm package metadata.
npm shows that version 0.0.33 contains the lowercase value:
That value matches the error exactly. This suggests that the submitted package entry may still have named 0.0.33, even if the top-level server version and npm’s latest version were already 0.0.34.
Could you share the submitted packages block, or confirm its version value? If it says 0.0.34, then there is more to investigate.
The error should also name the package version it validated. That would make this failure much easier to diagnose. If the maintainers agree, I can send a small patch for that diagnostic improvement.
Abenezer0923 commentedon Aug 18, 2026
Hello @sronix
Thank you so much for digging into this — you nailed it exactly. The submitted packages[].version was still 0.0.33. server.json's top-level name had already been corrected to the capital-L io.github.Lelu-ai/lelu-mcp, but packages[0].version never got bumped past 0.0.33 when we cut 0.0.34, so mcp-publisher was validating against the old release — the one published before we caught the casing mismatch ourselves. Really sorry for the false lead on the caching theory, and thank you for taking the time to verify against the npm registry directly rather than just taking my report at face value.
It's fixed on our end now: server.json points at 0.0.34 (no npm republish needed — 0.0.34's npm data was already correct, it was only our server.json pin that was stale). Retrying mcp-publisher publish now. We've also added a small pre-publish check so server.json can't drift from package.json like this again.
And please do send that diagnostic patch if you're up for it — having the error name the version it actually validated would have saved a lot of back-and-forth here, and it'll help the next person who hits this too. Really appreciate you taking the time on this, thank you again 🙏
sronix commentedon Aug 18, 2026
Thanks for confirming. I opened PR #1544 with the diagnostic change. It updates the npm, PyPI, Cargo, and OCI ownership errors to name the package version or image reference they checked.
fix(mcp): sync server.json with published npm version; add nauro-brid…
rdimitrov commentedon Oct 23, 2026
Closing the original publishing report based on the reporter's confirmation:
packages[0].versionstill pointed at 0.0.33, whose mcpName had the old casing. Updating that pin to the already-correct 0.0.34 resolved the manifest mismatch; this was not a Registry metadata cache bug. The separate diagnostic improvement to include the checked package version remains open in PR #1544.