Schema validation reuses the first schema registered under a $id: a changed outputSchema or a second tool with the same $id is validated against the wrong schema

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

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

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
68/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
typescript
領域
testing-qa

調査の方向性

Start by reading LinearPatternJsonSchemaValidator.getValidator and trace how its schema engine handles $id when schemas are compiled or reused. Reproduce both cases from the issue, then check the validator tests for coverage. Done means each call validates against the schema passed to it, including after a schema changes while retaining its $id.

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

説明

bug v2
Which version line?

v2 — current (@modelcontextprotocol/inspector@latest)

Which client?

All / shared core

Inspector version

2.14.0 (released package; also v2/main @ 3b387d3)

Node version

v22.23.4

Operating system (and browser, for the web client)

Linux (Debian)

Transport

Not applicable / never connected

MCP server under inspection

Any server whose tool outputSchema (or an elicitation requestedSchema) carries a $id. Reproduced directly against LinearPatternJsonSchemaValidator, which InspectorClient shares for the client's lifetime.

Steps to reproduce

getValidator does engine.getSchema(id) ?? engine.compile(schema) whenever the schema has a string $id, so whatever was first registered under that $id wins.

Case 1: tool output schema changes (e.g. after notifications/tools/list_changed) but keeps its $id:

const v = new LinearPatternJsonSchemaValidator();
const before = { $id: "urn:example:weather-output", type: "object",
  properties: { temp: { type: "number" } }, required: ["temp"] };
const after  = { $id: "urn:example:weather-output", type: "object",
  properties: { temp: { type: "string", pattern: "^-?\\d+C$" } }, required: ["temp"] };
v.getValidator(before)({ temp: 21 });
v.getValidator(after)({ temp: "21C" });  // conforms to the new schema
v.getValidator(after)({ temp: 21 });     // violates the new schema

Case 2: two tools declare the same $id (e.g. a generic "output"):

v.getValidator({ $id: "output", type: "object", required: ["a"] })({ a: 1 });
v.getValidator({ $id: "output", type: "object", required: ["b"] })({ b: 1 });
Expected behavior

Each call validates against the schema passed in: case 1 accepts "21C" and rejects 21; case 2 accepts { b: 1 }.

Actual behavior

Validated against the first schema registered under the $id:

  • case 1: { temp: "21C" } → data/temp must be number (false failure); { temp: 21 } → valid (false pass)
  • case 2: { b: 1 } → data must have required property 'a'

For an inspector, both directions matter: a server developer who fixes an outputSchema keeps seeing results checked against the old one until the client is recreated, and a non-conforming result passes.

Logs, errors, or screenshots

The same getSchema($id) ?? compile shape is in the SDK's AjvJsonSchemaValidator.getValidator (@modelcontextprotocol/client ajvProvider), which the Inspector used directly before 2.14, so this likely predates 2.14 and was carried into the 2.14 copy. Related SDK issue on the no-$id path: modelcontextprotocol/typescript-sdk#2605.

Already prototyped a fix?

Not a PR. Possible fix: only reuse getSchema(id) when the registered schema is deep-equal to the one passed in; otherwise removeSchema(id) and compile the new one (or key reuse on a stable hash of the schema rather than $id).

Before you submit
  • I searched existing issues and this is not a duplicate.
  • This is not a security vulnerability report (those go through the private advisory process).
主要言語
TypeScript
スター
11.3k
フォーク
1.6k
平均マージ
1時間 28分
マージ済み PR（30日）
138

環境構築

はじめの一歩

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

modelcontextprotocol/inspector のほかの issue

modelcontextprotocol/inspector の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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