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

skills/list, skills/get, resources/directory/read always fail: codec strips resultType before re-validating it

Cerrado
  • ¿Algo no está bien?
#2,789 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
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
76/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
nodejs, typescript
Área
api

Línea de trabajo

Lee core/mcp/skillsSchemas.ts y el flujo de decodeResult() y request() en dist/src-NAgB4Mp8.cjs. Ejecuta la reproducción de dos archivos con la Inspector CLI y, a continuación, verifica que skills/list, skills/get y resources/directory/read acepten resultados conformes con la especificación sin el error de validación.

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

Descripción

v2
Description

Client.request() in @modelcontextprotocol/client (v2.0.0, the "modern era" v2 client used by protocol revision 2026-07-28) rejects every spec-conforming skills/list / skills/get / resources/directory/read result with:

Invalid result for skills/list: resultType: Invalid input: expected "complete"

even though the server's response genuinely has resultType: "complete", exactly as the spec requires. This isn't a server bug to work around — no response shape a server can send will satisfy this check, because the client deletes the field it's about to require.

Root cause

decodeResult() validates resultType and then strips it from the result before handing it off:

// dist/src-NAgB4Mp8.cjs, decodeResult()
if (rawResultType !== "complete") return { kind: "invalid", ... };
...
const lifted = { ...raw };
delete lifted["resultType"];          // <-- stripped here
return { kind: "complete", result: lifted };

Client.request() then validates that already-stripped object against the caller-supplied resultSchema:

// same file, request()
const result = decoded.result;         // resultType is gone
validateStandardSchema(resultSchema, result).then((parseResult) => {
  if (parseResult.success) resolve(parseResult.data);
  else reject(new SdkError(SdkErrorCode.InvalidResult, `Invalid result for ${request.method}: ${parseResult.error}`));
}, reject);

The skills-extension (SEP-2640) methods still pass a schema that itself re-requires resultType:

// core/mcp/skillsSchemas.ts
const ModernListSkillsResultSchema = ListSkillsResultSchema.extend({
  resultType: z.literal("complete"),
  ttlMs: z.int().min(0),
  cacheScope: z.enum(["public", "private"]),
});

So the sequence for every call is: codec checks resultType === "complete" → strips it → hands the result to a schema that requires resultType === "complete" → fails, always. resources/directory/read (ModernDirectoryReadResultSchema) and skills/get (ModernGetSkillEnvelopeSchema) have the identical .extend({ resultType: z.literal("complete") }) pattern and are equally affected (confirmed for resources/directory/read; skills/get wasn't independently confirmed against a real skill, but goes through the exact same code path).

The core list methods (resources/list, prompts/list, tools/list) are unaffected because their result schemas don't redundantly declare resultType.

Reproduction

Fully self-contained, no external server needed - two files:

repro-server.mjs — minimal, spec-conforming 2026-07-28 server implementing only server/discover and skills/list:

import { createServer } from 'node:http';

const PROTOCOL_VERSION = '2026-07-28';

function rpcResult(id, result) {
  return {
    jsonrpc: '2.0',
    id,
    result: { ...result, resultType: 'complete', ttlMs: 0, cacheScope: 'private' },
  };
}

createServer((req, res) => {
  let body = '';
  req.on('data', (c) => (body += c));
  req.on('end', () => {
    const message = JSON.parse(body || '{}');
    res.setHeader('Content-Type', 'application/json');

    if (message.method === 'server/discover') {
      res.writeHead(200);
      res.end(JSON.stringify(rpcResult(message.id, {
        supportedVersions: [PROTOCOL_VERSION],
        capabilities: {
          resources: {}, tools: {}, prompts: {},
          extensions: { 'io.modelcontextprotocol/skills': { directoryRead: true } },
        },
      })));
      return;
    }

    if (message.method === 'skills/list') {
      // Spec-conforming: resultType is "complete", as the 2026-07-28 revision requires.
      res.writeHead(200);
      res.end(JSON.stringify(rpcResult(message.id, { skills: [] })));
      return;
    }

    res.writeHead(404);
    res.end(JSON.stringify({ jsonrpc: '2.0', id: message.id, error: { code: -32601, message: 'not implemented in this repro' } }));
  });
}).listen(8080, () => console.log('Repro server listening on http://localhost:8080/mcp'));

repro-catalog.json — forces the Inspector CLI to skip legacy handshake detection and connect directly in modern era:

{
  "mcpServers": {
    "repro": {
      "type": "streamable-http",
      "url": "http://localhost:8080/mcp",
      "protocolEra": "modern"
    }
  }
}

Steps:

node repro-server.mjs &
npx @modelcontextprotocol/inspector --cli --catalog ./repro-catalog.json --server repro --method skills/list

Result:

{"error":{"code":"error","message":"Invalid result for skills/list: resultType: Invalid input: expected \"complete\""}}
Expected

skills/list (and skills/get, resources/directory/read) should succeed against a server that returns a fully spec-conforming { skills: [...], resultType: "complete", ttlMs, cacheScope } result.

Suggested fix

ModernListSkillsResultSchema / ModernGetSkillEnvelopeSchema / ModernDirectoryReadResultSchema shouldn't re-declare resultType at all, since decodeResult() has already validated and stripped it by the time these schemas run - they should look like their non-"Modern" counterparts (ListSkillsResultSchema etc.), with the modern-vs-legacy distinction handled entirely by the codec layer, consistent with how the core list methods already work.

Environment
  • @modelcontextprotocol/inspector 2.6.0 (bundles @modelcontextprotocol/client 2.0.0)
  • Node v25.2.1, macOS 26.6.2 (also reproduced against a real application server, not just the minimal repro above)
Lenguaje dominante
TypeScript
Estrellas
13.6k
Forks
2.3k
Merge medio
1 d 14 h
PR fusionados (30 d)
53

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/typescript-sdk

Todos los issues de modelcontextprotocol/typescript-sdk

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.