When an underlying MCP server advertises 100+ tools (e.g. a Git platform, a cloud provider CLI, or an all-in-one automation tool), mcp-hub currently exposes every tool to the connected client with no way to reduce the surface area.
This creates two problems:
- Noise — clients (especially LLMs) receive an unwieldy tool list, making it harder to select the right tool for a task.
- No control — there's no server-side mechanism to limit which tools a given client can see or call. Fields like
autoApprove are passed through as metadata but aren't applied by the hub itself, and disabled_tools isn't implemented in the standalone server.
The Neovim plugin handles filtering client-side, but standalone mcp-hub clients have no equivalent option.
It would be useful to have a server-side tool filtering mechanism, whether through the config file, the REST API, or both.
When an underlying MCP server advertises 100+ tools (e.g. a Git platform, a cloud provider CLI, or an all-in-one automation tool), mcp-hub currently exposes every tool to the connected client with no way to reduce the surface area.
This creates two problems:
autoApproveare passed through as metadata but aren't applied by the hub itself, anddisabled_toolsisn't implemented in the standalone server.The Neovim plugin handles filtering client-side, but standalone mcp-hub clients have no equivalent option.
It would be useful to have a server-side tool filtering mechanism, whether through the config file, the REST API, or both.