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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the 'recent delivery attempts' framing, which signals a bounded log rather than full history, but it says nothing about pagination, retention window, or whether failed deliveries are included.

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?

One clean, front-loaded sentence with no filler. It is efficient, though the brevity edges toward under-specification for a listing tool returning an undefined structure.

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?

There is no output schema, so the description should describe what a delivery attempt record contains (status, timestamp, response code, error) and whether results are paginated or limited. For a read tool with an undocumented parameter and no return-value contract, the definition leaves real gaps.

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 0% and the single required 'id' parameter is completely undocumented. The phrase 'for a webhook endpoint' weakly implies id is the webhook endpoint identifier rather than a delivery id, but that must be inferred and is ambiguous against sibling naming like org_webhook_deliveries.

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: 'Lists recent delivery attempts for a webhook endpoint.' An agent understands the core operation immediately. However, it does nothing to distinguish itself from the near-identical sibling org_webhook_deliveries, nor from webhook_list/webhook_resend in the same family.

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?

There is no statement of when to use this versus org_webhook_deliveries, webhook_list, or webhook_resend (the obvious retry path). The agent must infer the use case purely from the name. 'Recent' implies a bounded history but no window or limit is given.

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