get_info() builds its serverInfo with Implementation::from_build_env() (crates/bugwarden/src/server.rs). That constructor lives in rmcp and expands env!("CARGO_CRATE_NAME") / env!("CARGO_PKG_VERSION") inside the SDK, so the values are the SDK's own, not this crate's.
Observed against a stdio session (--transport stdio, handshake by hand):
{"jsonrpc":"2.0","id":0,"result":{"protocolVersion":"2025-11-25","capabilities":{"tools":{}},
"serverInfo":{"name":"rmcp","version":"3.1.0"}, "instructions":"MCP server for Bugzilla…"}}
So every client is told it is talking to rmcp 3.1.0. The instructions string is bugwarden's, which makes the mismatch worse rather than better: the identity and the description disagree.
Not a regression from the rmcp 3.1 bump. from_build_env is byte-identical in rmcp 2.2.0 (model.rs:1057-1066) and 3.1.0 (model.rs:1428-1437), so 0.3.0 and every release before it advertised rmcp/2.2.0 the same way. Only the version in the lie changed. Filed separately from the bump for that reason.
Why it matters beyond cosmetics:
- A client, proxy or gateway that routes, allowlists or logs by
serverInfo.name sees the SDK, so two different rmcp-based servers are indistinguishable to it.
- An operator debugging a fleet cannot tell from a client-side trace which server answered.
- The version reported is the SDK's, so "which bugwarden is deployed" is unanswerable from the handshake — the one question the field exists to answer.
Fix
Build the value from this crate rather than borrowing the SDK's:
Implementation {
name: env!("CARGO_PKG_NAME").to_owned(), // expands here, not in rmcp
version: env!("CARGO_PKG_VERSION").to_owned(),
..Default::default()
}
Acceptance criteria
get_info()builds itsserverInfowithImplementation::from_build_env()(crates/bugwarden/src/server.rs). That constructor lives in rmcp and expandsenv!("CARGO_CRATE_NAME")/env!("CARGO_PKG_VERSION")inside the SDK, so the values are the SDK's own, not this crate's.Observed against a stdio session (
--transport stdio, handshake by hand):{"jsonrpc":"2.0","id":0,"result":{"protocolVersion":"2025-11-25","capabilities":{"tools":{}}, "serverInfo":{"name":"rmcp","version":"3.1.0"}, "instructions":"MCP server for Bugzilla…"}}So every client is told it is talking to
rmcp 3.1.0. The instructions string is bugwarden's, which makes the mismatch worse rather than better: the identity and the description disagree.Not a regression from the rmcp 3.1 bump.
from_build_envis byte-identical in rmcp 2.2.0 (model.rs:1057-1066) and 3.1.0 (model.rs:1428-1437), so 0.3.0 and every release before it advertisedrmcp/2.2.0the same way. Only the version in the lie changed. Filed separately from the bump for that reason.Why it matters beyond cosmetics:
serverInfo.namesees the SDK, so two different rmcp-based servers are indistinguishable to it.Fix
Build the value from this crate rather than borrowing the SDK's:
Acceptance criteria
bugwardenand this crate's version.from_build_env()fails rather than silently re-borrowing the SDK's identity.mcp_server_info's ownname/versionoutput and the handshake agree (the tool already reportsbugwarden/0.3.0, so today they contradict each other).