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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is known. Beyond that, the description adds real context: the confirmation gate tied to confirm=true and the authentication mode ('local WordPress authentication; no WooCommerce REST API keys are required'). It stops short of saying what happens to the zone or its other methods after removal, but with annotations carrying the destruction semantics, that gap is acceptable.

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 sentences, front-loaded with the action, then the confirmation requirement, then the authentication note. The mention of mirroring the woocommerce-mcp-server method is mildly meta but still informative for an agent reasoning about behavior. 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 destructive 5-parameter mutation with no output schema, the definition covers the confirmation gate and auth mode, which are the critical operational facts. It omits what the call returns on success, whether the operation is reversible, and any error conditions when the instance ID or zone ID is wrong, leaving the definition adequate but not complete.

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 every parameter is already documented, including site_id's dependency on list_sites and the meaning of confirm. The description only reinforces the confirm=true semantics, adding no format, default or constraint information beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 uses a specific verb and resource: it 'Deletes a shipping method from a WooCommerce shipping zone', which distinguishes it from wc_delete_shipping_zone (which removes the zone itself). It does not, however, contrast itself with sibling method tools such as wc_update_shipping_zone_method or explain the difference between deleting a method instance and a zone.

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 one concrete procedural rule, which is to ask the user for confirmation before calling with confirm=true, and that is genuinely useful. It offers no explicit when-to-use or when-not-to-use guidance relative to siblings, such as disabling a method instead of deleting it, or the distinction from deleting the parent zone, so usage is only partially covered.

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