SEP-1730's appendix asks SDK maintainers to "implement everything server based on a spec … check it into each SDKs repo". rust-sdk has the in-tree conformance/ binaries but no everything server (examples/clients/src/everything_stdio.rs is a client — see #769). Following docs/CONTRIBUTE.MD's discuss-first: we built one and would like to offer it in whatever form is least burden.
What it is — mcp-everything-server: rmcp 1.7-idiomatic, stdio + Streamable HTTP, Host/Origin validation on by default, implements every tool/resource/prompt the official server scenarios define, and passes the pinned suite (@modelcontextprotocol/conformance@0.1.16, spec 2025-11-25) at 40/40 checks across all 30 server scenarios in CI on every commit. A coverage manifest generated from tapped suite sessions keeps the capability surface honest (all seven server-party capability gates declared and exercised; 18 distinct wire methods observed).
Where it might help right now — running this repo's conformance-server (head 52e731b) against the same pinned suite today gives 38/40, failing prompts-get-with-args ("arg1 not substituted in prompt; arg2 not substituted in prompt") and elicitation-sep1330-enums ("Missing or invalid enumNames array for legacy titled enum", field legacyEnum). Repro: cargo build -p mcp-conformance --bin conformance-server, PORT=3000 ./target/debug/conformance-server, npx @modelcontextprotocol/conformance@0.1.16 server --url http://127.0.0.1:3000/mcp --spec-version 2025-11-25. Our server passes both scenarios, so the relevant handlers are directly borrowable. (The enumNames loss looks like an EnumSchema untagged-representation issue in rmcp itself rather than in the conformance-server — we have a test pinning the round-trip loss and will file that separately with a minimal repro.)
Possibly relevant to timing: the SEP-implementation issues for the 2026-07-28 window (#867–#878) will need a conformance target that keeps pace; we already track the RC text and plan dual-revision validation ahead of the release.
Three shapes, in whatever order suits you (referencing #684, since this is its territory):
In-tree adoption — we PR the server into this repo (relicensed Apache-2.0 to match, your style/CI; it's yours from then on).
Fixture adoption — we PR just the handlers/fixtures needed to take conformance-server to 40/40.
Stays external — it remains an independent cross-check and we cross-link.
No urgency from my side — happy to follow whatever process you prefer.
Cheers,
Tom
SEP-1730's appendix asks SDK maintainers to "implement everything server based on a spec … check it into each SDKs repo". rust-sdk has the in-tree conformance/ binaries but no everything server (examples/clients/src/everything_stdio.rs is a client — see #769). Following docs/CONTRIBUTE.MD's discuss-first: we built one and would like to offer it in whatever form is least burden.
What it is — mcp-everything-server: rmcp 1.7-idiomatic, stdio + Streamable HTTP, Host/Origin validation on by default, implements every tool/resource/prompt the official server scenarios define, and passes the pinned suite (@modelcontextprotocol/conformance@0.1.16, spec 2025-11-25) at 40/40 checks across all 30 server scenarios in CI on every commit. A coverage manifest generated from tapped suite sessions keeps the capability surface honest (all seven server-party capability gates declared and exercised; 18 distinct wire methods observed).
Where it might help right now — running this repo's conformance-server (head 52e731b) against the same pinned suite today gives 38/40, failing prompts-get-with-args ("arg1 not substituted in prompt; arg2 not substituted in prompt") and elicitation-sep1330-enums ("Missing or invalid enumNames array for legacy titled enum", field legacyEnum). Repro: cargo build -p mcp-conformance --bin conformance-server, PORT=3000 ./target/debug/conformance-server, npx @modelcontextprotocol/conformance@0.1.16 server --url http://127.0.0.1:3000/mcp --spec-version 2025-11-25. Our server passes both scenarios, so the relevant handlers are directly borrowable. (The enumNames loss looks like an EnumSchema untagged-representation issue in rmcp itself rather than in the conformance-server — we have a test pinning the round-trip loss and will file that separately with a minimal repro.)
Possibly relevant to timing: the SEP-implementation issues for the 2026-07-28 window (#867–#878) will need a conformance target that keeps pace; we already track the RC text and plan dual-revision validation ahead of the release.
Three shapes, in whatever order suits you (referencing #684, since this is its territory):
In-tree adoption — we PR the server into this repo (relicensed Apache-2.0 to match, your style/CI; it's yours from then on).
Fixture adoption — we PR just the handlers/fixtures needed to take conformance-server to 40/40.
Stays external — it remains an independent cross-check and we cross-link.
No urgency from my side — happy to follow whatever process you prefer.
Cheers,
Tom