feat: Add progressive tool discovery system #1644
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[DRAFT PR FOR OBSERVABILITY] Overview
This PR implements optional progressive disclosure of MCP tools through semantic grouping and lazy-loading. Servers can organize tools into semantic groups with gateway tools that load actual tools on-demand, achieving significant reduction in context token usage at the start of conversations.
Problem Being Solved
MCP servers with 50+ tools currently expose all tool definitions upfront, causing significant context bloat. This wastes valuable context budget and makes it harder for LLMs to reason effectively. Additionally, server developers struggle to unify disparate tools across different domains into a coherent organization system.
Solution
Progressive tool discovery allows servers to:
This enables server developers to organize disparate tools (like GitHub's repo management, pull requests, code changes, collaboration features) into semantic groups that make sense for users and LLMs.
Key Features
is_discovery_enableddefaults to FalseImplementation
New components:
Example Use Case
Testing
All tests pass:
Backward Compatibility
100% compatible:
Benefits
1. Improved LLM Reasoning & Reduced Hallucination
With fewer tools in context, LLMs have better focus and make fewer mistakes about which tools are available. Significantly reduces the likelihood of LLMs hallucinating about non-existent tools or choosing irrelevant ones.
2. Lower API Costs
Fewer tokens per request means reduced billing for users. This is especially impactful for high-volume applications where token savings directly translate to cost savings.
3. Faster Initial Connection
Quicker
listTools()response times at conversation start (500 tokens instead of 4,000+). Provides better user experience with lower latency on the critical first interaction.4. Extensibility for Large Codebases
Makes it trivial to add new tools without overwhelming LLMs with choices. Enables servers to grow from 10 tools to 100+ tools without degradation in LLM performance.
5. Aligns with Industry Standards
Follows the same pattern as OpenAI's function calling for large tool sets. Reflects best practices in API design and progressive disclosure that users expect.
6. Multi-Agent Ready
Different agents can be given different tool subsets based on their responsibilities. Enables more sophisticated orchestration patterns and agent specialization.
7. Better Composability
Makes it easier to combine multiple MCP servers and organize their tools coherently. Solves the "tool management" problem for complex deployments with many integrated services.
Impact
This feature addresses a fundamental scalability challenge in MCP as server toolsets grow larger. It enables the ecosystem to handle production-scale deployments with hundreds of tools while maintaining optimal LLM performance and user experience.