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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which clearly indicate this is a safe, non-mutating read operation. The description adds context about the specific fields returned (consecutiveFailures, lastDeliveryAt, lastFailureAt, lastError), which is useful for the agent. However, it doesn't disclose behaviors like caching, rate limiting, or error responses. Given the annotations cover the safety profile, the description adds some value but not extensive behavioral detail. It does not contradict the annotations.

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?

The description is a single, concise sentence with no filler. It front-loads the essential action and resource (Get one outbound webhook), then adds a brief mention of the endpoint and the health fields. Every word is purposeful and contributes to the agent's understanding. It is appropriately sized and well-structured for quick consumption.

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?

Given the tool's simplicity (one parameter, read-only, safe), the description is quite complete. It tells the agent what it does, what it returns (health fields), and the endpoint. Since the schema fully documents the parameter and there is no output schema, the description suffices to guide correct invocation. The only minor gap is not explicitly stating the tool is used to fetch a single webhook versus listing all, but that is arguably covered by the purpose clarity. Overall, it's complete for its complexity.

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?

The input schema provides 100% coverage of the single parameter 'webhookId', including its type, format (UUID), pattern, and a description. This is comprehensive. The description does not add anything about the parameter itself; it only refers to 'one outbound webhook', which implicitly ties the parameter to a webhook resource. Since the schema fully documents the parameter, the description is not required to add more, but it also doesn't enhance the meaning beyond what's already there. 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?

The description states a specific verb ('Get') and resource ('one outbound webhook'), and clearly identifies the tool's function: retrieving a single webhook by its ID. It also mentions the inclusion of delivery health fields, which distinguishes it from sibling tools like list_webhooks and update_webhook. The inclusion of the HTTP method (GET) and endpoint path provides additional clarity. An agent can immediately understand what this tool does and how it differs from other webhook-related tools.

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?

The description implies when to use this tool: when you need details about a specific webhook, including its delivery health. However, it does not explicitly state when not to use it or mention alternatives like list_webhooks for retrieving all webhooks. It also lacks guidance on prerequisites, such as the need to have a valid webhook ID. The description provides basic usage context but does not explicitly guide the agent on choosing between this and other webhook tools. Effective but not explicit.

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