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

With no annotations, the description carries the behavioral burden. It explicitly states that input files are not altered, that output_name is auto-generated when omitted, and that background mode runs as a job returning job_id. It does not cover failure modes for codec mismatches or overwrite behavior, but the core behavioral contract is clear.

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

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

The description is compact and well-structured: a one-sentence purpose, a short prerequisite line, then a labeled Args section. Every sentence earns its place, and the most important behavioral facts are front-loaded.

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

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

For a three-parameter tool with an output schema and no annotations, the description is nearly complete: it covers parameters, ordering, compatibility prerequisites, input persistence, and background job behavior. Minor edge details such as the exact generated output-name pattern or overwrite policy are omitted, but they are not essential 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%, but the description fully compensates by explaining every parameter in plain language: paths are relative to the workspace and order-sensitive, output_name is auto-generated if omitted, and background executes as a job returning job_id. This adds substantial meaning beyond the bare schema types.

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 action: 'Junta dois ou mais vídeos na ordem informada em um único arquivo.' This clearly states the verb, resource, and result, and naturally distinguishes concat_videos from sibling tools like cut_video or extract_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?

The description gives useful prerequisites: videos must have the same codec and resolution, and it gives a concrete example ('cortes do mesmo original'). However, it never names alternative tools or explicitly states when not to use this tool, so the routing guidance remains implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses that the original is not modified, that streams are copied without re-encoding by default, that this cuts at the nearest keyframe, that reencode=true gives exact cuts, and that background=true returns a job_id tracked via job_status. These are genuine behavioral traits beyond what schema types express.

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 well-structured and front-loaded: core behavior first, then key behavioral tradeoffs, then a compact parameter list. Every sentence earns its place, and the Args section is justified given the 0% schema coverage. Nothing is redundant 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 5-parameter tool with no annotations, the description is nearly complete: it covers the operation, non-destructive behavior, encoding tradeoffs, job mode, and all parameter meanings, and an output schema exists so return values need no elaboration. Minor gaps remain—no mention of output file naming/location or error edge cases like start > end—but these don't block 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%, so the description must compensate, and it does completely: all 5 parameters are documented with semantics—path relative to workspace, start/end in seconds, reencode for exact cut (slower), background returning a job_id. The 'Args' block adds real meaning beyond the bare schema property names and types.

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: 'Corta o trecho entre start e end (segundos) e salva um novo arquivo', which precisely states that this tool trims a video segment and writes a new file. This clearly distinguishes it from siblings like extract_audio (audio extraction), extract_frame (single frame), concat_videos (joining), and detect_scenes (scene detection), so an agent can discriminate without inspecting schemas.

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

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

The description gives strong usage context: it explains the default fast path (copy streams, cuts at nearest keyframe), when to switch to reencode=true (exact frame cut, slower), and when to use background=true (long videos) with job_status for monitoring. It lacks explicit exclusions naming sibling alternatives, but the parameter-mode guidance is clear and actionable.

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 explicitly warns 'Não há lixeira nem desfazer' (there is no trash or undo), which is critical for a destructive operation. This goes well beyond simply saying 'delete 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 concise and well-structured: action first, usage second, parameter semantics last. Every sentence adds value, and the most important operational warning (permanence, no undo) is front-loaded.

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

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

For a one-parameter destructive tool, the description covers what the tool does, when to use it, the irreversible behavior, and the path semantics. An output schema exists, so return-value documentation is not needed. Nothing essential 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 0% description coverage, so the description must compensate. It does so by defining 'path' as 'Arquivo, relativo ao workspace' (file, relative to the workspace), adding important meaning about path interpretation that the schema itself lacks. It could be slightly richer, but it is sufficient for the single required 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 opens with a specific verb and resource: 'Apaga permanentemente um arquivo do workspace.' This clearly states the action, the target, and the permanent nature of the deletion, distinguishing it from the listed sibling tools that operate on media files or job status.

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 para limpar saídas intermediárias' (use to clean intermediate outputs). It does not explicitly mention alternatives or when not to use it, but since there is no other deletion tool among the siblings, the guidance is sufficient for selection.

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 and does well: it discloses that the tool scans the full video, that long videos should use background mode, and that background=true returns a job_id. It does not mention blocking behavior or side effects, but the core behavioral profile is clearly conveyed.

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: a one-line function statement, a usage hint, and a concise parameter list. Every sentence earns its place and the most important guidance is front-loaded.

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

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

For a 3-parameter tool with no annotations and an output schema available, the description is complete enough: it covers purpose, parameter semantics, and the important background-job path. The mention of job_id also informs the agent that follow-up with job_status/job_result may be needed, which fits the sibling set.

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 fully document parameters. It does: path is relative to the workspace, threshold is a sensitivity value between 0 and 1 with lower values detecting more scenes, and background executes as a job returning job_id. This adds meaning well beyond 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 states a specific action ('detect scene changes'), the resource (video), and the return value (scene intervals). The stated purpose 'decide where to cut' clearly differentiates it from siblings like cut_video and probe_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 explicitly says to use it 'para decidir onde cortar' and advises using background=true for long videos because it scans the entire video. It gives clear context but does not explicitly mention when not to use it or 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 full burden. It does disclose the main output behavior and adds useful behavioral detail for the 'background' flag — running as a job and returning a job_id — but it does not mention output file naming, whether existing files are overwritten, or behavior for synchronous runs beyond implication.

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 one-sentence summary is front-loaded, and the Args block is compact and useful. Every line adds a distinct piece of 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 three-parameter tool with an output schema, the description covers the core workflow and all parameters. A small gap remains in not stating where the extracted audio file is written or that the non-background path runs synchronously, but this is minor given the output schema exists.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: 'path' is specified as video relative to the workspace, 'audio_format' lists the allowed values, and 'background' is explained as job execution returning a job_id. This is exactly the semantic information missing from the schema.

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

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

The description opens with a specific action and object — 'Extracts the audio track from a video to a separate file' — which clearly distinguishes it from siblings like transcribe_audio, extract_frame, and probe_video. Even without explicitly naming alternatives, the purpose 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?

No guidance is given about when to choose this over transcribe_audio, extract_frame, or other video tools. The usage context is only implied by the purpose statement, and no exclusions or alternatives are mentioned.

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 carry behavioral context. It discloses that the tool creates/saves an image file and extracts content from a video, which communicates the primary side effect. It does not detail output file naming or overwrite behavior, but the core behavior is transparent enough.

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 front-loaded with the main action, followed by a short use-case statement and parameter notes. Every sentence serves a purpose and no filler is present.

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

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

For a relatively simple extraction tool, the description covers purpose, parameter semantics, and the typical scenario. It could be more complete by mentioning where the image is saved or what the output schema contains, but it is still sufficient for an agent to select and invoke correctly.

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

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

Schema description coverage is 0%, and the description compensates by explaining path as relative to the workspace and time as expressed in seconds. image_format only restates the enum values from the schema, so it adds some but not exceptional value.

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: extracts a single frame from the video at a given instant and saves it as an image. It also hints at the intended use case ('before cutting'), which helps distinguish it from sibling tools like cut_video or detect_scenes.

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 context by saying this is useful for visually inspecting content before cutting. However, it does not explicitly mention when not to use it or name alternative sibling 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 provided, the description must carry behavioral disclosure. It does disclose the error behavior for unfinished jobs, which is valuable. However, it does not mention whether retrieval is idempotent, whether results are consumed, or any side effects — acceptable for a simple result getter but not richly 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 three concise sentences, front-loaded with the core purpose, then the error case, then parameter guidance. Every sentence earns its place with no redundancy.

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

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

An output schema exists, so return value details are already covered. The description covers the error condition, the ID source, and the completion requirement. It could be slightly more complete by referencing job_status for progress checks, but overall it is sufficient for a one-parameter 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 only says 'Job Id', but the description adds meaning: 'Id devolvido pela tool que iniciou o job' clarifies that the ID comes from the initiating tool. This is useful guidance beyond 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 states the tool's purpose: 'Obtém o resultado de um job que já terminou' — retrieving the result of a completed job. This distinguishes it from siblings like job_status, which monitors progress.

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 notes that calling it while the job is still running returns an error ('Retorna erro job_not_finished se ainda estiver rodando'). This serves as a when-not-to-use condition. It does not explicitly name an alternative like job_status for checking progress, 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 burden and it does disclose the possible status values plus the handoff to job_result. It does not mention polling or error behavior, but the presence of an output schema reduces the need to describe return structure.

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, purposeful sentences: the core function, the conditional next step, and the parameter definition. No filler or repetitive restatement.

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-parameter status-check tool with an output schema, this description covers purpose, possible states, parameter origin, and related-tool flow. Nothing essential is missing 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?

The schema provides zero parameter documentation (0% coverage), so the description is the sole source. It explains that job_id is the value returned by the tool that started the job, which is precisely the provenance information an agent needs to fill the parameter correctly.

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 action — informing whether a background job is pending, running, done, or failed — and distinguishes job_status from the sibling job_result by indicating that job_result is the follow-up for output. This makes the tool's role 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?

It explicitly names the alternative tool (job_result) and the exact condition for switching to it: when the status is done. This gives the agent a clear when-to-use/next-step rule without requiring 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?

With no annotations provided, the description carries the behavioral disclosure burden. It explicitly states 'Não altera nada' (doesn't change anything), which is essential for an agent to know the operation is safe and non-destructive. This goes beyond what a simple list operation might imply and adds meaningful 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 compact and well-structured: purpose first, followed by a usage hint and a non-destructive guarantee, then a clean bulleted list of parameters. Every sentence adds value, and the information is front-loaded for quick agent scanning.

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

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

For a low-complexity listing tool with an output schema, the description covers everything needed to call it correctly: what it does, when to use it, that it's non-destructive, and what each parameter means. The presence of an output schema reduces the need to describe return values. There are no meaningful 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%, but the description provides clear semantics for all three parameters: directory is the workspace subdirectory (root by default), kind filters by type, and recursive includes subdirectories. This fully compensates for the schema's lack of descriptions and makes the defaults unambiguous.

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 action and resource: 'Lista os arquivos disponíveis no workspace' (lists available files in the workspace). It clearly identifies the tool as a discovery/listing operation and distinguishes it from the sibling processing, deletion, and job-management 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?

The instruction 'Chame primeiro para descobrir com o que trabalhar' explicitly tells the agent to call this tool first to learn what files exist. This provides clear usage context, though it does not explicitly mention alternatives or when not to use it. The sibling tool list makes the differentiation obvious.

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 explicitly states 'Não altera nada', which directly communicates that the operation is non-destructive. It also specifies the data read (duration, resolution, fps, codecs, size), giving a transparent picture of what the tool does. The output schema exists to cover the exact return structure, so the description need not repeat those details.

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 efficiently structured: a one-line summary of output fields, a clear usage directive, a non-destructive note, and a simple Args block. Every sentence earns its place with no redundant filler. Important information is front-loaded, making it easy for an agent 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?

For a simple one-parameter, read-only probing tool, the description covers all essential aspects: what it reads, when to use it, that it changes nothing, and how the path argument is interpreted. The presence of an output schema means return values are already declared structurally. There are no significant missing pieces given 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%, and the tool has one required parameter with no schema-level description. The description compensates fully by documenting 'path: Caminho do vídeo, relativo ao workspace', which adds critical semantics about the path being workspace-relative. For a single-parameter tool, this is complete and adds meaning beyond the bare schema declaration.

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 a clear, specific verb and resource: 'Lê duração, resolução, fps, codecs e tamanho de um vídeo' — it enumerates exactly what the tool reads. This differentiates it from siblings like cut_video or concat_videos by focusing on metadata probing rather than manipulation. The purpose is unambiguous and the tool name is reinforced without being a tautology.

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 to use the tool before cutting or concatenating to know the file, which gives clear contextual placement among the sibling operations. It does not explicitly name alternatives or state when not to use it, but the primary use case is well defined. This is a clear context with no exclusions, matching a score of 4 rather than 5.

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

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

With no annotations provided, the description carries the full behavioral burden and does well: it discloses that the operation is slow, runs as a background job by default, returns timestamps, and can auto-detect language. It could add more detail about job lifecycle or blocking behavior when background=false, but the key traits an agent needs are present.

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 front-loaded: purpose first, then collaboration guidance, then the important performance/background note, then concise parameter definitions. Every sentence adds value and nothing is redundant with the schema.

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

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

For a 4-parameter transcription tool with an output schema present, the description covers the required input semantics, the behavioral caveats, and the relevant sibling collaboration. An agent has enough information to call the tool correctly and interpret the background-job 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, and it does thoroughly: path is specified as relative to workspace, model_size enumerates the available Whisper options, language gives example codes and clarifies auto-detection, and background is explained as running as a job and returning job_id. Every parameter gains meaning beyond 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 opens with a specific verb and resource: 'Transcreve a fala de um áudio ou vídeo, com tempos de cada trecho,' making it clear this tool produces a timestamped transcript. It also distinguishes itself from sibling tools by positioning it as the companion to cut_video for content-based cutting, so an agent can tell it apart from tools like probe_video or extract_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?

The description gives clear usage context: use it to transcribe speech and combine it with cut_video when cutting by spoken content. It also warns that the tool is slow and therefore runs in background by default, helping an agent set expectations. It does not explicitly name when-not-to-use alternatives, but no direct alternative transcription tool exists among the siblings.

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