Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Chiusa
  • Qualcosa non va?
#2,789 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
76/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
nodejs, typescript
Ambito
api

Direzione di ricerca

Leggi core/mcp/skillsSchemas.ts e il flusso di decodeResult() e request() in dist/src-NAgB4Mp8.cjs. Esegui la riproduzione in due file con la Inspector CLI, quindi verifica che skills/list, skills/get e resources/directory/read accettino risultati conformi alle specifiche senza l'errore di validazione.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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)
Lingua principale
TypeScript
Stelle
13.5k
Fork
2.3k
Merge medio
1g 22h
PR unite (30g)
52

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di modelcontextprotocol/typescript-sdk

Tutte le issue di modelcontextprotocol/typescript-sdk

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.