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

No annotations are provided, but the description carries the full burden and does so well. It reveals default behavior (Scribe transcription), grouping logic (max_words), styling specifics (white bold, black stroke, drop shadow, centered low-third, Hebrew RTL), and customization options (captions, style overrides). This is rich behavioral 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 description is two sentences, but each is information-dense. The first sentence states the core function and accepted inputs; the second unpacks default behavior, styling, and alternatives. No redundant phrasing or filler — every clause contributes.

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 complex tool with 7 parameters and an output schema, the description covers the main workflow thoroughly: input sources, default transcription, chunking, styling, and pipeline position. It does not explain output details, but the presence of an output schema reduces that need. Minor gaps like behavior without a video are acceptable given the overall completeness.

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 `captions`, `style`, `max_words`, and mentions `video`/`task_id` as input sources. However, it does not clarify `language` or `output_path`. The description adds value but leaves several parameters undocumented in any 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?

The description starts with an explicit verb and resource: 'Burn word-timed captions onto a video.' It clearly differentiates this from sibling tools (e.g., mix_narration, trim_video) by focusing on caption burning with precise details about the default Scribe transcription flow and styling.

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 gives explicit sequencing: 'Run AFTER verify_generated_audio passes and BEFORE stitch_videos.' This tells the agent when in the pipeline to use it. It also notes that passing `captions` bypasses Scribe, providing an alternative path. It lacks a formal 'when not to use' but the contextual guidance is strong.

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 disclose behavioral traits beyond the basic action. It only states the action without addressing consequences like permanence, permissions, or impact on related data. The lack of any warning about irreversibility is a significant gap for a delete 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?

The description is a single, tightly worded sentence: 'Delete a private asset.' It is front-loaded with the action and resource, contains no fluff, and is appropriate for a tool with a single parameter.

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 destructive tool with no annotations and an output schema not shown, the description lacks critical context such as reversibility, permissions, and what happens after deletion. It is minimal and does not fully cover the operational aspects needed for an agent to use 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%, and the description does not explain 'asset_id' beyond the schema's string type. However, the parameter name is self-explanatory, so the agent can infer its purpose, but no additional semantics are provided.

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 the specific verb 'Delete' with the resource 'private asset', making the action unambiguous. It clearly distinguishes from sibling tools like get_asset, upload_asset, and list_assets, so the agent knows this is the only tool for removal.

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 usage context is provided. The description does not mention when to use this tool vs alternatives, prerequisites, or whether deletion is irreversible. This is particularly important for a destructive operation, but the description is silent.

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 full responsibility. It discloses non-destructive nature ('pure analysis'), exact return format, the lower-octave pinning behavior, and the edge case for silence/undetectable pulse. This is thorough and goes well beyond basic expectations.

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 structured in three short paragraphs: purpose/return, octave nuance, and usage/edge case. It is front-loaded with the core function and every sentence contributes value, though the 'no output' phrase could be more precise.

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?

Covers input path, parameter behavior, output schema (in prose), edge cases, and intended use case. For a tool with no annotations and moderate complexity, this description is exceptionally complete. The only minor gap is the ambiguity of 'no output' versus the JSON return.

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 description explicitly references min_bpm and max_bpm and explains their semantic role (octave pinning), adding context beyond the schema's type/default definitions. Audio_path is implied, so two of three parameters gain meaningful explanation despite 0% schema coverage.

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

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

The description clearly states the tool's function with a specific verb and resource: 'Detect tempo and beat times of an audio track'. It also positions itself as 'pure analysis', distinguishing it from sibling generation/editing tools. This is explicit and 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?

Provides a clear use case: 'Use this to beat-snap multi-clip seams onto a music bed before stitching.' It does not explicitly list alternatives or exclusions, but given the sibling tools are largely generation/editing, this guidance is sufficient for a specialized analysis 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?

With no annotations, the description discloses some behavior: default is the last frame, upload=true hosts a temporary public URL, and output is PNG. However, it doesn't mention side effects like asset creation or how to access the saved frame, leaving some behavioral aspects unclear.

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 two sentences, front-loaded with the core purpose, followed by a practical use case and upload behavior. No redundant wording; every sentence earns its place.

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

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

For a three-parameter tool with no annotations, the description covers the core function, default behavior, upload option, and a common workflow. It omits specifics about time_s and output details, but an output schema exists, so return values may be documented there.

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. It clarifies 'video' (local path or URL) and 'upload' (hosts on temporary public URL). 'time_s' is only implied by 'default = LAST frame,' without stating that it selects a specific frame or its units, leaving ambiguity.

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 the tool's function clearly: 'Save one frame of a video (local path or URL) as PNG; default = LAST frame.' It uses a specific verb and resource, and the mention of bridging continuity with generate_seedance_first_last distinguishes it from siblings.

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

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

It gives concrete usage guidance: 'Use the last frame of clip N as image_first of clip N+1...' and explains when upload=true is useful. It doesn't explicitly state when not to use it or name alternatives, but the reference to a sibling tool indicates integration context.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does mention the temp file side effect and the use of ElevenLabs, but it omits other important behaviors such as output format, return value, or whether the temp file is cleaned up. It provides some useful context but not comprehensive 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 description is a single sentence, front-loaded with the core action, and contains no filler. It is appropriately concise for what it 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?

This is a complex tool with 15 parameters, no annotations, and no parameter descriptions. The one-sentence description covers only the basic action and side effect, leaving the agent without essential context like parameter roles, workflow placement, or prerequisites. It is minimally viable but insufficient for the tool's 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?

The description contains no parameter information, and the input schema has no parameter descriptions (0% coverage). With 15 parameters, the agent receives zero guidance on what each parameter means, how they interact, or which are essential beyond the required text and voice_id.

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 tool's function: 'Synthesize speech with ElevenLabs and write the audio to a temp file.' It uses a specific verb ('synthesize') and resource ('ElevenLabs'), and the 'voiceover' in the tool name distinguishes it from siblings like generate_music or generate_sound_effect.

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 usage guidance is provided. The description only states what the tool does, with no mention of when to use it versus alternatives, prerequisites, or exclusions. The agent must infer from the tool name and 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 must disclose behavioral traits, but it provides none. There is no mention of how the tool handles waiting, audio, content checks, resolution defaults, or any side effects. The text only restates the basic function and modes.

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 extremely short, but this is under-specification rather than concise quality. It contains only one sentence that adds minimal value, offering no structure or front-loaded essential details for a tool with 13 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?

Despite having an output schema, the description is severely incomplete given the tool's complexity. It does not mention required input patterns, defaults like version/duration/resolution, or any operational context needed to invoke the tool correctly. There is no coverage of the diverse parameter space.

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 does not compensate. The 13 parameters are entirely unexplained; even the hint at 'single prompt or multi-shot' does not map to specific parameter semantics (e.g., prompt vs shots). This fails to help an agent construct correct arguments.

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 ('Generate') and identifies the resource ('Kling Omni video'), and clarifies the two operational modes ('single prompt or multi-shot'). However, it does not distinguish from sibling video-generation tools like generate_seedance_video, so it misses the differentiation criterion for 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?

No guidance is given on when to use this tool versus alternatives such as generate_seedance_video or stitch_videos. The phrase 'single prompt or multi-shot' hints at modes but does not establish context, prerequisites, or 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 burden. It discloses the duration range, the effect of force_instrumental (to avoid competing with voiceover), and the complementary nature of the music bed. It doesn't mention async behavior or error conditions, but for a generative music tool, it adds meaningful behavioral context beyond the basic purpose.

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 compact and well-structured. The first sentence states the purpose, and the second provides targeted operational guidance. Every sentence is functional—no filler or repetition.

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 description is sufficiently complete for the main use case, covering generation parameters and next steps (mixing). The presence of an output schema likely covers return values, so that absence is not a penalty. Minor omissions (e.g., async polling, verification) are compensated by the practical guidance and sibling tool context.

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 no property descriptions (0% coverage), so the description compensates by explaining the key parameters: prompt (with example qualifiers like 'soft, sparse'), duration_s (match to video), and force_instrumental (set true for ads). It does not explain model_id or output_path, but their defaults make them lower-risk.

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 ('Compose'), a clear resource ('a music track'), and a scope ('from a text prompt'), also noting the duration range (3-600s). This clearly distinguishes it from sibling tools like generate_sound_effect and generate_elevenlabs_voiceover.

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?

Provides a detailed, concrete use case for speech ads—how to prompt for low-key background music, set force_instrumental=true, and match duration_s—and points to mix_music_into_video as a follow-up. It does not explicitly name alternative tools or state when not to use this tool, but the context is clear enough.

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 explain side effects, async behavior, and requirements. It only says 'Generate a Seedance video' and gives no information about task creation, waiting, resolution, or other behavioral traits. This is a significant gap for a generation 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, focused sentence that immediately states the verb and resource. It is front-loaded, avoids redundancy, and contains no filler. The structure is appropriately minimal for the limited information it conveys.

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 8 parameters and no annotations, the description is far from complete. It fails to mention the significance of the wait flag, service_mode, task lifecycle, or how the first/last frames are used. Even though an output schema exists, the operational context remains unclear.

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 only indirectly references image_first and image_last. It does not explain any of the other six parameters (prompt, duration, wait, resolution, task_type, service_mode), nor their defaults or interactions. The description adds minimal value over the raw schema.

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

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

The description clearly identifies the action ('Generate a Seedance video') and the specific input modality (first/optional last frame image). It distinguishes this tool from text-to-video generation by emphasizing the frame images, though it doesn't explicitly contrast with the sibling tool 'generate_seedance_video'.

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 tool is for using start and end frame images to generate video, but it provides no explicit guidance on when to choose this over alternatives like generate_seedance_video. No context, 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 provided, the description carries full burden and delivers rich behavioral detail: it states task_type is forced and 'requesting another type has no effect; this is intentional, not an error', explains that user-supplied carriers are ignored, and discloses asset requirements and QA gates. It also clarifies the romanized_text gate and the implications for lip-sync, which goes well beyond a simple operation description.

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

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

The description is long but employs clear section headers (HEBREW, Prompt, romanized_text, References) and bullet-like lists. Every sentence adds valuable information, avoiding filler. It is front-loaded with the core purpose and then organized by topic, making it scannable despite its length.

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 highly complex tool with 24 parameters, no annotations, and no schema descriptions, this description covers the essential workflow, special cases, and constraints comprehensively. It explains the Hebrew BVAC chain, romanization requirements, asset handling, and behavioral overrides. An output schema exists, so not needing to describe return values is acceptable. The description is thorough enough to guide correct invocation in almost all scenarios.

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 heavily compensates. It explains the meaning and usage of critical parameters: text, voice_id, audio_path, romanized_text, prompt, image_roles, other_roles, human_image_urls, other_image_urls, auto_upload_assets, task_type, wait, and image_urls as a legacy alias. However, parameters like duration, resolution, aspect_ratio, mode, service_mode, content_check, verify_speech, audio_urls, video_urls, and asset_retention_hours remain undocumented; while some are self-explanatory, the coverage is not complete.

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 'Generate a Seedance video' which clearly states the action and resource. It immediately distinguishes itself from siblings by adding 'auto-chain Hebrew BVAC lipsync when language is Hebrew', and contrasts with generate_kling_video and generate_seedance_first_last by specifying the video engine and Hebrew-specific behavior.

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 provides strong when-to-use guidance for Hebrew: it says 'this tool runs the ENTIRE BVAC chain itself; do NOT pre-build anything' and gives the audition flow with generate_elevenlabs_voiceover. It does not explicitly mention alternatives for non-Hebrew cases, but the Hebrew-specific context is clear and actionable. The guidance about not building carriers or uploading audio is a valuable exclusion.

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 full burden and does disclose important behavioral traits: the output is a generation-only bed (not mixed), duration is limited to 0.5-30s, and loop=true creates a seamless bed. It does not explain prompt_influence or output behavior, but the key generation-only semantics are transparent.

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

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

Three sentences front-load the purpose and then provide actionable usage guidance without fluff. Every sentence earns its place, and the structure is easy to scan.

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 description covers the core workflow, duration limit, loop guidance, and separation of generation from mixing, which is sufficient for a 5-param tool with an output schema. It omits optional parameter semantics for output_path and prompt_influence, but those have self-explanatory names and defaults.

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 description adds meaning for prompt (describe concretely), duration_seconds (clip/ad runtime), and loop (seamless bed). However, it does not clarify output_path or prompt_influence, and since schema description coverage is 0%, these two parameters remain underdocumented.

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 'Generate an ambient/diegetic sound-effect bed (0.5-30s) from a text prompt,' clearly naming the verb, resource, and scope. It distinguishes this tool from siblings like generate_music and generate_elevenlabs_voiceover by specifying it produces sound-effect beds rather than music or voiceover.

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 clear when-to-use context: 'Generation only — the caller mixes the bed onto the video locally' and instructs to pass duration_seconds and keep loop=true for a seamless bed. It gives a when-not (don't expect mixing), though it does not explicitly name alternative tools.

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 transparency burden. It explicitly discloses the non-obvious TTL refresh side effect, which is valuable beyond a plain read operation. However, it omits other traits like required permissions or error behavior, so it is not maximally transparent.

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 one concise sentence that efficiently communicates both the main purpose and a key side effect, with no redundant or filler 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 simple, single-parameter tool, the description covers the core purpose and the significant TTL side effect. An output schema exists, so return details are handled. The lack of explicit alternatives or operational caveats makes it slightly incomplete, but it is largely adequate for the tool's simplicity.

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

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

The schema has 0% description coverage for asset_id, and the description does not explain the parameter format or its relationship beyond the tool name. The phrase 'a single asset' indirectly ties asset_id to the asset, but this is insufficient to fully clarify the parameter's semantics.

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

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

The description uses the specific verb 'Get' plus the resource 'a single asset's current state', clearly distinguishing it from list_assets (which would retrieve multiple assets). The parenthetical about refreshing TTL adds further scope clarification.

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 when a single asset's state is needed, and the TTL refresh hints at a reason to use it (extending asset life). However, it does not explicitly name alternatives or state when not to use it, leaving guidance at the implied level.

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 present, and the description only says 'fetch' without disclosing behavior such as error handling, idempotency, or whether the task must exist. It adds minimal transparency beyond the tool name.

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 sentence, immediately states the purpose, and contains no redundant information. It is perfectly concise for a simple getter.

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 that is not missing. However, with no annotations and no usage guidance, the description is minimal and does not fully equip an agent to decide when and how to invoke this 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?

The schema has one parameter, task_id, with no description. The description does not explain how to obtain task_id or any format expectations, so the parameter remains semantically bare.

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 action ('Fetch') and the resource ('current state of a PiAPI task'). It is specific and distinguishes this from sibling tools like get_asset by targeting tasks.

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 guidance is provided on when to use this tool, such as after submitting a generation job to poll status. It does not mention alternatives or exclusions, leaving the agent without invocation context.

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

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

With no annotations, the description carries the transparency burden. It discloses key behavioral traits: temporary public URL, ~1h retention, and the use of 'tmpfiles' as the hosting mechanism. It does not mention potential file size limits or security considerations, but the temporary nature is the most crucial behavior and is clearly stated.

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

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

Two sentences, front-loaded with the core action and retention, followed by usage guidance. No wasted words; every sentence adds 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?

Given a single parameter, no annotations, and an existing output schema, the description covers purpose, when to use, when not to use, and the key temporary-retention behavior. It could mention additional constraints like file size, but for the intended use cases it is 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 provides no description for the single 'path' parameter (0% coverage), so the description must compensate. It indicates the path refers to 'a local file' and gives examples (ElevenLabs mp3, product/room photo), but it does not clarify required format (absolute vs relative) or whether the file must exist locally. This is minimal but sufficient for a simple string path.

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+resource: 'Host a local file on a temporary public URL (tmpfiles, ~1h retention).' It also clearly differentiates from sibling upload_asset by explicitly stating that human/persona refs should use upload_asset, and illustrates intended use cases (audio_urls, other_image_urls).

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 provides when-to-use guidance: 'Use for non-asset references that need a provider-fetchable URL' with concrete examples. It also gives an exclusion and alternative: 'Human/persona refs do NOT go here — register those with upload_asset instead.' This names the alternative tool and sets clear boundaries.

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 mentions the status filter but does not disclose whether the operation is read-only, how pagination works, or any access control implications of 'private' assets. The description adds minimal behavioral context beyond what the name suggests.

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 redundant or filler content. It conveys the core purpose and the most important filter option efficiently.

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 tool's simplicity and the existence of an output schema, the description is adequate but misses pagination semantics and a clearer definition of 'private assets'. This leaves some gaps for an agent unfamiliar with the domain, but the core list operation is clear.

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 provides no descriptions for page, size, or status, and the description only explains the status parameter (with allowed values). The page and size parameters are entirely undocumented, leaving users to infer their purpose from naming conventions.

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 action ('List') and resource ('private assets'), and specifies an optional status filter with enumerated values. This differentiates it from sibling tools like get_asset (single asset retrieval) and list_voices (different resource).

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 it is used for listing assets, but does not explicitly state when to choose this over alternatives like get_asset or upload_asset. No prerequisites or exclusions are mentioned, so usage context 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?

With no annotations, the description carries full burden. 'List available' suggests a non-destructive read operation, but it does not disclose details such as whether the list is paginated, sorted, or includes any filters. It adds minimal context beyond the name.

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 words. It is appropriately concise for a tool with no parameters and a simple 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?

Given the simplicity of the tool (no parameters, output schema exists), the description is fully adequate. It states what the tool does, and the output schema covers the return format, so nothing important 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 input schema has zero parameters, so the baseline for this dimension is 4. The description does not need to add parameter semantics, and it correctly says nothing that would conflict 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?

The description uses a specific verb 'List' and a specific resource 'ElevenLabs voices', clearly distinguishing it from sibling tools like 'list_assets'. It states exactly what the tool does with no ambiguity.

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: call this to retrieve available voices. However, it provides no explicit guidance on when to use it versus alternatives, or any prerequisites, so it falls to the 'implied usage' tier.

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 fully discloses key behaviors: adaptive gain, loudness measurement, default ducking behavior, the meaning of LUFS values (14 vs 18-20), how to override with music_gain_db, and that the video stream is copied untouched. This is comprehensive and adds significant value beyond the 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?

The description is about 100 words but every sentence adds meaningful information. It is front-loaded with the core purpose, uses parameter names in backticks for clarity, and avoids filler. The structure follows a logical flow: purpose, default behavior, parameter usage, and special notes.

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 6-param complexity, no annotations, and an output schema, the description covers all essential usage aspects: default adaptive gain, ducking, fixed gain override, the purpose of the music bed, and input flexibility (URLs). The existence of an output schema means return values don't need explanation. The description is sufficiently complete for correct selection and 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%, making this the description's critical burden. It explains music_below_speech_db with concrete LUFS examples, duck as a gentle side-chain dip, and music_gain_db as the fixed-gain override. Even the video/music parameters are clarified by 'inputs may be URLs'. This fully compensates for the lack of schema descriptions.

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+resource: 'Lay a music bed under a video's existing speech/ambience audio.' This precisely distinguishes it from sibling tools like mix_narration (which handles narration) and clearly communicates the tool's function.

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 provides strong contextual guidance, such as 'Music for speech ads is complementary, not the main event' and explains when to use fixed gain vs adaptive gain. However, it does not explicitly name alternative tools or state when NOT to use this tool, leaving the agent to infer exclusions from the sibling list.

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 entire transparency burden and meets it admirably. It discloses full-level voice, untouched video stream copying, bed mixing with LUFS offset, side-chain ducking, output duration behavior with padding/trimming, and ffprobe verification. This is far richer than a typical generic description.

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

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

The description is compact yet information-dense, with the lead sentence capturing the essence and every following clause adding a distinct behavioral or parameter detail. There is no filler or redundancy; the 'ffprobe-verified' tag is a concise way to indicate reliability.

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 moderate parameter count and no annotations, the description is remarkably complete. It covers the full workflow, parameter meanings, output timing behavior, and edge cases (shorter/longer audio). The existence of an output schema means return value documentation is not required, so no major gaps remain.

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 the parameters, and it does. It clarifies bed_path as ambient/music, bed_below_voice_db as LUFS level below the voice, and implicitly ties voiceover_path to the primary audio. It also defines the relationship between video time and output audio length, covering the output_path semantics.

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

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

The description opens with a specific verb and resource ('Lay a voiceover as the PRIMARY audio over a (silent) video'), making the tool's core action unmistakable. It goes further by explicitly positioning itself as 'the inverse of mix_music_into_video', which clearly distinguishes it from a closely related sibling.

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

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

The description states the ideal use case (voiceover as primary audio over a silent video) and implies a when-not-to-use case by contrasting with mix_music_into_video for videos that already contain speech. This gives the agent an explicit alternative and a clear decision boundary.

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

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

With no annotations, the description fully discloses behavioral traits: speed clamping to [0.5, 2.0], ToolError outside range, audio retiming, ffprobe verification, and interpolation behavior (motion interpolation vs frame duplication with default off). This goes well beyond basic expectations and surfaces critical details for agent decision-making.

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?

Six sentences, front-loaded with the core purpose, then logically covering parameter variants, usage scenario, interpolation nuance, constraints, and side effects. Every sentence adds value and the density is appropriate for a tool with 5 parameters and no schema descriptions.

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 absence of annotations and schema descriptions, the description covers all critical aspects: purpose, parameter semantics, constraints, error behavior, audio handling, and verification. It also includes output schema (yes) so return value explanation is unnecessary. The description is fully complete for safe and effective tool 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 has 0% description coverage, but the description thoroughly explains the key parameters: target_duration_s (speed computed as source/target), speed (1.0 unchanged, 0.5 = half-speed/2x longer), and interpolate (default false, smoothing slow-mo). It also clarifies the mutual exclusivity of speed and target_duration_s, which is essential for correct invocation.

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

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

Description opens with 'Stretch/compress a clip to hit a target duration (or explicit speed),' using a specific verb and resource. The primary function is clear and distinct from sibling tools like trim_video (cut) or stitch_videos (combine), establishing unique identity.

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?

Provides a concrete use case: 'Use this to slow a b-roll clip slightly to fill a voiceover segment without repeating footage,' which clarifies when to choose this tool. Lacks explicit exclusion or named alternatives like 'for cutting, use trim_video,' but the contextual guidance is strong and practical.

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 must disclose behavioral traits. It does mention the return structure ('Returns len(points)+1 ordered segments with paths and durations') and the 'strictly increasing' constraint on split_points_s. However, it omits side effects (e.g., whether the original file is modified), permissions, or error behavior. The output schema covers return values, so the description's mention of them is somewhat redundant, leaving the behavioral disclosure incomplete.

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 four sentences, each adding distinct value: the core action, return behavior, a concrete workflow, and a constraint. It front-loads the verb and resource, and the structure is logical, though the workflow sentence is somewhat dense. No significant redundancy exists, making it efficient without being 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?

The presence of an output schema reduces the need to document return values. The workflow context is strong and gives the agent a clear use case, but the description does not address failure modes, prerequisites (e.g., file existence, MP3 format), or the behavior of output_dir. Given no annotations and 0% parameter coverage, the description leaves operational gaps that could hinder correct invocation in edge cases.

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

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

With schema description coverage at 0%, the description must compensate for all three parameters. It explains split_points_s (units and constraint) and implies audio_path is the mp3, but output_dir is never mentioned or explained. The description also does not clarify the expected format of audio_path (e.g., path vs. URI). This leaves a meaningful gap for one of the parameters, so the description only partially compensates for the missing schema documentation.

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 ('Cut') and resource ('master voiceover mp3'), and further clarifies the operation by referencing split points. It clearly distinguishes itself from sibling tools like trim_video and retime_video by focusing on audio segmentation. The function is unambiguous and immediately understandable.

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 explicitly outlines a full workflow: generate a master VO with generate_elevenlabs_voiceover, pick sentence-boundary timestamps, split here, then pass each segment to generate_seedance_video. This tells the agent exactly when to use this tool and how it fits into a larger pipeline, while also implicitly differentiating it from other audio/video editing 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 of disclosure. It reveals key behavioral traits: hard cuts (no transitions) and normalization to the first clip's resolution/fps for clean concatenation. However, it does not mention audio handling or return behavior, leaving a small 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 description is two sentences: the first states the core function and inputs, the second provides behavioral details and usage guidance. Every sentence earns its place, with no redundancy 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?

Given no annotations and a moderately complex operation, the description covers essential points: concatenation, ordering, normalization, and usage context. It is missing details about audio handling, but for a simple stitch tool, it is sufficiently 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 provides no parameter descriptions (0% coverage), so the description compensates by explaining that 'videos' accepts local paths or URLs and that order matters. It also hints that 'output_path' produces an MP4. It does not fully elaborate on output_path, but enough meaning is added for usage.

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

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

The description clearly identifies the tool's function: 'Concatenate >= 2 clips (local paths or URLs, in order) into one MP4.' This specific verb and resource, combined with the requirement of multiple clips, distinguishes it from sibling tools like trim_video or retime_video that operate on single clips.

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 explicitly says when to use the tool: 'Use this for the final assembly of a multi-clip ad.' It also gives a clear exclusion: 'do not shell out to ffmpeg concat yourself,' preventing misuse and reinforcing that this is the designated tool for concatenation.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It transparently reveals that transliteration is performed via LMStudio/OpenRouter LLM, which is useful context about external dependencies. However, it does not mention potential failure modes, latency, or output formatting.

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 that immediately names the action, source, target, and use case. Every word contributes value, with no redundancy 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?

Given the tool's simplicity (one parameter, output schema present), the description covers the essential contextual aspects: purpose, input language, output script, and intended application. It does not over-elaborate, and any missing return-format details are likely provided by the output schema.

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

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

The input schema provides zero description for the 'text' parameter, and the description partially compensates by indicating the input should be 'Hebrew text' and output is Latin. This adds meaning beyond a bare string field, but lacks detail on encoding, length limits, or transliteration style.

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 the specific verb 'transliterate' with a clear resource ('Hebrew text to Latin'), making the tool's function unambiguous. This distinct purpose differentiates it from all sibling tools, which focus on media generation and asset management.

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

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

The phrase 'for visual prompts' provides a clear use case, implying when to use this tool. It does not explicitly name alternatives or exclusions, but no sibling tool performs transliteration, so the context is sufficient.

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. It discloses several behavioral traits: re-encoding (not stream copy), preservation of resolution/fps/aspect, silence preservation, and ffprobe-verified duration return. It also frames the operation as frame-accurate. This is a solid disclosure of what the tool does, though it stops short of mentioning error conditions or what happens if both modes are provided.

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 four concise sentences, front-loaded with the core purpose. The remaining sentences provide essential usage and behavioral details without redundancy. Every line earns its place, and the structure is easy to scan.

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 description adequately covers the main usage scenarios and behavioral details for a trim operation with five parameters. Since an output schema exists, the return value is already documented, and the description adds the ffprobe-verified duration note. It could be more complete by addressing mutually exclusive parameter validation, but overall it is well-rounded and sufficient for the tool's 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 description coverage is 0%, so the description must compensate. It explains the core parameter semantics: 'duration_s (keep [0, duration_s])' and 'start_s+end_s' for specifying the exact span. It also clearly implies the roles of video_path and output_path through the operation context. This is sufficient for an agent to understand how to fill these parameters, despite not detailing every edge case.

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

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

The description opens with 'Frame-accurately cut a clip to an exact span', which is a specific verb and resource. The additional 're-encode, not -c copy' and emphasis on exact span distinguish it from sibling tools like retime_video, extract_frame, and stitch_videos. This is a clear, differentiated purpose.

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 provides a concrete use case: 'Use this to cut a generated b-roll clip down to a voiceover segment's length.' It also clearly states the parameter selection constraint (EITHER duration_s OR start_s+end_s). However, it does not explicitly mention when not to use this tool or suggest alternatives, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden. It usefully discloses that local paths are uploaded to a temporary public host, that the asset persists on PiAPI for days, and that providing influencer_page causes a side effect of recording the asset id in an Obsidian file. This is more than minimal but omits potential details like auth requirements or failure 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?

The description is concise and front-loaded: the first sentence states the core purpose and return value, the second and third sentences add necessary behavioral nuance and side effects. Every sentence earns its place without fluff.

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 description covers the main workflow and the influencer_page side effect, but with 5 parameters and 0% schema coverage, the agent lacks enough context about optional parameters and when to use them. The output schema exists, so return values are less critical, but missing parameter semantics leaves the tool only partially 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 coverage is 0%, and the description only explains influencer_page. It does not clarify the meaning of name, asset_type, wait_active, or the exact format of image (beyond 'local path or public URL'). Since the schema has no descriptions, this lack of parameter information is a significant gap for correct invocation.

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

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

The description uses a specific verb ('Register'), names the resource ('a private asset'), and clarifies the input forms ('local path or public URL') and the return value ('asset://id'). This clearly distinguishes it from siblings like list_assets, get_asset, and delete_asset.

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 for asset registration, and the mention of influencer_page side effect suggests a particular workflow, but it does not explicitly state when to use this tool versus alternatives like host_file or get_asset. There are no when-not-to-use conditions or named alternatives.

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

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

With no annotations, the description carries the full burden and does so admirably. It discloses the entire pipeline: 'Downloads the video, extracts its audio, transcribes with ElevenLabs Scribe, and judges against text.' It even provides threshold details (100% pass / 85-99% warning / <85% raises) and asserts its canonical status, leaving no doubt about the tool's 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?

The description is four sentences, each contributing unique value: definition, usage timing, process details, and exclusion. It is front-loaded with the main action and contains no redundant or filler 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?

Given the tool's complexity and the existence of an output schema, the description covers all necessary contextual elements: when to use, what it does, how parameters relate, and behavioral outcomes. It is sufficiently complete for an agent to select and invoke the tool without additional ambiguity.

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 provides only types and defaults (0% coverage), but the description explains each parameter's meaning: 'text' is the original spoken Hebrew, 'task_id' is from the async job, and 'video_url' is an alternative to task_id. This adds essential semantic context beyond the bare schema.

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

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

The description clearly states the tool's function: 'Run the generated-video Scribe QA gate on a finished Seedance task.' It specifies the exact resource (finished Seedance task) and distinguishes it from generation siblings by focusing on verification. The mention of 'Hebrew lipsync job' further narrows the scope.

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?

Explicit usage guidance is provided: 'Use this after an async (wait=false) Hebrew lipsync job completes.' It also clarifies exclusions: 'Do not substitute local whisper or other ASR — this is the canonical gate.' This tells the agent exactly when to invoke this tool and when not to use alternatives.

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