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

Goes well beyond the annotations: discloses that nothing is persisted, that no retry is performed, that hidden spot checks are skipped (a real semantic limitation of the preview vs. real verification), and a concrete rate limit of 30 previews per task per hour. These are exactly the traits an agent needs and none of them appear in the structured fields.

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 compact sentences with the critical qualifier ('Assigned provider only') front-loaded. Every clause carries distinct information: precondition, action, side-effect profile, and quota.

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 2-param, no-output-schema tool with safety annotations already present, the description supplies the side-effect profile and quota that the annotations cannot. It could say more about what the preview actually returns to the caller (pass/fail detail), but the core behavior is covered.

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 50%: output_payload is documented in the schema, task_id is not. The description references output_payload semantically ('the output you would submit' is echoed) but adds no explanation for task_id or the required pairing of the two. It 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?

States a specific verb and resource: 'run the task's automated checks on an output_payload'. The 'before submitting it' phrasing positions it clearly relative to the delivery flow, though it never names a sibling (e.g. get_verification or submit_deliverable) to disambiguate. Purpose is clear without sibling differentiation.

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?

'Assigned provider only' and 'before submitting it' give a clear conditional context for when to call it. There is no explicit exclusion or named alternative for the case where the caller is not the assigned provider, but the triggering situation is unambiguous.

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