Server logs a fabricated 'initialize' (with synthesized rmcp/3.8.0 peer identity) for no-initialize SEP-2567 requests, ignoring clientInfo from _meta #1425

Activity

1. github-actions

   added

   bugSomething is not workingSomething is not working

   P2Medium: important but non-blocking improvementMedium: important but non-blocking improvement

   T-serviceService layer changesService layer changes

   T-transportTransport layer changesTransport layer changes

   ready for workIssue is well-defined and ready to be picked upIssue is well-defined and ready to be picked up

   on Nov 3, 2026
2. github-actions

   assigned

   jamadeo

   on Nov 3, 2026
3. github-actions commented on Nov 3, 2026

   

   github-actionsBot

   on Nov 3, 2026 – with GitHub Actions

   Contributor

   More actions

   @jamadeo is on triage rotation this week and is the reviewer for this one.

   Codex labeled this bug / P2 (T-service, T-transport). Please confirm or correct those labels.

   _{Automated triage. Labels are a first pass and the assigned maintainer has the final say.}
4. jamadeo commented on Nov 3, 2026

   

   jamadeo

   on Nov 3, 2026

   Contributor

   More actions

   Thanks for the report - yes this is misleading. Logging the identity from _meta makes sense. As for the lifecycle accuracy, I think we could simply make it neutral, e.g. "Server service started"
5. jokemanfire commented on Nov 8, 2026

   

   jokemanfire

   on Nov 8, 2026

   Member

   More actions

   Reproduced on 3.8.0, and the cause is a synthesized peer identity plus a log message that is written for a handshake that never happened.

   Repro (no server code beyond the default config)

   StreamableHttpService<Calculator, LocalSessionManager> with with_legacy_session_mode(false), one POST with exactly your headers/body (Mcp-Method: tools/list, _meta clientInfo distinctive-probe-XYZ/9.9.9), log level INFO:

   INFO serve_inner: rmcp::service: Service initialized as server peer_info=Some(InitializeRequestParams {
     meta: None, protocol_version: ProtocolVersion("2026-07-28"),
     capabilities: ClientCapabilities { experimental: None, extensions: None, roots: None, sampling: None, elicitation: None },
     client_info: Implementation { name: "rmcp", title: None, version: "3.8.0", description: None, icons: None, website_url: None } })
   INFO serve_inner: rmcp::service: input stream terminated
   status=200 OK
   

   Both of your observations reproduce: no initialize was sent, and the _meta clientInfo never appears.

   Where it comes from

   1. peer_info_for_stateless_request (crates/rmcp/src/transport/streamable_http_server/tower.rs:2432-2451) builds an InitializeRequestParams for any request that is not an initialize: it takes the protocol version from the MCP-Protocol-Version header and hardcodes

      meta: None,
      capabilities: ClientCapabilities::default(),
      client_info: Implementation::default(),

      Implementation::default() is from_build_env() (crates/rmcp/src/model.rs:1700-1703), i.e. rmcp + CARGO_PKG_VERSION — hence rmcp/3.8.0.

   2. That synthesized value is passed to serve_directly_with_ct(..., peer_info, ...) (tower.rs:1537-1545, same for the negotiated path at 2308-2316) and becomes the peer's identity (service.rs:1291).

   3. serve_inner logs it unconditionally when a peer identity exists (service.rs:1351-1353):

      if R::IS_CLIENT { info!(?peer_info, "Service initialized as client") }
      else { info!(?peer_info, "Service initialized as server") }

   Nothing reads _meta even though the accessors exist and are already used for validation nearby: RequestMetaObject::client_info() / client_capabilities() (crates/rmcp/src/model/meta.rs:459-477).

   Options

   A. Read the client context out of _meta (recommended). In peer_info_for_stateless_request:

   let meta = request.request.get_meta();
   Some(InitializeRequestParams {
       meta: Some(meta.clone()),
       protocol_version: version,
       capabilities: meta.client_capabilities().unwrap_or_default(),
       client_info: meta.client_info().unwrap_or_default(),  // or an explicitly synthetic fallback
   })

   Logs become truthful for the SEP-2575 path, and handlers that inspect peer_info() (capabilities, client name) see what the client actually declared. Caveat: clientInfo is optional in the draft schema, so the fallback still needs a decision — I'd use something obviously synthetic (Implementation::new("unknown", "unknown")) rather than rmcp/<version>, so it can never be mistaken for an rmcp client again.

   B. Stop claiming an initialize happened. The message, not just the payload, is the bug: a no-initialize request should log e.g. stateless request served method=tools/list, at INFO or DEBUG. This needs the stateless origin plumbed into serve_inner (a flag, or a small enum next to peer_info) so it can pick the right wording; it is a slightly wider change than A but it is what makes the log self-describing.

   C. Minimal band-aid. Keep the synthesis, swap Implementation::default() for a synthetic identity and demote the line to DEBUG. Smallest diff, but the INFO line still says "Service initialized" if anyone turns DEBUG off... rather: the misleading wording survives for every other log consumer; I'd only take this as a stopgap.

   A + B together are what I'd merge: A removes the wrong identity, B removes the wrong verb. They also make the fix testable — a request with _meta.clientInfo should yield that client_info in peer_info, and a stateless request should not emit "Service initialized".

   Happy to send the PR for A (plus B if you want it in the same change); say the word and I'll put it against main with tests. I have not opened one, since this is your report and the fallback-identity choice is a maintainer call.