Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#439 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
58/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
typescript
Ambito
testing-qa

Direzione di ricerca

Inizia esaminando l’implementazione di input-required-result-capability-check, inclusa la relativa forma generata in dist/index.js, e gli scenari correlati menzionati nell’issue. Confronta il comportamento per inputRequests mancanti, vuote e valorizzate, quindi esegui i controlli di conformità per confermare i verdetti previsti. Esamina separatamente schema/draft/schema.ts e la gestione degli scenari SEP-2575 e json-schema-2020-12 prima di decidere come dovrebbero essere valutati i casi deprecati di sampling e roots.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
127
Fork
101
Merge medio
4g 7h
PR unite (30g)
6

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di modelcontextprotocol/conformance

Tutte le issue di modelcontextprotocol/conformance

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.