Repository navigation
Repeated MCP discovery reports "Found 0 tools" for an already-loaded namespace #4773
Description
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
- In a fresh session, discover the configured MCP namespace. In this case, the call was
api_tool.list_resources({"paths":["pr-copilot"]}). - Observe "Found 4 tools" and all four tool definitions being loaded.
- Repeat the identical discovery call without changing MCP configuration.
- 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
Activity
aldi949 commentedon Sep 9, 2026
@m-nash I'm looking at this because the repeated
Found 0 toolsresult against an already-loaded namespace is exactly the kind of failure that's hard to diagnose from the outside.I'm working on an open-source tool-calling debugger and I've frozen the current RC before external testing so I can't tune it around individual reports. If you still have the original pre-debugging session/request data for this failure, would you be willing to share a sanitized copy of the relevant payload/tool catalog and the failing logs? Environment/config details around the MCP namespace would help too.
I'd like to try reproducing the same failure identity and run the frozen diagnoser against it, then send you the result and evidence. If you've already figured out the root cause, please don't tell me yet — just let me know it's known so I don't treat the case as blind validation.
No credentials or private project data needed.