Check progress and retrieve results of background jobs (batch, long task, benchmark, or pull) by providing a job ID. Optionally include output previews for each task.
Progress and results of a background job (batch, long task, benchmark or pull).
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| include_outputs | No | Include output previews of each task. |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true, so the description doesn't need to restate that. However, it adds no behavioral detail beyond that: no mention of possible errors, blocking behavior, pagination, or whether the job might be in progress and return partial data. The description is a static statement of content, not behavior.
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 sentence, which is concise and easy to parse. However, it is under-specified: it front-loads a general statement without critical details like the required parameter or the nature of the output. It's concise but not effectively structured for an agent.
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?
With no output schema and minimal description, the tool is incomplete. It doesn't explain the return format, how progress is represented, or what happens when a job_id is invalid. Given the tool deals with background jobs, the description should cover at least the shape of results and the role of include_outputs. It is inadequate for an agent to call correctly.
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 50%: include_outputs has a description, but job_id does not. The tool description does not mention either parameter, so it adds no value beyond the schema. It fails to clarify what job_id refers to or how include_outputs affects results. The description does not compensate for the undocumented parameter.
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 states the tool provides 'Progress and results of a background job' and lists job types (batch, long task, benchmark, pull). This is not a tautology and gives some specificity, but it lacks an explicit verb like 'retrieve' or 'get' and doesn't differentiate from siblings like fleet_status or fleet_pull. The purpose is clear enough but vague on what 'progress' entails.
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 guidance on when to use this tool versus siblings. It doesn't mention alternatives or any conditions for use. The description provides no context for selecting this tool over fleet_status or fleet_pull, so an agent has to infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.