Claude Desktop/CoworkでMCPサーバーが丸ごと使えなくなる「outputSchema unsupported dialect」エラーの原因と直し方
MCPサーバーのoutputSchemaがJSON Schema draft-07を宣言していると、Claude Desktop/Coworkの2020-12専用バリデータがツールを全て拒否する。CLIで再現しない理由と、GitHub Issue #86142の検証結果に基づくサーバー側の直し方・クライアント側の回避スクリプトまで整理した。
エンジニアのゆとです。
MCPサーバーを繋いだ瞬間、そのサーバーのツールが1つ残らず使えなくなる不具合が今も直っていない。エラーはTool 'X' 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。原因はサーバーのoutputSchemaがdraft-07というJSON Schemaの古い方言を宣言していることで、Claude Desktop/Coworkのバリデータがそれを見た瞬間、リクエストをサーバーに送る前にクライアント側で全ツールを拒否する。MongoDBの公式MCPサーバーから、Anthropic自身が配布しているFilesystem拡張まで巻き込んでいる、地味だが影響範囲の広いバグだ。
この記事を書いている2026年9月20日時点でもIssue #86142は解決していない。一度「CLIでは再現しない」という理由でクローズされたのに、Desktop/Coworkでの報告が止まらず何度もreopenが要求されている、という経緯自体もややこしい。この記事では、何が起きているか・なぜ一度クローズされたか・どう回避するかを、公式のMCP仕様とGitHub Issueの検証コメントから整理する。
まず結論 — 症状別の対処表
| 症状 | 原因 | 対処 |
|---|---|---|
| Desktop/Coworkで特定のMCPサーバーの全ツールが「invalid outputSchema」で拒否される | サーバーのoutputSchemaが$schema: draft-07を宣言している | サーバーをアップデート、なければ下記のシムスクリプトで回避 |
| 同じサーバーをClaude Code CLIから使うと問題なく動く | CLIは古い方の緩いバリデータを使っており、Desktop/Coworkの新しいバリデータとは別物 | 急ぎならCLI側で作業する。恒久対応にはならない |
| シムでエラーは消えたのに、設定したディレクトリにアクセスできなくなった(filesystemサーバー限定) | サーバーがクライアントの announce する roots で許可ディレクトリを上書きする仕様に変わった | シムでcapabilities.rootsも一緒に落とす(後述) |
| リモートHTTP接続のMCPコネクタ(Cowork経由など)で同じエラーが出る | ローカルのstdioシムが使えない別のバリデータ経路 | サーバー側の修正を待つしかない。回避策なし |
何が起きているか
最初の報告は2026年8月12日、MongoDBの公式MCPサーバー(mongodb-mcp-server)のcount・aggregate・find・list-collectionsが軒並み使えなくなったというものだった。報告者はMongoDB側にも問い合わせているが、MongoDBは「outputSchemaの$schemaフィールドは仕様上正当なものだ」として対応を断っている。実際その通りで、MCP仕様のSEP-1613は「埋め込みスキーマのデフォルト方言は2020-12だが、$schemaで別の方言を明示的に宣言してよい」と定めている。つまりdraft-07を宣言すること自体はMCP仕様に違反していない。違反しているのはそれを問答無用で拒否するクライアント側、という話になる。
このエラーの厄介なところは、壊れるのが「該当ツール1個」ではなく「そのサーバーの全ツール」であること。tools/listの段階で拒否されるため、サーバープロセス自体には一度もリクエストが届かない。サーバー側のログを見ても何も残っていない、という報告が複数ある。
影響が確認されたMCPサーバーは、自分が追えた範囲だけでもこれだけある。
| サーバー | 提供元 |
|---|---|
| mongodb-mcp-server | MongoDB公式 |
Filesystem拡張(ant.dir.ant.anthropic.filesystem) | Anthropic公式 |
| Perplexity公式MCPサーバー | Perplexity |
| mssql-mcp-node | サードパーティ |
| n8nインスタンス内蔵MCPサーバー(33ツール) | n8n |
| kObsidian(66ツール) | サードパーティ |
| ClickUp公式リモートMCPサーバー | ClickUp |
| Triple Whale(Moby)MCPサーバー | Triple Whale |
| Cypress Cloud MCPコネクタ | Cypress |
| anki-mcp-server | サードパーティ |
MongoDBやAnthropic公式拡張を含めてこの規模で報告が出ているということは、「特定のMCPサーバー実装が悪い」のではなく「MCP TypeScript SDKを素直に使うと大体これになる」という構造的な問題だと考えたほうがいい。
原因 — SDKのデフォルトとクライアントの検証が噛み合っていない
Issue #94351のコメントで、Filesystem拡張のnode_modulesを直接grepして特定された生成経路がある。
@modelcontextprotocol/sdk/dist/esm/server/zod-json-schema-compat.js
@modelcontextprotocol/sdk/dist/cjs/server/zod-json-schema-compat.jsMCP TypeScript SDKでzodスキーマからJSON Schemaへ変換する際、このcompatシムがzod-to-json-schemaライブラリを呼び出しており、そこがデフォルトで$schemaをdraft-07に固定している。zod v4自体はネイティブにz.toJSONSchema()で2020-12を出力できるが、SDKが実際に通しているのは古いcompatシムの経路だ、という指摘になっている。つまりサーバー開発者が特に何も意識せずMCP SDKの標準的な書き方でツールを定義すると、自動的にdraft-07を宣言したoutputSchemaが生成される。
一方のClaude側は、2026年8月中旬のアップデートでバリデータをAjvベースに切り替え、https://json-schema.org/draft/2020-12/schemaとhttp://json-schema.org/draft/2020-12/schema以外の$schemaを宣言したスキーマを、その方言のメタスキーマを登録する代わりに例外を投げて拒否するようになった。SDK側のデフォルトとクライアント側の検証方針が正面衝突した結果が、この大量のツール拒否ということになる。
さらに検証を進めたコメント(2026-09-02、ハンドルネームm13vによる一連の投稿)によると、実際には検証エンジンが2つある。
- AjvJs: ローカルのstdio接続(
.mcp.jsonやclaude_desktop_config.jsonで設定するサーバー)側の検証 - CfWorkerJsonSchemaValidator: リモートHTTP接続・Cowork経由のdevice-bridge接続側の検証
どちらも「draft-07を拒否する」という症状は同じだが実装は別物で、片方を直してももう片方は直らない。加えて、どちらの検証エンジンが使われるかはtengu_brindle_causewayという名前のランタイム設定(リモートのフラグ管理システムで制御されている様子)によってv1(draft-07を許容)/v2(拒否する)が切り替わっている。つまりビルドを更新しなくても、フラグの切り替えだけで同じバージョンのクライアントが「動いていたのに急に動かなくなる」ということが起こり得る、という指摘だ。
なぜ一度クローズされたか
Issue #86142は2026年8月15日、Anthropicのエンジニアが「Claude Code CLI 2.1.233(macOS)では再現しない」としてクローズしている。これ自体は嘘ではない。後の調査で判明したのは、Claude Code CLIはそもそもこの新しい厳格なバリデータを使っていないということだった。
This is Claude Desktop, not the CLI.
と報告者自身が8月15日のコメントで切り分けている。つまり検証対象がそもそも違っていた。その後もDesktop・Coworkでの再現報告(mongodb、n8n、Perplexity、Anthropic公式Filesystem拡張など)が延々と積み重なり、非コラボレーターはGitHub上でissueを自分でreopenできない仕様のため、コメント欄で「reopenしてほしい」という依頼が繰り返されるという状態が続いた。最終的に9月8日、Filesystem拡張という第三者の実装ミスでは説明のつかないケース(Anthropic自身が配布している拡張)に絞ってIssue #94351が別issueとして立てられている。
この経緯から得られる教訓は単純で、「CLIで再現しない」はDesktop/Coworkでの不具合の反証にならないということ。逆に言えば、Desktop/Coworkで同じエラーに当たった場合、応急処置としてClaude Code CLI側で同じMCPサーバーを設定し直せば、少なくとも作業は止まらない可能性が高い。
対処法
1. まずサーバー側が既に直っていないか確認する
回避スクリプトを書く前に、使っているMCPサーバーの最新版で直っていないかを確認したほうが早い。git-mcp-serverは2026年8月24日リリースのv2.15.2で、tools/listの応答時に$schemaを明示的に2020-12へ書き換える対応を入れており、報告者から「新しいバージョンで解決した」と確認が取れている。npmやGitHub Releasesで該当サーバーのCHANGELOGにdraft-07や2020-12やoutputSchemaといった単語が出てこないか検索するのが早い。
2. 自分でMCPサーバーを書いている・PRできる立場なら
durable fixはサーバー側でoutputSchemaの$schemaを明示的に2020-12へ揃えること。
{
"$schema": "https://json-schema.org/draft/2020-12/schema"
}もしくは$schemaキー自体を削除してしまう手もある。ただしこれには注意点があって、$schemaを消すとクライアント側のバリデータは(方言不明のまま)デフォルトの2020-12ルールで検証を通してしまう。スキーマがdraft-07固有のキーワード(dependenciesや真偽値のexclusiveMinimumなど)を実際に使っている場合、方言の違いを検出できないまま「一見通っているが意味的には壊れている」状態になり得る。ほとんどのzod由来のスキーマはこの種のキーワードを使っていないので実害は出にくいが、複雑なスキーマを手で書いている場合は一度目視で確認したほうがいい。
3. サーバーを直せない・まだ修正版がない場合のクライアント側シム
自分の管理下にないMCPサーバー(サードパーティ製・SaaSベンダー配布)を使っていて、修正版もまだない場合は、stdio接続をラップしてtools/list応答から$schemaだけを取り除くプロキシスクリプトを間に挟む回避策が報告されている。Node.jsの標準ライブラリだけで書けるので追加の依存関係は不要。
import { spawn } from "node:child_process";
const [, , command, ...args] = process.argv;
if (!command) {
process.stderr.write("mcp-schema-shim: usage: node mcp-schema-shim.mjs <server-command> [args...]\n");
process.exit(2);
}
const child = spawn(command, args, { stdio: ["pipe", "pipe", "inherit"], env: process.env });
// クライアント → サーバー: そのまま素通し
process.stdin.pipe(child.stdin);
process.stdin.on("end", () => child.stdin.end());
// サーバー → クライアント: JSON-RPC over stdioは改行区切りJSONなので1行ずつバッファする
let pending = "";
child.stdout.setEncoding("utf8");
child.stdout.on("data", (chunk) => {
pending += chunk;
let newline;
while ((newline = pending.indexOf("\n")) !== -1) {
const line = pending.slice(0, newline);
pending = pending.slice(newline + 1);
process.stdout.write(rewrite(line) + "\n");
}
});
child.stdout.on("end", () => {
if (pending) process.stdout.write(rewrite(pending));
});
function rewrite(line) {
if (!line.includes("$schema")) return line; // 高速パス: 何も削るものがない
let message;
try {
message = JSON.parse(line);
} catch {
return line; // JSONでなければそのまま
}
const tools = message?.result?.tools;
if (!Array.isArray(tools)) return line; // tools/listの応答だけを書き換える
let changed = false;
for (const tool of tools) {
for (const key of ["inputSchema", "outputSchema"]) {
const schema = tool?.[key];
if (schema && typeof schema === "object" && "$schema" in schema) {
delete schema.$schema;
changed = true;
}
}
}
return changed ? JSON.stringify(message) : line;
}
child.on("exit", (code, signal) => process.exit(code ?? (signal ? 1 : 0)));
child.on("error", (err) => {
process.stderr.write(`mcp-schema-shim: failed to start "${command}": ${err.message}\n`);
process.exit(1);
});
for (const sig of ["SIGINT", "SIGTERM", "SIGHUP"]) {
process.on(sig, () => child.kill(sig));
}保存先は~/.config/claude/mcp-schema-shim.mjsあたりが分かりやすい。動作確認はnode --checkで構文だけ先にチェックできる。
mkdir -p ~/.config/claude
node --check ~/.config/claude/mcp-schema-shim.mjs && echo "shim OK"設定側(claude_desktop_config.jsonや.mcp.json)では、元のコマンドをこのシム経由に差し替える。
{
"mcpServers": {
"example_mcp_server": {
"command": "/opt/homebrew/bin/node",
"args": [
"/Users/YOUR-USERNAME/.config/claude/mcp-schema-shim.mjs",
"npx", "-y", "mongodb-mcp-server@latest", "--readOnly"
],
"env": {
"MDB_MCP_CONNECTION_STRING": "既存の値をそのまま使う"
}
}
}
}もともとのcommand/argsをそのままシムの引数として後ろにぶら下げるだけなので、既存の設定を大きく書き換える必要はない。
4. filesystemサーバーだけ追加で気をつけること
@modelcontextprotocol/server-filesystemを上のシムで直した直後に、今度は「設定したディレクトリが見えなくなる」という別の問題を踏むことがある。これはスキーマの話とは無関係で、最近のバージョンのfilesystemサーバーが、クライアントがinitialize時に通知してくるrootsでコマンドライン引数の許可ディレクトリを丸ごと上書きしてしまう仕様変更(公式ドキュメント記載の意図された挙動)が原因。Claudeのクライアントはセッションのフォルダをrootsとして通知するため、設定ファイルで指定したディレクトリが上書きされて到達不能になる。「エラーは消えたのに中身が空っぽ」というときはこれを疑う。
対応としては、シムでinitializeメッセージからcapabilities.rootsを削除し、notifications/roots/list_changedを転送しない、という2点を追加すればいい。2026年9月20日時点で@modelcontextprotocol/server-filesystem v2026.8.31に対しても動作確認済みという報告がIssue #86142のコメントにある。実装の全文はコメント内にあるので、filesystemサーバーで詰まった場合はそちらを参照してほしい。
5. リモートHTTP接続のMCPコネクタは回避策がない
ClickUpの公式リモートMCPサーバーのように、自分でコマンドを起動していない(ホスト先のHTTPエンドポイントに直接繋いでいる)場合、stdioをラップするシムは原理上使えない。この経路は前述のCfWorkerJsonSchemaValidator側の検証で、2026年9月20日時点で回避策の報告は見当たらない。該当ベンダーが2020-12へスキーマを揃えるか、Anthropic側がこのエンジンにもdraft-04/06/07のメタスキーマを登録するまで待つしかない。
実行手順まとめ
- エラーメッセージに
unsupported dialectとdraft-07が出ていることを確認する - 同じMCPサーバーをClaude Code CLIから使って動くか試す(応急処置)
- 使っているMCPサーバーの最新版のCHANGELOGを確認し、2020-12対応済みならアップデートする
- 自分がサーバー側を管理できるなら、outputSchemaの
$schemaを2020-12に書き換えるか削除する - サーバーを管理できず修正版もないなら、stdio接続にシムスクリプトを挟む
- filesystemサーバーの場合は
roots上書き問題も一緒に対処する - リモートHTTP接続の場合は現状回避策がないため、ベンダー側の対応を待つ
FAQ
Claude Code CLIでも同じエラーが起きますか?
2026年9月20日時点の報告を見る限り、CLIは別の(draft-07を許容する)バリデータを使っているため基本的に再現しない。Desktop/Coworkに固有の制限として扱ったほうがいい。ただしtengu_brindle_causewayというランタイムフラグでバリデータの挙動が切り替わっているとの分析もあるため、今後変わる可能性はある。
このエラーはサーバー側のバグですか、Claude側のバグですか?
MCP仕様(SEP-1613)は$schemaで2020-12以外の方言を宣言することを明示的に許容しているため、draft-07を宣言したこと自体は仕様違反ではない。宣言された方言のメタスキーマを登録せずに例外を投げて全ツールを拒否しているクライアント側の実装が、仕様への準拠という観点では問題がある。
Issueはいつ直りますか?
2026年9月20日時点でIssue #86142・Issue #94351ともオープンのまま。公式の修正リリースはまだ確認できていない。状況が動く可能性が高いので、対応を急ぐ場合はサーバー側アップデートかシムでの回避を先に検討したほうが早い。
どのMCPサーバーで起きますか?
MCP TypeScript SDKのzod連携をそのまま使ってoutputSchemaを生成しているサーバーの大半で起こり得る。mongodb-mcp-server、Anthropic公式のFilesystem拡張、Perplexity公式MCPサーバー、n8n、kObsidian、ClickUp、Triple Whaleなどで報告が確認できている。自分が使っているサーバーが今のところ無事でも、SDKのアップデートやスキーマの書き方次第で今後同じ症状が出る可能性はある。
