Loading ToolBench
This MCP server has critical gaps in definition quality across all four tools. While tool names start with action verbs (run_, complete_, fail_, show_), they lack the specificity required by production standards. Descriptions exist but are minimal (11 - 77 characters for English descriptions; the non-English descriptions in tool outputs obscure intent). Input schemas are present and properly typed, but parameter descriptions are sparse or absent. Error handling is implicit (returns strings) rather than structured. The server does not implement any of the recommended error-recovery patterns, tool annotations (readOnlyHint/destructiveHint), or response shaping. Output is unstructured free-text strings rather than typed JSON objects.
标记任务为已完成（文件已由AI直接写入）
标记任务为失败
获取并执行一个待处理的任务
显示如何使用前端网页进行任务管理
Tool descriptions are critically short and lack actionable context. 'run_task' (11 chars in English, wrapped in Chinese): '获取并执行一个待处理的任务' does not tell the LLM WHEN to call this vs other discovery tools, or what the output structure is.
Parameters lack descriptions. 'run_task' accepts 'project_name' with only '项目名称（对应输出目录下的文件夹名）' (Chinese-only, 26 chars). An English-speaking LLM may not parse this reliably. 'complete_task' and 'fail_task' have similar issues.
Tool outputs are unstructured free-text strings (e.g., 'complete_task' returns task_manager.complete_task(...)["message"] as a plain string). LLMs cannot reliably parse or extract data from unstructured text for downstream composition. Per pattern:response-shaper, return typed JSON with explicit fields (success: bool, task_id: string, status: string, word_count: int, etc.).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 47 | - | v1 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). 'complete_task' and 'fail_task' are destructive state mutations, but the schema declares no such hint. Per current MCP spec (2026-07-28), destructive tools must declare destructiveHint=true so agents know these are irreversible.
Error handling is minimal. When a project doesn't exist, 'run_task' returns '❌ 项目不存在: {project_name}' (unstructured). Per pattern:recovery-guide, errors should include what the LLM should try next (e.g., 'Project not found. Call list_projects() to see available projects, or create one by uploading a novel file.').
Parameter type mismatch in composition. 'run_task' returns a 'task_id' embedded in unstructured text (e.g., '🎯 任务: {task['id']}'), but there's no guarantee an LLM can reliably extract and use it in a subsequent 'complete_task' call. Per pattern:tool-chain, the first tool's output schema must explicitly include all IDs the next tool needs.
'show_web_usage' is a discovery/informational tool with no parameters, but the description is vague ('显示如何使用前端网页进行任务管理', ~17 chars). An LLM may not recognize when to call this vs run_task. Per pattern, discovery tools should explicitly state what information they reveal and when to call them.
Chinese-language descriptions and output strings. Tool descriptions and error messages are primarily in Chinese (e.g., '获取并执行一个待处理的任务', '❌ 项目不存在'). English-language LLMs may struggle to understand intent and error guidance. Per pattern, descriptions should be in the LLM's native language or be language-agnostic.
No input validation or constraints in schemas. 'project_name' is a bare string with no length limits, format constraints, or enum validation. Per pattern:constrained-input, enums or regex patterns should be used to prevent hallucinated/invalid project names.