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

With no annotations, the description carries the full burden and delivers: it discloses that the call consumes credits, that the exact charge is returned in response.meta.usage.credits_consumed, that the operation is stateless with only billing/usage metadata logged, and explicitly warns that nothing is persisted so the caller must relay and save the full response. This is exactly the kind of cost/side-effect/retention context an agent needs before invoking.

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?

Content is dense and front-loaded with purpose before parameter detail, and almost every clause delivers a constraint. It loses a point for redundancy: the credit-charging and non-persistence facts are stated twice (mid-paragraph and again in the closing IMPORTANT sentence), and the single unbroken paragraph makes scanning harder than it needs to be.

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?

Despite no output schema, the description fully enumerates the V2 return shape (meta+usage, participants, verdict, scores, detections, frameworks, timeline, categories_summary, executive summary, scoring explanation, gzip+base64 HTML report) and adds the operational caveat that the response is not stored. Nothing essential for correct invocation or result handling 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 0%, so the description must compensate and does so extensively: dialog format string with speaker-label variants and 300k char cap, duration_seconds consistency constraint (>= last turn end), the pt-BR/en-US/es-ES enum for language and response_language, audio_events limit of 500, participants limit of 10 with role values, call_direction values, response_format 'v2', and client_reference_id charset and max length.

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 precise verb+resource ('Runs a compliance risk audit on a diarized call transcript') and enumerates the specific processing steps (violation/positive detection, ISO 31000 matrix, risk-level classification, NIST/OWASP framework mapping). It explicitly separates itself from the sibling space by ruling out generic summarization, so an agent can distinguish it from transcribe_audio or diagnostic without opening a schema.

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 a clear when-to-use ('compliance and quality audits of company-agent-to-client calls') and a when-not ('not for generic conversation summarization'). It stops short of naming the sibling tools (e.g., transcribe_audio for raw transcription) that an agent should route to instead, so the alternative mapping is left implicit rather than explicit.

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