Loading ToolBench
An AI agent system that uses MCP (Model Context Protocol) to dynamically load and execute tools. Implements a ReAct agent pattern with tool calling capabilities for complex task planning and execution.
This MCP server has fundamental definition quality problems. Three tools are registered (terminate, ask_human, plan), but critical information is missing or poorly specified. Tool descriptions exist but lack LLM-optimized guidance on when to use each tool and what they return. The 'plan' tool has a severely malformed schema with an 'enum' field in the wrong place (plan_id parameter shows enum values that are actually command names, not plan IDs). Parameter descriptions are minimal or absent. No output schemas are documented. Error handling guidance is absent. The server would not pass code review for production use.
Ask human for help when the request is met OR if the assistant cannot proceed further with the task. When you have finished all the tasks, call this tool to end the work.
A planning tool that allows the agent to create and manage plans for solving complex tasks. The tool provides functionality for creating plans, updating plan steps, and tracking progress.
Terminate the agent execution with a completion status.
Critical: 'plan' tool has malformed schema. The 'plan_id' parameter declares enum=['create','update','set_active','delete','get','mark_step'], these are COMMAND values, not valid plan IDs. The 'command' parameter should be the enum field. This will cause LLM confusion and tool failures.
High: No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required data. Callers must guess what fields are returned.
High: 'ask_human' description is vague ('Ask human for help when... OR if... When you have finished...'). Does this tool block execution? Return user input? Terminate? The LLM cannot determine when to call it vs 'terminate'.
High: 'terminate' tool description lacks actionable detail. What happens after termination? Can the agent continue? Is the status enum values ('成功','失败') documented? These are Chinese characters, no explanation of what constitutes success vs failure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 25 | - | v1 |
High: 'plan' tool parameter descriptions are minimal or missing. 'step_status' parameter has an enum=['not_started','in_progress','completed','blocked'] but no description of when each status applies. 'plan_id' description says 'Required for create...' but 'create' is a command, not a parameter.
Medium: No error handling guidance. If a tool call fails (invalid plan_id, missing step, malformed arguments), how should the LLM recover? No error examples or recovery paths documented.
Medium: 'ask_human' and 'terminate' naming lack action verbs. 'ask_human' could be 'prompt_user' or 'request_user_input'. 'terminate' lacks context, terminate what? The agent? The plan? Just the verb + noun is insufficient.
Medium: 'plan' tool bundles 7 distinct commands (create, update, list, get, set_active, mark_step, delete) into a single tool. This violates single-responsibility; LLMs must infer which command to use based on intent. Consider splitting: create_plan, update_plan, list_plans, etc.
Medium: Parameter 'inquire' in 'ask_human' is non-standard. Use 'query', 'question', or 'prompt', 'inquire' is awkward and inconsistent with common naming conventions.