get_bulk_statusTrack a bulk screenshot job by UUID, returning percent complete and successful or failed URL counts; download results once it reaches 100%.
Returns the progress of a bulk screenshot job by uuid: percent complete plus successful and failed URLs. Call download_bulk_results once it reaches 100%.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Job uuid returned when the bulk job was submitted. |
Changes observed during successful MCP inspections.
v1.0.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the return payload (percent, success/fail counts) and the completion handoff, which is genuinely useful. It says nothing about behavior on an unknown or expired uuid, whether failed URLs are retryable, or job retention, which are material gaps for a polling tool with no structured safety hints.
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 waste, and the effect (progress read) is front-loaded ahead of the next-step instruction. Nothing could be cut without losing routing information.
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?
There is no output schema or annotations, but the description compensates by summarizing the return fields and the completion workflow, which is sufficient to call this correctly. Only error/expiry behavior is left unaddressed, a minor gap for a one-parameter read tool.
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 100% with a single required parameter whose description already says it is the job uuid returned at submission. The description's 'by uuid' adds no syntax, format, or provenance information beyond the schema. Baseline 3 applies when the schema does all the work.
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 specific verb (returns the progress) and resource (bulk screenshot job by uuid) and enumerates the payload: percent complete plus successful and failed URLs. The agent can distinguish it from download_bulk_results, which is explicitly named as the follow-up rather than an alternative.
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?
Clear usage context: call it to poll a job, and call download_bulk_results once progress hits 100%. That sequencing is exactly what an agent needs. It doesn't state what to do on a failed or stalled job, and there are no explicit exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.