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

Annotations already disclose that the tool is idempotent and non-destructive. The description adds context about the prerequisite ('approved') and the requirement for explicit row decisions, which goes beyond the annotations. It does not fully describe side effects (e.g., creating or linking prospect records), but the decision enum in the schema covers this.

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 that front-loads the action and key inputs without any fluff or repetition. Every phrase earns its place.

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?

The tool has a complex decisions array and requires a workflow (dry-run → approve → apply), but the description assumes knowledge of that flow. It does not explain how to obtain preview_hash, the meaning of import_id, how decisions are applied, or what the return value is (no output schema). This is incomplete for an agent to safely call the tool.

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 0%, so the description must explain all parameters. It only mentions preview_hash and row decisions, leaving import_id (required), request_id, and idempotency_key unexplained. This is a significant gap for correct invocation.

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 action ('Apply'), a clear resource ('approved Prospect CRM import preview'), and key inputs ('preview_hash' and 'explicit row decisions'). It differentiates itself from siblings like prospect_imports_dry_run by using 'apply' versus 'dry_run', so an agent can immediately tell this is the committing step.

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 phrase 'approved preview' clearly implies the tool should be used only after a preview has been generated and approved, providing context for when to call it. However, it does not explicitly name alternatives or state when *not* to use it, leaving some inference to the agent.

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