list_tasksRetrieve historical tasks with optional filtering by project path or status, defaulting to 50 results. Use to review past executions and track progress.
列出历史任务（可按项目路径 / 状态过滤，limit 默认 50）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No | ||
| projectPath | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety profile is covered. The description adds the historical scope and filter support, but does not disclose pagination behavior or whether the results are limited to certain statuses beyond the stated filters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the verb and resource before optional filtering details. Every element earns its place and there is no redundant repetition of the tool name or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with no required parameters and no output schema, the description covers purpose, filters, and default limit. It does not describe the exact return shape, but the tool name and 'list tasks' phrasing make the core behavior sufficiently clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description names all three parameters and their roles: projectPath and status are filters, and limit defaults to 50. This adds meaningful semantics beyond the bare schema, though it does not enumerate valid status values or projectPath formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (列出/list) and resource (历史任务/historical tasks), and states the filter dimensions. This clearly distinguishes it from siblings like run_task, cancel_task, query_task, and get_task_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by framing it as a way to list historical tasks with optional filters. However, it does not explicitly state when to prefer this over query_task or get_task_report, leaving some selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.