Loading ToolBench
MCP server implementing a human-in-the-loop routing skill that routes agent tasks to human reviewers based on confidence scores
This server has critical definition quality issues. The single tool 'execute_skill_action' has a minimal description ('Execute human-in-the-loop router skill action', 17 chars, below the 20-char hard threshold), making it impossible for an LLM to understand when to call it or what it actually does. The input schema is present but severely underdocumented: 'confidence_score' has a basic type (float) and range hint (0.0-1.0) but no actionable description explaining what confidence represents, when to compute it, or how routing decisions are made. The output schema is completely undocumented, neither the tool description nor the source code reveals what the response contains, so an LLM cannot plan downstream tool calls or extract results. The tool name 'execute_skill_action' is generic and violates verb_noun clarity (it does not convey 'route' or 'decide'). The implementation in client.py shows a 'route_target' field is returned, but this is not documented in the MCP schema. There is no error handling, no recovery guidance, no parameter validation messaging, and no documentation of when to use this tool vs alternatives. The server does not implement proper MCP protocol patterns, it merely prints JSON to stdout without parsing incoming requests or handling the Model Context Protocol message format.
Execute human-in-the-loop router skill action
Tool description is 17 characters, below the 20-character hard minimum. Descriptions under 20 chars score at most 0-20. This description ('Execute human-in-the-loop router skill action') does not explain WHAT the tool does in agent terms, WHEN to use it (what decision scenarios), or WHAT it returns. An LLM cannot infer routing logic from this.
Input parameter 'confidence_score' has type (float) and range hint (0.0-1.0) but NO description. Per the rubric, every parameter needs a description explaining what it controls. 'confidence_score' is ambiguous: Is this the LLM's confidence in its own decision? The agent's confidence? A user-provided confidence metric? An LLM cannot infer how to compute or provide this value without documentation.
Output schema is not documented. The source code (client.py) shows the tool returns {'route_target': '...'} with values 'human_reviewer' or 'agent_resolve', but this is not declared in the MCP schema or tool definition. An LLM cannot know what to expect in the response, what fields are available for downstream tool calls, or how to interpret the result.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 20 | 2026-07-28+ | v2 |
Tool name 'execute_skill_action' is generic and does not follow verb_noun clarity. It does not convey the actual action: 'route'. A clearer name would be 'route_to_human_or_agent' or 'route_request_by_confidence', which immediately tells the LLM what decision is being made.
No error handling or recovery guidance. What if confidence_score is invalid (outside 0.0 - 1.0)? What if routing fails? The tool has no error response pattern to guide the LLM on next steps (retry, ask user, abort). Per the rubric, error responses must tell the agent what to do next.
No input validation documented. The parameter description should state 'confidence_score must be a float in the range 0.0 - 1.0' explicitly in the parameter description so the LLM can validate before calling and understand constraints. Currently, the constraint is hidden in the type/range and not documented in text.