fix pdf-server outputSchema draft-07 dialect rejection

[bonallure]

Fixes #765

Motivation

display_pdf and interact in examples/pdf-server fail client-side on any client with a strict JSON Schema 2020-12-only output-schema validator (Claude Desktop, Claude Code), before the tool call ever reaches the server:

Tool 'display_pdf' has an invalid outputSchema: JSON Schema declares an unsupported dialect
("$schema": "http://json-schema.org/draft-07/schema#"). The default validator supports
JSON Schema 2020-12 only, pass a pre-configured Ajv instance to AjvJs

Root cause is in the pinned @modelcontextprotocol/sdk (^1.29.0, still present in latest 1.30.0): the tools/list handler always emits "$schema": "http://json-schema.org/draft-07/schema#" on Zod-derived inputSchema/outputSchema, with no registerTool/registerAppTool option to configure it (zod-json-schema-compat.js's mapMiniTarget() falls back to 'draft-7' since mcp.js never passes a target). This is an already-filed, still-open upstream bug: modelcontextprotocol/typescript-sdk#2721 — there is no released SDK version that fixes it, so this can't be resolved by a version bump.

What changed

• src/server/index.ts: new exported fixOutputSchemaDialect(server). Wraps the low-level Server.setRequestHandler to intercept the handler McpServer registers for ListToolsRequestSchema, rewriting "$schema": "http://json-schema.org/draft-07/schema#" to "https://json-schema.org/draft/2020-12/schema" on every tool's inputSchema/outputSchema before the response goes out. Must be called immediately after constructing McpServer, before any tool registration (documented in the JSDoc, with an @example).
• src/server/index.examples.ts: companion fixOutputSchemaDialect_basicUsage region for the JSDoc example.
• src/server/index.test.ts: unit tests covering the rewrite and the pass-through case for other request schemas.
• examples/pdf-server/server.ts: calls fixOutputSchemaDialect(server) right after new McpServer(...), before list_pdfs registers.

How it was verified

• npm test — 376 pass, 1 pre-existing skip, 0 fail.
• npm run build — clean, no type errors.
• End-to-end: built createServer() from examples/pdf-server, connected via InMemoryTransport + a real SDK Client, called listTools(). Confirmed display_pdf/read_pdf_bytes/save_pdf's outputSchema.$schema (and every tool's inputSchema.$schema) is now 2020-12, list_pdfs/interact unaffected, and a real tool call (list_pdfs) still round-trips correctly — the fix only touches tools/list schema metadata, not tool invocation.
• Confirmed the ordering constraint is real: calling fixOutputSchemaDialect after the first tool registration (instead of before) leaves the dialect at draft-07, since McpServer only installs its real tools/list handler once, lazily, on first registration.

Scope note: other examples (budget-allocator-server, cohort-heatmap-server, system-monitor-server, etc.) declare outputSchema and hit the same bug but aren't touched here — kept this PR focused on the reported pdf-server failure; noted them as follow-up in #765.

"Allow edits by maintainers" is checked.

[ochafik]

Thanks Laurent! Good news is this went away with the SDK 2.0 migration (#720, just merged): @modelcontextprotocol/server@2.0.0 converts zod schemas with the 2020-12 target, so tools/list now advertises https://json-schema.org/draft/2020-12/schema on every pdf-server tool, outputSchema included (verified against the built example). That also covers the other examples you listed in #765. I'd rather not ship a public helper that patches setRequestHandler for a bug the current SDK no longer has, so closing this one; #765 stays open until 2.0.0 is on npm and the server-pdf package is republished. Thanks for the thorough repro, it made this easy to confirm :-)

[bonallure]

Thanks @ochafik! Opened this for my team at Netflix looking to use the connector. Glad it's resolved.