Overview

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
fix/gemini-image-ga-model-ids-and-per-model-sizes
a5d0c4ee Merge a098c4cdf383cd093fc821fa672799a197f9879a into 0fb826321c9ba7bd5d8ba0062be2a00b6178726d
by Katsuyuki ...
Succeeded
fix/gemini-native-image-model-options
8d64180d Merge d676d22faf65bd8d8d6882f6eafb773b412e11fd into efe3b07688a29960a4b3e25c44219a253bb75a00
by Katsuyuki ...
Succeeded
main
347a3f6e feat(ai-mcp): forward clientOptions to the MCP SDK client (#1070) * feat(ai-mcp): forward clientOptions to the MCP SDK client `createMCPClient` and `createMCPClientFromTransport` built their SDK `Client` with `new Client({ name, version })` and no second argument, so nothing in `ClientOptions` was reachable from this package. The one that matters is `jsonSchemaValidator`. The SDK validates a tool's `structuredContent` against its declared `outputSchema`, and its default AJV provider compiles each schema by building JavaScript source and handing it to `new Function`. Edge runtimes forbid that: on Cloudflare Workers, connecting to any MCP server whose tools declare an `outputSchema` fails with `Error compiling schema` — AJV's wrapper around `Code generation from strings disallowed for this context`. That fails a whole run rather than one tool call. Validators are built in `cacheToolMetadata` during `tools/list`, so the throw lands in discovery, before the model has seen a single tool. The SDK already ships the fix — `CfWorkerJsonSchemaValidator`, backed by the optional peer `@cfworker/json-schema` — and its `ClientOptions` docblock documents installing it. It was simply not installable through this package. ```ts import { CfWorkerJsonSchemaValidator } from '@modelcontextprotocol/sdk/validation/cfworker' const mcp = await createMCPClient({ transport: { type: 'http', url: 'https://mcp.example.com/mcp' }, clientOptions: { jsonSchemaValidator: new CfWorkerJsonSchemaValidator() }, }) ``` Additive and optional: omitting it keeps the SDK's defaults, which the third unit test pins. `createMCPClients` picks it up through `MCPClientOptions` for free. E2E installs a validator that REFUSES everything, which is what makes the pass-through observable — the mock server's `get_guitar_price` returns `structuredContent` the default provider accepts, so an option dropped on the floor would leave the run indistinguishable from the existing test. * fix(ai-mcp): keep clientOptions across the MCP Apps reconnect `createMcpAppCallHandler` rebuilds a client per call from `getInfo()`, and that descriptor carried only `transport` and `prefix`. So a client created with `clientOptions` served widget tool calls through a REBUILT client that had none — back on the SDK's AJV validator, which is the failure the option exists to avoid, reintroduced for every MCP Apps call on an edge runtime. `getInfo()` now reports the options the client was built with, the descriptor carries them, and the handler forwards them. `MCPClients.getServers()` reports them the same way, since the handler reads pools through it. Optional on the return type rather than required: a hand-rolled `MCPClient` would otherwise stop compiling, and it is omitted entirely when the client was built without options, so a descriptor round-trips unchanged. * fix(ai-mcp): expose clientOptions on the pool descriptor type `MCPClients.getServers()` returns `clientOptions` since the previous commit, but its declared return type did not, so a TypeScript consumer could not read or forward it. `createMcpAppCallHandler` reads pools through exactly this method — the value was there at runtime while the public type said it was not. Also pins the omission contract in the `getInfo()` test. `toBeUndefined()` passes whether the key is absent or present-and-undefined, and the implementation deliberately omits it so a descriptor round-trips unchanged; `toStrictEqual` is what tells the two apart. Both reported by CodeRabbit on #1070.
by Katsuyuki ...
Succeeded
main
347a3f6e feat(ai-mcp): forward clientOptions to the MCP SDK client (#1070) * feat(ai-mcp): forward clientOptions to the MCP SDK client `createMCPClient` and `createMCPClientFromTransport` built their SDK `Client` with `new Client({ name, version })` and no second argument, so nothing in `ClientOptions` was reachable from this package. The one that matters is `jsonSchemaValidator`. The SDK validates a tool's `structuredContent` against its declared `outputSchema`, and its default AJV provider compiles each schema by building JavaScript source and handing it to `new Function`. Edge runtimes forbid that: on Cloudflare Workers, connecting to any MCP server whose tools declare an `outputSchema` fails with `Error compiling schema` — AJV's wrapper around `Code generation from strings disallowed for this context`. That fails a whole run rather than one tool call. Validators are built in `cacheToolMetadata` during `tools/list`, so the throw lands in discovery, before the model has seen a single tool. The SDK already ships the fix — `CfWorkerJsonSchemaValidator`, backed by the optional peer `@cfworker/json-schema` — and its `ClientOptions` docblock documents installing it. It was simply not installable through this package. ```ts import { CfWorkerJsonSchemaValidator } from '@modelcontextprotocol/sdk/validation/cfworker' const mcp = await createMCPClient({ transport: { type: 'http', url: 'https://mcp.example.com/mcp' }, clientOptions: { jsonSchemaValidator: new CfWorkerJsonSchemaValidator() }, }) ``` Additive and optional: omitting it keeps the SDK's defaults, which the third unit test pins. `createMCPClients` picks it up through `MCPClientOptions` for free. E2E installs a validator that REFUSES everything, which is what makes the pass-through observable — the mock server's `get_guitar_price` returns `structuredContent` the default provider accepts, so an option dropped on the floor would leave the run indistinguishable from the existing test. * fix(ai-mcp): keep clientOptions across the MCP Apps reconnect `createMcpAppCallHandler` rebuilds a client per call from `getInfo()`, and that descriptor carried only `transport` and `prefix`. So a client created with `clientOptions` served widget tool calls through a REBUILT client that had none — back on the SDK's AJV validator, which is the failure the option exists to avoid, reintroduced for every MCP Apps call on an edge runtime. `getInfo()` now reports the options the client was built with, the descriptor carries them, and the handler forwards them. `MCPClients.getServers()` reports them the same way, since the handler reads pools through it. Optional on the return type rather than required: a hand-rolled `MCPClient` would otherwise stop compiling, and it is omitted entirely when the client was built without options, so a descriptor round-trips unchanged. * fix(ai-mcp): expose clientOptions on the pool descriptor type `MCPClients.getServers()` returns `clientOptions` since the previous commit, but its declared return type did not, so a TypeScript consumer could not read or forward it. `createMcpAppCallHandler` reads pools through exactly this method — the value was there at runtime while the public type said it was not. Also pins the omission contract in the `getInfo()` test. `toBeUndefined()` passes whether the key is absent or present-and-undefined, and the implementation deliberately omits it so a descriptor round-trips unchanged; `toStrictEqual` is what tells the two apart. Both reported by CodeRabbit on #1070.
by Katsuyuki ...
Succeeded
feat/ai-mcp-client-options
7f834a71 Merge 5586c274414392c95871176969f2ac6fd8a0ab08 into ea9c07724bd6992480238a699fbb18835eab743e
by Katsuyuki ...