Skip to content

chore: sync registry manifest versions to 3.0.0#186

Open
yawbtng wants to merge 1 commit into
browserbase:mainfrom
yawbtng:chore-sync-registry-manifests
Open

chore: sync registry manifest versions to 3.0.0#186
yawbtng wants to merge 1 commit into
browserbase:mainfrom
yawbtng:chore-sync-registry-manifests

Conversation

@yawbtng

@yawbtng yawbtng commented Jun 4, 2026

Copy link
Copy Markdown

Why

While reading the publish pipeline (.github/workflows/publish-mcp.yml) to understand how this server reaches the MCP registry, I noticed the registry manifests have drifted from the published package version.

package.json, CHANGELOG.md, and the latest git tag are all 3.0.0, but:

  • server.json is pinned at 2.2.0 (top-level + both the npm and OCI package entries)
  • gemini-extension.json is pinned at 2.4.1

publish-mcp.yml runs mcp-publisher publish, which uploads server.json verbatim to registry.modelcontextprotocol.io on each v* tag, and nothing in the release flow auto-bumps these files. So the official MCP registry advertises 2.2.0 for a package that is actually 3.0.0 on npm, and the Gemini extension manifest sits two minors behind.

What changed

Bumped the version fields in both manifests to 3.0.0 to match the currently-published package. No other fields touched.

  • server.json: 2.2.03.0.0 (×3 — top-level, npm package entry, OCI package entry)
  • gemini-extension.json: 2.4.13.0.0

Notes

  • No changeset: neither file is in the npm files allowlist, so this doesn't affect the published npm package — it only corrects repo-side registry metadata that had drifted (cf. [STG-1726] feat: rename package to @browserbasehq/mcp #166, where the manifest-version changeset was removed as unnecessary). A changeset would also bump the package past 3.0.0, re-introducing the drift this fixes.
  • Deliberately out of scope (follow-up candidates):
    • server.json's environment_variables list marks only GEMINI_API_KEY as required; since v3.0.0 the default is google/gemini-2.5-flash-lite and GOOGLE_API_KEY is also accepted. Left as-is to keep this a pure version sync.
    • The release workflow could auto-sync these manifest versions to package.json to prevent future drift.

Test plan

  • pnpm lint, pnpm build, pnpm test (15/15) all pass.
  • server.json and gemini-extension.json validate as JSON and pass prettier --check.

cc @shrey150 — packaging/distribution

server.json (2.2.0) and gemini-extension.json (2.4.1) had drifted from the
published package version (3.0.0 in package.json/CHANGELOG/tag). publish-mcp.yml
ships server.json verbatim to the MCP registry, so the registry advertised a
stale version. Bump both manifests to 3.0.0 to match.
@yawbtng

yawbtng commented Jun 10, 2026

Copy link
Copy Markdown
Author

Gentle nudge on this 🙏 — CI is sitting at action_required (first-time-contributor workflow approval), so the checks haven't run yet. If one of you can approve the run, it's a version-only sync of server.json/gemini-extension.json to 3.0.0 — the MCP registry currently advertises 2.2.0 (published verbatim from server.json) while npm is at 3.0.0. Happy to adjust if you'd prefer a different approach. cc @Kylejeong2 @shrey150

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant