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

With no annotations, the description carries the full burden. It usefully discloses a real side effect/cost constraint ('Uses a voice slot'), which is more than most mutation tools offer. However, it says nothing about subscription requirements, reversibility/removal, duplicate handling, or failure when slots are exhausted.

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?

Two short sentences, front-loaded with the action, and the trailing slot-usage note is compact. 'so it can be used for speech' is mildly redundant with the verb 'add ... to your own voices' but not wasteful enough to penalize heavily.

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 write tool with no annotations and no output schema, the description covers the core action and the slot cost, but omits prerequisite/auth context (a sibling named check_subscription hints at entitlement constraints) and return/error behavior. Adequate but with real gaps.

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 a middling 67% — 'name' and 'public_owner_id' are documented, but 'voice_id' is bare in the schema and the description adds no parameter meaning at all. The description therefore fails to compensate for the uncovered parameter.

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 (add) plus resource (shared-library voice) and the outcome (usable for speech), which is clear. It implicitly distinguishes itself from search_voice_library (the source of library voices) but does not name or explicitly contrast that sibling.

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?

There is no explicit when-to-use/when-not guidance or named alternative in the description. The only routing hint ('public_owner_id from search_voice_library') lives in the schema, not the description, so usage is only implied by context.

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

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

With zero annotations the description must carry the full behavioral burden; it does well on output characteristics (-16 LUFS, MP3 192 kbps) and per-segment processing, but says nothing about overwrite behavior for an existing filename, what happens when a referenced file is missing, or what the tool returns (no output schema). The sentence 'The result is normalised to -16 LUFS' also reads as unconditional while the schema exposes a disableable 'normalize' flag, creating ambiguity about the default behavior.

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 sentences, each load-bearing and front-loaded: purpose plus ordering, then per-segment options, then output format. No filler or restatement of the name.

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?

No annotations, no output schema, and partial parameter coverage; the description omits the return value (output path or filename), failure modes for missing input files, and overwrite semantics — all things an agent needs before invoking a file-producing tool. It is informative but not complete for a 3-parameter assembly operation.

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?

At 33% schema coverage the description partially compensates by explaining that fades, gap, and gain apply per segment and that output is normalized, but it never states units for fade_in/fade_out (schema only annotates gap_after as seconds) and never mentions the 'normalize' parameter by name or its default. It adds real meaning for the processing knobs but leaves key semantics to guesswork.

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 ('Join') and resource ('audio files ... into a finished episode') plus the exact source directory, and the ordering example with arrows makes the segment sequence semantics unambiguous. Siblings like text_to_speech and compose_music generate audio, whereas this assembles it, so the agent can route 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?

The phrase 'from the output directory' implies this is the downstream step after generation tools, but no sibling is named and there is no explicit when-to-use/when-not guidance. An agent can infer the workflow position but gets no stated prerequisites (e.g. files must already exist via list_outputs).

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

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

With no annotations, the description carries the full behavioral burden, and it discloses nothing beyond the field list: no statement that it is read-only, no auth/plan prerequisites, no rate-limit or freshness notes. The name implies a safe read, but that is inference, not disclosure.

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?

A single terse sentence with no filler or repetition, and the key concept (plan) is front-loaded. It is grammatically a fragment rather than a complete statement, 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 zero-parameter tool with no output schema, the description usefully enumerates what comes back (plan, credits used/remaining, quota reset timing), which is the main thing an agent needs. It omits usage context and any behavioral notes, keeping it short of fully complete.

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 tool takes zero parameters, so the baseline is 4. There are no inputs whose semantics could be clarified, and the description's field enumeration maps to outputs rather than parameters.

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 is a noun phrase enumerating returned fields ('Plan, credits used and left, and when the quota resets') rather than stating a verb+resource action. Combined with the name check_subscription, an agent can infer it retrieves subscription/usage status, but the description itself never says what the tool does. No sibling overlap exists, so differentiation isn't the gap.

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?

There is no guidance on when to call this tool, no prerequisites, and no alternatives named. Siblings like list_outputs or list_models are unrelated, but the description offers no context that would help an agent decide when a subscription check is warranted.

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

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

No annotations are provided, so the description carries the full behavioral burden and discloses only a licensing/plan constraint. It says nothing about generation latency, whether the result is saved as a file (implied only by the filename param), cost, or how the output can be retrieved.

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?

Two compact fragments: purpose first, then use cases, then the licensing caveat. Every clause earns its place, though the em-dash list is dense in a single sentence.

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 5-parameter generative media tool with no output schema, the description covers intent and licensing but omits return behavior — where the music lands, its format, and whether generation is asynchronous. An agent can call it, but cannot predict the result.

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 description coverage is 80% and the schema already documents prompt, seconds, filename, and instrumental (the model_id enum is self-describing). The description adds no parameter detail of its own, so the baseline 3 applies.

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+resource ('Original music from a text prompt') and enumerates concrete use cases (intro/outro themes, beds under speech, transitions) that separate it from text_to_speech and sound_effect. It does not name a sibling explicitly, but the resource is unambiguous.

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 use-case list plus the plan prerequisite ('licensed for commercial use on paid plans') gives an agent clear context for when this tool fits and a real constraint to check. It stops short of naming exclusions or pointing to sibling tools for adjacent needs.

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

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

With no annotations, the description must carry the full behavioral burden. "List" implies a read-only, non-destructive operation, and the model characterizations add useful context, but it discloses nothing about auth requirements, rate limits, or whether results change over time.

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?

Two tight sentences: the first front-loads what is returned, the second packs concrete, decision-relevant trade-offs with no filler. Every clause earns its place.

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 zero-parameter list tool with no output schema, the description adequately explains what comes back (models with languages) and why one model differs from another. Return-field details are the only minor omission, which is acceptable given the tool's simplicity.

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 tool takes zero parameters, so the baseline is 4. There are no arguments whose meaning could be clarified or omitted.

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 the resource plainly (speech models and their languages), which cleanly separates it from the sibling list_voices (voices) and list_outputs (generated output). It stops short of an explicit verb like "list all available," but the intent is unambiguous.

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 offers genuine model-selection guidance (eleven_v3 for expressiveness, eleven_multilingual_v2 for stable long narration, flash/turbo for speed and cost), which helps an agent pick a model. However, it gives no explicit guidance on when to call this tool versus alternatives like list_voices, leaving tool usage to inference.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose two real traits: results are sorted newest-first and each entry carries a duration. Read-only intent is only implied by 'list', and nothing is said about pagination, whether all files are returned, or error behavior when the directory is empty.

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?

One compact sentence with the resource, ordering, and payload front-loaded and no filler. It is under-specified rather than padded, so the brevity is a plus even though a fragment reads slightly truncated.

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 zero-parameter read tool with no output schema, the description tells the agent what comes back in broad terms (audio files, newest first, with duration). However, since there is no output schema, the burden of describing the returned fields falls on the description, and it omits file paths/names, count/pagination limits, and the scope of the directory.

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 tool takes zero parameters, which is the baseline-4 case. The description correctly implies no filtering input is available, so there is no schema detail missing that an agent would need.

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 resource precisely (audio files in the output directory) and adds distinguishing detail on ordering and payload ('newest first, with duration'), so an agent can tell it apart from generation siblings like text_to_speech or compose_music. It is phrased as a noun fragment rather than a verb+resource statement, and it does not explicitly contrast itself with the other list_* siblings, which keeps it below 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?

There is no statement of when to call this tool, when not to, or which alternative to use. The 'output directory' framing implies usage context, but the agent gets no routing guidance versus list_models, list_voices, or check_subscription.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing beyond return content ('with their voice_id'). It omits pagination behavior despite a page_size parameter (default 30, max 100), does not state ordering, and does not confirm the operation is a safe read. For a list endpoint with zero annotation coverage this is a significant gap.

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?

A single dense fragment with zero padding; the library-scope constraint is front-loaded. It loses a point only because the fragment form leaves the action ('list') implicit and reads as a noun phrase rather than an instructional sentence.

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 low-complexity, zero-required-parameter read tool with no output schema, the description conveys the essentials: which voices are returned and that voice_id comes back. What is missing is what an agent actually needs to invoke it well — pagination semantics and the distinction from search_voice_library.

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 description coverage is 50%: 'search' is documented in the schema, but 'page_size' carries only type/default/min/max constraints with no stated meaning, and the description adds nothing about either parameter. With coverage below the 80% baseline, the description needed to compensate and does not.

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 resource (voices), the scope (your own library), and what is returned (voice_id), and its parenthetical enumerates the sources included (premade, cloned, designed, added from shared library). It implicitly separates itself from the sibling search_voice_library by scoping to 'your own library', but it never names that sibling explicitly and is a sentence fragment rather than a verb-led statement.

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?

There is no when-to-use or when-not-to-use guidance. The parenthetical hints at scope but does not tell an agent when to call list_voices instead of search_voice_library, add_library_voice, or list_models, all of which sit in the same sibling cluster.

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

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 library's scale ('thousands of community voices') and the required add_library_voice prerequisite, but says nothing about pagination, result format, or rate/usage limits for an 8-parameter query tool.

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?

Two sentences, zero waste. The capability and filter dimensions come first and the prerequisite workflow hint is placed last, which is exactly the right front-loading.

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?

No output schema and no annotations, so the description must stand alone for an 8-parameter search tool, and it leaves pagination, default result ordering (sort defaults to 'trending'), and return shape unexplained. Adequate to select the tool, insufficient to invoke it with full confidence.

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 50%, and the description only echoes the language/accent/gender/use case filters, which the schema already names. It adds no meaning for the undocumented age enum, sort options, free-text search syntax, or page_size bounds, so it only partially compensates.

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 (search) and resource (ElevenLabs' shared voice library) and clarifies the corpus as community voices filterable by language/accent/gender/use case. This implicitly separates it from the sibling list_voices (the user's own voices), though it never names that distinction explicitly.

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 explicit workflow guidance — 'Add a voice with add_library_voice before using it' — naming the follow-up sibling and the ordering constraint. It lacks when-not guidance (e.g. when to use list_voices instead for owned voices), so it stops short of a 5.

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

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

With no annotations, the description carries the full burden and discloses almost nothing behavioral: it does not say whether audio is returned inline, saved to disk, or by URL; whether it is asynchronous; or what latency/cost to expect. The only behavioral signal is that generation is driven by a text description.

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?

One short sentence, front-loaded with the core concept and no filler. It is arguably too terse rather than verbose, which is a completeness issue rather than a conciseness one.

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 5-parameter generative tool with no annotations and no output schema, the description is a fragment: it omits what the tool returns, where output goes, and any operational constraints. An agent would still need to guess at the invocation contract.

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 description coverage is 80%, so the schema already documents loop, text, filename, and prompt_influence, which sets the baseline at 3. The description adds no parameter meaning beyond the examples of sound effect types, which loosely inform the text prompt but nothing more.

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 noun phrase 'A sound effect from a description' clearly identifies the resource (text-prompt-driven audio generation) and the examples (stingers, whooshes, ambience, applause) pin down the domain, distinguishing it from compose_music and text_to_speech. However, no verb is stated (generate/create) and no sibling is named as an alternative, so it falls short of the 5-level specificity.

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?

There is no when-to-use guidance and no routing versus siblings like compose_music (music) or text_to_speech (speech), which are the likely confusions for an audio-generation tool. The example list implies scope but does not state exclusions or conditions.

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

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

With no annotations, the description carries the full burden and does real work: it discloses that long scripts are chunked into ~2000-character requests with whole lines preserved, that chunks are joined, and that local execution requires ffmpeg. Audio tags steering delivery is valuable behavioral context. It omits cost/latency, auth requirements, and what happens on partial failure.

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?

Two dense sentences with the core identity front-loaded and operational caveats (chunking, ffmpeg) trailing. Every clause carries information, though the parenthetical about chunk sizes makes the first sentence heavy.

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 7-parameter, no-annotation, no-output-schema tool, the description covers the essentials: input shape, model, chunking behavior, delivery tags, and the tier-gated output formats. Remaining gaps (return value, seed behavior, error handling) are modest given no output schema exists to document returns.

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 description coverage is 57%, so several parameters (seed, model_id, lines) rely on the description. It explains the lines structure (text + voice_id per line), names the default model eleven_v3, and documents audio tags embedded in text — genuine additions. However, seed and the interaction between stability/language_code and dialogue output go unaddressed.

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 capability — multi-speaker conversation from a script of ordered lines — plus the model and a concrete use case ('core podcast tool'). The 'multi-speaker' framing implicitly separates it from the single-voice text_to_speech sibling, so an agent can route without opening schemas.

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?

Usage context is implied rather than stated: 'the core podcast tool' and 'multi-speaker' suggest when to pick this over text_to_speech, but it never names the alternative or the when-not condition. The instruction to 'pass the script as ordered lines' is invocation guidance, not selection guidance.

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

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

With no annotations, the description carries the full behavioral burden and largely drops it: it does not say the tool writes an audio file to disk (only the 'filename' param hints at it), where that file lands, whether the call consumes credits (a check_subscription sibling exists), or anything about latency or failure modes for invalid voice_ids. Only the speaker-count behavior is disclosed.

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?

Two short clauses, zero filler, and the defining constraint (single speaker) plus the routing rule are both front-loaded. Nothing is restated from structured fields.

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?

Ten parameters, no annotations, no output schema, and half the parameters undocumented — this tool needed the description to explain the voice_id prerequisite, what is produced and where, and the tier constraints that only the output_format description hints at. Instead the description covers purpose and sibling routing only.

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 50% and the description adds nothing about parameters. Half the params — text, voice_id, speed, style, similarity_boost — have no description anywhere, and the description never compensates by explaining voice selection, speed range intent, or how style/similarity interact. This falls below the baseline-3 case where schema coverage is high.

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 resource and operation concretely ('One voice reading a text') and grounds it with three example use cases (narration, cold open, ad read). It also explicitly contrasts with the sibling text_to_dialogue, so an agent can route correctly. It stops short of stating that it synthesizes and saves an audio file, which keeps it from a 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?

'For several speakers use text_to_dialogue' gives an explicit alternative and the condition that selects it. No exclusion is given against other audio siblings (compose_music, sound_effect), and it never mentions that a voice_id must first come from list_voices, but the core when-to-use guidance is present.

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