list_tasksRetrieve tasks in a project, filtered by status (default open: todo, doing, blocked), so you can review outstanding work.
Tasks in a project, filtered by status.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory, used if project is omitted | |
| model | No | Your model id, e.g. 'claude-opus-5'. | |
| status | No | Default 'open' (todo + doing + blocked) | |
| project | No |
Changes observed during successful MCP inspections.
v0.1.4Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the status-filtering behavior and default scope, which is modest but real added context beyond the annotations. No pagination, ordering, or return-shape disclosure though.
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?
Extremely short, which is efficient, but it's a sentence fragment rather than a front-loaded structured sentence. It's under-specified rather than concise – the brevity comes at the cost of substance.
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 read-only list tool with no output schema, the minimum viable bar is met because the annotations carry the safety profile. However key behaviors – default status, the project/cwd either-or requirement, ordering, pagination – are only in the schema, not surfaced or clarified by the description.
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 coverage is 75% and the schema documents status (with default 'open'), cwd, and model itself. The description echoes the status filter but adds nothing about project/cwd mutual exclusivity (the anyOf constraint) or the model param, which is the most cryptic field.
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?
States a verb (list) and resource (tasks) with a scoping note about projects and status filtering, so the purpose is discernible. But it's a fragment, not a sentence, and adds nothing to distinguish it from siblings like get_task beyond the implicit list-vs-single distinction.
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?
No indication of when to use this versus get_task, or versus search. The status filtering mention hints at scope but provides no when/when-not guidance or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.