Retrieve task status and paginated evidence to monitor asynchronous coding jobs. Use it to query progress and results without treating completion as independent test verification.
Read task status and paginated evidence. Completed is not independent test verification.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| task_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only that evidence is paginated and a caution about completed tasks, but doesn't disclose rate limits, auth needs, or what happens on missing tasks. With annotations present, this is modest added value.
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 short sentences, front-loaded with the core action. The second sentence is somewhat cryptic but brief, and there is no wasted text.
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 tool with a paginated output schema and three parameters, the description is incomplete. It doesn't explain pagination mechanics, how to interpret the output, or the caution about verification in a useful way. The output schema exists, so return values needn't be described, but the behavioral and parameter gaps remain significant.
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%, so the description should compensate for three parameters (task_id, limit, cursor). It mentions 'paginated evidence' which hints at limit/cursor, but provides no details on formats, defaults, or the meaning of task_id. Baseline 3 is generous given the coverage gap, but the pagination hint is the only parameter-related signal.
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 (Read) and a resource (task status and paginated evidence), which is clear enough, but it doesn't explain what 'task' means in this context or how it differs from siblings like wait_task or submit_task. The odd second sentence about completed tasks not being independent verification is ambiguous and doesn't clarify purpose.
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?
There is no explicit guidance on when to use get_task versus sibling tools such as wait_task (which likely blocks for completion) or submit_task. The description implies a read operation but offers no conditions for choosing it over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.