{"slug": "mcp-output-schemas-can-break-clients-on-edge-runtimes", "title": "MCP output schemas can break clients on edge runtimes", "summary": "SlopIt's MCP server failed mcp.so's \"Fetch tools\" check on October 10 after SlopIt added an outputSchema to every tool, because the v1 TypeScript SDK client compiles output schemas with Ajv, which uses `new Function` and throws \"Code generation from strings disallowed for this context\" on Cloudflare-style edge hosting; since SDK version 1.21 a failed compile kills the whole tool list, a known issue tracked as typescript-sdk#689. SlopIt fixed the listing by stopping output-schema transmission over the deprecated SSE transport and by returning a 405 to plain GET requests instead of an empty stream that never sends anything, while keeping the schemas on Streamable HTTP. The company recommends two pre-listing checks: list tools with a current v1 client under `node --disallow-code-generation-from-strings`, and list them again over legacy SSE, which mcp.so and n8n's MCP client can still use.", "body_md": "*mcp.so's SlopIt listing on October 10, while \"Fetch tools\" kept failing.*\n\nI listed SlopIt's MCP server on the MCP directory mcp.so on October 10, and its \"Fetch tools\" button kept loading and then nothing. [SlopIt](https://slopit.io) is our blog platform for AI agents, and its MCP server lives at `slopit.io/mcp`. Claude Code fixed that, and the next click gave `SSE error: Non-200 status code (405)`. It fixed that too, and then I got `Code generation from strings disallowed for this context`.\n\nEarlier that day we'd added an `outputSchema` to every tool, as part of the work that took our [Smithery score from 73 to 98](https://blog.slopit.io/smithery-73-to-98/). mcp.so's checker seems to run on Cloudflare-style hosting, where code isn't allowed to build functions from strings (`new Function`). The v1 TypeScript SDK client compiles every output schema with Ajv, which does exactly that, and since version 1.21 a failed compile kills the whole tool list. It's a known SDK problem ([typescript-sdk#689](https://github.com/modelcontextprotocol/typescript-sdk/issues/689) hit the same error on Workers). So mcp.so's normal attempt crashed and it fell back to the old SSE transport, which we weren't serving properly either. The first two errors came from that fallback.\n\n*What mcp.so's \"Fetch tools\" went through, and what each fix changed.*\n\nFor anyone writing a client, the SDK has had a validator that doesn't generate code since 1.21, and the v2 client switches to it on its own on Workers:\n\n``` js\nimport { CfWorkerJsonSchemaValidator } from '@modelcontextprotocol/sdk/validation/cfworker'\n\nconst client = new Client(\n  { name: 'my-client', version: '1.0.0' },\n  { jsonSchemaValidator: new CfWorkerJsonSchemaValidator() },\n)\n```\n\nOn our side we couldn't change mcp.so's client, so we stopped sending output schemas over the old SSE transport (they were added to the spec after it was deprecated anyway). That's what got mcp.so working. We also dropped the SDK's default of answering a GET with an empty stream that never sends anything, which was the endless loading. Now that GET gets a 405, unless it comes from an old SSE client, which gets a real stream.\n\n*The same listing after the fixes, with all 12 tools.*\n\nWe still send the schemas over Streamable HTTP, though. So a v1 client on 1.21 or later, running on Workers with the default validator, still can't list our tools unless it falls back to SSE like mcp.so does. We're keeping them for now, and I think that's fine. Every client we tested outside an edge runtime reads them, and they're part of the Smithery 98.\n\nTwo checks worth running before you list an MCP server anywhere:\n\n- list its tools with a current v1 client under `node --disallow-code-generation-from-strings` , which throws the same error Workers does\n- list them again over the legacy SSE transport, since mcp.so and n8n's MCP client can still use it\n\n— NJ\n\n*I run [SimbaStack](https://simbastack.com/), where we build AI agents and the systems they work in. If you need help getting an agent into production, tell me what you're building: [nj@simbastack.com](mailto:nj@simbastack.com).*", "url": "https://wpnews.pro/news/mcp-output-schemas-can-break-clients-on-edge-runtimes", "canonical_source": "https://blog.simbastack.com/mcp-output-schemas-edge-runtimes/", "published_at": "2026-10-10 21:27:59+00:00", "updated_at": "2026-10-27 11:43:40.548037+00:00", "lang": "en", "topics": ["agent-protocols", "ai-agents", "developer-tools", "ai-tools"], "entities": ["SlopIt", "mcp.so", "Model Context Protocol", "TypeScript SDK", "Cloudflare", "Ajv", "Smithery", "n8n"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/mcp-output-schemas-can-break-clients-on-edge-runtimes", "markdown": "https://wpnews.pro/news/mcp-output-schemas-can-break-clients-on-edge-runtimes.md", "text": "https://wpnews.pro/news/mcp-output-schemas-can-break-clients-on-edge-runtimes.txt", "jsonld": "https://wpnews.pro/news/mcp-output-schemas-can-break-clients-on-edge-runtimes.jsonld"}}