MCP outputSchemaがdraft-07で拒否される原因と対処法

outputSchemaにJSON Schema draft-07を宣言しているMCPサーバーのツールが、サーバーへ何も届かないまま「unsupported dialect」エラーで丸ごと使えなくなる不具合が報告されています。原因はサーバー側の設定ミスではありません。MCP TypeScript SDKが既定で出力するdraft-07の$schemaを、クライアント側の検証器が受け付けないことです。

報告の大半はClaude DesktopとCoworkで、Claude Code CLIでは、動くという報告と再現するという報告が混在しています。サーバーを直せない性質のバグなので、この記事は「自分の環境で当たっているか」「当たっていたら何ができるか」の順に進めます。

「unsupported dialect」エラーの正体

該当のツールを呼び出すと、サーバーへのリクエストが一切送られないまま次のエラーで失敗します。

Tool 'count' 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

GitHub Issue #86142の報告では、サーバーのログにtools/callの受信履歴が残りません。outputSchemaを宣言していない同じサーバーの他のツールは正常に動くため、原因がoutputSchemaの$schema宣言だと切り分けやすいバグです。

エラー文の末尾にある「pass a pre-configured Ajv instance to AjvJs」は、MCP SDKの標準検証器(AjvJsonSchemaValidator)が出す文言の途中までです。ログではメッセージが途中で切れます。この検証器は、$schemaが2020-12のURL以外だと、スキーマの中身を見る前に拒否します。

厄介なのは、失敗するタイミングが接続時ではなく最初の呼び出し時に寄っている点です。Issueに寄せられた報告から、利用者が見る流れは次のようになります。

draft-07がなぜ既定になるのか

Issueのコメントでは、draft-07はMongoDBなど個別サーバーの選択ではなく、MCP TypeScript SDK(@modelcontextprotocol/sdk)がoutputSchemaをZodのスキーマから生成する際の既定の方言だと指摘されています。SDK内部の変換関数は、targetが明示されなければ'draft-7'にフォールバックする実装です。registerTool経由でこのtargetを上書きする手段は用意されていません。

そのため、MCP TypeScript SDK 1.x上でZodからoutputSchemaを作っているサーバーに及ぶ可能性があります。Zod v3ではzod-to-json-schema経由、v4ではSDK内部の変換経由で、どちらもdraft-07を出します。

エラー文のとおり、既定の検証器が受け付けるのは2020-12だけです。draft-07に限らず、draft-04・draft-06・2019-09を宣言したスキーマも同じ扱いになります。

上流では、@modelcontextprotocol/client 2.0.0(2026-07-27にマージされたtypescript-sdk#2534)で、既定の検証器がdraft-07とdraft-06の宣言を拒否せず扱うようになりました。SDK 1.xの既定を2020-12に変える提案は、typescript-sdk#2653にあります。

mongodb-mcp-serverのようにSDKの既定をそのまま使うサーバーは、更新しても直りません。一方、git-mcp-server 2.15.2やobsidian-mcp-server 3.3.0のように、$schemaを2020-12で明示する版を出したサーバーもあります。MongoDB側は、$schemaは標準のフィールドだとして、削除を求める別のIssue(2025年)を断っています。

自分のサーバーがdraft-07か調べる

outputSchemaの$schemaはサーバーのtools/list応答にそのまま載っているため、クライアントを介さずに調べられます。stdioで起動するサーバーなら、標準入力に次の3行(1行1メッセージ)を送ります。Issueの検証スクリプトが送っているのと同じ手順です。

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"probe","version":"1"}}}
{"jsonrpc":"2.0","method":"notifications/initialized"}
{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}

idが2の応答で、各ツールのoutputSchemaにある$schemaを見ます。http://json-schema.org/draft-07/schema#なら、Desktop / Coworkでこのエラーに当たる条件を満たします。$schemaが無い、または2020-12なら別の原因です。

Issueの検証では、mongodb-mcp-serverの1.14.0・2.0.0・2.1.0がいずれも全outputSchemaでdraft-07を返していました。バージョンを選んでも逃げられないことの裏付けでもあります。Issueの検証スクリプトでは、不具合が出る前のバージョンと出た後のバージョンで、サーバーが返す$schemaが一字一句同一でした。クライアントの検証ロジックが変わったのであって、サーバーのペイロードは変わっていません。

影響が報告されているMCPサーバーの例

Issue #86142には、複数の利用者から次のサーバーでの再現報告が寄せられています。

• mongodb-mcp-server(最初の報告。1.14.0〜2.1.0のどのバージョンでも発生)
• mssql-mcp-node(6ツールすべてが同時に使用不能に)
• n8nのインスタンスレベルMCPサーバー(33ツール全滅の報告あり。n8nのMCPサーバー活用自体はn8nのMCP Server Triggerも参照してください)
• Anthropic公式のリファレンス実装@modelcontextprotocol/server-filesystem
• Perplexityの公式MCPサーバー(@perplexity-ai/mcp-server)
• Obsidian Local REST APIのMCPサーバー
• Cypress CloudのMCPコネクタ
• Anthropic同梱のFilesystem拡張(ant.dir.ant.anthropic.filesystem v2026.7.10。Coworkで発生)

いずれもサーバー自体は仕様どおりに動作しています。draft-07を明示した$schemaはMCP仕様上も有効です。

環境によって挙動が分かれる

同じエラーでも、どの環境から使うかで再現するかどうかが変わります。Issueは2026-08-17に「Claude CodeのCLIで再現しない」ことを理由にクローズされました。その後、DesktopとCoworkの利用者が再現報告を重ねています。

リモートHTTPのサーバーでも、n8n(2026-08-18)やClickUp(09-01)、MongoDB Atlas(09-30)で同じ拒否が報告されています。伝送方式は原因ではないということです。

試しても直らないもの

Issueの報告者が試して効果がなかった対処が、いくつも記録されています。

• サーバーとアプリの再起動: $schemaの値が変わらないため効果がありません。コネクタを削除してclaude_desktop_config.jsonから入れ直しても同じ結果でした
• MCPサーバーのバージョン更新・ピン留め: mongodb-mcp-serverは1.14.0でも2.1.0でも同じdraft-07を返します。draft-07を返さない「安全なバージョン」が用意されていないサーバーも複数あります

症状から見る切り分け

状況によって、取れる手が変わります。

今回のエラーは「接続はできるがツール呼び出しだけ失敗する」型です。接続の切り分けの4層のうち、最後の「ツール表示」より後ろで起きる点が目印になります。

コミュニティが共有しているシムと落とし穴

Issueのコメントには、サーバーの起動コマンドを包んで$schemaだけ取り除く小さなNode.jsスクリプト(シム)が共有されています。Anthropicの手段ではなく、利用者が書いたコードです。

落とし穴も報告されています。@modelcontextprotocol/server-filesystemの最近のバージョンは、許可ディレクトリをクライアントが通知するrootsで丸ごと置き換えます。Desktop側がセッションのフォルダを通知するため、シムで拒否を外してもツールが読み込まれるだけで、設定ファイルで渡したディレクトリには届かなくなります。2026-09-20のコメントでは、initializeメッセージからcapabilities.rootsを取り除く処理を加えた版が共有されました。

シムは設定ファイルで起動するコマンドを包む作りなので、リモートHTTPのサーバーには使えません。標準入出力を流れるデータを書き換えるコードでもあります。使う場合は中身を読み、何を書き換えるか把握したものだけを選んでください。

ドキュメントとの食い違い

Claude Codeの公式ドキュメントには「Tools with invalid input schemas」という節があります。そこでは「$schemaを省略したスキーマと2020-12を明示したスキーマにだけ2020-12メタスキーマの適合チェックをかけ、他の方言を明示したスキーマはこのチェックをスキップする」と書かれています。ただしプロパティ名の検査は、他の方言を明示したスキーマにも残ります。

この説明はinputSchemaについてのものです。outputSchemaの検証と対応方言は、同ページの該当節に載っていません。今回のエラーはoutputSchema側で起きており、inputSchemaの寛容な扱いとは別の経路が動いていることになります。

CHANGELOGにも、dialect・Ajv・2020-12・draft-07を含むエントリはありません。outputSchemaに触れる2件はclaude mcp serveの修正で、今回の拒否とは別物です。更新のたびに自分のサーバーで再テストするのが、現実的な手になります。

MCPのツール定義まわりのJSON Schema対応が2026-07-28版の仕様改訂でどう広がったかは、MCPのツール定義がJSON Schema 2020-12の全機能に対応にあります。

似た名前のエラーとして、claude -p --json-schemaが2020-12のスキーマを拒否する逆方向の不具合もIssue内で言及されています。こちらは別の検証経路で起きる逆向きの現象で、Issueでは同じ検証器設定の不整合が疑われています。詳しくはClaude Code --json-schemaエラーの直し方にあります。

まとめ

Issue #86142は2026-08-17にクローズされた後も、DesktopとCoworkでの再現報告が2026-09-30まで続いています。

直すのはサーバーでなくクライアント側のため、まずtools/listでサーバーの$schemaを調べ、draft-07ならCLIで動かすか、中身を読んだうえでシムを使うか、修正を待つかを選ぶことになります。