通信上のエラーを読み解く

すべてのリクエストが成功するとは限りません。何かが失敗すると、JSON-RPCは結果の代わりにerrorオブジェクトを返します。これを読み取ることが、問題を解決する最短の道です。

エラーレスポンスではリクエストのidはそのまま残り、resultの代わりにcodeとmessageを含むerrorオブジェクトが返されます。

各エラーには数値のcodeが含まれます。標準のJSON-RPCコードは負の数で、通信中によく現れるものがいくつかあります。

コード-32700は、サーバーがJSONを解析することさえできなかったことを意味します。通常は、余分なカンマや壊れた引用符によってメッセージ自体が不正になっています。

コード-32601は、そのメソッド名が存在しないことを示します。入力ミスがないか、またはtoolz/listのようにサーバーが一度も通知していないメソッドを指定していないか確認してください。

コード-32602は、不正なparamsを示します。引数が不足しているか、型が間違っています。メソッド自体は存在しますが、送信した入力が要件に合っていません。

コード-32603は、サーバー側の汎用的な内部エラーです。リクエストには問題ありませんが、処理中に何らかの問題が発生しました。

codeはエラーの分類を示し、messageは何が起きたのかを説明します。サーバーが失敗したフィールドや理由を具体的に追加していることが多いため、必ず読んでください。

エラーには、どのパラメーターが拒否されたかなど、構造化された追加情報を含むdataフィールドが付く場合もあります。存在していれば、デバッグに大いに役立ちます。

JSON-RPCのerrorは、プロトコル自体が失敗したことを意味します。一方、ツールが実行されてisErrorを返した場合は通常の結果なので、この2つを混同しないでください。

次の習慣を身につけてください。まずcodeを読んで分類し、messageを読んで場所を絞り込み、その後dataで正確な原因を確認します。MCPのバグの多くは、この方法ですぐに見つかります。

有効なメソッドを送信しましたが、引数が1つ不足していました。どのエラーコードが当てはまりますか？

これで失敗をスムーズに読み取れるようになりました。errorオブジェクトにはcode、message、場合によってはdataが含まれます。codeが分類し、messageが説明し、dataが原因を特定します。