Draft a reply for a lead

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the safety bar is partly covered, but the description adds genuinely useful context: the result is queued for review and 'nothing is sent.' That clarifies a mutation whose effect is non-delivering, which annotations alone do not convey. It does not discuss idempotency or permission requirements, keeping it short of a 5.

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?

Front-loads the core action, then the workflow position, the non-sending guarantee, and a concrete call example. Every sentence carries distinct information with no filler, and the example is compact and directly actionable.

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 5-parameter mutation with a full output schema and high schema coverage, the description supplies everything an agent needs: purpose, workflow placement, the routing to the approve tool, and a usage example. Return values are correctly left to the output schema.

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 100%, so leadId, guidance, workspace overrides, and idempotencyKey are already documented in the schema. The description echoes that guidance is optional ('Optional guidance steers tone or content') and the example illustrates a call shape, but adds no new semantics. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('draft a voice-matched reply for a lead') plus the outcome ('queue it for review'), which cleanly separates it from send tools like luca_conversations_send and luca_approve_and_send. The phrase 'voice-matched' adds a distinguishing detail about how the draft is produced.

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?

Places the tool explicitly in a workflow ('the middle step of the reply loop: triage → draft → approve') and names the downstream alternative with its purpose ('Nothing is sent; approve it with luca_approve_and_send'). The agent knows both when to call this and what to call next.

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