List tasks with optional filters by guild and status, using cursor-based pagination to retrieve results in reverse chronological order.
List tasks. Filter by guild slug and/or status. Paginate newest first with 'before' (task id) and 'limit'.
| Name | Required | Description | Default |
|---|---|---|---|
| guild | No | Guild slug (e.g. 'evals'). | |
| limit | No | ||
| before | No | Return tasks with id < before. | |
| status | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It does disclose key behaviors: pagination via 'before' and 'limit', ordering ('newest first'), and filtering by guild/status. However, it does not mention the return shape, default limit, whether results are paged in one call or require multiple calls, or any error/edge-case behavior. This is adequate but not rich.
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, no filler. The main verb and resource are front-loaded, then filters, then pagination. Every clause adds operational meaning.
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 a moderate 4-parameter list operation with no annotations or output schema, the description covers the essential invocation details: filters, ordering, and pagination mechanism. It does not describe the response format, but for a simple list operation an agent can likely infer that from the tool name or sibling get_task. It is sufficiently complete for correct invocation.
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?
The description adds meaning beyond the schema by explaining that 'guild' is a slug, 'before' is a task-id cursor for pagination, and that status is a filter. It also clarifies the 'limit' role within pagination. Schema coverage is only 50%, so this extra context is valuable and compensates for the undocumented 'limit' and 'status' fields.
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 clearly states the operation ('List tasks') and identifies the resource. It also mentions the two primary filters (guild, status) and pagination, so an agent can distinguish this from get_task or create_task. However, it does not explicitly name a sibling or contrast itself with alternatives, so it stops just 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?
The description implies usage: use this when you need to list/filter multiple tasks, while get_task would be for a single task. But it never states when not to use it or explicitly names alternatives. The guidance is inferable from sibling names and the verb 'list', but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.