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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds genuine context beyond them: what fields come back (event types per endpoint, enabled flag) and the operational rule that failing endpoints are auto-disabled by Sendocado. That auto-disable note is important for interpreting an "off" endpoint as a health signal rather than a user choice. Pagination and ordering behavior are not mentioned.

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?

Two short sentences, front-loaded with what is listed and what each item shows, followed by the one non-obvious behavioral fact. No filler or restatement of the tool name.

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?

With no output schema, the description carries the return-value burden and does so by naming the URL, event types, and enabled state per endpoint. For a single-parameter read tool with annotations covering safety, that is nearly complete; only pagination/ordering and the exact meaning of the project_id value remain unaddressed.

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% for the single required project_id, so the schema alone gives no meaning. The description partially compensates by framing the listing as project-scoped ("the URLs the project posts events to"), but it never says whether project_id is an ID, slug, or name, nor whether results are paginated.

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 gives a specific verb ("List") and resource ("the URLs the project posts events to") plus the fields returned, so an agent knows this is the collection read for webhook endpoints. It does not explicitly distinguish itself from get_webhook_endpoint or list_webhook_deliveries, so the sibling differentiation is left to inference.

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 plural "List" plus the required project scope, which suggests fetching all endpoints for a project. However, no alternative is named, so an agent must infer on its own that get_webhook_endpoint is for a single endpoint and list_webhook_deliveries is for delivery attempts rather than configuration.

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