Loading ToolBench
A server for coordinating human-in-the-loop operations with AI agents
The Human Loop MCP Server defines a single tool 'evaluate_need_for_human' with a clear input schema and basic description. However, the server has significant gaps in definition quality. The tool name uses 'evaluate' prefix (verb-starting, good), but the description is extremely brief (47 chars, below the 194-char baseline for production tools). The input schema is present and typed, but lacks critical elements: no output schema is documented, making it impossible for LLMs to plan downstream operations. The 'modelCapabilities' parameter lacks a description, violating the requirement that every parameter must explain what it controls. The tool performs a READ_ONLY evaluation with no state modification, but this is not documented in the description. Error handling is minimal, the code throws generic 'Unknown tool' errors rather than actionable recovery guidance. The TaskEvaluator.evaluateTask() implementation returns a complex nested object (needsHuman, confidence, reason, suggestedAction, confidentStatements, humanQuestions) but this output schema is never documented in the tool definition, forcing LLMs to infer the response structure.
Evaluate if a task requires human intervention
Output schema not documented. Tool returns a complex object with fields (needsHuman, confidence, reason, suggestedAction, confidentStatements, humanQuestions) but ListToolsRequestSchema response omits the output schema entirely. LLMs cannot plan what data will be available after calling this tool.
Parameter 'modelCapabilities' lacks description. The array parameter is defined but has no explanation of what values it expects, what each capability string should contain, or when/why to provide it. Rubric requires every parameter to have a description explaining what it controls.
Tool description too brief (47 chars). Baseline is 194 chars (p10=34, p90=392). Current description 'Evaluate if a task requires human intervention' lacks context for when/why an LLM should call this tool vs solving the task directly. No mention of prerequisites (what does 'modelCapabilities' need to contain?) or what the confidence score means.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Error handling provides no recovery guidance. The code throws 'Unknown tool' for invalid tool names but provides no actionable error message. Per the recovery-guide pattern, errors should tell the LLM what to do next.
Tool response structure is undocumented. Internal evaluation logic returns fields like 'confidentStatements' (array of strings) and 'humanQuestions' (array of strings) with no documented format. If an LLM receives a 'humanQuestions' field, it has no schema to validate or understand its structure.
No indication of whether confidence is 0-1 or 0-100. The code calculates and returns a 'confidence' field but does not document the scale, range, or meaning. LLMs cannot reliably interpret an undocumented confidence value.