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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the return contract: it names the exact fields surfaced and explicitly states the secret is never returned. That 'never the secret' clause is real behavioral disclosure beyond the annotations, though it omits what happens when no webhook is configured.

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 telegraphic fragments with zero filler, and the most decision-relevant content (what you get back, and that the secret is excluded) comes first. The fragmentary style is efficient but slightly under-structured.

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 simple no-required-param read with no output schema, listing return fields covers most of the gap. Still missing are the empty/no-webhook case and any indication of whether failure counters or last-delivery timestamps can be null, which an agent calling this cold would want.

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?

With a single optional agent_key parameter at 100% schema description coverage, the schema already explains that it can be omitted when the bearer token is present. The description adds nothing about the parameter, which is acceptable at this coverage level but not additive.

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 enumerates exactly what is returned (url, events, enabled, consecutive failures, last delivery), which makes the resource and read intent unmistakable, and the sibling name set_webhook makes the get/set split obvious. It lacks an explicit verb such as 'retrieves', but the field list functions as one.

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 call this versus set_webhook, delete_webhook, or test_webhook, and no prerequisites or follow-up hints. The agent must infer usage entirely from the name.

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