Nativ

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

No annotations are supplied, so the description carries the full behavioral burden and only tells us the data is persisted for reuse. It does not state whether duplicate source/target pairs are deduplicated or rejected, whether the write is immediate, what permissions are needed, or any failure modes. For a mutation tool with zero annotation coverage this is a significant gap.

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

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

The purpose sentence and usage sentence come first, then the Args list — front-loaded and easy to scan. The Args entries are short and each earns its place; nothing is 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?

An output schema exists, so return values need not be explained, and the parameter list is fully covered. However, for a write tool with no annotations, the description should still resolve duplicate-handling and persistence semantics to be 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%, and the Args block compensates by defining all five parameters in plain language, including format examples ('en', 'fr-FR') and a concrete example for name. It does not note that name is optional, nor give any guidance on length or multi-segment source text, so it falls slightly short of full compensation.

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: 'Add a new entry to the translation memory.' This clearly distinguishes it from the update_/delete_/search_/list_ siblings, though it never explicitly names those alternatives to confirm the boundary (e.g. that adding a duplicate is not the same as updating one).

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 store approved translations so they are reused in future localizations' gives a solid when-to-use rationale tied to the downstream benefit. It stops short of exclusions — nothing says what to do if an entry already exists for the same pair, or when to prefer update_translation_memory_entry.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the output shape (SAFE / NOT SAFE, affected countries, concrete fix), but says nothing about cost, latency, image size limits, authentication requirements, or whether the verdict is deterministic — gaps that matter for a judging tool an agent may call repeatedly.

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 verdict/return summary is front-loaded and the Args block is tight and scannable. Minor redundancy in restating return values already covered by the output schema, but nothing that wastes the reader's attention.

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 read-style tool with an output schema and no annotations, the definition covers inputs and outputs adequately. The remaining omission is operational context — limits, latency, or failure modes — which would matter for repeated or batch use but is not blocking for a correct single 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%, yet the description fully compensates: image_path is defined as a public HTTPS URL on hosted transport or a local path on stdio, with accepted formats (PNG, JPEG, WebP); countries is defined as a comma-separated list with a worked example and an explicit default (top markets by GDP).

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 — 'Analyze an image for cultural-sensitivity issues across markets' — plus the decision it supports ('before launch'). The domain is narrow enough that it is unambiguously distinct from siblings like localize_image or extract_image_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?

'Before launch' implies a pre-release review workflow, which is useful timing context. However, there is no explicit when-not guidance, no prerequisites, and no named alternative for related needs (e.g., localize_image vs. this check), so the agent must infer 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 well: it discloses the consent/ownership gate, the input-location constraint (local paths in stdio or public HTTPS URLs), and the returned voice_id. It stops short of failure modes, rate limits, or what happens if consent validation fails, so it is strong but not exhaustive.

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 core action and consent requirement are front-loaded, followed by input constraints, the return value, and the sibling alternative. Every sentence adds distinct information with 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?

For a four-parameter mutation tool with an output schema, the description covers the consent gate, input formats, the return value, and the sibling alternative. The only gap, language_code, is minor and the output schema handles return-value detail.

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 does for three of four parameters: reference_path is the reference speech, consent_path is the spoken consent, and confirm_ownership is the explicit ownership/permission confirmation. language_code is never mentioned, leaving one parameter undocumented in both schema and description.

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 opens with a specific verb and resource ('Create a Google voice clone from reference speech and spoken consent') and explicitly distinguishes itself from the sibling create_byo_voice, which handles ElevenLabs clones from video speech. An agent can route between the two without opening 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?

It states the prerequisite (explicit ownership/permission confirmation), names the helper tool to obtain the consent wording (get_voice_consent_script), and gives an explicit alternative with its condition (create_byo_voice with clip_reference=true for saved ElevenLabs clones). When-to-use and when-not-to-use are both covered.

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 supplied, the description carries the full burden and does well: it discloses the consent-recording prerequisite, mandates explicit user confirmation of ownership ('never assume it'), and distinguishes local filesystem paths (stdio) from public HTTPS URLs (hosted). It does not cover failure modes, whether a clone can be undone, or cost implications, but the safety-critical behavior for a voice-cloning mutation is well surfaced.

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 organized by concern (cloning mode, consent, input sources, outputs). Nearly every sentence adds information, though the line-broken layout makes the provider branching slightly harder to scan than a single tight paragraph would.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter, unannotated creation tool, this is fairly complete: consent requirements, provider-specific prerequisites, accepted input sources, and next-step tools are all covered. An output schema exists so return values need no explanation, but the missing differentiation from `clone_voice` and the undocumented `name`/`language_code` leave small gaps.

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

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

Schema description coverage is 0%, so the description must compensate, and it explains the non-obvious parameters: `clip_reference`, `clip_ranges` as speech-only `{start_ms,end_ms}` ranges for individual speakers, `consent_path` as the consent recording, and `reference_path` as local path or public HTTPS URL. `name` and `language_code` are never mentioned, and `confirm_ownership`'s exact semantics are only implied by the confirmation sentence.

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 first line gives a specific verb and resource (create/save a reusable voice clone) plus scope (caller's workspace), which is far better than a tautology. However, the sibling tool `clone_voice` appears to overlap heavily and the description never states how `create_byo_voice` differs from it, so the agent must guess between two similar-sounding creation tools.

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 explicit conditional branching: set `clip_reference=true` for ElevenLabs cloning from audio/video, otherwise Google cloning requires `consent_path`. It also names downstream consumers (`preview_voice`, `synthesize_audio`, `list_voices`), which helps the agent place this step in a workflow. It stops short of saying when to prefer `create_byo_voice` over the sibling `clone_voice`, and gives no exclusions.

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

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

No annotations are provided, so the description carries the full burden; it does disclose that the guide is persisted ('save'), scoped to the workspace, and applied to subsequent translation calls, which is real behavioral context. It omits what happens on duplicate titles, whether creation requires permissions, and whether the new guide is active immediately.

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 no filler or redundancy. It is clean, though for a mutating tool with three undocumented parameters it is arguably under-sized rather than well-proportioned.

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?

An output schema exists, so return values need not be explained, but for a create/mutation tool with zero annotation coverage and 0% schema description coverage the definition leaves too much unspecified. Content format, enabled-by-default behavior, and duplicate handling are all gaps an agent must guess at.

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 all three parameters (title, content, is_enabled) rely on the description, which says nothing about them. In particular the expected format and structure of 'content' and the meaning of the is_enabled default are undocumented, which matters for a style guide that drives future translations.

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 and save a workspace style guide') plus its downstream effect ('used by future translations'), which is clear enough to distinguish it from read-side siblings like get_style_guides or list_style_guides. It does not, however, differentiate itself from write-side siblings such as upload_style_guide, update_style_guide, or update_language_custom_style.

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 sentence describes the effect of the tool but gives no when-to-use trigger, no prerequisites, and no named alternative. An agent cannot tell from this text when to create a guide from scratch versus uploading an existing one or updating an existing guide.

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 and idempotentHint=true, so the safety profile is covered structurally. The description's added value is the ownership constraint ('belonging to the caller'), which hints at a failure mode when the voice is not owned, but it says nothing about irreversibility, impact on existing audio using that voice, or error behavior.

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

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

One short sentence with the action and scope front-loaded and no filler. The trailing clause 'when explicitly requested' is a bit soft for a destructive operation but still carries usage intent rather than being wasted words.

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?

An output schema exists, so return values need no explanation, and the tool surface is small (one required string). However, for an irreversible destructive operation the description stops short of covering the ownership precondition, confirmation expectation, and consequence of deletion, which are the details an agent most needs here.

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 voice_id has 0% schema description coverage, so the description carries full burden but never mentions the parameter at all. It does not say where a voice_id comes from (e.g., list_voices) or what format it takes, leaving the only required argument undocumented in both structured and prose form.

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 ('Delete a saved cloned voice') and scopes it to the caller's own voices. It is clearly distinct from the other destructive siblings (delete_style_guide, delete_subtitle, delete_translation_memory_entry) which operate on different resources, though it does not explicitly name them.

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?

'When explicitly requested' is a light usage signal implying this should not be called speculatively, and 'belonging to the caller' implies an ownership precondition. There is no explicit when-not guidance, no mention of alternatives such as list_voices to find the right voice_id, and no stated prerequisite for confirming intent with the user.

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 and idempotentHint=true, so the safety profile is covered. The description adds the cautionary "when explicitly requested" constraint, consistent with destructiveness, but says nothing about permanence, whether deletion is recoverable, or what happens to guides still in use — all behavior beyond the 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?

One short sentence, front-loaded with the action and resource. Nothing is padding, though the trailing qualifier is compressed to the point of being slightly terse.

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?

An output schema exists, so return-value explanation is not required, and the annotations cover idempotency and destructiveness. What remains missing is how to obtain a valid guide_id and any indication of irreversibility, which matter for a destructive one-argument 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?

There is one required parameter, guide_id, with 0% schema description coverage, so the schema conveys only type string. The description does not say where guide_id comes from (list_style_guides / get_style_guides) or what format it takes, leaving the caller to infer everything about the single input.

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 (Delete) and resource (a workspace style guide), which cleanly separates it from create_style_guide, update_style_guide, get_style_guides, and list_style_guides. It does not explicitly name a sibling it might be confused with, but the verb-resource pairing 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?

"When explicitly requested" is a real usage gate implying the agent should not delete proactively, which is useful context. However, it names no alternative (e.g., use update_style_guide to modify instead of removing, or get_style_guides to confirm the target) and gives no prerequisites or recovery 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 destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds two pieces of context beyond that: the deletion is scoped to the caller's own subtitles (an authorization boundary) and should only happen on explicit request. It doesn't state permanence or recovery options, but that is largely implied by destructiveHint.

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 no filler; the verb and resource come first and the conditional guard follows. 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?

An output schema exists, so return values need no explanation, and annotations cover the destructive/idempotent profile. However, for a destructive single-parameter tool the description leaves the key input (storage_path) and the permanence of deletion unaddressed, which is a meaningful gap.

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 required parameter, storage_path, with 0% schema description coverage, and the description says nothing about it — not its format, where it comes from, or whether it is the same path returned by list_subtitles. With the schema silent, the description needed to compensate and does not.

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

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

States a specific verb and resource ('Delete a saved subtitle') plus an ownership scope ('belonging to the caller'), which cleanly separates it from the sibling delete_* tools that target voices, style guides, and translation memory entries. It stops short of naming an alternative, but the resource is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The clause 'when explicitly requested' gives a real usage guard — the agent should not delete proactively — but no alternatives or preconditions are named, and it doesn't say what to do if the caller is unsure which subtitle to remove.

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 and idempotentHint=true, so the irreversibility and repeat-safety profile is covered structurally. The description adds a cautionary usage clause but says nothing about permissions, whether deleted entries are recoverable, or how upstream entries are affected.

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 with the resource and the caution clause front-loaded; nothing is redundant. It is arguably too terse given the gaps elsewhere, but there is no wasted wording.

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?

An output schema exists, so return values need not be described. For a destructive single-parameter tool, though, the definition leaves the agent without guidance on sourcing entry_id or confirming what deletion entails, which is a meaningful gap.

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% — entry_id has no description — and the description adds no meaning about its format or where the value comes from (presumably from list_translation_memory_entries or search_translation_memory). 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?

The description states a specific verb and resource ("Delete a translation memory entry"), which is unambiguous and clearly distinct from siblings like update_translation_memory_entry or list_translation_memory_entries. It does not explicitly name those siblings, 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?

"When explicitly requested" gives a real invocation constraint, implying the agent should not delete speculatively. However, it offers no alternatives (e.g., pointing to update_translation_memory_entry or search_translation_memory for verification before deleting) and no prerequisites such as locating the entry_id first.

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

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

With no annotations, the description must carry the full behavioral burden, and it does disclose the key traits: format is retained unless qc=true, and regenerate applies saved QC edits before export. It omits whether the export writes to output_path overwriting existing files, whether it requires permissions, and whether regenerate has side effects on stored state.

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 core output behavior is front-loaded in the first sentence, and subsequent sentences are tight flag guidance with no filler. Slightly choppy fragmentation but no wasted content.

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?

The output schema covers return values, so the description needn't explain them, and the format/qc/regenerate behavior is covered. For a no-annotation tool with five parameters, the unexplained required storage_path and source_language leave a meaningful completeness gap.

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 explain all five parameters; it explains qc, regenerate, and the extension convention for output_path. It says nothing about storage_path (a required parameter) or source_language, so two of five parameters, including one that is mandatory, remain opaque.

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 ('Export a saved subtitle or its QC workbook') plus the return form ('file/download URL'), so the agent knows exactly what happens. It does not name or contrast with the closest sibling, get_subtitle_download_url, leaving the agent to infer which one to call.

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 real conditional guidance for two flags: 'Set qc=true for the review XLSX' and 'regenerate=true applies saved QC edits first.' However, it never says when to prefer this over get_subtitle_download_url or how it relates to get_subtitle_review/update_subtitle_review, so the when-vs-alternative question is unanswered.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose the accepted formats (PNG, JPEG, WebP) and the hosting constraint (public HTTPS URL vs local path under stdio), but says nothing about size limits, failure modes, or whether extraction is read-only and side-effect free.

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 purpose sentence, then the pipeline guidance, then the argument note, with no filler. The Args block is mildly verbose relative to a single parameter but still earns its place by adding format and transport detail.

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?

An output schema exists, so return-value explanation is unnecessary, and the description covers purpose, pipeline position, and input format. Only the absence of any failure-mode or limit note keeps it from being fully complete for a no-annotation 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 description coverage is 0% and image_path is bare in the schema, so the description must compensate, and it does: it explains that the argument is either a public HTTPS URL (hosted) or a local path (stdio) to a PNG/JPEG/WebP file. The hosting-mode distinction is meaning the schema does not convey.

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 ('Extract text segments from an image') plus the ordering guarantee ('in reading order (OCR)'). This clearly separates it from siblings like localize_image and translate, which are transformations rather than extraction.

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 the tool as the first step of an image localization pipeline and names the exact sequence: extract, then translate, then re-render with localize_image. When-to-use and which siblings to follow with are both stated, leaving nothing 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?

No annotations are supplied, so the description carries the full burden. It does disclose the key behavioral trait that outputs may not cover the whole input, and that duration_ms and transcript boundaries should be respected - valuable context about silent truncation. It does not state whether the call is side-effect free, whether limits are per-account or per-key, or caching behavior.

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

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

Three short lines, front-loaded with the purpose before the caution. The second and third sentences both address the same concern (incomplete processing of long inputs), so there is minor overlap, but no wasted framing or 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?

An output schema exists, so return values need not be explained, and with no parameters there is little surface to cover. The description supplies purpose, call timing, and the one trap an agent could fall into (assuming full transcription). Only a note on limit scope or failure modes 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 description has nothing to disambiguate and the baseline is 4. The schema is empty and fully described; no parameter meaning is lost.

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: retrieve the caller's audio/video duration limits and long-form eligibility. This is clearly distinguishable from the transcription, synthesis and translation siblings. 'Capabilities' is a slightly broad container term, but the sentence immediately qualifies it with concrete contents.

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 timing guidance: 'Check before transcription', and a precondition-style warning not to assume a long input was processed fully. It does not name a specific alternative tool to call instead, but the usage context is unambiguous for the pre-transcription step.

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

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

No annotations are provided, so the description carries the full burden. The verb 'Get' plus the presence of an output schema makes the read-only nature reasonably apparent, and the description adds useful context about the prompt's contents, but it says nothing about permissions, fallback behavior when no brand voice is configured, or whether the value is customizable.

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 definition in the first line, and the total length is short. The second and third sentences overlap somewhat ('master prompt that shapes all translations' vs. 'captures the brand's tone, personality, terminology'), which is a minor redundancy but still earns its place by describing the return 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?

For a no-parameter getter with an output schema, the description supplies enough context about what the returned prompt represents and what it contains. The only meaningful gap is lack of differentiation from sibling prompt/voice tools, which belongs more to usage guidance.

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 to disambiguate. Baseline 4 applies; the description correctly implies a no-argument retrieval rather than suggesting any scoping inputs.

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 the brand voice prompt') and explains what the resource is ('companies' master prompt that shapes all translations'). It is clear what is returned, but it does not distinguish itself from nearby siblings such as get_combined_prompt or get_style_guides, which also retrieve prompt-like content.

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 only implied: the phrase 'shapes all translations' hints that this is fetched before localizing, but there is no explicit when-to-use or when-not-to-use statement, and no alternative tool is named for related prompt/voice retrieval needs.

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

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

No annotations are supplied, so the description carries the full burden. "Get" implies a read-only, side-effect-free operation, but the description does not state what "enabled" means, how many style guides are merged or in what order, or how conflicts between the brand prompt and style guides are resolved. Output schema exists, so return shape does not need to be described here.

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 no filler, so every word earns its place. It is, however, terse to the point of omitting the merge semantics that would make the definition self-sufficient.

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 parameters, an output schema, and a simple read shape, the description is nearly sufficient. The remaining gap is behavioral: it never explains how the combination is composed or what "enabled" implies, which an agent would need in order to trust the result.

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

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

The tool takes zero parameters, which is the baseline-4 case. Nothing in the schema needs compensating for, and the description correctly implies the workspace context is implicit rather than passed in.

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?

"Get the workspace brand prompt combined with its enabled style guides" names a specific verb (get) and a specific composite resource (brand prompt + enabled style guides). This implicitly separates it from siblings like get_brand_voice, get_style_guides, and list_style_guides because it returns a merged artifact rather than the individual pieces, though it never says so 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?

The word "combined" hints that this is the tool to use when one assembled prompt is wanted rather than the raw brand voice or style guide list. However, no when-to-use or when-not-to-use guidance is given, and none of the obvious alternatives (get_brand_voice, get_style_guides, list_style_guides) are named as fallbacks.

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

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

No annotations are supplied, so the description carries the full burden; 'List' implies a safe read, and 'workspace' implies results are scoped to the current workspace configuration. It does not state whether the levels are static or workspace-customizable, nor whether any permission is required, but for a zero-parameter read this is a modest gap.

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

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

A single front-loaded sentence with no wasted words. It is terse to the point of omitting routing hints, but every word 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?

With zero parameters and an output schema present, return-value explanation is unnecessary, and the description covers the core semantics. Only the relationship to update_language_formality and list_language_settings 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, which sets the baseline at 4; there is no parameter meaning the description needs to compensate for. The description correctly implies no filtering input is required.

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 ('List') and a specific resource ('supported workspace language formality levels'), so the agent knows exactly what comes back. It does not, however, explicitly distinguish itself from nearby siblings such as list_language_settings or update_language_formality.

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 only implied: an agent can infer this is the discovery call that precedes update_language_formality, but the description never says so or names alternatives. No when-not-to-use guidance is given, which is a clear gap for a lookup tool with many siblings.

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 supplied, the description carries the full burden of behavioral disclosure. It implies a safe read via "Get" and states the shape of each record, but says nothing about authorization, workspace scoping behavior, ordering, page size, or whether the result can be empty for an unconfigured workspace.

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 no filler; the subject of the operation is front-loaded and the return contents follow immediately. Nothing is repeated or 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 zero-parameter read with an output schema present, the description covers purpose and return contents adequately, so return-value detail is not required. The one real gap is the absence of any pointer distinguishing it from the closely named list/get siblings.

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 and the baseline of 4 applies. The per-language field list (names, codes, formality settings, custom style directives) reinforces what the caller receives without conflicting with 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?

"Get all languages configured for the Nativ workspace" is a concrete verb+resource with clear scope, and the second sentence enumerates what each record contains. It stops short of differentiating from the nearby siblings list_language_settings and get_language_formality_options, which read as overlapping.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to call this versus list_language_settings or get_language_formality_options, and no stated prerequisites or exclusions. The agent must infer selection purely from tool names.

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

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

No annotations are supplied, so the description carries the full behavioral burden; it does convey that this is a workspace-scoped read by disclosing the returned fields (titles, content, enabled status). It says nothing about permissions, whether disabled guides are included, or result size, which leaves meaningful gaps for a no-annotation tool.

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

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

Two short sentences, front-loaded with the operation and followed by the return fields; nothing is padded. Minor redundancy between 'style guides' in line one and 'each style guide' in line two, but it costs little.

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?

The tool is a simple read with no parameters and an output schema, so the description plus structured data is nearly sufficient. The one real omission is disambiguation from list_style_guides, which matters given the near-duplicate sibling name.

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 and the schema is an empty object, so there is no parameter meaning to add. Baseline for a zero-parameter 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?

States a specific verb and resource ('Get all style guides configured for the workspace') and names the fields returned, so the operation is unambiguous. However, it never distinguishes itself from the sibling list_style_guides, which an agent could easily mistake for the same 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?

No when-to-use or when-not-to-use guidance is given. With siblings get_style_guides vs list_style_guides both present, the description should say why one is chosen over the other, and it does not.

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

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

With no annotations, the description carries the full behavioral burden. 'Expiring' usefully discloses that the URL is time-limited, but it omits the TTL, whether access is signed or authenticated, and whether the URL can be reused — all material for a download-link 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?

A single front-loaded sentence with no filler or redundancy. It is efficient, though its brevity is partially the source of the missing parameter and usage detail.

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?

The output schema covers return values, so the description needn't explain them, and a one-parameter tool is simple. Still, the single required parameter is undocumented and there is no guidance on URL lifetime or prerequisite state, leaving an agent guessing about how to obtain a valid input.

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, yet it only restates 'storage_path' with no format, example, or pointer to the tool that produces it. An agent cannot tell whether it needs an absolute path, a bucket key, or an ID returned by list_subtitles.

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 ('expiring download URL') scoped to a saved subtitle's storage path. It implicitly distinguishes itself from export_subtitle and delete_subtitle by framing the result as a temporary URL, 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?

The word 'saved' weakly implies the subtitle must already exist, but there is no explicit when-to-use guidance, no statement of when to prefer export_subtitle instead, and no mention of where the required storage_path should come from (e.g., list_subtitles).

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only implies read-only via the verb 'Get'. It says nothing about whether the path must exist, what happens on a missing file, permission requirements, or whether the returned translations are raw versus approved — even though 'approval status' hints at state, the semantics of that state are unexplained.

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 front-loaded sentence with no filler, and the key payload fields are listed in a scannable series. The terseness is only a problem because it leaves required information out, not because the text is bloated.

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?

The presence of an output schema covers what is returned, and the tool is simple with one required parameter, so the description is close to sufficient for invocation. The critical gap is storage_path, whose format is documented nowhere in the description or 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?

The single parameter storage_path has 0% schema description coverage, so the description needed to compensate and does not mention it at all. The agent is left to guess what form of path is expected (local, bucket key, review artifact id) and whether it points to a file or a directory.

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 gives a specific verb ('Get') and enumerates the resource contents (QC rows, translations, rationales, approval status), so an agent knows this reads saved subtitle review data. It does not explicitly contrast with the sibling update_subtitle_review, 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?

There is no statement of when to use this tool, no mention of a prerequisite review having been created, and no routing to alternatives such as update_subtitle_review (for writes) or list_subtitles (for enumeration). The agent must infer that this is the read counterpart to the update tool.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the shape of the returned metrics and 'Get' implies a non-mutating read, but it says nothing about permissions, whether the stats are scoped globally or per workspace/language, or how costly the call is.

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

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

Two short sentences, front-loaded with the purpose and followed by the return contents. No filler, though the enumerated metrics partially duplicate what the output schema likely covers.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only tool with an output schema that documents return values, the description covers everything an agent needs to select and invoke it. The only shortfall is absent guidance on scope and when to prefer this over the listing/search siblings.

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 of 4 applies. No parameter-level meaning is missing.

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 uses a specific verb and resource ('Get statistics about the translation memory') and enumerates the metrics returned: total entries, enabled/disabled counts, and breakdown by source type. That clearly distinguishes it from siblings like list_translation_memory_entries and search_translation_memory, though it does not name them 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?

Usage is implied rather than stated: an agent can infer this is the aggregate-summary tool versus the entry-listing and search siblings. There is no explicit 'use this when...' or exclusion guidance, and no mention of prerequisites such as whether a translation memory must exist first.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only says 'Get' (implying a read-only operation) but does not explicitly state side effects, authorization needs, rate limits, or what the script looks like. For a tool with zero annotation coverage, this is a significant gap in transparency.

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 a single, front-loaded sentence with no filler words. It is concise and easily parsed, but it is also so brief that it skips important details. The conciseness is good, but the structure could have included more useful information without losing clarity.

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?

This is a simple tool with one optional parameter and an output schema (not shown), so the description need not explain return values. However, it leaves gaps: it does not explain how the language_code parameter affects the script, nor does it provide any context on the content of the consent script. It is minimally adequate but incomplete for full agent understanding.

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 has one parameter (language_code) with a default value but no description, and schema description coverage is 0%. The description does not mention the parameter at all, so it adds no meaning beyond the bare name. With no coverage and no description, the agent receives no guidance on how to use the parameter, making this a serious deficiency.

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 ('Get'), a specific resource ('spoken consent script'), and its purpose ('required for voice cloning'). This clearly distinguishes it from sibling tools like list_voices or synthesize_audio, which perform different actions. The purpose is unambiguous and actionable.

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 'required for voice cloning' implies when this tool should be used, but it does not explicitly state any alternative tools or situations where it should not be used. There is no mention of prerequisites, ordering, or context relative to other voice-related tools. The usage is implied but not fully articulated.

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, so the safety profile is covered; the description adds real behavioral value by saying the payload is complete and ID-bearing, making it the prerequisite step for the two update tools. It stops short of stating any auth or pagination behavior, which keeps it from 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?

The purpose statement is front-loaded in the first sentence and the follow-on sentences each do concrete work (routing to the update tools, offering the compact alternative). Slightly verbose framing but no wasted content.

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-argument read tool with an output schema already present, the description covers the one thing the schema cannot: that the IDs are meant to feed update_language_formality and update_language_custom_style. Nothing an agent needs to invoke it 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 no input parameters, which is the baseline-4 case; the only parameter-like concept, mapping_id, is an output field and is explained in terms of where to pass it, which adds useful meaning but is not a request 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 names a specific verb and resource ('Get complete workspace language settings') and pins down the distinguishing content ('including IDs for updates'), which separates it from the sibling get_languages without any schema lookups needed.

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 names two downstream tools that consume the returned ids as mapping_id and names the alternative (get_languages) for the human-readable use case, so the when-to-use decision is fully specified.

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?

The readOnlyHint=true annotation covers the safety profile and the description is consistent with it. Beyond that, the description adds real behavioral context: this returns full content rather than the compact summary, and the fields returned (IDs, enabled state, ordering) are what downstream mutation tools consume. Pagination and size characteristics are not mentioned, keeping it shy 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?

The key information — full listing plus the update/delete/reorder use cases — is front-loaded in two short sentences. The clause 'The compact get_style_guides summary is unchanged' is slightly awkward and reads like release-note residue, though it does serve the differentiation purpose.

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 an output schema present, return-value details need not be explained, and annotations cover read safety. The description supplies the differentiation and downstream-purpose information an agent needs to pick this over get_style_guides, leaving only minor gaps such as result-size expectations.

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 no-param tool applies. The description correctly focuses on what comes back rather than inventing parameter guidance.

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 uses a specific verb ('Get') plus an enumerated resource set — full style-guide content, IDs, enabled state, ordering — and explicitly contrasts itself with the compact get_style_guides sibling. An agent can distinguish it from that sibling without opening 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?

It names the concrete follow-up actions that select this tool ('obtain guide_id for update/delete, or IDs for reorder') and identifies the alternative it is not (the compact get_style_guides summary). Both when-to-use and the sibling routing are 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?

No annotations are supplied, so the description carries the burden. It does add scoping context by saying the results are 'the caller's' saved assets, which implies a read-only, account-scoped operation, but it says nothing about pagination, result limits, or ordering. Return structure is partially covered by the existing output schema.

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 first and the enumerated resources immediately after. Every word carries information and there is 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?

For a no-parameter read tool with an output schema, this is nearly complete: the agent knows what categories of assets come back without needing return-value detail. The only meaningful gap is the absence of any hint about how the listed sources feed into sibling tools like localize_subtitles or export_subtitle.

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 no parameter semantics to explain and the baseline of 4 applies. The description correctly spends no words re-describing an empty input 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 ('List') and names three concrete resources it returns: 'saved subtitle sources, localized files, and storage paths'. It is clearly a subtitle-domain enumeration tool, though it doesn't distinguish itself explicitly from neighbors such as parse_subtitle or get_subtitle_download_url.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not-to-use guidance and no mention of alternatives. An agent must infer that this is a discovery step before localize_subtitles, export_subtitle, or delete_subtitle, and that inference is left entirely unstated.

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

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

No annotations are supplied, so the description carries the full behavioral burden, yet it says nothing about default ordering, whether disabled entries are included by default, permission requirements, or result-size limits. Only pagination is acknowledged, and that is already evident from the limit/offset parameters.

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 with the core action front-loaded and no filler. Nothing extraneous is present, though the sparseness is a coverage problem rather than a wording problem.

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 seven-parameter tool with zero schema documentation and no annotations, this description is too thin; it never explains how the filters combine or what the default listing includes. The presence of an output schema excuses it from describing return values, but not from explaining inputs.

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 seven parameters, and the description does not explain any of them. The filters that most affect results (search, enabled_only, information_source, source/target language codes) get no semantics at all beyond their bare titles.

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?

Names a specific verb and resource (list and paginate translation memory entries) and adds a concrete downstream benefit ('including IDs for editing'). It does not, however, distinguish itself from the sibling search_translation_memory, so an agent must still infer which listing route applies.

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 only implied: 'including IDs for editing' suggests a fetch-then-update workflow with update_translation_memory_entry. There is no explicit statement of when to prefer this over search_translation_memory or get_translation_memory_stats, and no exclusions or prerequisites.

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

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

No annotations are supplied, so the description carries the full behavioral burden, and it only implicitly signals a safe read via "List". It does not state whether all voices are returned when the filter is omitted, whether results are paginated, or whether voices are engine/region-scoped, though the presence of an output schema offsets part of the gap in return-value 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?

The purpose line is one sentence and front-loaded, with the parameter note following in a compact Args block. Minor waste in docstring scaffolding rather than user-facing content, but no padding of substance.

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 single-optional-parameter read tool with an output schema covering return values, the description supplies purpose, scope, and the one filter format an agent needs. Nothing required to call it 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?

Schema coverage is 0% and the parameter is documented only as a bare string titled "Language Code". The description adds real meaning by marking it optional as a filter and giving concrete format examples ("fr", "ja-JP"), which is exactly the disambiguation the schema lacks.

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 TTS voices") scoped to dubbing, which separates it from mutation siblings like clone_voice or delete_saved_voice. It doesn't explicitly name a sibling alternative, so it stays at 4 rather than 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance and no mention of alternatives such as get_audio_capabilities or preview_voice. The phrase "for dubbing" hints at context but never tells the agent when this tool is the right choice over its siblings.

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 well: it discloses that only text is rewritten while layout/colours/graphics are preserved, that output goes to disk with a returned path (not raw bytes), and that hosted mode returns a download URL instead. It does not say what happens when an 'original' string is not found on the image, or whether the default output path can overwrite an existing file.

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?

Purpose and behavior are front-loaded in the first two sentences, with the parameter detail relegated to a conventional Args block. The Args formatting repeats parameter names but every line adds semantics not present in the schema, so little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter mutation tool with no annotations, the description covers mode-dependent input handling, output destination, variant counts, format, and the pipeline context. An output schema exists, yet the return-path-vs-download-URL note is still useful and nothing needed to call it 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?

Schema coverage is 0%, so the description must compensate and it does fully: image_path explains the HTTPS-vs-local-path distinction by mode, replacements gives the exact JSON shape with an example, output_path documents the default naming pattern, num_images gives the 1-5 range and default, and output_format lists the three accepted values.

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 ('Localize an image in place by replacing its on-image text with translations') plus the key constraint that non-text elements are preserved. This clearly separates it from extract_image_text (which pulls strings out) and translate (which produces text only).

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 names the companion tools and the order of the flow ('Pair with extract_image_text ... and translate ... for a full image localization flow'), so the agent knows where this sits in a pipeline. It stops short of stating when-not to use it, e.g. an image with no extractable text.

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 two non-obvious traits: the call is billed and the backend expects query parameters for this route. However, it says nothing about whether the operation is synchronous, whether it overwrites or creates a new subtitle, failure behavior for an invalid storage_path, or any permission requirements.

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, then the SRT redirect — no filler. The line about the backend expecting query parameters is an internal implementation note that adds little for an agent and is the one sentence that does not fully earn 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?

An output schema exists, so return values needn't be explained, and the critical routing and billing facts are present for a billed write-style tool. The remaining gap is that the non-required parameters (context, glossary) and the language-code convention are left entirely to an undocumented 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 description coverage is 0% across four parameters, and the description only clarifies storage_path (its provenance and that a local path or URL is invalid). target_languages (language code format?), context, and glossary (what format a glossary string takes) get no explanation anywhere, leaving three of four parameters undocumented.

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: localize an *already saved ITT subtitle file* via its storage path. It also names the sibling path for the SRT case (upload_subtitle(auto_localize=true) or localize_subtitles), so an agent can tell this apart from the other localization tools 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?

Gives explicit routing: use this only for files already in storage, source storage_path from upload_subtitle/list_subtitles, and do not pass a local path or HTTPS URL. It also names the alternatives for SRT, which is exactly the when-not/alternative guidance an agent needs.

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

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

With no annotations, the description carries the full burden and does add real value: it discloses mode-dependent behavior ('Hosted mode always returns subtitle download URLs', output_dir only applies to stdio). It omits cost, rate limits, failure behavior, and whether localization is destructive or repeatable.

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 leading sentence front-loads the core action, and the Args block is scannable with no filler. The raw docstring formatting (indentation, trailing blank line) is slightly untidy but costs nothing in comprehension.

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 an 8-parameter tool with no annotations, the description covers inputs and the hosted/stdio output split, and an output schema exists so return values need no explanation. It still leaves open whether subtitle_path or video_path is mandatory and what happens if neither is supplied.

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 documents all eight parameters including the hosted-URL vs local-path split per path argument and a concrete example format for target_language_codes. Weak spots remain: 'context' and 'formality' are described only tautologically, with no expected values or format.

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 ('Localize subtitles in-memory') and clarifies the accepted input types (SRT/ITT file and/or video via STT). The 'in-memory' qualifier implicitly distinguishes it from localize_subtitle_file, but no sibling is named explicitly, 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?

There is no guidance on when to pick this over localize_subtitle_file, translate, translate_dialogue, or upload_subtitle, nor any stated prerequisites. Only a weak implication ('and/or a video (STT)') hints at input-mode selection, leaving the agent to guess.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses one useful behavior: it parses files rather than doing STT. However, it does not mention whether the operation is read-only, what errors can occur, or how the output is structured, though the presence of an output schema reduces the need to describe return values.

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 a single sentence with no filler. It front-loads the core action, then lists the supported formats and the key alternative, making it immediately scannable for an AI agent.

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 tool with an output schema, the description covers the essential purpose and accepted input formats. It leaves some gaps, such as what happens with unsupported files and any side effects, but the simplicity of the tool and the existing output schema keep it reasonably complete.

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

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

The schema has only a bare 'file_path' property with 0% description coverage, so the description must compensate. It partially does by indicating the accepted file extensions and the general purpose of the file. However, it does not explicitly state that 'file_path' must point to a file with one of these formats or describe any constraints such as file size or encoding.

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 ('parse') and resource ('a script file'), and lists the supported formats. It also distances itself from STT, which helps distinguish it from transcription tools. However, it does not clearly differentiate itself from the sibling 'parse_subtitle', especially since .srt and .itt are subtitle formats.

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 'instead of STT' explicitly signals when to use this tool: when a script file is available rather than performing speech-to-text. It implies the alternative of transcription, but it does not spell out when not to use the tool or how it relates to sibling 'parse_subtitle'.

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

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

No annotations are provided, so the description carries the full burden; it discloses the important non-persisting behavior ('no storage'), which is genuinely useful. However it says nothing about failure modes such as malformed subtitle files, encoding issues, or size limits, and return shape is handled by the output schema.

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 front-loaded sentence with zero filler; the most distinguishing detail ('no storage') is placed where it is read first.

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?

An output schema exists, so return values need not be explained, and the non-storage behavior is covered. What is missing for this simple tool is the meaning of file_path and any handling expectations for malformed input, leaving an agent to guess at a required argument.

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 file_path has 0% schema description coverage and the description adds no meaning: it does not clarify whether the path is a local filesystem path, a previously uploaded server-side asset, or a URL. With only one parameter the exposure is limited, but the key ambiguity is left entirely unaddressed.

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

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

States a specific verb (parse), the accepted formats (SRT/ITT), and the output (timed cues), plus a scope qualifier '(no storage)' that implicitly separates it from storage-oriented siblings like upload_subtitle. It stops short of naming a sibling explicitly, so it is clear but not fully differentiated.

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?

'(no storage)' implies this is the read-only/non-persisting path versus upload_subtitle or delete_subtitle, but the description never says when to choose this over those alternatives or what preconditions must hold (e.g. whether the file must already be uploaded).

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 the important behavioral split: hosted mode returns a download URL while stdio writes to a WAV path. It omits permissions, cost/latency implications of TTS generation, and whether previews are cached or overwrite existing files at output_path.

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 behavioral summary is front-loaded in two short sentences, followed by a scannable Args block with no filler. The docstring-style indentation is slightly verbose but each line adds parameter meaning rather than repeating 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?

An output schema exists, so the description rightly avoids detailing return values while still flagging the download URL case. For a 4-parameter generation tool with no annotations, the main remaining gap is routing guidance versus the synthesize_audio siblings and any file-overwrite behavior.

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 description compensates well: it ties voice_id to list_voices, explains that output_path is a filename hint in hosted mode but a real WAV path in stdio, and bounds text at 200 characters. Only language_code ('Optional locale') remains thin relative to what an agent might need, such as format or fallback behavior.

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 ('Generate a short TTS preview') plus the mode-dependent return ('Hosted mode returns a download URL'). It does not explicitly distinguish itself from sibling synthesize_audio / synthesize_audio_advanced, so an agent must infer that 'preview' is the short, throwaway variant.

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?

No when-to-use or when-not-to-use guidance is given; the description never says to prefer this over synthesize_audio for short samples or the reverse. The max-200-chars note on text implies a lightweight use case, but that is inference rather than stated guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions the return value (video_id) and does not cover side effects, error conditions, authentication requirements, or file constraints. This is minimal for a tool that likely stores a file.

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 a single, efficient sentence that front-loads the action and purpose. It contains no unnecessary words or redundant details.

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 one simple parameter and an output schema (presumably documenting the return), the description covers the basic action. However, it lacks usage guidelines and behavioral details, which are important for an agent to call it correctly, especially without annotations.

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 should compensate for the undocumented file_path parameter. It only implies that file_path is the path to the source video, adding no information about format, size limits, or other requirements.

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 states the verb 'upload' and the resource 'source video', and specifies its purpose 'for later remuxing', which distinguishes it from the sibling remux_video. It does not explicitly name alternatives but the intent is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage in a remuxing workflow but provides no explicit when-to-use or when-not-to-use guidance. There are no alternatives mentioned or conditions under which this tool should be preferred over others.

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

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

With no annotations, the description carries the full burden. It usefully discloses that the target video must already be registered and that output_path behaves differently in hosted vs stdio transports, but it says nothing about whether the source video is mutated or a new artifact is produced, whether existing output is overwritten, or what errors occur if the audio is not WAV.

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 core purpose is front-loaded in one sentence, followed by a compact Args block that adds real semantics rather than restating types. The Args block repeats parameter names already in the schema, but each line earns its place by adding transport-dependent meaning.

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?

An output schema exists, so return values need no explanation, and the three parameters are all documented. What is missing for a media-mutating tool with zero annotations is side-effect disclosure: whether the registered video is modified in place, whether output_path overwrites an existing file, and what happens on transport mismatch.

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 supply all parameter meaning, and it does: video_id's provenance, audio_path's dual URL/path semantics by transport, and output_path's differing role as a filename hint vs an MP4 path. The only gap is that output_path's default value and the WAV-only constraint are not restated.

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?

"Mux a WAV file onto a previously registered video" names a specific operation (muxing audio onto an existing video) and its input resource, which clearly separates it from siblings like register_video or synthesize_audio. It stops short of explicitly naming an alternative, but the verb+resource pair is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the prerequisite that video_id must come from register_video or transcribe_audio, which is genuinely useful ordering guidance. However, it never states when to choose this tool over alternatives, what to do if the video was not registered, or any exclusion 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?

No annotations are supplied, so the description carries the full behavioral burden, and it does not say whether the supplied list replaces the entire ordering, what happens to guides omitted from guide_ids, or whether the operation is workspace-scoped. Only the vague word "Save" signals mutation, with no disclosure of reversibility or permissions.

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 front-loaded sentence with zero filler; the action, the resource, and the ID source all appear immediately. 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?

An output schema exists, so return values need not be explained, and a single-parameter tool keeps the surface small. Still, for a reordering mutation with no annotations, the omission of full-replacement semantics and omission behavior leaves a real gap an agent would need to guess at.

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 clarifies that guide_ids values come from list_style_guides, which is genuinely additive. However, it never states the crucial semantic that array position defines the new order, nor whether the list must be exhaustive.

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 and resource ("Save the order of workspace style guides") and points to the sibling list_style_guides as the ID source, which distinguishes it from update_style_guide. It stops short of stating whether this is a full reordering of all guides or a partial one.

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 tells the agent where to get valid IDs (list_style_guides), which is meaningful usage guidance for a mutation. It gives no guidance on when to call this versus update_style_guide or on any preconditions such as needing the complete set of guides.

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

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

No annotations are supplied, so the description carries the full burden. It does add real behavioral detail – fuzzy matching scored 0-100 and the important gotcha that min_score default 0 returns all results – but it never states that the operation is read-only, how results are ordered, or whether output is paginated.

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?

Purpose is front-loaded in one sentence, followed by usage and a compact Args block; no filler. The Args block repeats some defaults present in the schema, which is mild redundancy but aids usability at call time.

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 an output schema present, return values need not be described, and all five parameters are documented. What is missing is modest: result ordering/pagination and an explicit statement that this is a non-mutating lookup, which would matter more given the absence of annotations.

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 and largely does: it explains each of the five parameters, restates defaults (source 'en', limit 10, min_score 0), defines the score range and its default semantics. Only the exact matching behavior of 'query' (substring vs fuzzy) remains unspecified.

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?

Specific verb 'search' plus resource 'translation memory' with the object being searched (existing translations). It is clearly a query tool, though it never names the sibling it is distinct from, such as list_translation_memory_entries or get_translation_memory_stats, so the agent must infer the boundary between searching and listing.

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 two concrete situations to reach for this tool: checking for existing translations before creating new ones and finding reference translations for consistency. It stops short of naming an alternative tool or stating when not to use it (e.g. full listing or stats), so it is clear context without exclusions.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose an important boundary — that this does not write to translation memory, which is the main wrong-action risk — but it omits whether feedback overwrites prior feedback, whether it requires an existing translation/review object, and permission requirements. Useful but incomplete for a mutation tool with zero annotation coverage.

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 the core action front-loaded and the disambiguation second. The trailing line break/indentation is slightly awkward but nothing is redundant. Every sentence 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?

An output schema exists, so return values needn't be explained, but the tool has five undocumented all-optional parameters and no annotations, and the description addresses none of that. For a feedback-recording mutation where an agent must decide which fields to populate, the definition leaves the critical invocation detail 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% across five optional parameters (result, source, approved, feedback, language), and the description adds no meaning beyond the parameter names. It never explains what 'source' vs 'result' represent, whether approved and feedback are mutually exclusive, or what happens when all params are null. The names are partly self-evident, which keeps this above 1.

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 uses a specific verb and resource ('Save user feedback or an approval rating for a translation') and explicitly distinguishes itself from the sibling add_translation_memory_entry. It stops short of 5 because it doesn't fully position itself against the broader review/translation siblings (e.g. get_subtitle_review, update_subtitle_review) that an agent might confuse it with.

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 clear usage context: use this to record feedback/approval, and use add_translation_memory_entry instead when the goal is persisting an approved translation for future reuse. That is an explicit alternative with a selecting condition. No when-not-to-use or prerequisite conditions (e.g. required identifiers) are 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?

With zero annotations the description carries full behavioral burden; it does disclose two genuinely valuable traits — that generation is billed and that hosted mode returns download URLs while stdio writes to a path. However, it never explains how hosted vs stdio mode is selected (presumably via output_path), what happens on failure, timing/ordering constraints on segments, or cost magnitude, leaving major behavioral ground uncovered for a billed mutation.

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 purpose line is properly front-loaded, but the body is a raw Google-style Args block pasted into prose, with inconsistent trailing periods and a dangling closing quote. Given the 0% schema coverage the per-parameter list earns its place, though it should have been folded into the schema rather than the description.

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 12-parameter tool with no annotations, the definition covers the operational essentials: what it produces, what it costs, what it returns in hosted mode, and how every input parameter feeds the pipeline. The residual gap is sibling disambiguation (advanced variant) and mode-selection mechanics, which matters but is narrower than the parameter surface it already documents. An output schema exists, so return values need not be explained.

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 does: all twelve parameters get an explanatory line, including conditional relationships ('keep_background_music: mix transcribed music bed when stem_id is set', 'video_output_path: when video_id is set'). Gaps remain — no units or format for segments beyond the brace sketch, no valid range or default semantics for source_duration_ms — but this is well above baseline for a 12-parameter tool.

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: 'Generate billed localized TTS (and optional dubbed video)' plus the hosted-mode return behavior. It never distinguishes itself from the sibling `synthesize_audio_advanced`, so an agent cannot tell from the description which of the two to call.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance and no exclusion: the biggest ambiguity, plain vs `synthesize_audio_advanced`, is left entirely unaddressed. Usage is only implied indirectly by prerequisites ('voice_id from list_voices', 'stem_id from transcribe_audio'), which tell the agent what to obtain but not when this tool is the right 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?

With no annotations provided, the description carries the full burden of transparency. It discloses vital behavioral traits including the output modalities (local files/expiring download URLs) and the crucial constraint that there are 'no inline media blobs.' This is highly effective behavioral context.

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 dense and technical, which is appropriate for an advanced API tool. While slightly run-on, every piece of information provided is highly specific and essential for tool understanding, preventing wasted words.

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?

Given the high complexity (16 parameters) and the lack of annotations, the description covers the most critical, high-level operational constraints (billing, output format, and segment structure). It provides enough context to handle the complexity without being exhaustive on every single 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?

With 0% schema description coverage, the description is highly valuable. It provides essential context for the complex `segments` array (explaining its internal fields) and `speaker_voices` mapping, which are not detailed in the raw schema structure.

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 defines the tool's core function as multi-speaker audio/video synthesis. It differentiates itself by highlighting 'complete timing and review data,' suggesting a higher level of complexity compared to simpler synthesis tools like `synthesize_audio`.

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 provides important operational constraints, explicitly stating that it is a 'Billed operation.' This is a key piece of usage information that helps an agent determine when calling this tool is financially appropriate.

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

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

No annotations exist, so the description carries the full burden. It adds useful behavior beyond the schema: the operation is marked an 'unbilled draft', video inputs yield a video_id for later muxing, and `keep_background_music` splits a music bed for remix. It says nothing about permissions, size/duration limits, latency, or whether uploads are retained, which are notable gaps for an unannotated media-ingest 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?

Front-loaded with the purpose in the first clause, then pipeline guidance, then a compact Args block that exists to fill the zero-coverage schema. Every sentence carries usable information and nothing is 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?

An output schema exists, so return values need not be described, and the pipeline context covers the main follow-on steps. However, for a media-ingest tool with no annotations, the definition never states input constraints (file size, duration, supported codecs beyond extension examples) or how it differs from the 'detailed' sibling.

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, and it largely does: it explains that `file_path` is a public HTTPS URL in hosted mode or a local path in stdio mode, enumerates audio and video extensions, gives a language-hint example, and clarifies the effect of `keep_background_music`. Only the format/syntax of `source_language_code` (e.g. ISO codes beyond 'en') is left thin.

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 ('Transcribe speech from an audio or video file') and names the accepted media types. It does not differentiate itself from the sibling 'transcribe_audio_detailed', so an agent cannot tell from the description alone which transcription 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?

It gives explicit downstream usage: feed returned segments to `translate` and then `synthesize_audio` to produce a dubbed track, and notes that video uploads yield a video_id for muxing. It offers no when-not-to-use conditions or comparison against the 'detailed' variant, so a sibling disambiguation gap remains.

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

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

No annotations are supplied, so the description carries the full burden; it discloses the payload shape (segment IDs, speaker IDs, speech islands, processed duration, video_id, stem_id) and the two input transport modes (local path under stdio vs public HTTPS URL under hosted). It omits cost/rate-limit or failure behavior, and the phrase "Draft step" is unexplained, leaving some ambiguity about processing guarantees.

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 purpose and the sibling contrast, then transport, prerequisites, and parameter notes in descending priority. Slightly dense and the elliptical "Draft step" fragment costs a little clarity, but no sentence 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?

An output schema exists, so return-value explanation is optional and the extra segment-field detail is a bonus. However, for a 5-parameter, annotation-free mutation-ish processing tool, three parameters remain opaque and there is no note on expected latency or failure modes for long-form jobs.

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 explains file_path transport semantics and speaker_count's 0-for-auto / 1-8 range, but leaves enterprise_long_form, source_language_code, and keep_background_music entirely undocumented in both schema and description — three of five 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 ("Transcribe audio/video with complete timed segments and speaker metadata") and immediately distinguishes itself from the sibling compact tool: "Unlike the compact transcribe_audio display, returns all segments...". An agent can select between the two without opening 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 an explicit alternative (transcribe_audio for compact output), a use case ("multi-speaker dubbing or long transcripts"), and a prerequisite workflow step ("check get_audio_capabilities before requesting long-form processing"). This is close to ideal when/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?

With no annotations, the description carries the full disclosure burden and does substantial work: it states that the team's translation memory, style guides, and brand voice are applied automatically, and that the response includes the translation plus TM match info and rationale. It stops short of saying whether the call has any side effects on translation memory or what happens when no TM entry matches, but the behavioral picture is far richer than the structured data provides.

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 front-loaded with purpose and return behavior, then a well-ordered Args block that mirrors the parameter list; nothing is padded. The prose sentences are efficient, though the Args block is a docstring paste whose content partially duplicates the schema's own titles.

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 10-parameter translation tool, the definition covers purpose, engine behavior, return contents, and every argument, and an output schema exists so return formatting need not be spelled out. The remaining gaps are sibling routing and any statement about side effects or permissions, which are the pieces an agent would still have to guess.

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 entirely, and it does: all ten parameters are documented with meaning, defaults, examples, and accepted values. It even supplies the formality enumeration (very_informal through very_formal) and a CSV example for glossary, neither of which appears in the schema as an enum or format hint.

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 opening sentence gives a specific verb (Translate) and resource (text) and names the engine, so the agent knows exactly what the tool does. It does not differentiate against the obvious siblings translate_batch and translate_dialogue, so an agent cannot tell from the description alone which of the three to pick for multiple strings or dialogue.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit statement of when to use this tool versus translate_batch, translate_dialogue, or localize_subtitles, all of which appear in the sibling list and overlap heavily. The singular 'text' hints at a single-string scope, but the agent is left to infer that, and no prerequisites or exclusions are given.

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

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

With no annotations, the description carries the full burden and does real work: it discloses that the team's translation memory and style guides are applied, that a failed or incomplete batch surfaces as a tool error, and that the agent must not synthesize missing output. It leaves out operational limits such as maximum batch size or output ordering guarantees.

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, then usage, then parameters, with no filler sentences. The Args block partly duplicates schema titles, but that is justified given 0% schema description coverage.

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?

An output schema exists, so return-format explanation is unnecessary, and the description covers purpose, batching semantics, failure behavior, and all seven parameters. It falls short only on formality value vocabulary and any batch size ceiling for a tool that could be called with very large input.

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 Args block is the only parameter documentation and it does cover all seven parameters with defaults and an example value ('French'). However, several entries are near-tautological (context: 'Optional context to guide all translations', formality: 'Tone override for all translations') and give no valid values, even though a get_language_formality_options sibling exists that presumably defines them.

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 first line gives a specific verb and resource with scope: translate multiple texts into a single target language. The line 'Prefer one batch over separate translate calls' implicitly contrasts it with the singular translate sibling, so an agent can distinguish the two 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?

It names concrete use cases (lists of strings, UI labels, i18n files, subtitle cues, voiceover segments) and states the batch-over-individual-calls preference explicitly. What is missing is a when-not clause, for example routing dialogue content to translate_dialogue or subtitle files to localize_subtitle_file.

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

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

No annotations are supplied, so the description carries the full burden. It does disclose useful behavior: output is timed translated turns with 'review details', turns may target different languages, and it performs no speech synthesis. It omits cost/credit implications, error behavior, and how `context` or `formality` alter the result.

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 segment requirements, then return shape and the synthesis exclusion. No filler sentences. Slightly compressed to the point of terseness on the undocumented top-level parameters.

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?

An output schema exists, so the return-value note is a bonus rather than a necessity. For a 6-parameter tool with zero schema documentation, however, half the parameters remain opaque in both the schema and the description, which is a real 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 6 parameters, so the description must compensate. It usefully enumerates the per-segment fields (id, text, target_language, target_language_code, start_ms, end_ms, speaker_id), but leaves `context`, `speakers`, `formality`, `source_language` and `source_language_code` entirely unexplained, including valid formality values.

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: localizing 'speaker turns together with shared dialogue context', which separates it from the plain `translate`/`translate_batch` siblings. The scope (multi-segment dialogue, per-turn target languages) is clear. It stops short of explicitly naming which sibling to use instead for single-string or file translation.

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?

Implies the intended workflow by requiring segments 'from transcribe_audio_detailed', and gives one explicit exclusion ('Does not synthesize speech', pointing away from synthesize_audio). It never states when to choose this over `translate_batch` or `localize_subtitles`, so the routing decision is 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?

No annotations are provided, so the description carries the full burden. It usefully discloses that this persists workspace-level state and that null removes the setting, but says nothing about permissions, whether existing instructions are overwritten, or any side effects on translations already produced.

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; the primary action and the null-clearing case are both front-loaded and immediately actionable.

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 workspace mutation with an output schema present, the description covers purpose, prerequisite source of the ID, and clearing semantics. Only overwrite behavior and permission requirements are left unstated, which are minor gaps at this complexity.

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 both parameters have only bare titles, so the description must compensate. It does so well: mapping_id is tied to the ID from list_language_settings, and custom_style is defined as per-language style instructions where null clears them — the two facts an agent most needs. It stops short of describing acceptable content or length for the style text.

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 uses a specific verb ('Set'/'clear') on a specific resource ('saved per-language style instructions'), which tells an agent exactly what effect to expect. It is distinguishable from siblings like list_language_settings and update_language_formality, though it does not explicitly contrast itself with them.

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 the prerequisite for the call (the ID comes from list_language_settings) and states the clearing case (pass null). There is no explicit when-not guidance or named alternative, but the operational context is clear enough to select and invoke correctly.

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 the most important trait: the change is persisted to workspace settings rather than applied per call. It says nothing about permission requirements, whether an invalid mapping_id errors or creates, or reversibility; the return shape is covered by the output schema.

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 with the core action front-loaded and the disambiguation second. Minor deductions for the indented multi-line formatting and blank-line artifacts carried over from the source, which add no 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?

For a simple two-parameter settings mutation with an output schema, the description covers action, persistence semantics, discovery path and the sibling alternative. The remaining gap is the domain meaning of a mapping and error behavior, which is modest given the tool's simplicity.

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

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

Schema description coverage is 0%, so the description should compensate. It partially does by pointing to list_language_settings as the source of mapping_id, which is genuinely useful. The formality enum values are self-documenting in the schema, but what a "mapping" actually represents is never explained.

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: "Change the saved formality for a mapping from list_language_settings." It also differentiates itself from the translate tool's transient formality argument, so an agent can tell the two apart without inspecting 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?

Explicitly names the alternative (translate's formality argument) and the condition that selects it ("one-off request"), leaving the persistent-settings case for this tool. This is exactly the when-to-use/when-not-to-use framing that routes an agent correctly.

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

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

No annotations are provided, so the description carries the full behavioral burden. It indicates a mutation and enable/disable capability but does not disclose partial-update semantics, permission requirements, reversibility, or what happens to omitted fields.

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 a single front-loaded sentence with no wasted wording. It is appropriately concise for a short tool definition, even though more detail is needed elsewhere.

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 mutation tool with no annotations and 0% schema description coverage, the description is too thin. The output schema covers return values, but the description still omits key update semantics and parameter behavior needed to invoke the tool confidently.

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 four parameters, so the description must compensate. It conceptually maps edit to title/content and enable/disable to is_enabled, but it does not explain optionality, null handling, or the required guide_id beyond implication.

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 set (edit, enable, disable) and resource (existing workspace style guide), making the operation clear. It distinguishes itself from create/upload by specifying an existing guide, though it does not explicitly name sibling alternatives.

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 implies use for existing style guides but gives no explicit when-to-use guidance, prerequisites, or comparison to alternatives such as create_style_guide or upload_style_guide. An agent must infer the selection context.

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

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

No annotations are supplied, so the description carries the full burden; it does disclose one genuinely important behavior, that saved edits do not take effect until export_subtitle is run with regenerate=true. It says nothing about whether updates merge with or replace existing review rows, whether partial row objects are allowed, permission requirements, or failure modes for bad row indices.

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

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

Two short sentences, front-loaded with the payload shape, then the workflow guidance, with no filler. The field enumeration is dense but earns its place given the opaque 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 mutation tool with no annotations, an opaque array schema, and a missing storage_path explanation, the description covers the row payload and the read-then-write-then-export cycle but leaves key mechanics unaddressed. An output schema exists, so return values need not be described, which offsets some of the gap.

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 'updates' parameter is an untyped array of free-form objects, so the description's row field list (row_index, translation, approved, rationale) is doing real compensating work that the schema cannot. However, the second required parameter, storage_path, is never explained and no field types or requiredness within a row are given.

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 ('Save') and resource ('subtitle review edits') and enumerates the row fields being persisted (row_index, translation, approved, rationale). It is clearly distinguishable from the read counterpart get_subtitle_review and from export_subtitle, though it never explicitly contrasts itself with them.

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 concrete precondition ('Use row indices returned by get_subtitle_review') and a concrete follow-up ('Export with export_subtitle(regenerate=true) after editing to apply the changes'), which routes the agent through the correct workflow. It stops short of stating when not to use this tool or what happens if rows are omitted.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that this is a mutation and that 'enabled' controls future translation usage, but says nothing about whether editing resets the entry's approved status, what permissions are required, or what happens to unspecified fields (both optional params default to null).

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 with the primary action front-loaded and the secondary toggle attached efficiently. Nothing is wasted, though splitting the edit behavior from the enable/disable behavior might read slightly clearer.

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?

An output schema exists, so return values need not be explained. But for a three-parameter mutation with no annotations and no schema descriptions, the description leaves out side effects (approval state, whether null means 'unchanged') that an agent would need before calling it safely.

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 clarify that 'enabled' toggles use in future translations and that editing concerns the translation text itself, implicitly mapping to target_text. It does not explain entry_id semantics or the critical null-vs-value distinction for the optional fields (partial update vs. no change).

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 ('Edit') and resource ('an approved TM translation'), plus a second mode of operation (enabling/disabling). An agent can distinguish this from add_translation_memory_entry or delete_translation_memory_entry by the verb alone, though no sibling is named 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?

'approved TM translation' implies a precondition (the entry must already exist and be approved), which is useful guidance. However, there is no explicit statement of when to use this versus add/delete/search translation memory siblings, so the routing signal is only 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?

No annotations are supplied, so the description carries the full burden. It does add genuine value by disclosing the two transport modes for file input (local path under stdio, public HTTPS URL when hosted), which is not derivable from the schema. However, for a creation/mutation operation it says nothing about permissions, size limits, parse failures, or whether an existing guide with the same title is replaced, leaving real behavioral gaps.

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 that front-load the core action and then the input-location rule; nothing is wasted. The second sentence is indented and fragmentary, which reads slightly unpolished but does not harm comprehension.

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?

An output schema exists, so return values need not be described. For a no-annotation creation tool the definition is nonetheless thin: it omits what the uploaded file is used for downstream, any limits, and how the optional title is applied, leaving the agent to guess at failure and overwrite behavior.

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 for both parameters. It explains file_path well (local path vs. public HTTPS URL by deployment mode), but the 'title' parameter and its empty-string default are never mentioned, so only half the parameters gain meaning.

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