Merge branch 'main' into fix/rpc-error-message-prefix

Author: KKonstantinov

.changeset/fix-unknown-tool-protocol-error.md

@@ -0,0 +1,15 @@
+---
+"@modelcontextprotocol/core": minor
+"@modelcontextprotocol/server": major
+---
+
+Fix error handling for unknown tools and resources per MCP spec.
+
+**Tools:** Unknown or disabled tool calls now return JSON-RPC protocol errors with
+code `-32602` (InvalidParams) instead of `CallToolResult` with `isError: true`.
+Callers who checked `result.isError` for unknown tools should catch rejected promises instead.
+
+**Resources:** Unknown resource reads now return error code `-32002` (ResourceNotFound)
+instead of `-32602` (InvalidParams).
+
+Added `ProtocolErrorCode.ResourceNotFound`.

.changeset/twelve-dodos-taste.md

@@ -0,0 +1,5 @@
+---
+"@modelcontextprotocol/express": patch
+---
+
+Add jsonLimit option to createMcpExpressApp

.github/workflows/main.yml

@@ -58,11 +58,47 @@ jobs:
 
             - run: pnpm test:all
 
+    test-runtimes:
+        runs-on: ubuntu-latest
+        strategy:
+            fail-fast: false
+            matrix:
+                include:
+                    - runtime: bun
+                      version: "1.x"
+                    - runtime: deno
+                      version: v2.x
+        steps:
+            - uses: actions/checkout@v6
+            - name: Install pnpm
+              uses: pnpm/action-setup@v4
+              with:
+                  run_install: false
+            - uses: actions/setup-node@v6
+              with:
+                  node-version: 24
+                  cache: pnpm
+                  cache-dependency-path: pnpm-lock.yaml
+            - name: Set up Bun
+              if: matrix.runtime == 'bun'
+              uses: oven-sh/setup-bun@v2
+              with:
+                  bun-version: ${{ matrix.version }}
+            - name: Set up Deno
+              if: matrix.runtime == 'deno'
+              uses: denoland/setup-deno@v2
+              with:
+                  deno-version: ${{ matrix.version }}
+            - run: pnpm install
+            - run: pnpm build:all
+            - name: Run ${{ matrix.runtime }} integration tests
+              run: pnpm --filter @modelcontextprotocol/test-integration test:integration:${{ matrix.runtime }}
+
     publish:
         runs-on: ubuntu-latest
         if: github.event_name == 'release'
         environment: release
-        needs: [build, test]
+        needs: [build, test, test-runtimes]
 
         permissions:
             contents: read

CLAUDE.md

@@ -102,10 +102,10 @@ The SDK uses `zod/v4` internally. Schema utilities live in:
 
 ### Validation
 
-Pluggable JSON Schema validation (`packages/core/src/validation/`):
+Pluggable JSON Schema validation (`packages/core/src/validators/`):
 
-- `ajv-provider.ts` - Default Ajv-based validator
-- `cfworker-provider.ts` - Cloudflare Workers-compatible alternative
+- `ajvProvider.ts` - Default Ajv-based validator
+- `cfWorkerProvider.ts` - Cloudflare Workers-compatible alternative
 
 ### Examples
 

README.md

@@ -25,7 +25,7 @@
 
 The Model Context Protocol (MCP) allows applications to provide context for LLMs in a standardized way, separating the concerns of providing context from the actual LLM interaction.
 
-This repository contains the TypeScript SDK implementation of the MCP specification and ships:
+This repository contains the TypeScript SDK implementation of the MCP specification. It runs on **Node.js**, **Bun**, and **Deno**, and ships:
 
 - MCP **server** libraries (tools/resources/prompts, Streamable HTTP, stdio, auth helpers)
 - MCP **client** libraries (transports, high-level helpers, OAuth helpers)
@@ -57,12 +57,20 @@ They are intentionally thin adapters: they should not introduce new MCP function
 
 ```bash
 npm install @modelcontextprotocol/server zod
+# or
+bun add @modelcontextprotocol/server zod
+# or
+deno add npm:@modelcontextprotocol/server npm:zod
 ```
 
 ### Client
 
 ```bash
 npm install @modelcontextprotocol/client zod
+# or
+bun add @modelcontextprotocol/client zod
+# or
+deno add npm:@modelcontextprotocol/client npm:zod
 ```
 
 ### Optional middleware packages

docs/client-quickstart.md

@@ -19,10 +19,13 @@ This quickstart assumes you have familiarity with:
 
 Before starting, ensure your system meets these requirements:
 
-- Node.js 20 or higher installed
+- Node.js 20 or higher installed (or **Bun** / **Deno** — the SDK supports all three runtimes)
 - Latest version of `npm` installed
 - An Anthropic API key from the [Anthropic Console](https://console.anthropic.com/settings/keys)
 
+> [!TIP]
+> This tutorial uses Node.js and npm, but you can substitute `bun` or `deno` commands where appropriate. For example, use `bun add` instead of `npm install`, or run the client with `bun run` / `deno run`.
+
 ## Set up your environment
 
 First, let's create and set up our project:
@@ -109,7 +112,7 @@ First, let's set up our imports and create the basic client class in `src/index.
 
 ```ts source="../examples/client-quickstart/src/index.ts#prelude"
 import Anthropic from '@anthropic-ai/sdk';
-import { Client, StdioClientTransport, type CallToolResult } from '@modelcontextprotocol/client';
+import { Client, StdioClientTransport } from '@modelcontextprotocol/client';
 import readline from 'readline/promises';
 
 const ANTHROPIC_MODEL = 'claude-sonnet-4-5';
@@ -201,7 +204,7 @@ Now let's add the core functionality for processing queries and handling tool ca
         const result = await this.mcp.callTool({
           name: toolName,
           arguments: toolArgs,
-        }) as CallToolResult;
+        });
 
         finalText.push(`[Calling tool ${toolName} with args ${JSON.stringify(toolArgs)}]`);
 

docs/client.md

@@ -16,10 +16,11 @@ The examples below use these imports. Adjust based on which features and transpo
 import type { Prompt, Resource, Tool } from '@modelcontextprotocol/client';
 import {
     applyMiddlewares,
-    CallToolResultSchema,
     Client,
     ClientCredentialsProvider,
     createMiddleware,
+    CrossAppAccessProvider,
+    discoverAndRequestJwtAuthGrant,
     PrivateKeyJwtProvider,
     ProtocolError,
     SdkError,
@@ -153,6 +154,51 @@ For user-facing applications, implement the {@linkcode @modelcontextprotocol/cli
 
 For a complete working OAuth flow, see [`simpleOAuthClient.ts`](https://github.com/modelcontextprotocol/typescript-sdk/blob/main/examples/client/src/simpleOAuthClient.ts) and [`simpleOAuthClientProvider.ts`](https://github.com/modelcontextprotocol/typescript-sdk/blob/main/examples/client/src/simpleOAuthClientProvider.ts).
 
+### Cross-App Access (Enterprise Managed Authorization)
+
+{@linkcode @modelcontextprotocol/client!client/authExtensions.CrossAppAccessProvider | CrossAppAccessProvider} implements Enterprise Managed Authorization (SEP-990) for scenarios where users authenticate with an enterprise identity provider (IdP) and clients need to access protected MCP servers on their behalf.
+
+This provider handles a two-step OAuth flow:
+1. Exchange the user's ID Token from the enterprise IdP for a JWT Authorization Grant (JAG) via RFC 8693 token exchange
+2. Exchange the JAG for an access token from the MCP server via RFC 7523 JWT bearer grant
+
+```ts source="../examples/client/src/clientGuide.examples.ts#auth_crossAppAccess"
+const authProvider = new CrossAppAccessProvider({
+    assertion: async ctx => {
+        // ctx provides: authorizationServerUrl, resourceUrl, scope, fetchFn
+        const result = await discoverAndRequestJwtAuthGrant({
+            idpUrl: 'https://idp.example.com',
+            audience: ctx.authorizationServerUrl,
+            resource: ctx.resourceUrl,
+            idToken: await getIdToken(),
+            clientId: 'my-idp-client',
+            clientSecret: 'my-idp-secret',
+            scope: ctx.scope,
+            fetchFn: ctx.fetchFn
+        });
+        return result.jwtAuthGrant;
+    },
+    clientId: 'my-mcp-client',
+    clientSecret: 'my-mcp-secret'
+});
+
+const transport = new StreamableHTTPClientTransport(new URL('http://localhost:3000/mcp'), { authProvider });
+```
+
+The `assertion` callback receives a context object with:
+- `authorizationServerUrl` – The MCP server's authorization server (discovered automatically)
+- `resourceUrl` – The MCP resource URL (discovered automatically)
+- `scope` – Optional scope passed to `auth()` or from `clientMetadata`
+- `fetchFn` – Fetch implementation to use for HTTP requests
+
+For manual control over the token exchange steps, use the Layer 2 utilities from `@modelcontextprotocol/client`:
+- `requestJwtAuthorizationGrant()` – Exchange ID Token for JAG at IdP
+- `discoverAndRequestJwtAuthGrant()` – Discovery + JAG acquisition
+- `exchangeJwtAuthGrant()` – Exchange JAG for access token at MCP server
+
+> [!NOTE]
+> See [RFC 8693 (Token Exchange)](https://datatracker.ietf.org/doc/html/rfc8693), [RFC 7523 (JWT Bearer Grant)](https://datatracker.ietf.org/doc/html/rfc7523), and [RFC 9728 (Resource Discovery)](https://datatracker.ietf.org/doc/html/rfc9728) for the underlying OAuth standards.
+
 ## Tools
 
 Tools are callable actions offered by servers — discovering and invoking them is usually how your client enables an LLM to take action (see [Tools](https://modelcontextprotocol.io/docs/learn/server-concepts#tools) in the MCP overview).
@@ -198,13 +244,16 @@ if (result.structuredContent) {
 Pass `onprogress` to receive incremental progress notifications from long-running tools. Use `resetTimeoutOnProgress` to keep the request alive while the server is actively reporting, and `maxTotalTimeout` as an absolute cap:
 
 ```ts source="../examples/client/src/clientGuide.examples.ts#callTool_progress"
-const result = await client.callTool({ name: 'long-operation', arguments: {} }, undefined, {
-    onprogress: ({ progress, total }) => {
-        console.log(`Progress: ${progress}/${total ?? '?'}`);
-    },
-    resetTimeoutOnProgress: true,
-    maxTotalTimeout: 600_000
-});
+const result = await client.callTool(
+    { name: 'long-operation', arguments: {} },
+    {
+        onprogress: ({ progress, total }: { progress: number; total?: number }) => {
+            console.log(`Progress: ${progress}/${total ?? '?'}`);
+        },
+        resetTimeoutOnProgress: true,
+        maxTotalTimeout: 600_000
+    }
+);
 console.log(result.content);
 ```
 
@@ -484,7 +533,6 @@ All requests have a 60-second default timeout. Pass a custom `timeout` in the op
 try {
     const result = await client.callTool(
         { name: 'slow-task', arguments: {} },
-        undefined,
         { timeout: 120_000 } // 2 minutes instead of the default 60 seconds
     );
     console.log(result.content);
@@ -523,7 +571,6 @@ const result = await client.request(
         method: 'tools/call',
         params: { name: 'long-running-task', arguments: {} }
     },
-    CallToolResultSchema,
     {
         resumptionToken: lastToken,
         onresumptiontoken: (token: string) => {

docs/migration-SKILL.md

@@ -203,7 +203,7 @@ import { OAuthError, OAuthErrorCode } from '@modelcontextprotocol/core';
 if (error instanceof OAuthError && error.code === OAuthErrorCode.InvalidClient) { ... }
 ```
 
-**Unchanged APIs** (only import paths changed): `Client` constructor and methods, `McpServer` constructor, `server.connect()`, `server.close()`, all client transports (`StreamableHTTPClientTransport`, `SSEClientTransport`, `StdioClientTransport`), `StdioServerTransport`, all Zod schemas, all callback return types.
+**Unchanged APIs** (only import paths changed): `Client` constructor and most methods, `McpServer` constructor, `server.connect()`, `server.close()`, all client transports (`StreamableHTTPClientTransport`, `SSEClientTransport`, `StdioClientTransport`), `StdioServerTransport`, all Zod schemas, all callback return types. Note: `callTool()` and `request()` signatures changed (schema parameter removed, see section 11).
 
 ## 6. McpServer API Changes
 
@@ -396,11 +396,39 @@ Request/notification params remain fully typed. Remove unused schema imports aft
 | `ctx.mcpReq.elicitInput(params, options?)` | Elicit user input (form or URL) | `server.elicitInput(...)` from within handler |
 | `ctx.mcpReq.requestSampling(params, options?)` | Request LLM sampling from client | `server.createMessage(...)` from within handler |
 
-## 11. Client Behavioral Changes
+## 11. Schema parameter removed from `request()`, `send()`, and `callTool()`
+
+`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.
+
+```typescript
+// v1: schema required
+import { CallToolResultSchema, ElicitResultSchema } from '@modelcontextprotocol/sdk/types.js';
+const result = await client.request({ method: 'tools/call', params: { ... } }, CallToolResultSchema);
+const elicit = await ctx.mcpReq.send({ method: 'elicitation/create', params: { ... } }, ElicitResultSchema);
+const tool = await client.callTool({ name: 'my-tool', arguments: {} }, CompatibilityCallToolResultSchema);
+
+// v2: no schema argument
+const result = await client.request({ method: 'tools/call', params: { ... } });
+const elicit = await ctx.mcpReq.send({ method: 'elicitation/create', params: { ... } });
+const tool = await client.callTool({ name: 'my-tool', arguments: {} });
+```
+
+| v1 call | v2 call |
+|---------|---------|
+| `client.request(req, ResultSchema)` | `client.request(req)` |
+| `client.request(req, ResultSchema, options)` | `client.request(req, options)` |
+| `ctx.mcpReq.send(req, ResultSchema)` | `ctx.mcpReq.send(req)` |
+| `ctx.mcpReq.send(req, ResultSchema, options)` | `ctx.mcpReq.send(req, options)` |
+| `client.callTool(params, CompatibilityCallToolResultSchema)` | `client.callTool(params)` |
+| `client.callTool(params, schema, options)` | `client.callTool(params, options)` |
+
+Remove unused schema imports: `CallToolResultSchema`, `CompatibilityCallToolResultSchema`, `ElicitResultSchema`, `CreateMessageResultSchema`, etc., when they were only used in `request()`/`send()`/`callTool()` calls.
+
+## 12. Client Behavioral Changes
 
 `Client.listPrompts()`, `listResources()`, `listResourceTemplates()`, `listTools()` now return empty results when the server lacks the corresponding capability (instead of sending the request). Set `enforceStrictCapabilities: true` in `ClientOptions` to throw an error instead.
 
-## 12. Runtime-Specific JSON Schema Validators (Enhancement)
+## 13. Runtime-Specific JSON Schema Validators (Enhancement)
 
 The SDK now auto-selects the appropriate JSON Schema validator based on runtime:
 - Node.js → `AjvJsonSchemaValidator` (no change from v1)
@@ -420,7 +448,7 @@ new McpServer({ name: 'server', version: '1.0.0' }, {});
 
 Access validators via `_shims` export: `import { DefaultJsonSchemaValidator } from '@modelcontextprotocol/server/_shims';`
 
-## 13. Migration Steps (apply in this order)
+## 14. Migration Steps (apply in this order)
 
 1. Update `package.json`: `npm uninstall @modelcontextprotocol/sdk`, install the appropriate v2 packages
 2. Replace all imports from `@modelcontextprotocol/sdk/...` using the import mapping tables (sections 3-4), including `StreamableHTTPServerTransport` → `NodeStreamableHTTPServerTransport`

docs/migration.md

@@ -337,6 +337,73 @@ Common method string replacements:
 | `ResourceListChangedNotificationSchema` | `'notifications/resources/list_changed'` |
 | `PromptListChangedNotificationSchema`   | `'notifications/prompts/list_changed'`   |
 
+### `Protocol.request()`, `ctx.mcpReq.send()`, and `Client.callTool()` no longer take a schema parameter
+
+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 like `CallToolResultSchema` or `ElicitResultSchema` when making requests.
+
+**`client.request()` — Before (v1):**
+
+```typescript
+import { CallToolResultSchema } from '@modelcontextprotocol/sdk/types.js';
+
+const result = await client.request(
+    { method: 'tools/call', params: { name: 'my-tool', arguments: {} } },
+    CallToolResultSchema
+);
+```
+
+**After (v2):**
+
+```typescript
+const result = await client.request(
+    { method: 'tools/call', params: { name: 'my-tool', arguments: {} } }
+);
+```
+
+**`ctx.mcpReq.send()` — Before (v1):**
+
+```typescript
+import { CreateMessageResultSchema } from '@modelcontextprotocol/sdk/types.js';
+
+server.setRequestHandler('tools/call', async (request, ctx) => {
+    const samplingResult = await ctx.mcpReq.send(
+        { method: 'sampling/createMessage', params: { messages: [...], maxTokens: 100 } },
+        CreateMessageResultSchema
+    );
+    return { content: [{ type: 'text', text: 'done' }] };
+});
+```
+
+**After (v2):**
+
+```typescript
+server.setRequestHandler('tools/call', async (request, ctx) => {
+    const samplingResult = await ctx.mcpReq.send(
+        { method: 'sampling/createMessage', params: { messages: [...], maxTokens: 100 } }
+    );
+    return { content: [{ type: 'text', text: 'done' }] };
+});
+```
+
+**`client.callTool()` — Before (v1):**
+
+```typescript
+import { CompatibilityCallToolResultSchema } from '@modelcontextprotocol/sdk/types.js';
+
+const result = await client.callTool(
+    { name: 'my-tool', arguments: {} },
+    CompatibilityCallToolResultSchema
+);
+```
+
+**After (v2):**
+
+```typescript
+const result = await client.callTool({ name: 'my-tool', arguments: {} });
+```
+
+The return type is now inferred from the method name via `ResultTypeMap`. For example, `client.request({ method: 'tools/call', ... })` returns `Promise<CallToolResult | CreateTaskResult>`.
+
 ### Client list methods return empty results for missing capabilities
 
 `Client.listPrompts()`, `listResources()`, `listResourceTemplates()`, and `listTools()` now return empty results when the server didn't advertise the corresponding capability, instead of sending the request. This respects the MCP spec's capability negotiation.
@@ -708,7 +775,7 @@ import { AjvJsonSchemaValidator, CfWorkerJsonSchemaValidator } from '@modelconte
 
 The following APIs are unchanged between v1 and v2 (only the import paths changed):
 
-- `Client` constructor and all client methods (`connect`, `callTool`, `listTools`, `listPrompts`, `listResources`, `readResource`, etc.)
+- `Client` constructor and most client methods (`connect`, `listTools`, `listPrompts`, `listResources`, `readResource`, etc.) — note: `callTool()` signature changed (schema parameter removed)
 - `McpServer` constructor, `server.connect(transport)`, `server.close()`
 - `Server` (low-level) constructor and all methods
 - `StreamableHTTPClientTransport`, `SSEClientTransport`, `StdioClientTransport` constructors and options