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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint: false, and openWorldHint: false. The description reinforces that it saves nothing and executes no action, which is useful, but it adds little about preconditions, error behavior, or what the preview returns.

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?

Three compact sentences, front-loaded with purpose, then invocation detail, then the no-side-effects guarantee. The CLI example earns its place and there is no filler.

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 tool with a deeply nested rule schema, no output schema, and only 25% schema description coverage, the definition is thin. It omits what the preview returns, how application_id is used beyond the vague 'real application' phrase, request_id semantics, and validation/error behavior.

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 only 25%, so the description needs to compensate. It explains the main rule parameter as create-style input with a CLI example and explains conditional rule_id, but application_id is only weakly implied by 'for a real application' and request_id is never explained.

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 (Preview) and resource (an unsaved workflow rule) and scopes it to a real application. It clearly distinguishes previewing from saving, but the reference to 'preview-rule' does not explain how this tool differs from that sibling.

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?

It gives a clear before-saving context and explains when to add rule_id for unsaved edits. However, it does not say when to choose this over yardstick_automation_rules_preview or yardstick_automation_rules_preview_rule; saying it gives the 'same result as preview-rule' muddies selection rather than routing.

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