feat(local-mcp): report the real plugin version - #10
Open
steve-calvert-glean wants to merge 1 commit into
Open
Conversation
steve-calvert-glean
force-pushed
the
steve/local-mcp-plugin-version
branch
from
August 1, 2026 00:03
26065e0 to
502ddb2
Compare
steve-calvert-glean
changed the title
steve-calvert-glean
force-pushed
the
steve/local-mcp-plugin-version
branch
3 times, most recently
from
August 1, 2026 16:11
f699e4d to
b82b605
Compare
The local MCP server hardcoded version "1.0.0" in both its outbound clientInfo and its serverInfo. That placeholder never tracked the plugin version (3.2.0), so every install that ever shipped reports the same value and there is no way to tell versions apart. Read the version at runtime from the package.json already shipped next to the bundle. `../package.json` resolves in both contexts because the manifest sits one level above the code either way: dev sources/local-mcp/src/version.ts -> sources/local-mcp/package.json built <plugin-root>/dist/index.js -> <plugin-root>/package.json That manifest is guaranteed present next to the bundle — it is shipped specifically so Node loads dist/index.js as an ES module, so a missing manifest breaks module loading long before this read. Its version is kept in step with the repo-root package.json (the one release-it bumps) by the prebuild sync, extending the existing changelog propagation; sync-changelog.mjs is renamed to sync-release-metadata.mjs to match its widened job. release-it's after:bump hook runs the build before committing, so the bumped version lands in the release commit alongside the changelogs, and publish.yml's bare `build:bundle` needs no extra step because the committed manifest is already correct. No build-time injection: an earlier revision used an esbuild `define` with a declared-but-nonexistent global and a typeof guard, which left tests reading a 0.0.0-dev sentinel instead of real behavior. build.mjs is untouched here. Deliberately not touching the User-Agent header. That field identifies the calling client application, and in this path the client is the host (Claude Code, Codex, Cursor) — the plugin is an intermediary. Stamping the plugin there would collapse every host into one bucket in client_user_agent and lose host attribution. If that header is ever populated it should carry the host identity, which the local server already receives via the host's own clientInfo on the stdio connection. Note the version is therefore not yet visible backend-side: scio reads client_user_agent from the raw User-Agent header and does not log MCP clientInfo. Getting it to the backend wants a Glean-specific channel — most naturally a version field on GatewayRequestMetadata, which already carries the GLEAN_PLUGIN origin marker — needing a coordinated change in scio's api.proto.
steve-calvert-glean
force-pushed
the
steve/local-mcp-plugin-version
branch
from
August 1, 2026 16:14
b82b605 to
2e2b8bd
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The local MCP server hardcoded
version: "1.0.0"in its clientInfo and serverInfo. That placeholder never tracked the real plugin version (3.2.0), so every install ever shipped reports the same value.Now it reads the version at runtime from the
package.jsonalready shipped beside the bundle —../package.jsonresolves from bothsrc/anddist/, and that file must exist anyway for Node to load the bundle as ESM. The prebuild sync (sync-changelog.mjs→sync-release-metadata.mjs) keeps it in step with the root manifest that release-it bumps.Not changing the User-Agent
An earlier revision also set
User-Agent: glean-plugin/<version>, since that's what feeds the backend'sclient_user_agent. Dropped: that field identifies the calling client, which here is the host (Claude Code, Codex, Cursor) — the plugin is an intermediary. Stamping it would collapse every host into one bucket.Consequence: the version isn't visible backend-side yet. scio reads
client_user_agentfrom the header and doesn't log MCPclientInfo. A version field onGatewayRequestMetadatais the natural home, but that needs a coordinatedapi.protochange.Full reasoning in the commit message.