Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#439 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 7 días

@marcus-kepler-92 ya está trabajando en esto.

Desde el 4/8/2026.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
58/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
typescript
Área
testing-qa

Línea de trabajo

Empieza revisando la implementación de input-required-result-capability-check, incluida su forma generada en dist/index.js, y los escenarios relacionados mencionados en el issue. Compara el comportamiento para inputRequests ausentes, vacíos y con contenido, y luego ejecuta las comprobaciones de conformidad para confirmar los veredictos previstos. Inspecciona por separado schema/draft/schema.ts y el manejo de los escenarios SEP-2575 y json-schema-2020-12 antes de decidir cómo deberían puntuarse los casos obsoletos de sampling y roots.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
130
Forks
107
Merge medio
8 d 19 h
PR fusionados (30 d)
2

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de modelcontextprotocol/conformance

Todos los issues de modelcontextprotocol/conformance

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.