🚀 Feature Proposal: Query-Aware list_tools for Scalable Tool Selection

Problem Statement

MCP servers hosting large toolsets (e.g., 400+ tools) face several issues with the current list_tools approach:

• High token usage: Tool metadata consumes LLM context.
• Reduced accuracy: LLMs struggle to identify relevant tools from large sets.
• Short tool definitions: Servers must truncate descriptions, hurting comprehension.

Proposal

Enhance the list_tools API to accept an optional query parameter and return a filtered subset of tools using semantic or vector search. This enables:

• Smaller, more relevant tool lists.
• Richer tool descriptions.
• Lower token usage and faster processing.

Key Features

• Optional query in list_tools().
• Vector/semantic filtering (e.g., FAISS).
• Top-K relevant tools returned.
• Backward-compatible with current behaviour.
• In-memory without needing an additional vector store.

Multi-Server Extension

For clients using multiple MCP servers, the same filtering can be made available on the client to,

• Narrow down toolsets across servers efficiently

Open Questions

• Should filtering be implemented server-side, client-side, or both?
• Should similarity scores be returned?
• Is mid-conversation re-filtering useful?
• Are keyword-based heuristics a simpler alternative?

Feedback

Suggestions, alternatives, and implementation ideas are welcome. Looking forward to community input (@ihrpr @Kludex).