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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds behavioral value by naming what the response reveals (quota counters and plan entitlements) and framing it as a diagnostic for refused requests. It does not mention auth or rate-limit constraints on the check itself.

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 with the capability front-loaded and the usage triggers appended. Every clause earns its place; nothing is padding.

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 carry the return-value burden, and it enumerates the returned fields explicitly. Combined with the read-only annotations and zero-param schema, an agent has everything needed to select and call this tool 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?

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies a parameterless, connection-scoped lookup ('behind this connection'), matching the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Show) plus resource (the FreeTTS plan behind this connection) and enumerates the concrete quota dimensions returned (characters today/month, requests per minute, HD voices, watermark). This clearly distinguishes it from the sibling tools, all of which generate or transform audio rather than report plan state.

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 triggers: user asks about limits, their plan, or why a request was refused. The refusal-diagnosis case is a genuinely useful routing signal. No alternatives or when-not conditions are named, which is a minor gap since no sibling overlaps functionally.

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 the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), and the description adds a genuinely useful prerequisite: a connected FreeTTS PRO account. However it says nothing about the output artifact beyond 'one audio file' — no return value, download location, or failure behavior for unnamed speakers, which is the main behavioral gap for a write 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?

Four short sentences, front-loaded with the core transformation, then format, then use cases, then the prerequisite. Every sentence carries weight, though 'with a pause between lines' mildly duplicates pause_ms in the 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 4-parameter tool with 100% schema coverage, existing annotations, and no output schema, the description covers purpose, input format, typical use cases, and the account prerequisite. The only real omission is what the caller gets back / where the rendered audio lives.

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 script, voices, language and pause_ms are all documented in the schema itself, including the 'Name: text' format and the default 600ms pause. The description restates the script convention and the pause behavior but adds no syntax or default information beyond the schema, which is the baseline 3 case.

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 ('Turn a script with several speakers into one audio file') plus the defining behavior — a different voice per speaker with pauses between lines. The 'one audio file' framing implicitly separates it from script_to_tracks, so an agent can route multi-speaker requests correctly 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 concrete use cases ('two-host shows, interviews, scenes, language lessons with two speakers') and a prerequisite ('Needs a connected FreeTTS PRO account'). It stops short of naming alternatives such as text_to_speech for single-voice input or script_to_tracks, so the exclusions are left 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 already declare readOnly/idempotent/closed-world, so the safety bar is covered. The description adds genuinely new behavioral context: results indicate which voices are free versus which require a FreeTTS PRO key, and name the paid tiers (HD, Signature).

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: what it returns first with its downstream use, then when to call it. No filler and nothing buried.

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 describes the return content (voice ids plus free/PRO indication). It does not mention pagination or the default limit behavior, but the schema covers the limit parameter, so the gap is minor.

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 schema already documents limit, gender, search, language and free_only with examples. The description reinforces the language/search/free-vs-paid axes but adds no syntax or format detail beyond the schema; 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 ('List FreeTTS voices') and adds the payload value ('the voice id to pass to text_to_speech'), so an agent knows what it gets back. It does not explicitly separate itself from the close sibling suggest_voice, which keeps it 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?

Gives concrete trigger conditions: user names a language, accent or gender, or asks what voices exist. Clear context for invocation, but no explicit exclusions or disambiguation against suggest_voice, which also deals with voice 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 cover the safety profile (non-destructive, idempotent, open-world), and the description adds behavior the annotations cannot: the required PRO account and the return shape (one combined file plus per-track files), which matters since no output schema exists. It stops short of describing failure modes or file formats.

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?

It is a dense two-sentence block that front-loads the core behavior and syntax, then the outputs, then the account requirement. Nothing is obviously redundant, though the syntax enumeration is lengthy and slightly crowds out the routing guidance.

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 9-parameter, non-read-only tool with no output schema, the description covers the essentials an agent needs: purpose, syntax conventions, output artifacts, account prerequisite, and example scenarios. Only light gaps remain around error behavior and how parameter interactions (e.g., my_part with NAME:) resolve.

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 genuine meaning beyond the schema by documenting the script body syntax ((pause 2), (beep), (ding), (click), 'CUE:', 'TRACK: name', 'NAME: line'), which is the central input semantics for the required parameter and is only referenced by URL in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Record a script with exact timing'), and immediately clarifies the exact output shape: one combined file plus one file per track. It also implicitly distinguishes itself from siblings like text_to_speech and dialogue_to_speech by framing itself as the multi-line, timed 'Script mode' recorder.

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?

It gives concrete, varied use cases (ear prompter tracks, voiceovers timed to footage, rehearsal tracks, workout/recipe step audio) and states the prerequisite of a connected FreeTTS PRO account. It does not explicitly say when to prefer this over sibling dialogue_to_speech, which keeps it from 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 cover the safety profile (readOnlyHint=true, idempotentHint=true, closed-world), so the description's added contribution is the return shape: exactly three candidates, each with a rationale. That output-cardinality detail is genuinely useful given there is no output schema, though latency/cost behavior is unstated.

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, front-loaded with what the tool returns followed by the when-to-use condition. No 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 usefully describes the return (three voices plus reasons) and names the triggering condition. The only real gap is the gender filter, which is neither mentioned in the description nor fully documented in the 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?

Schema coverage is 67%, and the description enriches the vague 'in a few words' use parameter by enumerating concrete use categories (audiobook, tutorial, ad, news, children's story, meditation, podcast). However, it says nothing about the gender parameter or its enum, so the 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 verb (suggest), resource (FreeTTS voices), cardinality (three), and the dimensions it varies over (language, use), plus what it returns (a short reason each). This is readily distinguishable from list_voices or text_to_speech.

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 when the user has not named a voice" gives a clear selection condition and implicitly separates it from a lookup-style sibling like list_voices. It stops short of naming an alternative tool explicitly, so it is 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?

Goes well beyond the annotations (which only say it is a non-read-only, open-world, idempotent, non-destructive call) by disclosing tiered behavior: 2,000-char cap and a spoken 'FreeTTS' tag with 1-hour retention without a key, versus HD voices, no tag, 10,000 chars and 30-day retention with a PRO key. This is exactly the operational context an agent needs.

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-loads purpose, then usage trigger, then tier constraints in a single dense paragraph. No filler sentences; every clause carries either routing or limit 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 still explains the return value (download link, optionally audio bytes via include_audio) and the retention/limit differences per tier. For a 6-param tool with 100% schema coverage, nothing material is left 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 100% (baseline 3), and the description adds real value on top: it clarifies that the effective character limit is tier-dependent (2,000 vs 10,000) even though the schema advertises maxLength 30000, and that format=wav requires PRO. It ties voice/format defaults to the key tier without restating every field.

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 (convert text to spoken audio) plus the concrete return artifact (download link to MP3/WAV). It is distinguishable from siblings like dialogue_to_speech and script_to_tracks because it explicitly handles a single block of text.

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 trigger conditions ('when the user wants text read aloud, narrated, or saved as an audio file') and implicitly the multi-voice sibling dialogue_to_speech. However, it never explicitly says when NOT to use it versus dialogue_to_speech or script_to_tracks, so the agent must infer the boundary.

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, idempotent and openWorld, so the safety profile is covered. The description adds meaningful context beyond them: an account/entitlement requirement (PRO) and the no-auth-free constraint of needing a publicly reachable https URL.

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 with zero filler, and the core purpose is front-loaded before prerequisites. 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 simple 2-parameter read tool with no output schema, the description covers purpose, constraints and formats adequately. It does not describe the return shape (e.g., transcript text/timestamps), a minor omission given no output schema exists.

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 baseline is 3. The description goes further by enumerating accepted audio formats (mp3, wav, m4a, ogg, webm), which the schema does not specify, adding real value for the audio_url 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 and resource ('Turn a recording into text') and names the provider (FreeTTS speech to text). It is unambiguously distinguishable from TTS-oriented siblings like text_to_speech and dialogue_to_speech, which operate in the opposite direction.

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 preconditions: a public https URL to an audio file and a connected FreeTTS PRO account. It does not explicitly name an alternative tool or exclusion, but the direction of conversion makes alternatives self-evident.

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