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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds useful domain context (triggers, actions, firing behavior) but does not address rate limits, pagination interaction with runs, or return shape. With annotations carrying the safety profile, a 3 is appropriate.

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?

Front-loads the purpose, then the domain model, then the views, then args. The view list is the densest value and is well structured. The 'Args' section duplicates some schema info but is justified given the low schema coverage.

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 multi-view read tool with 9 params and 11% schema coverage, the description fills most gaps: view behavior, conditional params, filters, and window. Missing only user_intent semantics and how pagination behaves for 'runs' vs 'list'. No output schema, so return-value notes are correctly omitted.

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 only 11%, so the description must compensate, and it largely does: it explains view semantics, conditional requirements (workflow_id for 'get', run_id for 'run_detail'), the days window (1-90, default 30), and filtering by status. It does not document user_intent, and the offset/limit ranges are only in schema.

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+resource ('Read workflow automation state') and immediately explains what workflows are and what this tool surfaces ('see what's configured and what's fired recently'). The five-view breakdown makes it unmistakably distinct from the sibling manage_workflow (which writes).

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?

Explicitly maps each view to a purpose and names the required parameter for each ('get' requires workflow_id, 'run_detail' requires run_id). An agent can pick the correct view without reading the schema.

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