You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
`setRequestHandler`/`setNotificationHandler` accept the v1 `(ZodSchema, handler)` form as a first-class alternative to `(methodString, handler)`. `request()` accepts an explicit result schema (`request(req, resultSchema, options?)`) and has a method-keyed return type for spec methods. `callTool(params, resultSchema?)` accepts the v1 schema arg (ignored). `removeRequestHandler`/`removeNotificationHandler`/`assertCanSetRequestHandler` accept any method string.
**Custom (non-standard) methods** — vendor extensions or sub-protocols whose method strings are not in the MCP spec — work on `Client`/`Server` directly using the same v1 Zod-schema form:
|`ctx.mcpReq.elicitInput(params, options?)`| Elicit user input (form or URL) |`server.elicitInput(...)` from within handler |
407
416
|`ctx.mcpReq.requestSampling(params, options?)`| Request LLM sampling from client |`server.createMessage(...)` from within handler |
408
417
409
-
## 11. Schema parameter removed from `request()`, `send()`, and `callTool()`
418
+
## 11. Schema parameter on `request()` / `callTool()` is optional; removed from `send()`
410
419
411
-
`Protocol.request()`, `BaseContext.mcpReq.send()`, and `Client.callTool()`no longer take a Zod result schema argument. The SDK resolves the schema internally from the method name.
420
+
`Protocol.request()`and `Client.callTool()`still accept a Zod result schema as the second argument (the v1 form), but it is optional for spec methods — the SDK resolves the schema internally from the method name. `BaseContext.mcpReq.send()` no longer takes a schema.
412
421
413
422
```typescript
414
423
// v1: schema required
@@ -417,20 +426,20 @@ const result = await client.request({ method: 'tools/call', params: { ... } }, C
|`client.callTool(params, CompatibilityCallToolResultSchema)`|unchanged (schema ignored), or `client.callTool(params)`|
442
+
|`client.callTool(params, schema, options)`|unchanged, or `client.callTool(params, options)`|
434
443
435
444
Remove unused schema imports: `CallToolResultSchema`, `CompatibilityCallToolResultSchema`, `ElicitResultSchema`, `CreateMessageResultSchema`, etc., when they were only used in `request()`/`send()`/`callTool()` calls.
### `Protocol.request()`, `ctx.mcpReq.send()`, and `Client.callTool()` no longer take a schema parameter
391
+
### Custom (non-standard) protocol methods
392
392
393
-
The public `Protocol.request()`, `BaseContext.mcpReq.send()`, and `Client.callTool()` methods no longer accept a Zod result schema argument. The SDK now resolves the correct result schema internally based on the method name. This means you no longer need to import result schemas
394
-
like `CallToolResultSchema` or `ElicitResultSchema` when making requests.
393
+
Vendor-specific methods are registered directly on `Client` or `Server` using the same Zod-schema form as v1: `setRequestHandler(zodSchemaWithMethodLiteral, handler)`. `request({ method, params }, ResultSchema)` and `notification({ method, params })` are unchanged from v1.
394
+
395
+
```typescript
396
+
import { Server } from'@modelcontextprotocol/server';
### `Protocol.request()` and `Client.callTool()` schema parameter is now optional
407
+
408
+
The public `Protocol.request()` and `Client.callTool()` methods still accept a result schema argument, but for spec methods it is optional — the SDK resolves the correct schema internally from the method name. You no longer need to import result schemas
409
+
like `CallToolResultSchema` or `ElicitResultSchema` when making requests. (`BaseContext.mcpReq.send()` no longer accepts a schema; drop it.)
| Interactive Streamable HTTP client | CLI client that exercises tools/resources/prompts, notifications, elicitation, and tasks. |[`src/simpleStreamableHttp.ts`](src/simpleStreamableHttp.ts)|
30
-
| Backwards-compatible client (Streamable HTTP → SSE) | Tries Streamable HTTP first, falls back to legacy SSE on 4xx responses. |[`src/streamableHttpWithSseFallbackClient.ts`](src/streamableHttpWithSseFallbackClient.ts)|
31
-
| SSE polling client (legacy) | Polls a legacy HTTP+SSE server and demonstrates notification handling. |[`src/ssePollingClient.ts`](src/ssePollingClient.ts)|
| Multiple clients in parallel | Connects multiple clients concurrently to the same server. |[`src/multipleClientsParallel.ts`](src/multipleClientsParallel.ts)|
| Interactive Streamable HTTP client | CLI client that exercises tools/resources/prompts, notifications, elicitation, and tasks. |[`src/simpleStreamableHttp.ts`](src/simpleStreamableHttp.ts)|
30
+
| Backwards-compatible client (Streamable HTTP → SSE) | Tries Streamable HTTP first, falls back to legacy SSE on 4xx responses. |[`src/streamableHttpWithSseFallbackClient.ts`](src/streamableHttpWithSseFallbackClient.ts)|
31
+
| SSE polling client (legacy) | Polls a legacy HTTP+SSE server and demonstrates notification handling. |[`src/ssePollingClient.ts`](src/ssePollingClient.ts)|
| Multiple clients in parallel | Connects multiple clients concurrently to the same server. |[`src/multipleClientsParallel.ts`](src/multipleClientsParallel.ts)|
0 commit comments