Loading ToolBench
An MCP orchestrator server that routes tool calls from a single agent to multiple downstream MCP servers, enabling capability discovery and tool invocation across distributed MCP services.
Server defines 9 tools with clear naming (verb_noun pattern: list_, discover_, route, generate_, echo, fail, slow, get_, search_). Descriptions are present and substantive (avg ~120 chars), exceeding the 10-char minimum. All tools have input schemas with type declarations. However, schemas lack depth: parameter descriptions are minimal (e.g., 'Capability name from list_capabilities'), output schemas are undocumented (no return type specs), and error handling guidance is absent. The orchestrator pattern is novel but introduces composition risk: route() accepts arbitrary 'arguments' objects with no validation hints, forcing LLMs to infer correctness from discover_tools output alone. Three demo tools (echo, fail, slow) are diagnostic stubs, not production patterns. Overall: solid naming and basic schemas, but incomplete documentation and no error recovery guidance.
Connect to one downstream capability and list its concrete tools, each with its name, description, and JSON input schema. Use this after 'list_capabilities' to learn exactly what a capability can do and which arguments each tool needs, before calling 'route'.
Echo the supplied message back unchanged.
Always fails — used to test downstream error handling.
Generate a simple C# class. Provide a class name and an optional comma-separated list of fields.
Get a single JIRA issue by its key (e.g. PROJ-1). Returns key, summary, status, assignee.
List the downstream MCP capabilities this orchestrator can reach (e.g. 'jira', 'codegen', 'db'). Call this FIRST to find out what is available. Each entry has a name, a summary of what it does, and instructions telling you exactly what to pass. The reliable path is: read the instructions here, call 'discover_tools' to see a capability's tools and their schemas, then call 'route' with the exact tool and arguments. Follow each capability's instructions literally (e.g. 'always include the Jira issue key') — the orchestrator forwards what you send verbatim and does not interpret it.
route() accepts unvalidated 'arguments' object with no schema constraints. LLMs must infer correctness from discover_tools output; no inline validation or error guidance if arguments mismatch downstream tool schema.
No output schemas documented for any tool. LLMs cannot predict return structure (e.g., does list_capabilities return array or object? What fields in each entry?). Breaks tool chaining and forces discovery calls.
No error recovery guidance. Tools like route() can fail (downstream MCP unreachable, tool not found, arguments invalid) but descriptions do not explain what to do next or how to self-correct.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2025-06-18+ | v2 |
Forward a tool call to a downstream capability and return its result. You choose the capability and the exact tool name (from 'discover_tools') and pass an 'arguments' object matching that tool's input schema — you do the interpreting, the orchestrator just couriers the call verbatim and relays the response. Honor the capability's instructions when filling arguments (e.g. always include the Jira issue key).
Search JIRA issues by a free-text query against the summary. Returns matching issues.
Sleep for the given number of milliseconds, then return 'done'.
Parameter descriptions are terse (avg ~40 chars). 'Capability name from list_capabilities' lacks format/constraint hints. 'Arguments object matching the tool's input schema' does not explain how LLM validates match or what happens on mismatch.
Three tools (echo, fail, slow) are diagnostic stubs, not production patterns. They clutter the tool namespace and confuse LLMs about which tools are safe to call in real workflows.