MCP Serverに接続できているのにToolsが表示されない場合、最初に確認するのはTool実行ではなくtool discoveryです。`tools/list`が何を返しているかを境界にすると、Server側の登録問題なのか、Host側の表示・許可問題なのかを切り分けやすくなります。
まず確認：どの段階でToolsが消えているか
| 観測結果 | 疑う場所 | 次の確認 |
|---|---|---|
| Serverへ接続できない | transport / initialize | stdio・HTTP・認証・起動ログ |
| tools/listが呼べない | capability / protocol | Serverがtools capabilityを宣言しているか |
| tools/listが空 | Server registration / authorization | Tool登録状態・認可scope |
| tools/listにはあるがHostで見えない | Host設定 | 許可・filter・接続更新 |
| 表示されるが実行できない | tools/call / input / authorization | Tool名・schema・権限・実行エラー |
「接続できた」と「Toolを発見できた」は別の段階です。まず`tools/list`まで通るかを確認し、その結果を基準にServer側とHost側を分けます。
1：Serverがtools capabilityを公開しているか確認する
MCP 2026-07-28仕様では、ToolsをサポートするServerは`tools` capabilityを宣言し、Clientからの`tools/list`へ現在利用可能なTool集合を返します。Tool機能自体を公開していない場合は、Host側の再読み込みだけでは解決しません。
{
"capabilities": {
"tools": {
"listChanged": true
}
}
}用語解説：tools/list
MCP ClientがServerに対して利用可能なTool一覧を問い合わせるprotocol requestです。表示されるToolの名前・説明・input schemaなどの発見に使われます。
（MCP Serverそのものの役割から確認したい場合については『MCPサーバーとは？仕組みと使い方』をご参照ください）
2：tools/listの返り値を直接確認する
Clientを自作している場合は、Host画面を見る前に`listTools()`の結果を確認します。TypeScript SDK v2では、`listTools()`が接続先ServerのadvertiseするToolsを取得します。
const { tools } = await client.listTools();
for (const tool of tools) {
console.log(tool.name, tool.description);
}ここでToolsが返れば、ServerからClientまでのdiscoveryは成立しています。0件ならServerのTool登録と認可条件へ進みます。
3：空配列ならTool登録とauthorizationを切り分ける
現行MCP仕様では、`tools/list`が返す集合は空でも成立します。また、requestに付いたauthorizationによって利用可能なTool集合が変わることがあります。そのため「空＝通信失敗」と決めつけず、ServerがToolを登録しているか、現在の認可でそのToolを公開する設計かを確認します。
- Server起動時にTool登録処理が実行されているか
- 登録したToolがdisabled状態になっていないか
- Clientが想定したServer/環境へ接続しているか
- 現在のcredentialやscopeでToolが公開対象になっているか
TypeScript SDKのServer実装では、登録済みで有効なToolを`tools/list`へ組み立てます。Toolの実装ファイルが存在するだけでは一覧へ出ないので、実際のregister処理を確認します。
4：Toolsが返るのにHostで見えないならHost側へ移る
`tools/list`で目的のToolが返っているなら、protocol上のdiscoveryとHostでモデルへ公開される範囲を分けて考えます。Host製品によって設定名やUIは異なるため、共通して確認できるのは「接続を再読込したか」「そのServer/Toolが利用許可されているか」「Tool filterやpolicyで除外されていないか」です。
- MCP接続を切り替えた後にHostがTool一覧を再取得しているか
- 接続先Serverが有効になっているか
- Hostまたは組織policyでToolが非表示・無効化されていないか
- 別Environmentや別Profileを見ていないか
ここはMCP core protocolではなくHost実装の領域です。特定Hostの設定名を別製品へそのまま当てはめないようにします。
5：Toolを追加・変更した直後はlistChangedと再取得を確認する
ServerのTool集合が変化する構成では、`listChanged`対応を使ってClientへ変更を通知できます。通知を利用しないHostや接続では、再接続・再読込後に`tools/list`を取り直し、古い一覧を見続けていないか確認します。
Tool名を変えた、条件付きでToolを登録した、認可scopeを変えた、といった変更直後は、ServerログとClient側の取得結果を同じ時点で比較すると原因を追いやすくなります。
6：一覧に出た後の失敗はtools/call側として調べる
Toolが一覧に出るのに実行時だけ失敗する場合は、discovery問題ではありません。Tool名、input schema、argument、authorization、Server側処理を確認します。TypeScript SDKでは`callTool()`でToolを名前指定して呼び出します。
const result = await client.callTool({
name: "lookup-order",
arguments: { id: "A-1041" }
});
console.log(result.isError, result.content);この段階を`tools/list`問題と混ぜないことで、Server起動やHost設定を何度もやり直す無駄を減らせます。
確認順：connectionからtools/callまで1段ずつ進める
- Serverが起動しClientとinitializeできているか
- Serverがtools capabilityを宣言しているか
- tools/listの結果に目的のToolが含まれるか
- 空ならTool登録・enabled状態・authorizationを確認する
- 一覧にあるのに見えないならHost側の許可・filter・再読込を確認する
- 一覧にあり実行だけ失敗するならtools/call・schema・権限を確認する
重要なのは、画面に出ないという症状だけでServer・Client・Hostを同時に変更しないことです。`tools/list`を観測点にすると、変更箇所を絞ったまま検証できます。
まず現在の接続で`tools/list`の返り値を確認し、0件なのか、目的のToolは返っているのかを記録してから次の層へ進んでください。
