MCPエラー -32601: メソッドが見つかりません – 完全な修正とトラブルシューティングガイド 2026

主な要点

• MCP エラー -32601 "Method not found" は標準的な JSON-RPC 2.0 エラーであり、クライアントが MCP サーバーが実装していない、または capabilities で公開していないメソッドを要求したときに発生します。
• 主な原因には オプションのメソッドプローブ (resources/list, prompts/list, elicit)、クライアントとサーバーの SDK 間のバージョン不一致、および 不完全な capabilities 宣言 が含まれます。
• ほとんどのケースは良性かつ予期されたものであり、継続的なエラーは公式の MCP Inspector を使用し、実装を調整することで解決されます。
• Claude Desktop、Cursor、Continue.dev および FastMCP、Spring AI、または McpSharp で構築されたカスタムサーバーでよく発生します。

MCP メソッドが見つからないエラーについての理解

Model Context Protocol (MCP) は、AI クライアント (Claude、Cursor など) とツール、リソース、プロンプト用の外部サーバー間の通信を、様々なトランスポートを介して JSON-RPC 2.0 を使用して標準化します。

エラーレスポンスは通常次のようになります:

{
  "jsonrpc": "2.0",
  "id": 19,
  "error": {
    "code": -32601,
    "message": "Method not found"
  }
}

これは要求されたメソッド (例: tools/call, resources/list, prompts/list, または elicitation 関連) がサーバーに未知であることを示します。接続エラーや parse エラーとは異なり、トランスポート層は通常成功します — 問題はプロトコルレベルにあります。

コミュニティの報告や GitHub の issue から、このエラーは capabilities の探索中や、クライアントがサーバーが提供するよりも広範なサポートを前提としたときに頻繁に発生することがわかっています。

一般的な原因

最近の issues (2025–2026) の分析から、以下のトリガーが強調されます:

• オプションのメソッドが実装されていない: MCP サーバーはすべての機能をサポートする必要はありません。Claude Desktop などのクライアントは resources/list, prompts/list, または elicitation メソッドをプローブすることがあり、それらが欠けている場合 -32601 を引き起こします。
• Capabilities Advertisement のギャップ: サーバーの initialize レスポンスがサポートされる capabilities を正しく宣言していないため、クライアントがサポートされていないメソッドを呼び出します。
• SDK とバージョンの不一致: @modelcontextprotocol/sdk, FastMCP, Spring AI MCP, または McpSharp の異なるバージョンにより互換性問題が発生します。Java ユーザーは JDK 21 への切り替えで頻繁にこれを解決しています。
• IDE/クライアント固有の挙動: Cursor の agent chat はメソッドエラーとともに "No MCP resources available" を報告する可能性があります。Claude は "Method not found: resources/list" を繰り返しログ出力します。
• Elicitation 要求: FastMCP および同様のフレームワークは、ユーザー入力 elicit がクライアントによって完全にサポートされていない場合、McpError をスローします。
• カスタムまたは最小限の実装: 適切なエラー処理や完全なプリミティブサポート (initialize, tools/list, tools/call) なしに手動で作成されたサーバーは、実際のクライアントで失敗します。
• トランスポート/プロキシの問題: Docker、ngrok、または inspector proxy セットアップでは、ルーティング問題がメソッドエラーとして現れる可能性があります。

段階的なトラブルシューティングと修正

1. 診断に MCP Inspector を使用する

公式ツールはサーバーを検証する最も迅速な方法です:

# Node.js / TypeScript
npx @modelcontextprotocol/inspector "node your-server.js"

# Python
uvx mcp-inspector "python your_server.py"

インスペクターは能力（capabilities）を表示し、メソッドをインタラクティブにテストできるので、どのメソッドが-32601を返すかが正確にわかります。メソッドがここで失敗するなら、サーバーで実装されていません。

2. 能力を正確に検査し宣言する

initialize ハンドシーク時、サーバーは正確な能力を返す必要があります。例の構造：

{
  "capabilities": {
    "tools": {
      "listChanged": true
    },
    "resources": false,
    "prompts": false
  }
}

サポートされていない機能は、明示的に false に設定するか省略することで、不要なプローブを防ぎます。

3. バージョンと依存関係を調整する

• クライアントとサーバーを一致する MCP SDK バージョンに更新します。
• Java/Spring AIの場合：JAVA_HOME を JDK 21+ に設定し、キャッシュをクリアします。
• Cursor/Claudeの場合：更新後、アプリケーションを再起動し、MCP構成をリフレッシュします。
• 最新リリースが互換性の問題を引き起こしている場合、以前の安定バージョン（例：古いレポートでは Cursor 0.45）に戻します。

4. ログを徹底的に確認する

• サーバー側：届いた正確なメソッド名とルーティング方法を確認します。
• クライアント側：Claudeログ（macOSでは ~/Library/Logs/Claude/）、Cursor拡張機能の出力、またはContinue.devコンソールを確認します。
• シーケンスを探す：成功した initialize 後に失敗したオプションのメソッド呼び出し。

5. オプションおよびエッジケースのメソッドを扱う

• オプションメソッドの -32601 は、可能な場所ではクライアントコードで致命的ではないものとして扱います。
• 発話量が多いツールの場合：対象クライアント（例：Gemini CLI や特定の Cursor モード）がサポートしていない場合、優雅なフォールバックを実装したり、機能を無効にします。
• カスタムサーバーでは：クラッシュやタイムアウトではなく、適切な JSON-RPC エラーフォーマットで常に応答します。

高度なヒントと落とし穴

• リソースとプロンプトのプローブ：多くのサーバーは無害な「Method not found: resources/list」をログします — コアツールが機能する場合はこれを無視します。
• Dockerとリモートセットアップ：ポートフォワーディング、ヘルスチェック、POSTリクエストが正しいハンドラーに届いていることを確認します。405エラーが時々 -32601 に付随します。
• テスト戦略：最初に MCP インスペクターでテストし、次に複数のクライアント（Claude Desktop、Cursor、Continue.dev）でテストします。curlによる直接JSON-RPC呼び出しで低レベルバリデーションを行います。
• パフォーマンス関連の模倣：長時間実行されるツール呼び出しとタイムアウト（Spring AIで一般的）は、下流でメソッドエラーとして表面化する可能性があります。
• 最小限の実用サーバー：最低でも initialize、tools/list、tools/call、ping を実装します。すべての受信リクエストに対して堅牢なログ記録を追加します。

予防策のベストプラクティス

• エラーコードと機能レスポンスについては、最新のMCP仕様を厳密に遵守してください。
• スクラッチ実装ではなく、公式SDKを可能な限り使用してください。
• 本番サーバーには、包括的なログ記録とバージョン交渉機能を組み込んでください。
• 変更や破壊的変更に関する最新情報については、modelcontextprotocol GitHub組織を定期的に監視してください。
• 機能の検出を徹底的にテストしてください。これにより、実運用での大半の-32601問題を防ぐことができます。

機能を明確に公表し、オプションのメソッドを適切に処理する開発者は、サポートチケットが大幅に減少することを報告しています。

結論

MCP -32601「メソッドが見つかりません」エラーは、通常、重要な失敗ではなく、プロトコル機能のオプションとして期待される動作です。MCP Inspectorによる体系的な診断、適切な機能宣言、バージョンの一致により、ほぼすべてのケースが解決されます。

2026年にエコシステムが成熟し続ける中、MCPサーバーとクライアントを最新の状態に保ちましょう。解決困難な問題については、関連するGitHubリポジトリやコミュニティフォーラムに、サーバーの機能JSON、正確なメソッドログ、およびクライアントバージョンを共有することで、コミュニティからの迅速な支援を得られます。

これらのプラクティスを実践することで、より堅牢かつ互換性のあるMCP統合を構築してください。