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

Annotations only declare the generic profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true, destructiveHint=false). The description adds substantial context beyond that: auth requirement, the exact payload sent, that it blocks waiting for a response, the return envelope shape, the delivered/failed status values, and that a 409 webhook_disabled sends nothing. That is exactly the kind of external-side-effect and error disclosure the annotations cannot carry.

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?

Front-loaded with the use case, then prerequisites, then payload, then return shape, then failure modes — each sentence carries distinct information with no filler. The telegraphic style suits a single-parameter tool.

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?

Although an output schema exists, the description adds the delivery-status semantics and the two named error cases (409 webhook_disabled, 404 webhook_not_found), which an agent needs to interpret results and handle failures. For a one-parameter tool, nothing material is missing.

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% and the single parameter is already documented as a 'wh_…' id, so the schema does the heavy lifting. The description only restates that webhook_id is required and shows it embedded in the request body, adding minimal meaning beyond structured fields. Baseline 3 is 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?

States a specific verb and resource ('confirm a webhook URL accepts a signed POST right now'), which unambiguously separates it from siblings like cooper_list_webhooks, cooper_register_webhook, and cooper_update_webhook. An agent can identify the tool's job without opening the schema.

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?

Gives a clear triggering condition ('when you need to confirm a webhook URL accepts a signed POST right now'), which is enough to select it over registration or listing tools. It stops short of explicitly naming an alternative or stating when not to use it, so it lands at 4 rather than 5.

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