experimental.tasks.getTaskResult() throws TypeError: Cannot read properties of undefined (reading '_zod') when the optional result schema is omitted

Summary

client.experimental.tasks.getTaskResult(taskId) throws TypeError: Cannot read properties of undefined (reading '_zod') when called without an explicit result schema, which its type signature says is optional.

ExperimentalClientTasks.getTaskResult declares resultSchema?: T (src/experimental/tasks/client.ts) and forwards it to Protocol.getTaskResult, whose signature requires it (resultSchema: T) and passes it straight into request(). With undefined, validation reaches isZ4Schema(undefined) in src/server/zod-compat.ts, which reads ._zod off it.

Because the throw happens in _onresponse — inside the transport's message handler rather than in the awaited call path — it is also awkward to catch from application code.

Compare getTask and listTasks, which both pass a default schema; getTaskResult appears to have been missed.

Reproduction

import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { InMemoryTransport } from "@modelcontextprotocol/sdk/inMemory.js";
import { InMemoryTaskStore } from "@modelcontextprotocol/sdk/experimental/tasks/stores/in-memory.js";
import { CallToolRequestSchema, ListToolsRequestSchema } from "@modelcontextprotocol/sdk/types.js";

const store = new InMemoryTaskStore();
const server = new Server(
  { name: "repro", version: "1.0.0" },
  {
    capabilities: { tools: {}, tasks: { list: {}, cancel: {}, requests: { tools: { call: {} } } } },
    taskStore: store,
  },
);
server.setRequestHandler(ListToolsRequestSchema, () => ({
  tools: [{ name: "t", inputSchema: { type: "object" } }],
}));
server.setRequestHandler(CallToolRequestSchema, async (request, extra) => {
  const task = await extra.taskStore.createTask({ ttl: 60000 });
  await extra.taskStore.storeTaskResult(task.taskId, "completed", {
    content: [{ type: "text", text: "done" }],
  });
  return { task };
});

const [clientTransport, serverTransport] = InMemoryTransport.createLinkedPair();
const client = new Client({ name: "repro-client", version: "1.0.0" });
await Promise.all([server.connect(serverTransport), client.connect(clientTransport)]);

let taskId = "";
for await (const message of client.experimental.tasks.callToolStream({
  name: "t",
  arguments: {},
  task: { ttl: 60000 },
})) {
  if (message.type === "taskCreated") { taskId = message.task.taskId; break; }
  if (message.type === "result") { taskId = message.result.task?.taskId ?? ""; break; }
}

await client.experimental.tasks.getTaskResult(taskId); // TypeError

Expected

Either getTaskResult defaults to CallToolResultSchema (or ResultSchema) the way getTask and listTasks default theirs, or the parameter is made required so the type signature matches the behaviour.

Actual

TypeError: Cannot read properties of undefined (reading '_zod')
    at isZ4Schema (src/server/zod-compat.ts:60)
    at safeParse (src/server/zod-compat.ts:82)
    at src/shared/protocol.ts:1199
    at Client._onresponse (src/shared/protocol.ts:928)

Workaround

Pass the schema explicitly:

import { CallToolResultSchema } from "@modelcontextprotocol/sdk/types.js";
await client.experimental.tasks.getTaskResult(taskId, CallToolResultSchema);

Environment

• @modelcontextprotocol/sdk 1.30.0
• Node 22.23.1, macOS
• Both zod@3.25.76 and zod@4.1.5 present in the workspace; reproduced via the v3-resolved copy.

Happy to open a PR adding the default if that is the direction you would prefer.

Start in src/experimental/tasks/client.ts and compare getTaskResult with the default-schema handling in getTask and listTasks. Trace the forwarded schema through Protocol.getTaskResult in src/shared/protocol.ts and reproduce with the provided InMemoryTransport example. Done means calling getTaskResult(taskId) without a schema no longer throws, while the explicit-schema workaround remains supported.