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

With no annotations, the description carries the full burden; it does disclose the outbound POST cadence and the exact signature scheme (header name, HMAC-SHA256 over body, keyed by sha256('mm-party:'+token) in hex), which is genuinely useful. It omits whether the call replaces an existing webhook, whether delivery is retried on failure, timeouts, and what a successful response confirms, which are material for a mutation with zero annotation coverage.

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?

A single dense sentence with no filler, but it leads with the downstream effect rather than the action, so the most important information (what the tool does) is not front-loaded.

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 state-changing registration tool with no annotations and no output schema, the description should say what success returns or changes, whether an existing webhook is overwritten, and how failures are handled. Only the outbound payload and signing are covered, so an agent cannot predict the call's side effects on repeat invocation.

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 67% (url lacks a schema description). The description adds real meaning for token by explaining how it is used to derive the HMAC key, but says nothing about url constraints (HTTPS only? public host?) or about deal_id beyond what the schema already documents.

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 explains the effect ('MM will POST JSON to this URL on every deal event') but never states the action the tool performs, i.e. that it registers or sets a webhook for a deal. Combined with a title ('Get deal events by webhook') that reads like a read operation while the name is mm_set_webhook, an agent must infer the verb from the tool name rather than the description.

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 guidance on when to call this versus mm_get_deal or other deal tools, no prerequisites (e.g. must the deal be active, must the URL be publicly reachable), and no mention of whether a previous webhook is replaced. The only contextual hook is 'on every deal event', which is not usage guidance.

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