modelcontextprotocol/typescript-sdk

Summary packages/middleware/node/test/streamableHttp.test.ts has tests that call reader.read() once and then assert the accumulated text contains multiple SSE events. On Node v26.7.0, fetch can deliver those SSE events in separate chunks, so the middleware behavior works but the tests fail before reading the later events. Reproduction Run pnpm install --frozen-lockfile Run pnpm build:all Run pnpm --filter @modelcontextprotocol/node test -- test/streamableHttp.test.ts Observed failures: should handle batch request messages with SSE stream for responses reads only the req-1 event and then fails before reading req-2. should store and replay MCP server tool notifications reads an earlier {} event and then fails before reading Second notification from MCP server. Suggested fix Read from the SSE stream until the expected event text appears or a short timeout/cancel occurs, instead of assuming multiple SSE events share one fetch chunk. I pushed a minimal branch here: https://github.com/js

What happened? Connecting to an unreachable host with versionNegotiation: { mode: "auto" } rejects with an SdkError whose cause is undefined. The underlying TypeError: fetch failed — and the DNS error beneath it that actually names the failure — is retained, but at error.data.cause. Anything walking the standard .cause chain stops at the SdkError. classifyNetworkError passes { cause: error } as the third argument: // dist/index.mjs:2400 return { kind: "error", error: new SdkError(SdkErrorCode.EraNegotiationFailed, `Version negotiation probe failed: ${describeError(error)}`, { cause: error }) }; But SdkError's third parameter is data, not ErrorOptions, and super() is called without it: // dist/src-D_zzAWoS.mjs:342 var SdkError = class extends Error { constructor(code, message, data) { super(message); // <- options never forwarded this.code = code; this.data = data; // <- the { cause } object lands here this.name = "SdkError"; stampErrorBrands(this, new.t

Summary On SDK v1 (still latest on npm as of this writing — 1.30.0), passing a ZodObject (z.object({...})) where the API expects a Zod raw shape ({ field: z.string() }) produces failure modes that are either silent or cryptic, depending on the version and the API used. None of them point the developer at the actual mistake, and neither the troubleshooting page nor the v1→v2 migration guide mentions these symptoms. I hit this while building scorm-mcp-server and lost the better part of a day on it: the server started fine, tools/list looked plausible, but every client silently stripped my tool arguments. I've since tested the behavior across v1 versions — full matrix below. Reproduction matrix Minimal repro: register one tool with inputSchema: z.object({ name: z.string() }) (instead of the raw shape { name: z.string() }), connect an in-memory client, call tools/list. SDK version registerTool + z.object() server.tool() (positional) + z.object() 1.12.0 → 1.21.0 ❌ tools/lis

Describe the bug When you cancel a request using AbortSignal, the error you get back has code: 'REQUEST_TIMEOUT' — the same code as an actual timeout. There's no way to tell them apart. I had logic like this in my app: if (error.code === SdkErrorCode.RequestTimeout) { showRetryMessage(); // was also firing on manual user cancellation } Both a real timeout and a deliberate controller.abort() hit the same fallback in cancel() inside protocol.ts (line ~910), which unconditionally wraps any non-SdkError reason as SdkErrorCode.RequestTimeout. To Reproduce import { Client } from '@modelcontextprotocol/client'; import { Server } from '@modelcontextprotocol/server'; import { InMemoryTransport, SdkError, SdkErrorCode } from '@modelcontextprotocol/core'; const [clientTransport, serverTransport] = InMemoryTransport.createLinkedPair(); const server = new Server({ name: 'test-server', version: '1.0' }); const client = new Client({ name: 'test-client', version: '1.0' }); // handler that hangs

While reading the v2 README, I noticed @modelcontextprotocol/fastify is published (packages/middleware/fastify/package.json has "private": false and the same 2.0.0-alpha.2 version as the other middleware packages) but absent from the README in three places: Overview (around line 32) — the parenthetical reads "(Express, Hono, Node.js HTTP)"; Fastify is omitted. Middleware packages section (around lines 49–52) — the bullet list documents @modelcontextprotocol/node, /express, and /hono with no /fastify entry. Installation (around lines 83–91) — npm install commands for node, express, and hono, with no fastify line. The other three middleware packages share the same private: false + 2.0.0-alpha.2 shape and are documented, so this looks like an oversight rather than intentional exclusion. The package already has its own packages/middleware/fastify/README.md. Happy to send a small docs-only PR adding fastify alongside the other three. Let me know if there's a reason fastify shoul