Loading ToolBench
MCP server that exposes agents, agent groups, MCP server tools, and skills as callable tools. Implements JSON-RPC 2.0 protocol for tool listing and execution.
Critical gaps across all dimensions. Tool names lack clear action verbs (ask_<agentID>, group__<groupID>, skill__<skillID> are template-based, not verb-noun patterns). Descriptions are present but generic and lack WHEN/WHY guidance. Input schemas exist but are minimal, most parameters lack type constraints, enums, or validation hints. No output schemas documented. Error handling absent. The dynamic tool registration pattern (tools named with IDs/placeholders) makes it impossible to validate schemas statically; actual tool definitions are inferred from templates, not explicit registrations. This violates the 'cap inferred tools at 50' rule.
Send a question or task to a specific agent. The agent processes the input and returns a response.
Use this moderated multi-agent group when its combined members are better suited than a single agent. A moderator selects the agents best suited to answer, and they can build on previous contributions.
List all available agents that the user has access to.
Tool exposed by an external MCP server. The tool name and description are provided by the MCP server.
Retrieve the instruction content of a skill. Skills are instruction documents served verbatim on call.
Tool names use template placeholders (ask_<agentID>, group__<groupID>) instead of verb-noun patterns. LLMs cannot parse intent from names like 'ask_<agentID>', they need concrete, action-oriented names like 'send_question_to_agent' or 'query_agent'. Template-based naming violates the verb-noun convention and makes tool discovery ambiguous.
Input schemas present but severely incomplete. Parameters lack type constraints, enums, min/max bounds, and format specifications. E.g., 'question' is a bare string with no length limits, format hints, or examples. 'session_id' has no description of format or how to obtain one. No validation rules documented.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields without knowing response structure. E.g., does ask_<agentID> return {response: string} or {response: string, agent_id: string, session_id: string}? Unknown.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 40 | <=2025-11-25 | v2 |
Descriptions are generic and lack WHEN/WHY context. E.g., 'Send a question or task to a specific agent' does not explain when to use ask_<agentID> vs group__<groupID>, what prerequisites exist, or what the agent returns. Descriptions should be 50-200 chars and answer: What? When? Why? Current descriptions are 60-150 chars but lack actionable guidance.
Dynamic tool registration via templates makes static schema validation impossible. Tools are inferred from naming patterns, not explicitly registered with full schemas. Per HARD SCORING RULE: 'If you cannot see the actual tool definition in the source (only inferred): cap that tool's overall at 50.' Four of five tools are template-inferred.