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

Annotations already declare destructiveHint=true and idempotentHint=true, so the description is not obligated to re-state danger, yet it adds concrete consequences: no further deliveries, the delivery log is removed, and a pending confirmation is closed as withdrawn. It also discloses irreversibility and an authorization constraint that the annotations do not encode.

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?

Four short sentences, front-loaded with the action, then effects, then irreversibility, then permissions — every sentence contributes. The opening sentence merely restates the title, a small redundancy, but nothing else is wasted.

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 mutation with full annotation coverage and an output schema, the description supplies the side effects, irreversibility, and auth requirements an agent needs before calling it. The one gap is behavior on repeat invocation (does a second delete on the same id error or silently succeed), which the idempotent hint gestures at but does not clarify.

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?

There is a single parameter with 100% schema description coverage telling the agent it is the webhook endpoint's UUID id, so the schema carries the load. The description adds no extra meaning about the id (e.g., where to obtain it via list_webhook_endpoints), leaving the baseline of 3 appropriate.

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 opens with a specific verb+resource pair ('Delete a webhook endpoint') that is unambiguous and immediately distinguishable from siblings like create_webhook_endpoint or update_webhook_endpoint. It goes further to spell out what deleting actually means for the resource, so an agent knows exactly what operation it is selecting.

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?

Usage is implied by the destructive verb, and the final sentence gives a real precondition (only the account owner's API keys and connected apps can delete). However, it never states when NOT to delete, nor does it point at the obvious alternatives (change_webhook_endpoint_url or update_webhook_endpoint) for an agent that merely wants to disable or repoint a webhook.

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