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

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

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
68/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
testing-qa

Línea de trabajo

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.

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

Descripción

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).
Lenguaje dominante
TypeScript
Estrellas
11.3k
Forks
1.6k
Merge medio
1 h 28 min
PR fusionados (30 d)
138

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/inspector

Todos los issues de modelcontextprotocol/inspector

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.