Repeated MCP discovery reports "Found 0 tools" for an already-loaded namespace

まず、MCP名前空間に対する api_tool.list_resources の繰り返し呼び出しがモデル側でどのように処理されるかを追跡し、最初のレスポンスと後続のレスポンスを比較します。繰り返しの検出によって、すでに読み込まれているツールと、利用可能または一致するツールがない状態とが明確に区別され、既存の名前または件数が含まれていれば完了です。

Summary

Repeated model-side MCP tool discovery reports "Found 0 tools" for a namespace whose tool definitions were already loaded. This misleading result caused the agent to declare a working integration unavailable and skip a required workflow step.

Environment

• Copilot CLI 1.0.84-2
• Windows
• Local stdio MCP server exposing four tools

Reproduction

1. In a fresh session, discover the configured MCP namespace. In this case, the call was api_tool.list_resources({"paths":["pr-copilot"]}).
2. Observe "Found 4 tools" and all four tool definitions being loaded.
3. Repeat the identical discovery call without changing MCP configuration.
4. Observe "Found 0 tools", despite the previously loaded definitions remaining in context.

This was reproduced in a separate session after investigating the original failure.

Actual behavior and impact

The affected session already had all four schemas in its request history. Two later discovery responses completed with tools: []. The agent then reported: "The PR-monitor integration currently exposes no tools, so I can't start it."

The empty responses were real; the incorrect inference was that no tools were available. This report concerns model-side discovery, not a claim that the MCP server's raw tools/list returned an empty list. No stateful monitor invocation was needed to reproduce the discovery behavior.

Expected behavior

A repeated lookup should either return the existing tool definitions or explicitly report that the tools are already loaded, including their names/count. "No additional definitions to load" must be distinguishable from "no matching or available tools", so the agent does not abandon an available integration.

🤖 m-nash-copilot