Close the loop on a call

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

Annotations already flag destructive/openWorld/non-idempotent, and the description goes well beyond them: it explicitly states no message is sent to the lead itself, but that records start API work — no-show recovery scheduling a lead message, call summary queued for CRM sync, won/lost queuing a deal-stage update, and lost moving the lead to lost. It also states the confirm:true gate for no_show/won/lost, which the annotations do not capture.

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 core purpose is front-loaded and every subsequent sentence carries a distinct behavioral fact (side effects, confirm requirement, example). It is dense and paragraph-form rather than scannable, and the example at the end is somewhat long, but nothing is wasted.

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 16-parameter mutation with an output schema present, the description covers the essentials an agent needs: what it writes, which side effects fire under which attendance/outcome values, the destructive-action confirmation gate, and a concrete call shape. Return values are handled by the output schema, so nothing material is missing.

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 100%, so the baseline is 3, but the description adds conditional wiring (won with an amount, lost with a reason id from a named sibling tool, open with the next follow-up) and a worked example showing bookingId/attendance/outcome/amountMinor/currency/confirm together. That mostly restates schema-level 'required when outcome is X' notes, so it is a modest step above baseline rather than a large one.

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 opening sentence names a specific verb+resource+scope: 'File what happened on a call and what it was worth, in one call.' It then spells out the two distinct records it files (attendance on the call event, revenue outcome on the booking), which separates it from sibling tools like luca_call_events_feedback or luca_bookings_outcome_record that do only half the job.

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?

It gives clear conditions of use ('when an outcome is given, records the booking outcome'; completed vs no_show vs won/lost each trigger different downstream work) and names luca_bookings_outcome_reasons_list as the source of loss reason ids. It never explicitly says when to pick this over the related booking/call-event siblings, so it stays at 4 rather than 5.

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