List workflows

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond those hints: workflows include their triggers and actions inline, and the agent should treat the list as a prerequisite check before mutating filing 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?

Two sentences, no wasted words. The core subject is front-loaded, and the second sentence gives actionable advice that justifies checking this endpoint before making changes.

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?

Given rich annotations and fully documented parameters, the description is nearly complete for a read-only list endpoint. It communicates the payload shape and a practical use case; a minor gap is the slight ambiguity about how much trigger/action detail is present when full=false.

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 100%, so the parameters are already well documented. The tool description adds little parameter-specific meaning, though the mention of inlined triggers and actions loosely relates to the full parameter; the full parameter's own description provides the more useful guidance about when to keep it off.

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 identifies the resource clearly as "automation rules on this instance" and specifies that triggers and actions are inlined, so an agent can tell this is a list endpoint for workflow definitions. It does not explicitly name a sibling such as get_workflow or list_workflow_triggers, but the resource and scope are unambiguous enough.

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?

The description gives a clear usage context: read these workflows before changing filing behavior so you do not duplicate an existing rule by hand. It does not exclude alternatives or explicitly say when to prefer get_workflow, though that guidance appears in the full parameter description.

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