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

[Sonander]

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)

[tiagovilasboas]

I'd like to take this.

Plan: stop Client.request() from re-validating a result that decodeResult() already stripped of resultType. Keep codec complete-result lifting, and make the skills/directory schemas (and any other caller schemas that still require resultType) match the post-decode shape — or pass the unstripped result into resultSchema. Add regressions for skills/list, skills/get, and resources/directory/read so a spec-conforming resultType: "complete" payload is accepted.

Fork is ready (tiagovilasboas/typescript-sdk). Happy to open a PR today.