MCPサーバーが「Method not found」になる原因｜tools/list・tools/callを確認

MCPサーバーへ接続したときに、次のようなエラーが発生することがあります。

MCPError: Method not found

JSON-RPCのエラーコードまで表示される場合は、次のようになります。

{
  "code": -32601,
  "message": "Method not found"
}

MCPでMethod not foundが出た場合、単純に「指定したツール名が存在しない」という意味とは限りません。

MCPではtools/listやtools/callなどの操作自体がJSON-RPCのMethodとして定義されています。

そのため、クライアントがtools/listを送っているのにサーバー側にそのMethodを処理するHandlerが存在しない、古いMCPサーバーへ新しい仕様のMethodを送っている、Capabilityだけ宣言してHandlerを登録していない、といった場合にもMethod not foundが発生します。

MCP Python SDKではMCPError: Method not foundについて、一方が相手側にHandlerが存在しないJSON-RPCリクエストを送った状態として扱われます。現在はプロトコル世代の不一致も代表的な原因です。

この記事では、MCPサーバーでMethod not foundが発生する原因と、tools/list、tools/call、Capability、MCPのProtocol Versionを確認する方法を解説します。MCP Inspectorを使った実際の操作手順そのものはMCP Inspectorの使い方｜ツールを単体テストして接続エラーを調べるで詳しく扱っているため、この記事ではエラーの原因を切り分けるための考え方を中心にします。

MCPのMethod not foundはJSON-RPCのエラー

MCPはJSON-RPC 2.0をベースに通信します。

クライアントからサーバーへ処理を要求するときは、次のようにmethodを指定します。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

サーバー側がtools/listを処理できれば、利用可能なTool一覧が返ります。

一方、サーバー側がそのMethodを知らなければ、JSON-RPCでは-32601 Method not foundを返します。

現在のMCP SDKでも、認識できないRequest MethodやHandlerが登録されていないMethodについて、JSON-RPC仕様に従った-32601を返す動作になっています。MCP Python SDK v2では、以前は-32602 Invalid paramsとして扱われていた一部のUnknown Methodについても、現在は-32601 Method not foundとして扱われるよう修正されています。

つまり、

Method not found

というエラーが出たら、最初に確認するべきなのはTool名そのものではなく、

どのJSON-RPC Methodに対してエラーになったのか

です。

まずエラーになったMethod名を確認する

Method not foundだけを見ても原因は分かりません。

重要なのは、その直前にクライアントが何を送ったかです。

たとえば、

tools/list

で失敗しているなら、Tool一覧を取得する段階で問題が発生しています。

一方、

tools/call

なら、Toolを実行するMethodそのものが処理できていない可能性があります。

MCP Python SDKではMCPError: Method not foundが発生した際、エラーのdataにMethod名が含まれるため、どのRPCが失敗したのか確認できます。

ログへJSON-RPC Requestを残しているなら、次の部分を確認してください。

{
  "method": "tools/list"
}

あるいは、

{
  "method": "tools/call"
}

となっているかを確認します。

tools/listはTool一覧を取得するMethod

MCPクライアントは、サーバーで利用できるToolを知るためにtools/listを使用します。

現在のMCP仕様でも、Tool Discoveryではクライアントが次のようなRequestを送ります。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

正常であれば、サーバーはTool一覧を返します。

たとえばget_weatherというToolが登録されている場合は、概念的には次のようなResponseになります。

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "指定した都市の天気を取得する",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string"
            }
          },
          "required": ["location"]
        }
      }
    ]
  }
}

ここでMethod not foundになるなら、get_weatherの実装を調べる前に、サーバーがtools/list自体を提供しているか確認する必要があります。

Toolが0個なのとtools/listが存在しないのは別

ここは特に混同しやすいポイントです。

MCPサーバーにToolが1個も登録されていなくても、tools/listを実装しているなら、

{
  "tools": []
}

のように空の一覧を返すことができます。

一方、

Method not found

が返ってくるなら、単に「Toolが0個」という状態ではなく、tools/listというRPC Method自体を受け付けていない可能性があります。

MCP TypeScript SDK v2のMcpServerでは、Toolを1つでも登録すればCapabilityが自動で推論され、Toolが0件でもtools/list Handlerが用意され、空のTool一覧を返すようになっています。低レベルのServer APIを使う場合は、setRequestHandlerで自分でHandlerを登録する必要があります。

そのため、Low-level APIで独自MCPサーバーを実装している場合は特に注意が必要です。

tools Capabilityを宣言しているか確認する

MCPでは、サーバーがどの機能をサポートしているのかをCapabilitiesとして表現します。

Tool機能をサポートするサーバーでは、Capabilityにtoolsが含まれます。

tools Capabilityが存在する場合、クライアントはtools/listとtools/callを利用できるという対応関係になっています。

概念的には次のようなCapabilityです。

{
  "capabilities": {
    "tools": {
      "listChanged": true
    }
  }
}

ところが独自実装では、

Capabilityにはtoolsを宣言した

にもかかわらず、

tools/listのHandlerを登録していない

という不整合が発生することがあります。

この場合、クライアントから見ると「このサーバーはToolを使える」と見えるのに、実際にtools/listを呼ぶとMethod not foundになるという状態になります。

高レベルSDKを使えば自動的に処理される部分でも、Low-level Serverを使っている場合は自分でCapabilityとHandlerの整合性を保つ必要があります。

tools/callはToolを実行するためのMethod

Tool一覧を取得した後、クライアントが実際にToolを実行するときはtools/callを使用します。

現在のMCPでも正式なMethod名は、

tools/call

です。

たとえばget_weatherを実行する場合は次のようになります。

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "Tokyo"
    }
  }
}

ここで重要なのは、

tools/call

と、

get_weather

は別の名前だという点です。

tools/callはMCPのJSON-RPC Methodです。

get_weatherは、そのMethodを通して実行するTool名です。

tools/callのMethod not foundとTool not foundを区別する

Tool Callingのトラブルでは、この2種類を混同しやすくなります。

たとえば、

Method not found: tools/call

なら、MCPサーバー側がtools/callというRPC Methodを処理できない可能性があります。

一方、

Unknown tool: get_weather

のようなエラーなら、tools/call自体には到達しているものの、params.nameで指定されたToolが見つからない可能性があります。

構造としては、

tools/call
    ↓
get_weather

です。

前者はProtocolやHandlerの問題、後者はTool RegistryやTool名の問題として切り分けると調査しやすくなります。

「Toolを呼んだらMethod not foundが出た」というだけでは、Tool名を何度変更しても直らない可能性があります。

tools/listは成功するがtools/callだけ失敗するケース

tools/listでは正常にToolが表示されるのに、実行するとMethod not foundになる場合があります。

ここで注意したいのは、Tool側の入力値が不正で失敗する場合(こちらはMCP Inspectorの使い方のInput Validationの節で扱っています)ではなく、tools/callというMethodそのものにHandlerが存在しないケースです。

この場合は、

Tool Definitionは公開できている

ものの、

Tool実行Handlerが登録されていない

可能性があります。

たとえば独自のLow-level実装で、一覧取得用Handlerだけ作っている状態です。

概念的には、

tools/list → 実装済み

tools/call → 未実装

となっています。

これならクライアントにはToolが見えるため、LLMはそのToolを選択できます。

しかし実際にToolを呼ぶと、サーバーがtools/callを処理できません。

ToolがUIやMCP Inspectorに表示されているからといって、Call Handlerまで正常とは限らない点に注意してください。

Method名のスペルミスを確認する

独自MCPクライアントを実装している場合は、単純なMethod名の間違いも確認します。

正しいMethodは、

tools/list

です。

次のような名前ではありません。

tool/list

また、

tools/call

に対して、

tool/call

tools/invoke

を送っても、対応HandlerがなければMethod not foundになります。

MCP SDKのClient APIを利用している場合は通常SDK側が正しいMethodを生成しますが、JSON-RPCを直接組み立てている場合や独自Gatewayを挟んでいる場合にはRequest Bodyを確認してください。

HTTPのURLではなくJSON-RPC Methodを見る

REST APIに慣れていると、

/tools/list

というHTTPエンドポイントが存在するように考えてしまうことがあります。

しかしMCPのStreamable HTTPでは、単一のMCP EndpointへJSON-RPC Requestを送り、そのBody内のmethodで操作を指定します。

2026-07-28仕様では、たとえばtools/callは次のような単一POSTとして送信されます。

POST /mcp HTTP/1.1
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

Bodyには、

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "q": "MCP"
    }
  }
}

が入ります。

したがって、

POST /tools/call

という独自REST APIを作るのとは別の仕組みです。

なお、MCPサーバーが実装していないRPC Methodへリクエストが届いた場合、Streamable HTTPでは404 Not Foundと-32601 Method not foundのJSON-RPCエラーが返る仕様になっています。この404は、モダンなMCP Endpointを持たない旧世代のHTTP+SSEサーバーが返す404と区別するためのものなので、ステータスコードだけでなくエラーBodyの中身まで確認してください。

2026-07-28仕様ではProtocol Versionの違いが特に重要

2026年7月28日のMCP仕様では、ProtocolのLifecycleが大きく変更されました。

以前のMCPでは、

initialize
↓
initialized
↓
通常のMCP通信

というHandshakeが存在しました。

しかし2026-07-28ではinitializeとnotifications/initializedが廃止され、各RequestがProtocol VersionやClient情報を自身の_metaに持つStatelessな構成へ変更されています。事前にServer Capabilityを確認するためのserver/discoverも追加されました。

つまり2026年現在、古いMCPクライアントと新しいMCPサーバー、あるいは新しいクライアントと古いサーバーを組み合わせると、Methodそのものが片側に存在しない場合があります。

これがMethod not foundの重要な原因です。

新しいクライアントから古いサーバーへserver/discoverを送るとどうなるか

2026-07-28ではserver/discoverが利用できます。

これはサーバーが対応しているProtocol VersionやCapabilitiesを問い合わせるMethodです。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "server/discover",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28"
    }
  }
}

しかし古いMCPサーバーはserver/discoverを知りません。

そのため-32601 Method not foundが返ることがあります。

これは必ずしもサーバー故障ではありません。

新旧両方へ対応するstdioクライアントは、最初にserver/discoverを送り、Method not foundが返った場合には旧方式のinitialize Handshakeへフォールバックする、という後方互換の使い方が想定されています。

つまり、

server/discover → Method not found

だけなら、Protocol Version判定のために意図的に発生している可能性があります。

古いMethodを新しいMCPサーバーへ送ってもMethod not foundになる

逆方向の世代不一致でもエラーになります。

2026-07-28では、それまでのresources/subscribe / resources/unsubscribeがsubscriptions/listenへ置き換えられています。

そのため、2025年世代のresources/subscribeをそのまま2026-07-28だけに対応したサーバーへ送ると、Method not foundになります。

つまり、

SDKを更新した

直後にMethod not foundが出るようになった場合は、Method名だけではなく、

Client SDKのProtocol Version

Server SDKのProtocol Version

接続時に実際に選択されたProtocol Version

を確認する必要があります。

ClientとServerのSDKバージョンを揃えるだけでは不十分な場合がある

MCPの互換性を調べるときに、

npm packageのversion

だけを見るのは十分ではありません。

重要なのは、そのSDKがどのMCP Protocol Revisionを利用しているかです。

MCPのProtocol Versionは、

2025-06-18

2025-11-25

2026-07-28

のような日付形式で管理されています。

現在のMCP C# SDKなどでは複数世代をサポートし、新しい2026-07-28へ接続できない場合に旧initialize方式へフォールバックする仕組みも用意されています。

一方、Protocol Versionを明示的に固定すると自動Fallbackが行われない場合があります。

「SDKは最新版なのに接続できない」という場合は、Protocol Versionを手動指定していないかも確認してください。

Capabilityを確認してからMethodを呼ぶ

MCPではOptionalな機能もあります。

そのため、クライアントが「MCP ServerだからすべてのMethodを使える」と仮定するのは避けるべきです。

たとえばToolを利用するなら、Server Capabilityにtoolsがあるか確認します。

2026-07-28世代ではserver/discoverによってCapabilitiesを確認できます。

概念的には次のようなResponseです。

{
  "result": {
    "supportedVersions": ["2026-07-28"],
    "capabilities": {
      "tools": {}
    }
  }
}

ここにtoolsが存在するなら、クライアントはTool関連Methodを利用できると判断できます。

存在しないCapabilityに対応するOptional Methodを無条件で呼ぶ設計は、Method not foundを発生させる原因になります。

高レベルSDKを使っているならTool登録処理を確認する

MCP SDKの高レベルAPIを利用している場合は、通常tools/listやtools/callを直接実装する必要はありません。

たとえばToolをSDKへ登録すれば、SDKが一覧取得やTool Callを処理します。

この場合に確認するべきなのは、Tool Definitionだけを書いて終わっていないかです。

実際のサーバーインスタンスへToolが登録されているかを確認します。

Toolを定義したファイルが存在していても、

そのモジュールが読み込まれていない

なら登録されません。

条件付きImportやFeature Flagを利用している場合にも注意が必要です。

開発環境ではTool Moduleが読み込まれるのに、本番環境では環境変数によって登録処理が実行されないケースがあります。

Low-level ServerではHandler登録を確認する

Low-level SDKを利用してMCP Serverを自作している場合は、Method Handlerの登録状態を直接確認します。

たとえばCapabilityとして、

{
  "tools": {}
}

を宣言しているだけでは、利用しているSDKやAPIレベルによってはHandlerが自動登録されない場合があります。

MCP TypeScript SDK v2では高レベルのMcpServerならPrimitive CapabilityのHandlerが自動的に用意されますが、Low-level Serverでは宣言したCapabilityに対応するHandlerを自分で登録する責任があります。

独自実装でMethod not foundが出る場合は、

Capabilityを宣言したか

だけでなく、

そのMethodのRequest Handlerを登録したか

まで確認してください。

tools/listだけを直接テストする

AIホストからMCP Serverを呼んでいると、エラー発生場所が分かりにくくなります。

そこで最初にLLMやAgentを外し、tools/listだけを単体でテストすると切り分けやすくなります。

確認したいのは、

MCP Serverへ接続できるか

ではなく、

tools/listが正常なJSON-RPC Resultを返すか

です。

正常なら少なくとも、

Transport

Protocol Version

tools/list Handler

までは動いている可能性が高くなります。

ここでMethod not foundになるなら、LLMのTool選択やPromptは関係ありません。

サーバー実装またはProtocol互換性を調べます。

tools/list成功後にtools/callを単体テストする

tools/listが成功したら、返ってきたTool名を1つ選び、tools/callを直接実行します。

たとえば一覧に、

get_weather

があれば、

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "Tokyo"
    }
  }
}

を送ります。

ここで成功すれば、

tools/list

tools/call

Tool Registry

の基本経路は動作しています。

一方、tools/listだけ成功してtools/callがMethod not foundになるなら、Call Handler側へ問題を絞れます。

Tool名が違う場合は別のエラーとして調べる

tools/call自体が成功しているものの、

get_weather

というToolだけ見つからない場合は、今回のMethod not foundとは分けて考えます。

次の2つは別問題です。

tools/call

と、

get_weather

です。

Tool名の登録漏れや名前の不一致については、Function Callingと同じようにTool Registryを確認します。

get_weatherとgetWeatherのような表記違いでもTool Lookupに失敗する可能性があります。

まずMethodが存在することを確認し、その後Tool名を確認する順番にすると切り分けやすくなります。

Streamable HTTPではヘッダーも確認する

2026-07-28仕様のStreamable HTTPでは、Request Bodyだけでなく標準HTTP Headerも重要になっています。

現在は、

MCP-Protocol-Version

Mcp-Method

Mcp-Name

などを利用します。Mcp-MethodはすべてのRequestで必須、Mcp-Nameはtools/call・resources/read・prompts/getのようにToolやResource名を伴うRequestでのみ必須です。

たとえばTool Callなら、

Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather

のようになります。

これらのHeaderとRequest Bodyの値が一致しているかはサーバー側で検証され、食い違っている場合にはMethod not foundではなく400 Bad RequestとHeaderMismatchのJSON-RPCエラーが返る仕様になっています。

そのため2026年仕様でHTTP接続が失敗している場合は、JSON-RPC BodyだけでなくHTTP Headerも確認してください。

特にProxy、API Gateway、WAFを挟んでいる構成では、Headerが削除または書き換えられていないか確認する必要があります。

initializeがMethod not foundになる場合は新仕様サーバーの可能性がある

古いMCPクライアントが、

initialize

を送ったところ、

Method not found

になるケースも今後増える可能性があります。

2026-07-28仕様では従来のinitialize / initialized Handshakeが廃止されています。

そのため新仕様だけをサポートするServerへ、旧Lifecycleを前提としたClientから接続すると互換性問題が発生します。

この場合はServerにinitializeを無理に追加するより、

Clientを2026-07-28対応版へ更新する

または、

Server側でLegacy Protocolもサポートする

など、Protocol Versionを揃える方向で対応します。

SDK更新後に発生したならBreaking Changeを疑う

MCPは2026年7月28日に大きなProtocol変更が行われています。

2026-07-28はHandshakeとSessionの廃止、Stateless Core、server/discover、Header Based Routingなどを含む大規模なRevisionで、Release Candidateの段階からBreaking Changesを含むことが案内されていました。

そのため、

MCP SDKをアップデートした直後

や、

MCPクライアントだけ更新した直後

にMethod not foundが出るようになった場合は、アプリケーションコードのバグだけを探すのではなくProtocol Generationの不一致を確認してください。

特に、

server/discover

initialize

resources/subscribe

subscriptions/listen

など世代によって扱いが変わったMethodでエラーになる場合は、Protocol Versionを最優先で確認する価値があります。

MCP Inspectorでtools/listとtools/callを分けて確認する

手元でMCP Inspectorを使える場合は、Toolsタブでの一覧表示とTool実行を別々に確認すると、Protocolレベルの問題かTool内部の問題かを素早く切り分けられます。この具体的な操作手順や、接続エラーを層ごとに確認していく順番はMCP Inspectorの使い方｜ツールを単体テストして接続エラーを調べるにまとめているため、この記事では概念面の整理にとどめます。

ログにはMethodとTool名を分けて残す

MCP Serverを本番運用するなら、JSON-RPC MethodとTool名を別々にログへ残すとトラブルシューティングしやすくなります。

たとえば、

method=tools/call
tool=get_weather
protocol=2026-07-28

のように記録します。

これなら、

tools/call自体が存在しない

のか、

tools/callには成功したがget_weatherが存在しない

のかを簡単に区別できます。

Protocol Versionも同時に記録しておけば、SDK更新後に特定世代だけ失敗しているケースも見つけやすくなります。

Method not foundを握りつぶして再試行し続けない

Method not foundが返ってきたときに、同じRequestを何度もRetryしても通常は直りません。

Timeoutや一時的なネットワーク障害とは性質が違うためです。

サーバーにHandlerが存在しないなら、10回送っても同じ結果になります。

特にAIエージェント側で、

失敗したら自動再試行

という仕組みを入れていると、

tools/call
↓
Method not found
↓
再試行
↓
Method not found
↓
再試行

という無駄なループになる可能性があります。

-32601を受け取った場合は単純Retryではなく、Method名、Capabilities、Protocol Versionを確認するエラーとして扱ったほうがよいでしょう。

tools/listとtools/callを順番に確認すると切り分けやすい

MCPサーバーでMethod not foundが発生したときは、最初からToolの実装コード全体を調べる必要はありません。

まずエラーになったJSON-RPC Methodを確認します。

次にtools/listを単体実行し、サーバーがTool一覧を返せるか確認します。

tools/listが成功したら、そこに表示されたToolをtools/callで直接実行します。

この順番なら、

Tool Discoveryで失敗しているのか

Tool Callで失敗しているのか

Tool名だけが間違っているのか

を分離できます。

また、MCP 2026-07-28ではProtocol Lifecycleが大きく変わっているため、新旧SDKを組み合わせた環境ではProtocol Versionも重要です。旧世代にしか存在しないMethodを新世代へ送った場合や、新しいserver/discoverを古いServerへ送った場合にもMethod not foundが発生する可能性があります。

特にSDK更新後からエラーが出た場合は、Methodのスペルミスだけでなく、ClientとServerが同じMCP Protocol Revisionで通信しているかを確認してください。

MCPのMethod not foundを直すポイントは、「Toolが見つからない」と決めつけず、どのJSON-RPC MethodをどのProtocol Versionで誰が送ったのかを確認することです。

tools/list、tools/call、Capabilities、Protocol Versionの順に確認すれば、原因をかなり絞り込みやすくなります。

Method not foundに関するよくある質問

まとめ

MCPサーバーでMethod not foundが発生したときは、「Toolが存在しない」と決めつけず、まずどのJSON-RPC Methodでエラーになったのかを確認することが重要です。

tools/listとtools/callは別々のMethodであり、Capabilityの宣言とHandlerの登録も別々に確認する必要があります。

さらに2026-07-28仕様ではinitializeハンドシェイクの廃止やserver/discoverの追加など、Protocol Lifecycleそのものが大きく変わっているため、SDK更新やクライアント・サーバーの世代差もMethod not foundの重要な原因になります。

tools/list、tools/call、Capabilities、Protocol Versionの順に切り分ければ、原因をかなり絞り込みやすくなります。実際に手を動かす切り分け手順はMCP Inspectorの使い方を参考にしてください。