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

Beyond the annotations (readOnlyHint=false, idempotentHint=false, openWorldHint=true), it discloses real side effects: the lead appears in reports and counts toward lead totals. The 'send_notification is always off, so no emails go out' detail is genuinely non-obvious behavior not derivable from any structured field, and it elaborates the non-idempotency annotation with the concrete consequence of duplicate leads. Missing rate limits, but the annotation bar is already met.

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?

Four short sentences, front-loaded with the 'WRITE' marker and the purpose, with no filler. The agency/profile sentence and the endpoint hint are dense but each carries information; nothing is padded.

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 24-parameter, nested-object mutation tool with no output schema and no annotations covering side effects, the description covers the high-value operational facts (key scoping, no notifications, non-idempotency) but never explains which fields pair with which lead_type beyond a couple of schema-level notes, nor what the response contains. Adequate but with clear gaps.

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 67%, so the schema carries most parameter meaning. The only parameter the description touches is profile_id, and it merely restates the schema's own note about Agency vs Profile keys, adding no syntax or format detail. With 24 parameters, many of them lead_type-conditional, the description leaves most semantics to the schema.

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?

States a specific verb and resource ('WRITE: add a lead to WhatConverts') and immediately grounds it with concrete examples (offline phone call, form submission from another system, sale). Against siblings like get_lead, list_leads and update_lead, the 'add'/'WRITE' framing makes the create-vs-read-vs-update distinction unambiguous.

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?

Gives clear trigger contexts for when this tool is the right choice (offline leads, externally sourced forms, offline-attributed sales) and states a prerequisite - a Profile key adds to its own profile, an Agency key must pass profile_id. It stops short of naming the alternative for existing leads (update_lead), so it's contextually clear but not exclusionary.

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