Loading ToolBench
An aggregated MCP server that combines multiple MCP client functionalities and provides HTTP/STDIO transport with tools, prompts, and resources aggregation
This MCP server provides tool aggregation functionality with only 2 tools. Both tools have descriptions, but schema visibility is severely limited in the provided code excerpt. The naming follows basic conventions (ListAggregatedTools, CallAggregatedTool), but parameter descriptions are largely absent or generic. The code snippet is incomplete (cuts off mid-line in McpToolsHandler.cs), preventing full schema assessment. Based on visible evidence: tool names use generic verbs ('List', 'Call') without clear action intent; input schema for CallAggregatedTool shows only bare 'name' and 'arguments' without detailed parameter descriptions; no evidence of output schema documentation; error handling strategy is unclear from the excerpt. The aggregation pattern itself is sound, but the tool interface design does not meet production baseline standards for parameter clarity, output documentation, or error guidance.
Calls a tool on an aggregated MCP client by routing the request to the correct client based on tool name prefix (format: ClientName-ToolName)
Retrieves a list of tools from all aggregated MCP clients, prefixing tool names with client names in format 'ClientName-ToolName'
Input schema severely underspecified. CallAggregatedTool accepts 'arguments' as free-form object with no type constraints, enum values, or nested parameter documentation. LLMs cannot infer what nested keys are valid, required, or what types they expect.
Output schema not documented in visible code. No evidence of return type definitions for either tool. LLMs cannot plan downstream tool calls or extract required IDs (e.g., what fields do aggregated tools return? Are they prefixed? Can results be paginated?).
Parameter descriptions are minimal or missing. The 'arguments' parameter in CallAggregatedTool has only 'Tool arguments as key-value pairs', no guidance on structure, required keys, type expectations, or how they map to the remote tool's schema.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 31 | - | v1 |
Generic verb names lack clarity. 'ListAggregatedTools' and 'CallAggregatedTool' use weak verbs ('List', 'Call') that do not clearly signal intent. Pattern suggests 'list_' prefix is correct, but 'call_aggregated_tool' is still vague, does it execute, route, or forward? A name like 'route_to_aggregated_tool' or 'execute_remote_tool' would be clearer.
No evidence of error handling or recovery guidance. If CallAggregatedTool fails to route to a client, what error is returned? Can the agent retry? Are available clients listed? The code excerpt does not show error classification or actionable guidance.
Tool naming convention inconsistency. Server uses PascalCase (ListAggregatedTools, CallAggregatedTool) rather than snake_case (list_aggregated_tools, call_aggregated_tool). The MCP protocol and production baselines favor snake_case for tool names to align with LLM expectations.
No pagination support visible. ListAggregatedTools likely returns all tools from all clients. Large MCP server networks could return hundreds of tools, exhausting context window. No limit, page_size, or cursor parameters visible in schema.