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

No annotations are provided, so the description carries the burden and does well: English-speech-only validation, refusal of recordings longer than the reasoning budget, a 25s default wait, and async job-id return with an anti-polling instruction. It omits what a failure/refusal looks like to the caller and whether the answer text is the sole return value.

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?

Seven short sentences with the purpose front-loaded, then operand details, then the async flow instruction. Every sentence carries operational information; 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?

With 6 params, no annotations and no output schema, the description still covers the input semantics and the async continuation protocol via get_job_status. The main residual gap is the response shape and refusal/error surface, which an agent must discover at runtime.

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 0%, so the description must compensate and largely does: start/end are 'in seconds, for the part you want', wait_seconds defaults to 25, show_reasoning prepends model reasoning, and path is implicitly clarified as file or YouTube link. The accepted path format and question wording are left to inference.

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: answering a question about 'one audio file or one YouTube link', with an explicit cardinality limit. It is clearly distinct from transcribe/translate/identify_language siblings, which produce transcripts or labels rather than answers.

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 routing: pass start/end for a sub-segment, and on timeout 'call get_job_status' with the explicit rule 'Do not poll in a loop'. It does not say when to prefer transcribe instead of asking a question, so it stops short of full alternative coverage.

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 it does disclose one non-obvious trait: completed pieces survive cancellation and remain readable. It omits other behaviors an agent needs — whether cancellation is idempotent, what happens to in-progress segments, whether it errors on an unknown or finished job_id, and what the call returns.

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, no filler, with the primary action stated first and the consequential side effect second. 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?

No output schema and no annotations mean the description is the only source of behavioral detail; it covers the headline effect and partial-result retention but leaves the required job_id undocumented and says nothing about return value or failure modes. Adequate to call correctly in the happy path, incomplete around the edges.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter job_id has 0% schema description coverage, so the description must compensate, but it never mentions job_id, its expected format, or where to obtain it (presumably list_jobs or get_job_status). That is the main gap in an otherwise terse definition.

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?

"Stop a transcription job" gives a specific verb and resource, and the second sentence distinguishes this from a pure abort by naming get_job_result as the path to already-finished output. An agent can pick this over get_job_status or list_jobs 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?

Usage context is clear: use this to halt an in-flight transcription, and read partial output via get_job_result afterwards. It lacks an explicit exclusion (e.g. behavior when the job already completed or is already cancelled), so it falls short of a full when/when-not statement.

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 burden and does add real context: only text is stored (no timestamps or speaker labels), and offset/limit exist to avoid flooding the chat. Missing behaviors are the important ones though — whether the response includes job status, what a not-yet-finished job returns, and what the format parameter actually changes.

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 what is returned, then pagination rationale, then the storage constraint. No filler; the only weakness is that the last sentence reads as an afterthought rather than being integrated.

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 four-parameter read tool with no output schema and no annotations, the description covers return content and pagination adequately. The unexplained format parameter and undefined failure/empty-result behavior leave the definition short of what an agent needs to call it reliably in edge cases.

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 0%, so the description must document parameters. It explains offset and limit as a pagination slice, which is genuinely helpful, but job_id is never mentioned and format (default "text", with no declared enum) is left entirely unexplained — an agent cannot tell what values it accepts or what non-text output means.

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 words from a finished job" conveys that this retrieves transcript text, and the sibling set (get_job_status, list_jobs, transcribe) makes the retrieve-vs-poll distinction inferable. But it never states a verb or names the resource outright, so the agent has to reconstruct purpose from context rather than read it.

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?

"from a finished job" implies the prerequisite that the job must be complete, which is useful usage signal. It does not explicitly say to check get_job_status first, nor what to do if the job is still running or failed, and it names no alternatives.

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 at all, the description carries the full burden, and it does disclose real behavior the schema does not: the call can block up to 45 seconds and should not be loop-polled. It says nothing about permission requirements, error/not-found behavior, or what happens if wait_seconds exceeds 45.

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 purpose, then the key parameter constraint, then the agent directive. 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?

For a two-parameter status check with no output schema and no annotations, the description covers the mechanics of waiting but not the outcome space — it never says what statuses exist or how to recognize a terminal state, which is exactly what the agent needs to decide whether to call get_job_result next.

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 must compensate. It does explain wait_seconds (range 0-45, waits for completion), but job_id — the required parameter — gets no semantics at all, leaving the caller to guess whether it is the handle returned by transcribe.

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?

"How far a transcription job has got" names the resource (transcription job) and the concept queried (progress/status), so the intent is unambiguous. It does not, however, differentiate from close siblings like get_job_result or list_jobs, which an agent must choose between.

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 an explicit operating instruction: pass wait_seconds 0-45 to block until the job finishes, and "Do not poll in a loop" — a clear exclusion of a common wrong behavior. It stops short of saying when to prefer this over get_job_result or when a job is terminal.

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 delivers real behavioral detail: one label returned, roughly 10 seconds of audio sampled, an initial pause is skipped, degraded accuracy for Latvian and Slovenian. It doesn't disclose error/failure behavior or whether the call blocks synchronously versus returning a job handle, which matters given job-status siblings exist.

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?

Five short sentences, each earning its place: purpose, return value, sampling behavior, known weakness, and scope boundary. The most decision-relevant facts (what it returns, what it is not) are 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 and no annotations, the description does cover the return value (a single label) and reliability caveats, which is the core need. However, for a five-parameter tool at 0% schema coverage it leaves the label_set/candidates/wait_seconds behavior unexplained, which is a meaningful gap for correct invocation.

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% across five parameters, and the description only indirectly touches two of them — 'audio file or YouTube link' for path and 'about 10 seconds' for clip_seconds. label_set, candidates, and wait_seconds are entirely undocumented in both schema and description, leaving the agent to guess at label taxonomies, candidate constraints, and blocking timeout semantics.

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?

Uses a specific verb-plus-resource framing ('Say which language is spoken') and pins the input domain to 'one audio file or one YouTube link.' The closing 'Not a transcript' explicitly separates it from the transcribe sibling, so an agent can route correctly 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?

The 'Not a transcript' line gives a clear negative condition against transcribe, and the label example (en_us) shows the expected usage shape. It stops short of naming alternatives such as list_languages for supported labels or saying when to prefer transcribe/translate instead, so it's clear context rather than a full when/when-not routing rule.

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 behavioral burden, and it does disclose ordering (newest first) and machine-local scope — genuine traits not derivable from the schema. It omits whether results are paginated, what a job entry looks like, and how many jobs typically exist, so the safety/behavior profile is only partially covered.

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 with zero filler, and the resource plus ordering constraint is front-loaded before the usage hint. Nothing here could be cut 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?

No annotations, no output schema, and 0% parameter coverage leave the agent without the essentials for correct invocation: accepted state values, pagination behavior, and the shape of a returned job record. For a filterable list tool this leaves too much to guesswork.

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 neither of the two parameters (limit, state) is mentioned in the description. An agent cannot tell from this text what values 'state' accepts or that 'limit' defaults to 20, so the description does not compensate for the schema 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 the resource (jobs), the scope (on this machine) and the ordering (newest first), and pairs that with a concrete purpose: recovering a job id. That distinguishes it reasonably well from get_job_status and get_job_result, though it never names those siblings 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 this to recover a job id" gives one clear when-to-use case, which is more than most list tools offer. There is no when-not guidance and no mention of the alternative ways to reach a job (get_job_status, get_job_result), so the routing signal is implied rather than explicit.

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 provided, the description carries the burden and does add useful behavioral detail: it defines level, translate, and identify value semantics and notes data quirks like Latvian/Slovenian and Norwegian. It does not explicitly state read-only/non-destructive behavior, but the listing purpose is clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is reasonably compact and front-loads the main purpose before field definitions. The final Norwegian caveat is a bit awkward and uses the undefined term 'card', but overall it avoids bloat.

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 listing tool with no output schema, the description adequately explains the key returned fields and their value meanings. It could more explicitly describe the overall return shape, but the critical semantics are present.

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 has zero parameters, which sets the baseline at 4. There are no parameter semantics to explain, and the schema is empty.

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 clearly identifies the resource as the model's supported languages and describes the support-strength fields. It does not explicitly route against siblings like identify_language or translate, but the purpose is still clear.

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 explains the returned fields but gives no explicit guidance on when to call this tool versus alternatives such as identify_language, translate, or transcribe. Usage is only loosely implied.

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 so well: it discloses chunking behavior for long files ('cut at a pause and sent one piece at a time'), the 10-second overlap at joins with speaker number reconciliation, the wait_seconds default of 25, and that an unfinished job returns an id. The anti-polling instruction is exactly the kind of behavioral constraint an agent cannot infer elsewhere.

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?

Content is front-loaded and nearly every sentence carries distinct information, but the style definitions are delivered in a dense, telegraphic run of short sentences ('style clean drops fillers...', 'style raw_dictation drops punctuation...') that could be grouped more legibly. Slightly terse phrasing ('Waits wait_seconds (default 25)') costs a bit of parsing effort.

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 tool with no annotations and no output schema, the description covers the async job flow and the transcription-quality knobs thoroughly. It never says what a completed transcript result looks like (text field, timestamps, segments) or which audio formats are accepted, which is the main remaining gap for an agent planning the call.

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 0% and the schema has no enum for style, yet the description enumerates and explains all four style values (verbatim, clean, technical, raw_dictation) and their output differences. It also constrains speakers to 2-8, forbids it with style technical, and explains wait_seconds semantics, leaving only the trivial path parameter to 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?

Opens with a specific verb+resource ('Speech to text for one audio file or one YouTube link'), including the key scope limit of one input. It implicitly separates itself from siblings like translate and ask_about_audio, but never names them, so the differentiation is inferential rather than 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?

Gives strong operational guidance: which style to choose, that speakers must not be combined with style technical, that speakers must be 2-8, and explicitly what to do when a job id is returned ('Tell the user, then call get_job_status. Do not poll in a loop'). It does not explicitly say when to prefer translate or ask_about_audio instead, so it stops short of full 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?

With no annotations, the description carries the full burden and does so: environment-variable precedence, the English-language constraint, chunking of long files at pauses, the wait_seconds default, and the job-id fallback with a directive to inform the user and switch to get_job_status. That is unusually complete behavioral disclosure for an unannotated 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?

It is front-loaded with the core action and then the language rules, and nearly every sentence carries operational information. There is some redundancy between the source_language definition and the later override sentence, which keeps it from a 5.

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 behavior (result vs. job id after wait_seconds) and the correct next step. Combined with chunking and language-rule notes, an agent has everything needed to invoke 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 coverage is 0%, so the description must compensate, and it explains source_language and target_language with examples (Polish/pl, English/en), defaults, and precedence rules. path is only implied (an audio file or a YouTube link) without stating accepted formats or whether it is a local path or URL, leaving one 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?

"Write the speech in one audio file, or one YouTube link, in another language" states a specific verb (write speech) and resource (audio file / YouTube link) clearly enough to distinguish it from transcribe. It doesn't explicitly name the sibling it differs from, 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?

It explicitly says when to pass source_language/target_language, when to leave them empty (falling back to NEMOTRON_* env vars), the constraint that one language must be English, and names the follow-up tool get_job_status with an explicit "do not poll in a loop" exclusion.

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