choose_frontend_deploy

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description does not need to restate mutability. It adds important behavioral context: the tool requires user consent before execution, and for staticbot it may select a target automatically, so the agent must not make premature promises. These details go beyond the schema and annotations.

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 moderately long but well-structured: it leads with the trigger condition and the critical user-consent requirement, then enumerates the three options in a clear list. Each sentence serves a purpose—no fluff. The warning about staticbot analysis is concise and essential.

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 trigger, the required user interaction, the three choices with their parameters, and a specific caution about staticbot. Since an output schema exists (context signal: has output schema true), return value details are not needed. It omits nothing an agent needs to correctly invoke this tool in its workflow.

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 100% with descriptions for all four parameters, so baseline is 3. The description adds meaning by mapping method values to the corresponding choice values (e.g., 'continuous-sync' → 'setup-continuous-sync') and clarifying that skip requires no choice. This explains the relationship between method and choice, which the schema alone does not.

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 states a specific action: choosing frontend deployment strategy in Phase 8. It names the three distinct options (continuous-sync, staticbot, skip) and explains what each does, clearly distinguishing from sibling tools like choose_backend_switchover which handles a different phase. The verb 'choose' plus resource 'frontend deployment' makes it unambiguous.

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 explicitly specifies when to call: when MANUAL_CHOOSE_FRONTEND_DEPLOY is READY, and mandates user interaction ('MUST present these options... Do NOT pick without asking'). It does not name alternatives, but the context of a phase-based workflow makes it clear this is the right tool for this step. The instruction to not promise AWS/Cloudflare before staticbot analysis is also a usage guideline.

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