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

With no annotations, the description carries the full burden. It discloses the two-turn session limit, that the session closes after two turns, and the role-playing requirement ('staying in the role of the injured caller'). It does not cover auth or errors, but the essential behavior is transparent.

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?

Three concise sentences, each earning its place: the first defines the action and role, the second clarifies the response nature, and the third provides crucial session limit and next-step guidance. No redundancy or filler.

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 is simple, and the description covers its core purpose, role, session limit, and points to the transcript tool. It doesn't detail error handling or what happens if called after closure, but the two-turn limit implies this, and the lack of output schema and annotations reduces the burden.

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. The description reinforces the message parameter's purpose ('Answer whatever the desk asked you') but adds little beyond the detailed schema descriptions for message and demo_session_id.

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 clearly states the tool sends a follow-up message in an existing demo conversation while staying in the role of the injured caller. The verb 'send' and resource 'demo conversation' are specific, and it differentiates from siblings like start_intake_demo (starting) and get_demo_transcript (retrieving).

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 description gives explicit usage context: it is for continuing an existing demo, and it names get_demo_transcript as the tool to call after the session closes. The two-turn limit clarifies when this tool can be used and signals when to stop.

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