Loading ToolBench
An MCP proxy server that provides hierarchical tool discovery and lazy-loading of MCP clients. It exposes tools from multiple MCP servers through a unified interface with category-based discovery and on-demand activation.
lazy-mcp is a proxy/gateway MCP server that wraps external MCP servers and exposes a discovery + execution interface. The three tools present have critical definition gaps: tool descriptions exist but lack sufficient detail for LLM reasoning, schemas are partially visible but incomplete, and parameter descriptions are minimal. The server's primary role as a 'lazy loader' of external tools is evident, but the tool definitions themselves do not meet production quality standards. Tool names are verb-based and clear (get_tools_in_category, execute_tool), but parameter documentation and output schemas are severely under-specified. The activate_<server_name> tool is dynamically generated and inferred rather than explicitly defined in code, limiting confidence in its schema completeness.
Activate and load all tools from the specified MCP server. This will load tools, prompts, resources, and resource templates from that server.
Execute a tool by its full path. Automatically proxies the request to the appropriate MCP server.
You have MCP tools hidden within categories. You MUST use get_tools_in_category to learn more about what available tools you have within these categories. Returns children categories, and tools at the specified path. Call initially with an empty string to get root categories.
activate_<server_name> tool lacks explicit schema definition and documentation. The tool is dynamically generated (inferred from internal/client/client.go) but no schema properties, parameter descriptions, or return type is visible in source code.
execute_tool's 'arguments' parameter has type 'object' with 'additionalProperties: true' but no schema for the actual argument structure. LLMs cannot determine what fields are valid for different tool_paths. Output schema is also undocumented, what does the tool return? Status? Result data? Error?
get_tools_in_category lacks output schema documentation. The description claims it 'Returns children categories, and tools at the specified path' but does not specify the structure: is it {categories: [], tools: []}? What fields are in each tool object? LLMs must guess at downstream field references.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Parameter 'path' in get_tools_in_category has minimal description ('Category path using dot notation...'). No guidance on error cases: what happens if path does not exist? Should LLM retry with empty string? What is the maximum nesting depth?
execute_tool 'tool_path' parameter description says 'or just tool name if unique' but provides no guidance on how LLM determines uniqueness or recovers if name is ambiguous. No enumeration of known tool_paths. Error handling is absent.
No error classification or recovery guidance. What happens if execute_tool is called with an invalid tool_path? If a proxied tool fails, what does the error response contain and how should the LLM respond?
Tool descriptions lack context on WHEN to use each tool. get_tools_in_category says 'You MUST use... to learn more' (imperative) but does not explain when discovery is needed vs when direct execute_tool calls suffice. Agents cannot determine discovery strategy.
activate_<server_name> has no documented prerequisites, return value, or side effects. Does activation load tools into memory? Is it required before execute_tool works? What does 'loading tools, prompts, resources, and resource templates' actually mean for the agent workflow?