input-required-result: sampling/roots scenarios vs SEP-2577, and capability-check accepting no inputRequests

[paulbalandan]

Referee 0.2.0-alpha.10, server mode, --spec-version 2026-07-28 --suite all.

Three scenarios in the SEP-2322 set that a server following SEP-2577 cannot pass, plus two separate observations about input-required-result-capability-check, which is the fourth. The first item may well be a deliberate call about what the suite is scoring, so that part is a question rather than a bug report. The last one looks like a plain defect.

1. Three scenarios require the server to emit a deprecated request

input-required-result-basic-sampling, input-required-result-basic-list-roots and input-required-result-multiple-input-requests pass only if the server under test puts a sampling/createMessage or roots/list entry in inputRequests.

In schema/draft/schema.ts, CreateMessageRequest, CreateMessageResult, SamplingMessage, ListRootsRequest, ListRootsResult, Root and the ClientCapabilities.sampling / .roots slots all carry @deprecated Deprecated as of protocol version 2026-07-28 (SEP-2577). ElicitRequest is the one member of the InputRequest union left unmarked. SEP-2577 says new implementations "should not add support for them", and the changelog's Deprecated section repeats it.

A server that takes that guidance is then required by the suite to fail. The capabilities side compounds it: ClientCapabilities.sampling and .roots carry the same deprecation, so a client written to this revision declares neither, and the ability these three scenarios test has no conformant counterparty to exercise it against.

This may be intentional. An argument for the current behaviour: the suite scores the spec surface as written, deprecated members included, and a deprecated feature is still a valid feature for the twelve months SEP-2596 guarantees. If that is the intent then the failures are correct and we will keep them baselined on our side.

If it is not, the suite already has the shape this would want. The SEP-2575 client scenario reads _meta['io.modelcontextprotocol/clientCapabilities'] and records SKIPPED for an absent capability, and json-schema-2020-12 gates on spec version the same way. Either would let these three skip rather than fail for a server that omits the deprecated half of the union.

2. input-required-result-capability-check rejects -32021

The scenario sends _meta['io.modelcontextprotocol/clientCapabilities'] = {sampling: {}} and expects inputRequests naming sampling only.

A server whose only input-request type is elicitation cannot serve that. The 2026-07-28 revision defines MissingRequiredClientCapabilityError (-32021) for this exact case: "Returned when processing a request requires a capability the client did not declare in clientCapabilities". The check treats any JSON-RPC error as a failure, so that response scores FAILURE.

Is -32021 meant to be an acceptable outcome here? It is the only answer the schema offers a server that has nothing it may ask of the capabilities the client did declare.

3. input-required-result-capability-check passes a result carrying no inputRequests

Independent of the above, and this one looks like a plain bug. Lifting the check body out of dist/index.js and running it directly:

Server returns	Verdict
{"resultType":"input_required","inputRequests":{"a":{"method":"sampling/createMessage"}}}	SUCCESS (intended)
{"resultType":"input_required","inputRequests":{"a":{"method":"elicitation/create"}}}	FAILURE (intended)
a complete result	FAILURE (intended)
{"resultType":"input_required","requestState":"abc"}	SUCCESS
{"resultType":"input_required"}	SUCCESS

The cause is the else if (F(r) && r.inputRequests) arm. With inputRequests absent the chain falls through to the trailing else, where I(r) is false for an input_required result, so no violation is recorded and the check passes. A server that asks for nothing at all satisfies a check whose description is "Server only includes inputRequests for declared client capabilities".

Asserting inputRequests is present and non-empty before the loop would close it.

[marcus-kepler-92]

@paulbalandan — if you weren't planning to pick this up yourself, I'd like to take
item 3. Root cause is the arm you identified; one thing to add is that
inputRequests: {} reaches SUCCESS too, by a different path — the arm is taken
({} is truthy) and the loop simply has nothing to scan.

The one place I'd land differently from your suggested fix. inputRequests is
optional — a result carrying only requestState still satisfies "at least one of
inputRequests or requestState" — so a server that names none hasn't violated
"servers MUST NOT send an inputRequests that the client has not declared support
for in its capabilities". It just never exercised it. Per #248 / #372 that reads as
an untestable prerequisite rather than a violation, so I've made it report through
notTestable() with details.untestable. Still FAILURE, still red in CI — just
labelled "could not be verified" instead of "server did this wrong". Happy to make
it a plain assertion as you proposed if maintainers prefer.

Worth flagging: this turns a conformant server red on that check. That's the
intended consequence of the #248 policy — the expected-failures baseline is the
escape hatch — but it is a behaviour change for anyone currently green there.

Verified against --spec-version 2026-07-28: everything-server still 2/2; the
broken fixture reports Not testable: server returned no inputRequests, so the capability restriction was never exercised. I'll open the PR shortly.

I'll leave items 1 and 2 alone — both read as maintainer calls. One pointer for
item 2 rather than an answer: stateless.ts handles the same tension by declaring
the needed capability at the probe site so -32021 can't fire where it isn't the
behaviour under test (see the comment on test_streaming_elicitation), which may
be the precedent worth applying either way.

Out of scope for this fix, but the same empty-map case has a round-2 consequence I
filed separately as #440.