You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature Request: Tool to list and manage MCP servers to reduce context window #2418
When we add a lot of global MCP servers, the context window blows up significantly since they need to be included in every single call to the models. However, we might not need all MCP servers for every particular project, leading to unnecessary context consumption.
Benefits
Improved performance for projects that don't need all global MCP servers
Better context window management
More granular control over MCP server usage
Allows user to keep all mcp servers in a global file thereby not worrying about project specific mcps.
Use Case
Users working on specific projects (e.g., web development, data analysis) shouldn't have to load MCP servers for unrelated domains (e.g., Kubernetes, AWS tools) if they're not needed for that particular project.
mcp zero look like the idea. mcp-hub still pollutes the entire context with all the tools. integrating mcp-hub did decrease the startup time and i've moved all the tool there. so thats a plus.
If you have a large number of MCP servers you may want to only enable them per agent and disable them globally. To do this:
Disable it as a tool globally.
In your agent config enable the MCP server as a tool.
@mittalsuraj18, not sure if that covers what you wanted.
There is another workaround, which I use: Context specific configuration files.
But this only feels natural in a containerized setting, which is my case.
Anthropic just released a server-side Tool Search Tool (beta) that solves this exact problem with deferred tool loading. We could implement a similar client-side version for OpenCode that works across all providers.
Reacted by Xavier A, /dev/null and Stephan Schielke
In the spirit of calling out excellent engineering and design....
I've found that the Pi Coding Agent is more robust and, for me has none of the issues that I've encountered in OC, or has an elegant way to resolve them.... I'm dropping out of OC issues:
Activity
github-actions commentedon Sep 4, 2025
This issue might be a duplicate of existing issues. Please check:
Feel free to ignore if none of these address your specific case.
marcinpz commentedon Sep 4, 2025
What about using MCP zero idea? https://arxiv.org/abs/2506.01056
mittalsuraj18 commentedon Sep 7, 2025
mcp zero look like the idea. mcp-hub still pollutes the entire context with all the tools. integrating mcp-hub did decrease the startup time and i've moved all the tool there. so thats a plus.
taqtiqa-mark commentedon Sep 27, 2025
@mittalsuraj18 can you say how https://opencode.ai/docs/agents/#tools is not fit for purpose. Specifically, turning off
mymcp_:mittalsuraj18 commentedon Oct 26, 2025
Soory for the late reply.
@taqtiqa-mark that would work but it would require us to carefully manage agents and the tools exposed to them.
What we need is, exposure to all the tools without polluting the context windows.
taqtiqa-mark commentedon Oct 26, 2025
Ahh okay, I think I see. Apologies.
Essentially you need to use:
I believe the docs cover your exact use case?
https://opencode.ai/docs/mcp-servers/#per-agent
@mittalsuraj18, not sure if that covers what you wanted.
There is another workaround, which I use: Context specific configuration files.
But this only feels natural in a containerized setting, which is my case.
HTH?
feat(tool): add tool_search for dynamic tool discovery
sandipwane commentedon Jan 14, 2026
Anthropic just released a server-side Tool Search Tool (beta) that solves this exact problem with deferred tool loading. We could implement a similar client-side version for OpenCode that works across all providers.
feat(tool): add tool_search for dynamic tool discovery
taqtiqa-mark commentedon Feb 6, 2026
In the spirit of calling out excellent engineering and design....
I've found that the Pi Coding Agent is more robust and, for me has none of the issues that I've encountered in OC, or has an elegant way to resolve them.... I'm dropping out of OC issues:
github-actions commentedon Apr 7, 2026
To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.