TTS For Free

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds a genuinely useful behavioral constraint not in the annotations: this mutation should only be performed on explicit user request.

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 short sentence with the action front-loaded and the caveat placed last. Nothing is wasted and no padding is present.

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 one-parameter, non-destructive, idempotent mutation with rich annotations and a fully documented schema, the description plus structured fields give an agent everything needed. Only the absence of any note about already-favorited voices keeps it from being 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?

There is one parameter with 100% schema description coverage, and the schema already explains it is a 'Voice token (v1:...) from list_voices.' The description adds no further meaning about the parameter, so the baseline of 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?

The description states a specific verb and resource ('Save a voice to the user's favorites'), which cleanly separates it from siblings like remove_favorite_voice and list_favorite_voices. It does not explicitly name those siblings as alternatives, but the action 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 parenthetical '(only when the user asks)' gives an explicit consent/timing condition for invoking the tool, which is real when-to-use guidance. It stops short of naming alternatives or stating what to do when the voice is already favorited.

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?

Annotations only declare the generic safety profile (readOnly=false, idempotent=false, non-destructive). The description goes well beyond that, disclosing that the URL is one-time, valid for 15 minutes, requires an HTTP PUT of raw bytes, caps at 2 GB, and rejects externally hosted links. This is rich operational context an agent needs to invoke it correctly.

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?

Front-loaded with the core action, then constraints and workflow in a logical order. It is on the longer side, but nearly every clause (format list, size cap, PUT example, expiry, next-step routing, exclusion rule, fallback) carries distinct operational value, so waste is minimal.

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?

There is no output schema, so the description must convey the return contract; it does so by naming upload_url and public_url and explaining the 15-minute validity. Combined with the workflow routing and input constraints, an agent has everything needed to call this correctly.

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%: file_name is documented in the schema, while file_size_bytes has no description anywhere. The description supplies the 2 GB cap, which indirectly bounds file_size_bytes, but never explains that file_size_bytes should be supplied or what it is for. Baseline 3 is appropriate given partial coverage.

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 ('Get a one-time URL to upload a local video or audio file') with scope, supported formats, and size limit. It is clearly the upload-preparation step distinct from its siblings transcribe_media and localize_video, which it names as downstream consumers.

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 when-to-use (uploading a local file before transcription/localization), how to use it (HTTP PUT of raw bytes with a concrete curl example), what to do next (pass public_url to transcribe_media or localize_video), and explicit exclusions (only files uploaded here or on ttsforfree.com accepted; YouTube and external links never downloaded). Also provides a fallback when the agent cannot run commands.

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?

Annotations already declare readOnly=false, destructive=false, idempotent=false, so the safety profile is covered. The description adds value beyond them by disclosing that the call consumes one slot of a custom-voice quota and that it returns a `voice` token. It doesn't say whether the voice can later be removed or what happens when the quota is 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?

Three short sentences, front-loaded with the action, followed by the cost warning and the return value. No filler and every sentence carries information the agent needs.

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?

With no output schema, the description correctly compensates by naming the returned `voice` token, and it flags the quota side effect that annotations don't cover. Minor gaps remain around quota recovery/error behavior and the undocumented `display_name` parameter.

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%: `prompt` and `language_code` are documented in the schema, `gender` is a self-evident enum, but `display_name` has no description anywhere. The description only loosely maps 'natural-language description' to `prompt` and adds no constraints (length caps, locale format, gender effect) beyond the schema, so 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 and resource ('Create a new personal AI voice') plus the mechanism ('from a natural-language description'), which is enough to distinguish it from siblings like list_my_custom_voices, get_voice_details, and list_voices. An agent can identify the right tool without opening the 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 clear situational guidance ('Good for a unique narrator or a character voice in a video/podcast') and an important precondition ('confirm with the user first'). It does not name an alternative (e.g., picking an existing voice via list_voices), so it stops short of explicit when-not 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered structurally. The description adds value by disclosing that duration is measured from video_url and that the estimate spans the full dubbing pipeline, which annotations cannot convey.

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 with the core purpose front-loaded and the input guidance following. No filler; every clause carries information.

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?

With no output schema the description at least names the return unit (credits). For a 4-parameter tool with sparse schema descriptions it covers the main input paths, though source_language remains unexplained.

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 only 25%, so the description must compensate. It usefully explains the video_url vs duration_seconds choice and that duration is measured server-side, but leaves source_language entirely undocumented and only implicitly covers targets via 'one or more languages'.

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 (Estimate) and resource (credits to dub one video into one or more languages), and enumerates the underlying pipeline (speech-to-text + translation + voice + video merge). It is clearly a cost-preview step distinct from the sibling localize_video that actually performs the operation.

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?

Explicitly positions itself as a pre-flight step: 'before running localize_video', naming the alternative it precedes. It gives clear context for when to reach for it but does not state any when-not 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?

Annotations already establish readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavioral context by disclosing the returned fields and the pre-flight use case for large jobs, without contradicting the declared idempotentHint=false.

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 sentence lists the returned information and a second short sentence gives the call trigger. No filler, and the substantive content is front-loaded.

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?

With no output schema present, the description usefully enumerates what the response contains (plan tier, credits, limits), which largely substitutes for a return-value spec. It is complete enough for an agent to call correctly, though it does not state the response format.

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 there is nothing for the description to disambiguate; the baseline for a parameterless tool 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?

Starts with a specific verb ('Show') and enumerates exactly what is returned: plan tier, credits, per-request and per-job limits, and rate limits. This clearly separates it from the job-oriented siblings (get_job_status, get_job_detail), though the distinction is implied rather than stated.

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 closing instruction 'Call before large jobs' gives a concrete trigger for invocation, which is exactly the kind of proactive guidance an agent needs. It does not name alternatives or state exclusions, but there are no real sibling tools it could be confused with for this purpose.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds a useful caveat — durations are not supplied and must be measured in the renderer — but says nothing about auth, errors, or rate limits, so the extra behavioral value is modest.

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 dense sentence front-loads what is returned, then a second sentence gives the consumer use case. Every clause carries information and nothing is redundant.

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?

With no output schema, the description carries the burden of describing returns, and it does so well (segments + merged audio). The important caveat that durations must be measured by the caller covers the main downstream pitfall; only error/failure behavior is 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 description coverage is 0% and the single job_id is undocumented in both schema and description. The tool's framing makes it clear the call operates on one job, so the meaning is inferable, but the description adds no format, range, or validity guidance for the 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?

The description states a specific verb and resource ('Get a multi_voice_to_speech or srt_to_speech job with every segment') and enumerates the payload (text, per-segment voice and audio_url, merged audio). It implicitly separates itself from get_job_status by scoping to full segment detail, though it never names that sibling 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?

'Use it to build captions or a Remotion/NLE timeline' gives a concrete intended context, and the parenthetical '<Sequence> per segment' tells the agent how to consume the result. It stops short of stating when to prefer get_job_status instead, so no explicit exclusions or alternative routing.

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?

Annotations already declare readOnlyHint/idempotent/non-destructive, so the safety profile is covered. With no output schema, the description carries the return-value burden and does so well: it names the three status values and the audio_url field that only appears on SUCCESS, plus the guard against fetching audio prematurely.

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 short sentences, zero filler, and the most actionable constraint (don't fetch audio before SUCCESS) is placed last as a clear imperative. Nothing could be removed without losing information.

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?

With no output schema, the description correctly compensates by documenting the status enum and conditional audio_url, which is what an agent needs to interpret the result. It stops short of describing polling cadence or retry behavior, but the schema's wait_seconds field partially covers that ground.

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%, in the middle band, and the description contributes no parameter meaning at all. job_id in particular has no description anywhere, and the description never mentions job_type, wait_seconds, or the polling semantics the wait_seconds field hints at.

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 (check) and resource (a speech job created earlier) plus the payload returned, so the intent is unambiguous. It does not distinguish itself from close siblings such as get_job_detail or get_localization_status, leaving the agent to infer which status tool to pick.

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?

"Check a speech job created earlier" implies the post-creation polling context, and "Never guess or fetch an audio URL before SUCCESS" gives a real precondition. However, it never names an alternative (get_job_detail for richer info, list_recent_jobs for discovery) or states when this tool is the wrong choice.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful disclosure of what fields appear once a job reaches Completed, but says nothing about pending/failed states, latency, or the blocking behavior that the tool actually has.

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 front-loaded sentence that states the resource and then the conditional return payload. No filler, no redundancy.

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?

With no output schema, the description correctly carries the return-shape burden by naming the three artifacts and the per-language granularity. It is nearly complete for a polling tool, missing only guidance on non-Completed terminal states and the wait_seconds blocking semantics.

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%: wait_seconds is well documented in the schema, while job_guids carries no description (only minItems/maxItems constraints). The description mentions neither parameter, so it does no compensating work, but the one undocumented parameter is largely self-evident from its name.

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 a specific verb (status of jobs) and ties it to the concrete producing tool localize_video, then enumerates the returned artifacts (audio_url, final_video_url, translated SRT). It is clearly not a generic job tool, though it never explicitly contrasts itself with the sibling get_job_status/get_job_detail, so an agent must infer the boundary.

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 is implied: this is the polling tool for localize_video jobs. There is no explicit when-to-use vs get_job_status or get_job_detail, and no statement of preconditions. The only polling guidance ('if the job is still PENDING, call get_job_status later') lives in the schema, not the description.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavior: the SRT is returned only once finished, but it omits what happens while pending, whether errors are surfaced, and how waiting affects the call. With annotations carrying safety, this is adequate but not rich.

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 tight sentence front-loads the core action and result. It is not padded, though it is terse enough to leave behavioral gaps.

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 read-only polling/retrieval tool with annotations and no output schema, the description is minimally complete. It should explain return behavior when the job is still pending and clarify what 'once finished' means for the caller.

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 schema documents wait_seconds in detail, including the pending fallback. The description mentions the job being checked but does not explain job_id or the wait behavior itself. With 50% schema description coverage and one trivial required identifier, the schema does most of the work and baseline 3 is appropriate.

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 action and resource: checking a transcribe_media job and retrieving its SRT. It connects to the sibling transcribe_media tool and distinguishes the result (SRT) from a generic job detail. Sibling differentiation from get_job_status is implied but not explicit.

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 is implied by 'Check a transcribe_media job', meaning this is the follow-up call after transcription. It does not explicitly say when to use get_job_status or get_job_detail instead, nor does it state exclusions or preconditions.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuine value by disclosing the returned fields (persona, accent, pitch, styles, preview audio, credit cost), which matters since there is no output schema. It stops short of noting error behavior for an invalid token.

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 front-loaded sentence with the verb and scope first and the field list after; every clause earns its place and nothing is redundant.

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 read-only single-lookup tool whose annotations carry the safety profile, the description covers purpose and return contents adequately. The only minor gap is behavior on an invalid or stale voice token.

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?

There is one parameter with 100% schema description coverage, so the schema already explains the required voice token and its source. The description adds no syntax or format detail beyond that, making the baseline 3 appropriate.

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 ('Get') and resource ('full metadata for one voice token'), and the singular scope implicitly contrasts with the sibling list_voices. It also enumerates exactly what the metadata contains, so an agent knows what it gets 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 'for one voice token' implies the lookup workflow (fetch a token, then get its details), but there is no explicit when-to-use, when-not, or named alternative such as list_voices. Usage is only inferable.

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?

Annotations already establish the safe read-only, idempotent profile, so the bar is lower; the description adds the non-obvious return behavior that results come back 'in their saved order'. It doesn't cover empty-list or error behavior, but for a trivial read that is minor.

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, no waste, with the purpose front-loaded and the usage rule following. Every sentence 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 no-parameter read tool with no output schema, the definition gives enough to call it correctly and know what to expect (favorites in saved order). Only the shape of the returned list itself is left unspecified, which is acceptable given there is no output schema.

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?

Zero parameters, so the baseline is 4. There are no argument semantics for the description to add, and nothing is misleading.

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 (List) and resource (voices the user marked as favorites), and adds the scope 'in their saved order', distinguishing it from generic sibling list_voices and list_my_custom_voices. An agent can tell what it returns 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?

'Check this first when the user did not name a voice' is an explicit routing rule that tells the agent when to prefer this tool. It falls short of naming the alternative (e.g. list_voices) to use otherwise, but the selection condition is clearly stated.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds that the return is language codes, but says nothing about ordering, count, or format beyond that. Adequate but not rich.

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, both front-loaded with the essential information, and every clause earns its place: what is listed and what the output feeds into.

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 no-argument, read-only enumeration tool with no output schema and full annotation coverage, the description supplies exactly the missing piece (what the values are for) and needs nothing more.

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 no parameters and schema coverage is 100%, so the baseline is 4. There is nothing for the description to compensate for, and the statement about returned language codes is peripheral to 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?

States a specific verb and resource ('List every language supported by TTSForFree text-to-speech'), which is unambiguous. It also implicitly separates itself from list_voices by describing languages as codes feeding into that tool, though it stops short of an explicit 'this is not list_voices' distinction.

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?

Tells the agent the downstream use of the result ('language codes to pass to list_voices'), which effectively signals when this tool belongs in a workflow. It does not state any exclusion condition or prerequisite, but for a zero-param lookup that is a minor gap.

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?

Annotations already declare a safe, idempotent, non-destructive read. The description adds real value beyond them by disclosing what comes back (custom voices plus the remaining custom-voice quota) and how the returned identifier should be consumed. Pagination or result-size behavior is not mentioned, keeping it at 4.

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 with no filler, front-loading what the tool lists and then how to use the output. Every clause earns its place with no redundancy.

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?

With no input parameters and no output schema, the description carries the burden of describing the return payload, and it does: custom voices plus remaining quota, plus the key field name (`voice`). Nothing an agent needs to call and consume this correctly 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 tool takes zero parameters, so the schema has nothing to document and there is no parameter semantics to add. Baseline 4 applies; nothing in the description is needed here.

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 (List) and resource (the user's personal custom voices), and narrows the scope by naming the two creation paths (Voice Design, Voice Clone). This distinguishes it clearly from siblings like list_voices and list_favorite_voices without opening their 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?

Gives concrete downstream guidance: 'Use `voice` from the result in any speech tool,' which tells the agent why and when to call this. It does not explicitly name the alternative tools (list_voices, list_favorite_voices) or state when not to use it, so it stops short of full routing 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered structurally. The description adds that results carry status and audio URLs and that this avoids re-paying for synthesis, which is real behavioral value, but says nothing about pagination/ordering (how 'recent' is defined) with a limit capped at 50.

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 front-loaded sentence that combines the action, the returned data, and the motivating benefit with no filler or redundancy.

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?

With no output schema, the description usefully previews the return payload (status, audio URLs), and annotations cover safety. However, an agent still lacks any explanation of limit semantics or the job_type enum, which are needed to call the tool confidently, leaving it only minimally 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?

Schema description coverage is 0%, so the description carries the full burden for both parameters, yet it never mentions 'limit' or 'job_type'. The enum values single/multi/srt are especially opaque and left unexplained, so the description does not compensate for the coverage gap.

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 (list recent speech jobs) and even names the payload fields returned (status, audio URLs), which is more than a restatement of the title. It does not explicitly differentiate itself from the similar-sounding siblings get_job_detail and get_job_status, so it stops short of 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?

The trailing clause 'to reuse earlier audio instead of paying again' supplies a genuine usage motivation, but there is no explicit when-to-use/when-not guidance and no named alternative (e.g. get_job_detail for a single job). Usage is implied rather than instructed.

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?

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds genuinely new traits: results are sorted by popularity, `can_use=false` signals plan ineligibility, and the token must be passed through unchanged. It stops short of describing pagination or result-count behavior against `limit`.

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 tight sentences, front-loaded with what the tool does and immediately followed by the actionable token contract. The closing preference hint is short and non-redundant; no sentence is 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?

With no output schema, the description carries the burden of explaining returns and does so for the fields that matter most (the `voice` token and `can_use`). Other returned attributes such as name, style, gender or persona are left unmentioned, a minor gap for a discovery tool.

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%, so roughly a third of parameters rely on the description. The description clarifies the `can_use`/`only_usable` relationship but says nothing about `limit`, `gender`, or how `query` interacts with `language`, so it only partially compensates for the coverage gap.

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 with scope: 'Search the AI voice catalog for one language.' It also makes the downstream purpose concrete by naming the tools the returned `voice` token feeds into (text_to_speech, multi_voice_to_speech, srt_to_speech), which lets an agent place it precisely against siblings like get_voice_details, list_favorite_voices and list_my_custom_voices.

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 clear context: use it to obtain a `voice` token for TTS calls, and prefer the user's favorite or custom voices when they exist. It does not explicitly name list_favorite_voices or list_my_custom_voices as the alternatives for that preference, so the routing is implied rather than spelled out.

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?

Annotations only mark this as a non-read-only, non-destructive mutation. The description adds substantial behavioral context: it is long-running (several minutes), returns job_guids immediately, and yields per-language audio_url and final_video_url outputs — critically the async polling requirement, which nothing structured conveys.

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 front-loaded sentences: purpose first, then per-language return values, then timing and follow-up steps. No filler; every clause (YouTube multi-language track, alignment, polling) carries operational value.

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?

With no output schema, the description carries the return-shape burden and does so (audio_url, final_video_url, timeline alignment). It also covers async timing and the required polling tool, leaving nothing an agent needs to invoke and follow up correctly.

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 100%, and each parameter already carries a description (voice tokens, language codes, video_url source, volume semantics). The description adds no parameter-level detail beyond the schema, 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 precise verb and resource ('Full automatic dubbing of an uploaded video') and enumerates the pipeline (transcribe, translate, voice, render per language). This clearly separates it from text_to_speech, multi_voice_to_speech, and transcribe_media siblings.

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?

Explicitly routes the agent to get_localization_status for polling and estimate_video_localization for cost on long videos. It gives clear workflow context but does not state when NOT to use it or contrast directly against a close alternative.

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?

Annotations cover the safety profile (non-read-only, non-destructive, non-idempotent, closed-world), so the bar is lower. The description still adds value the annotations don't: 'Consumes credits' (cost) and the merged-MP3 return format, which matters because there is no output schema. It omits any mention of the async polling flow, which lives only in the wait_seconds schema field.

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 with no filler: the output shape and segment semantics come first, then the use cases and the selection condition. Nothing is repeated from the title or schema.

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 no-output-schema generation tool, it covers purpose, cost, use cases, and return format, and the polling behaviour is carried by the wait_seconds schema description. It leaves segment-count limits and the job_id/get_job_status round-trip unmentioned in prose, which is a minor gap rather than a blocker.

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?

With 50% schema coverage, the description compensates for the undescribed top-level 'segments' parameter by disclosing that segments are ordered and each carries its own voice — real semantic content not present in the schema. It adds nothing about wait_seconds, though the schema already documents that field and its polling fallback.

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 concrete verb and resource ('Render ordered segments ... into ONE merged MP3') and adds the differentiator 'each with its own voice', which separates it from single-voice text_to_speech and timestamp-driven srt_to_speech without needing to open either 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 explicit use contexts ('podcasts, dialogues, interviews, audio dramas or explainer videos with several speakers') plus a selection condition ('when there are no fixed timestamps'), which implicitly routes timestamped work to srt_to_speech. It never names an alternative tool or states when not to use it, 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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds only the 'only when the user asks' caveat — mildly useful, but it does not disclose what happens when the voice is not currently favorited or any auth context. No contradiction with annotations.

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 front-loaded sentence with the verb and resource first and the usage caveat second; no filler. It is appropriately sized for a one-parameter tool.

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, single-parameter mutation tool whose annotations carry destructive/idempotent semantics and whose schema documents the token, the description is reasonably complete. The main omission is behavior on a non-favorited voice, which the idempotentHint annotation effectively covers.

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?

With one parameter at 100% schema description coverage, the schema fully documents the 'voice' token and even points to list_favorite_voices for obtaining it. The description adds no parameter meaning beyond that, which is the expected baseline.

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 states a specific verb (remove) and resource (a voice from the user's favorites), which is clearly distinguishable from the inverse sibling add_favorite_voice. It stops short of explicitly naming the counterpart tool, so it is clear but not sibling-routing.

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 parenthetical '(only when the user asks)' implies a usage condition but gives no explicit when/when-not rationale tied to alternatives such as add_favorite_voice or list_favorite_voices. Usage is implied rather than stated.

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?

Annotations already declare readOnly=false, idempotent=false, destructive=false, openWorld=false. The description adds genuinely useful context beyond them: credit consumption, that the output is a single MP3 aligned to 00:00 of the video, and that ffmpeg mux commands are returned. It does not detail async/pending behavior beyond what the wait_seconds schema field already says.

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?

Dense but front-loaded: the core behavior and the input-mode choice come first, then speaker handling, then output/muxing, then the credit note. Every sentence carries information, though the use-case list is slightly padded.

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-param tool with nested objects and no output schema, the description covers purpose, input modes, multi-speaker handling, output artifact and cost. Minor gaps remain: it doesn't state precedence if both srt and segments are supplied, nor that zero parameters are marked required.

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, but the description adds real meaning: the srt/segments duality as alternatives and the speaker-prefix convention ('[Name]' or 'Name:' in cue text) mapped to speaker_voices. That convention is not documented in the schema and directly affects correct invocation.

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 ('Create ONE MP3 that follows a subtitle timeline') and immediately names the distinguishing trait versus plain TTS siblings: every cue is anchored to its timestamp with auto-fitting speed. An agent can tell this apart from text_to_speech or multi_voice_to_speech without opening any 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 concrete when-to-use scenarios (video voiceover, dubbing translated subtitles, YouTube localization, tutorials, any edit where audio must line up). It also clarifies the two mutually exclusive input paths (srt vs segments). It stops short of explicitly naming sibling alternatives for the non-timed cases, so not a full 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?

Annotations only say it is a non-read-only, non-destructive, non-idempotent write; the description adds the credit model ('characters x voice rate'), the async contract, and the returned fields (job_id, status, audio_url). It does not state failure/retry behavior or permission requirements, which keeps it short of a 5.

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, front-loaded with the core conversion, then usage, then cost/return. Every sentence carries distinct information with no repetition of the tool name or title.

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?

With no output schema, describing job_id/status/audio_url is genuinely necessary and present, and the wait_seconds/PENDING handoff is covered in the schema. Minor gap: no mention of what happens on provider failure or how long jobs persist.

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 100%, so the baseline is 3; the text restates text/voice cardinality but adds no syntax, format, or constraint detail beyond what the schema already carries (pitch provider caveat, wait_seconds PENDING flow).

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 concrete verb+resource with cardinality: 'Convert one text into one MP3 with one voice.' The 'one/one/one' framing implicitly distinguishes it from sibling tools like multi_voice_to_speech and srt_to_speech without needing the 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 positive-use context (narration, voiceover scripts, articles, lessons, announcements, 'any audio whose length can follow the speech'), which hints at what it is not for. It never names an explicit alternative such as multi_voice_to_speech or srt_to_speech, so routing is left partly 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?

Annotations only give the generic safety flags (readOnlyHint=false, idempotentHint=false), while the description adds genuinely non-obvious behavior: credits are charged per second of media and measured by the server. The async pattern is partly covered by the wait_seconds schema, so this is a strong but not exhaustive 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?

One tight passage, front-loaded with what the tool does and its output, then cost and parameter pointers. No filler sentences.

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 exists, but the description compensates by naming the return value (timestamped SRT) and the billing model. It could mention what happens on failure or how get_job_status ties in, but an agent has enough to call it correctly.

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 100%, so the baseline is 3. The description only adds that language must come from list_languages, which is mildly useful but mostly redundant with the schema's 'Spoken language code' text and the create_upload_url reference for media_url.

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 ('Speech-to-text for an uploaded video or audio file') plus the concrete output ('timestamped SRT'), and names the downstream sibling srt_to_speech so the agent can distinguish its role. Nothing ambiguous.

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 clear positive guidance: use language codes from list_languages, and the SRT feeds srt_to_speech for rewrite/translate/re-voice. It stops short of explicit exclusions versus siblings like get_transcription or localize_video, so a 4 rather than 5.

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