Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#439 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 7 日以内に返信

@marcus-kepler-92 がすでに取り組んでいます。

2026年8月4日 から。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
58/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
typescript
領域
testing-qa

調査の方向性

まず、input-required-result-capability-check の実装（dist/index.js にある生成後の形式を含む）と、issue で示されている関連シナリオを確認します。inputRequests が存在しない場合、空の場合、値が設定されている場合の動作を比較し、その後 conformance checks を実行して意図された verdicts を確認します。別途 schema/draft/schema.ts と SEP-2575 および json-schema-2020-12 のシナリオ処理を調査してから、deprecated な sampling と roots のケースをどのように評価すべきかを判断します。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
130
フォーク
107
平均マージ
8日 19時間
マージ済み PR（30日）
2

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

modelcontextprotocol/conformance のほかの issue

modelcontextprotocol/conformance の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。