Server scenarios fail servers for capabilities they never declared

Examine the conformance test suite structure, likely in a src/ or tests/ directory. Look for scenario definitions and how they are gated or filtered. The issue mentions specific scenario categories like prompts-* and resources-*. Find where server capabilities from the initialize method are read and used to determine test applicability. Understanding the test runner and reporting logic is key to implementing the suggested gating.

The same minimal server as above declares only tools. Against it, server mode reports 6 passed, 24 failed. Nearly all of the 24 are not conformance failures:

For comparison, @modelcontextprotocol/server-everything 2026.8.31 scores 13 passed, 19 failed on 0.1.16.

This is expected for a suite built to test SDKs against the everything-server. The result is still that the suite cannot be pointed at a production server to answer "is this server conformant?", which is the question most operators and registries are asking. A correct server scores 6/30, and its only real defect is buried among 23 false ones.

Suggestions, cheapest first:

1. Gate on declared capabilities. Read capabilities from initialize and report prompts, resources, logging and completions scenarios as not applicable when the capability is absent. Answering -32601 for an undeclared capability is what the spec says to do.
2. Mark fixture-dependent scenarios (those that call test_* tools or test:// resources) as needing the fixture, and report them as not applicable when the tool is missing from tools/list, rather than failing them.
3. A capability-agnostic suite (e.g. --suite production) holding only the scenarios that apply to any server: initialize, ping, tools/list shape, unknown-method and invalid-params handling, session handling, protocol-version header validation, and DNS-rebinding protection. That would let registries and operators cite the official suite for a real server.

Happy to contribute scenarios for (3) if that direction is welcome.