List background tasks

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds context that tasks are returned with their state, result, and the ID of any created document — useful for understanding what the call surfaces. It does not discuss pagination behavior, the default acknowledged filter, or how 'full' affects the payload, but with strong annotations a 3 is appropriate.

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?

Two sentences with zero waste. The scope ('background tasks — consumption, merges, reprocessing — with their state and result') is front-loaded, and the second sentence earns its place by linking the tool to the upload workflow. Nothing is redundant with the title or schema.

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?

Given 8 optional parameters, a read-only/idempotent annotation set, and no output schema, the description supplies the essential return semantics an output schema would otherwise provide: state, result, and the created document ID. The only material gap is the absence of routing guidance among list_tasks, get_active_tasks, and get_task, which would make selection deterministic without opening schemas.

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 100% — all 8 parameters have individual descriptions, several of which are unusually helpful (e.g., status: "'success' and 'failure' are the interesting ones"; task_id: 'e.g. the one upload_document returned'). Per the rubric, the baseline is 3 when the schema does the heavy lifting, and the description adds no parameter-level detail beyond that.

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 the resource ('background tasks'), the categories covered ('consumption, merges, reprocessing'), and the returned data ('state and result'). The second sentence adds a genuinely distinguishing function — this is where an upload's outcome appears, including the created document ID. It lacks an explicit contrast with closely related siblings like get_active_tasks and get_task, so it stops short of a 5.

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?

'This is where an upload's outcome shows up' provides a clear implied usage context: after calling upload_document, check this tool for the resulting document ID and status. However, there is no explicit when-to-use versus alternatives — notably get_active_tasks (only running tasks) and get_task (a single task by UUID) — and no exclusions are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.