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

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

首先跟踪模型侧对某个 MCP 命名空间重复调用 api_tool.list_resources 的处理方式，并比较第一次响应与后续响应。完成的标准是，重复发现能够明确区分已加载的工具与没有可用或匹配工具的情况，并包含现有名称或数量。