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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds real behavioral depth beyond that, notably the 202-accepted-runs-count-as-succeeded caveat and the instruction to read run.status for the true outcome. It also discloses the 30-day window, the 50-call cap on recent calls, and that only metadata is returned, though it does not mention rate limits or pagination.

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 content is front-loaded with the returned fields and every sentence contributes something, including the important 202 caveat. It is a dense run-on paragraph, however, and the enumeration of return fields could be tightened or bulleted for faster scanning.

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, the description carries the full burden of explaining return values and does so field by field, plus the counting semantics that govern those values. For a single-parameter read-only analytics tool, nothing essential is missing.

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?

There is a single required parameter with 100% schema description coverage ('A workflow ID, like wf_…'), so the schema already carries the semantics. The description adds nothing about workflow_id and does not state what happens for an unknown or non-existent ID, so the baseline of 3 applies.

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 names a specific verb and resource (returns usage metrics for a workflow) and enumerates the exact payload: calls, success rate, p50/p95 latency, credits, calls per day, status codes, per-version breakdown, in-progress runs, and the latest 50 calls. This clearly separates it from siblings like get_workflow (definition) and list_runs (individual runs).

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?

Usage context is implied by the fixed 30-day window and by the scope note that only API calls, automations, and webhook triggers are counted (Studio tests excluded), which helps an agent know when numbers will look wrong. However, there is no explicit routing to or away from siblings such as list_runs or get_run for per-run detail.

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