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

Annotations already indicate a non-read-only, open-world, non-idempotent, non-destructive call. The description adds behavior beyond that: utterances are queued and spoken sequentially, the call fails with session_not_connected if made before connection, and an admin-issued api_key is mandatory. It still does not describe return values or rate limits.

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 compact sentences with the core action first, then preconditions, then the auth requirement. No filler, though the error-code clause and the parenthetical auth note could be folded together.

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 3-required-parameter mutation tool with no output schema, the description covers the main things an agent needs: what happens, the required connection state, the failure code, and the auth requirement. Only 'session_id' semantics and response behavior are left unaddressed.

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 67%: 'text' and 'api_key' are documented in the schema, while 'session_id' has no description in either place. The description reinforces that api_key is an admin-issued key ('管理画面で発行したキー') and that a live session is implied, but adds no syntax or format detail beyond the schema.

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: make the session's avatar speak given text. It also discloses the queueing behavior ('キューに積まれ、順に発話'), which is a meaningful detail. It does not explicitly differentiate from the sibling 'interrupt', which is the closest alternative.

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 precondition (call after the browser SDK connects via session.start) and the failure mode before connection (session_not_connected), plus the api_key requirement. It does not name a sibling alternative such as 'interrupt' for stopping speech, so it stops short of full when/when-not routing.

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