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

Annotations already mark destructiveHint=true, so the agent knows operations here can be destructive. The description adds useful context—live events and HMAC-signed deliveries—but it does not disclose what each action does (create/list/delete), side effects of deletion, or any permission requirements. This adds some value beyond annotations but not substantial behavioral detail.

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 sentences with no filler; the purpose and concrete event examples are front-loaded, and the HMAC signing detail is placed second. Every sentence earns its place, making the description easy to scan.

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 CRUD-style webhook tool with a required action enum and no output schema, the description omits what list/delete actually do and what responses look like. The schema provides parameter names and enums, and annotations signal destructiveness, so the definition is minimally adequate but leaves the agent to infer the operational semantics of the action parameter.

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 high at 75%, with descriptions for id, url, action, and events, including the 'omit = all' behavior. The description adds meaning for a few event names (e.g., call.settled when someone rents your capability), but it does not clarify the semantics of the required action parameter (create/list/delete) or the id/url relationship. 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 names a specific action (wire a webhook), a specific resource (your node's LIVE mesh events), and concrete event examples, making the tool's purpose immediately recognizable. It does not explicitly mention the create/list/delete operations or differentiate itself from sibling mesh tools, so it is clear but not maximally precise.

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 gives clear use context: subscribe to live mesh events such as call.settled, vibe.followed, and capability.listed. However, it does not state when not to use it or name alternatives among the many mesh_* sibling tools, so the guidance is context-rich but lacks explicit exclusions.

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