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

Fechada
  • Algo errado?
#2,789 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
76/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
nodejs, typescript
Domínio
api

Direção de pesquisa

Leia core/mcp/skillsSchemas.ts e o fluxo de decodeResult() e request() em dist/src-NAgB4Mp8.cjs. Execute a reprodução de dois arquivos com a Inspector CLI e, em seguida, verifique se skills/list, skills/get e resources/directory/read aceitam resultados em conformidade com a especificação sem o erro de validação.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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)
Linguagem predominante
TypeScript
Estrelas
13.7k
Forks
2.3k
Merge médio
2d 7h
PRs com merge (30d)
26

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de modelcontextprotocol/typescript-sdk

Todas as issues de modelcontextprotocol/typescript-sdk

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.