validate_workflow

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

With no annotations, the description carries the full transparency burden and does so well. It warns that validation sends real preview notifications and webhooks for delivery tasks, and it clarifies what it does not do: fetch or run against request logs. This is exactly the kind of behavioral disclosure an agent needs.

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 description is compact and front-loaded with the core purpose, followed immediately by a critical warning. Every sentence adds value, and there is no redundant 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?

The description covers the essential context: what is validated, the real side effects, the committed-only limitation, and the needed fallback action. It does not describe the expected return value or validation result format, which would make it more complete, but this is not fatal given the tool's clear purpose.

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?

The schema already provides 100% coverage for both parameters, including a const:true constraint and a clear explanation for confirm_preview_deliveries. The description's warning reinforces the confirm parameter's purpose but does not add meaning beyond what the schema already supplies.

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 clearly states the specific action: validating the latest editable draft's structure and task configuration. It also distinguishes itself by noting it cannot validate committed-only workflows, setting it apart from related workflow tools.

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 explicitly calls out an important when-not case (committed-only families) and directs users to create_workflow_draft first when needed. It could be even stronger by explicitly framing this as a pre-commit/pre-deploy validation step, but it gives clear operational guidance.

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