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

The description goes beyond the annotations by concretely disclosing that the server original is consumed once the call starts, so it cannot be re-run, and it explicitly states there is no additional charge. This is valuable operational context that annotations alone do not provide.

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 essential action is front-loaded in English, and the later Korean sentence repeats the same download-as-base64 idea rather than adding new information. The consumption and billing notes are valuable, but the duplication prevents a top conciseness score.

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 simple one-parameter tool with no output schema, the description covers the action, the result format (base64 MP3), the one-time destructive behavior, and the cost implication. No critical operational fact an agent needs for correct invocation 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?

The single parameter job_id is fully documented in the schema with a regex, length constraints, and the 'completed 상태인 32자리 ID' description. Since schema coverage is 100%, the description adds no new parameter-level meaning beyond reinforcing 'completed'.

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 names the action ('Download'), the exact resource ('completed MP3 result'), and the constraints ('once as base64'), making it clearly distinct from siblings like tts_jobs_status or tts_jobs_subtitles. However, it does not explicitly name or contrast a sibling/alternative, so it stops just short of a full 5.

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 qualifier 'completed' and the warning that the server original is consumed on call tell the agent this is the terminal fetch after a TTS job succeeds, not a status check or a retryable operation. It gives clear context but does not explicitly list when-not conditions or name alternative tools.

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