vscode copilot sees (MCP) tools as disabled even if they are not. #184219
Replies: 8 comments 1 reply
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
This is extremely frustrating and costing tons of premium requests 😒 |
|
I've run into similar issues that often seem to be an MCP tool group that needs to be activated by the agent. Unfortunately the groups don't seem to be listable by the agent, so it can only succeed if it can guess the group name. I've not found a way to see the list either which seems to be created by Copilot. |
|
MCP: reset cached tools worked for me. |
|
For me it does not even work after resetting the tools cache |
|
One useful diagnostic is to separate tool availability from the model's ability to select and invoke a tool reliably. If the server exposes a large number of tools, I'd test with a reduced MCP configuration containing only the few tools needed for the current task. Keep the same model, prompt, and server, then compare behavior with the full tool list. Also check whether the main agent and subagent receive the same MCP configuration. A tool being available to one agent does not necessarily mean it is available to another, depending on how the client configures each agent. For reproducibility, record the exact tool name, whether it appears in the active session's tool list, which agent attempted to call it, and whether the previous successful call occurred in that same agent context. If the tool is present and callable but the model still claims it is disabled, that points toward a tool-selection or context issue rather than a server-connection failure. A minimal reproduction with a small tool set would help distinguish those possibilities. Could you confirm whether this happens with a single agent and only a handful of MCP tools, or only when subagents and the larger tool inventory are enabled? |
|
This is also hit and miss for me for awhile but I think am getting the pattern. I created a searxng mcp, and while testing it, I observe the following:
It is trivial to throw away those testing chat in this situation. But I can't imagine keep throwing away long session for bigger project. VSCode: Version: 1.144.0 (Universal) on MacOS |
Uh oh!
There was an error while loading. Please reload this page.
Select Topic Area
Bug
Copilot Feature Area
Copilot Agent Mode
Body
I keep seeing things like the example below. This happens even if the tools is there and it just used it. Sub-agents are in use (if that is important context). The sub agent rarely have a problem executing it tho, it's the main agent that has this problem. If i "prove" to it that the tool exist like #query-database explicitly .. it will understand and accept it. This is super annoying. I have 116 active tools so optimization isn't even in place (and it used the tool in the turn before it).
Explained by copilot itself (after seeing my mcp.json too):
The dbt-core MCP server is configured. The tool should be available but appears to be disabled. This might be a runtime configuration issue. Let me try checking if there are other available dbt tools:
The MCP server is working. Let me check the tool list to see the actual tool name for querying:
Based on my earlier successful test and the subagent's success, the query_database tool exists. However, it seems to be disabled for direct use in the main context but available to subagents. Let me delegate this to a subagent again to get you the timestamp information:
All reactions