Server logs a fabricated 'initialize' (with synthesized rmcp/3.8.0 peer identity) for no-initialize SEP-2567 requests, ignoring clientInfo from _meta
Maintainer thường phản hồi trong vòng 3 ngày
@jamadeo đang làm issue này rồi.
Từ ngày 3/11/2026.
Đánh giá
Issue này chưa được đánh giá.
Mô tả
Summary
On rmcp 3.8.0, a streamable-HTTP server emits a Service initialized as server peer_info=Some(InitializeRequestParams { ... }) INFO log line for every no-initialize (SEP-2567, protocol 2026-07-28) request, as though an initialize handshake had occurred. The logged peer identity is a synthesized Implementation { name: "rmcp", version: "3.8.0" }, and a clientInfo explicitly provided in the request's _meta (io.modelcontextprotocol/clientInfo) is ignored — never surfaced in the log.
This makes server-side logs actively misleading for client-behavior analysis: a sessionless 2.0 client appears in logs as a legacy initialize handshake from an rmcp client.
Environment
- rmcp 3.8.0, server role,
transport-streamable-http-server(StreamableHttpService+LocalSessionManager::default(), axumnest_service("/mcp", ...)) - Client: any no-initialize 2.0 caller (curl below; also observed with a real third-party client identifying as
zcode/0.17.1)
Reproduction
- Start any streamable-HTTP server built on rmcp 3.8 (e.g. the counter example) and note its stderr/journal.
- Send a no-initialize request (no
initializeever sent):
curl -sS -X POST http://127.0.0.1:8000/mcp \
-H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' \
-H 'MCP-Protocol-Version: 2026-07-28' -H 'Mcp-Method: tools/list' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{"_meta":{
"io.modelcontextprotocol/protocolVersion":"2026-07-28",
"io.modelcontextprotocol/clientInfo":{"name":"distinctive-probe-XYZ","version":"9.9.9"},
"io.modelcontextprotocol/clientCapabilities":{}}}}'
- The request succeeds (HTTP 200, tool list returned), and the server logs:
INFO serve_inner: rmcp::service: Service initialized as server peer_info=Some(InitializeRequestParams {
meta: None,
protocol_version: ProtocolVersion("2026-07-28"),
capabilities: ClientCapabilities { ... all None ... },
client_info: Implementation { name: "rmcp", title: None, version: "3.8.0", ... }
})
Two discrepancies vs. what actually happened on the wire:
- No
initializerequest was ever sent; the log fabricates one. - The client identified itself as
distinctive-probe-XYZ/9.9.9in_meta; the log showsrmcp/3.8.0.
Real-world impact
We spent three rounds of diagnosis mis-attributing a third-party client's behavior because its sessionless 2.0 requests were logged as initialize handshakes from "rmcp 3.8.0". This included incorrectly concluding the client used a legacy handshake and had a clientInfo of rmcp/3.8.0 (wire capture later disproved both). Details and retraction: zai-org/feedback#1372.
Suggested direction
- For no-initialize requests, log something that reflects the actual lifecycle (e.g.
stateless request served), notService initialized ... InitializeRequestParams. - Surface
io.modelcontextprotocol/clientInfofrom_metawhen present, so per-request identities are observable; if absent, make the synthesized default obviously synthetic (or omit identity from the log).
Happy to provide full tcpdump captures or a minimal repro project if useful.
- Ngôn ngữ chính
- Rust
- Star
- 4.1k
- Fork
- 694
- Merge trung bình
- 4 ngày 16 giờ
- Pull request đã merge (30 ngày)
- 43
Chuẩn bị môi trường
Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của modelcontextprotocol/rust-sdk
-
Return MergedList<T> from list_all_* and drop the _with_cache_hint variantsCó thể đã có người làm @DaleSeo đã nhận 2 ngày trước. Đang mởenhancement P3 ready for work T-service v4
modelcontextprotocol/rust-sdk#1430 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 3 ngày
-
OAuth discovery drops explicit default ports from advertised issuer identifiersCó thể đã có người làm @gocamille đã nhận 5 ngày trước. Đang mởbug P1 ready for work T-security T-transport
modelcontextprotocol/rust-sdk#1420 · 3 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 3 ngày
-
`register_client` drops `client_secret_expires_at` from the registration responseCó thể đã có người làm @gocamille đã nhận 6 ngày trước. Đang mởbug P2 ready for work T-security
modelcontextprotocol/rust-sdk#1416 · 1 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 3 ngày
-
Typed client calls drop the parse error when a reply misses a required fieldCó thể đã có người làm @gocamille đã nhận 6 ngày trước. Đang mởenhancement P2 ready for work T-core T-service
modelcontextprotocol/rust-sdk#1415 · 1 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 3 ngày
-
Return merged cache hints from list_all_* client methodsCó thể đã có người làm @DaleSeo đã nhận 1 ngày trước. Đang mởenhancement P2 ready for work T-service
modelcontextprotocol/rust-sdk#1411 · 1 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 3 ngày
Tất cả issue của modelcontextprotocol/rust-sdk
Issue tương tự
-
area/tools bug session-analysis
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 80/100
oracle/rust-oracledb#66 ·
-
p3 testing
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
respanai/respan-gateway#166 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
fixes
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
astral-sh/ruff#30076 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày