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

With no annotations, the description carries the full behavioral burden. It reveals the sidecar JSON mechanism but does not disclose file naming, duplicate behavior, overwrite semantics, path restrictions, permissions, or reversibility of the add operation.

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

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

The description is a single efficient sentence with zero wasted words. It front-loads the core action and adds a useful contextual reason for the sidecar approach.

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 six parameters, zero schema descriptions, and no annotations, the description is far too sparse. It omits parameter formats, sidecar naming conventions, path handling, and any behavioral constraints, leaving critical information missing.

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

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

Schema description coverage is 0% and the description adds no meaning to any of the six parameters. It does not clarify target, time units, name constraints, note/color defaults, or allow_any_path behavior, leaving the agent without the information needed to supply correct values.

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

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

Description states a specific verb and resource: add a marker to a sidecar JSON next to a media or timeline file. The FFmpeg context and sidecar mechanism make it distinguishably different from siblings like list_markers.

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 on when to use this tool versus alternatives such as list_markers or other edit tools. The parenthetical about FFmpeg explains why sidecars exist but does not state conditions, prerequisites, or when not to use this 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?

Annotations are absent, so the description carries the full burden of behavioral disclosure, yet it only reveals that ffmpeg's lut3d filter is used. It does not disclose that overwrite defaults to true (a destructive trait), that allow_any_path implies default path validation, or what happens on failure.

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

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

A single front-loaded sentence stating the action, resource, and method with zero filler. Every word contributes something, and it is as compact as it can be while carrying the core 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?

For a tool with 6 parameters, no annotations, and 0% schema coverage, the description is far too thin. Although an output schema exists, parameter semantics and behavioral edge cases are uncovered, leaving an agent to guess at interp options and path restrictions.

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

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

With 0% schema description coverage, the description must compensate, but it only adds a .cube format hint relevant to lut_path. interp's accepted values, the meaning of allow_any_path, and the overwrite behavior are all left unexplained.

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

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

The description names a specific verb (apply), resource (.cube LUT), target (clip), and mechanism (ffmpeg lut3d). The purpose is unambiguous and inherently distinct from the closest sibling generate_lut (create vs. apply) and from the generic run_ffmpeg.

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 on when to use this tool versus alternatives such as generate_lut or run_ffmpeg. It does not state prerequisites (e.g., ffmpeg availability), exclusions, or conditions under which a sibling tool would be preferable.

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 behavioral disclosure burden. It mentions the track-0 concatenation rule and the optional save_as, but omits behaviors of reencode, overwrite, and allow_any_path (e.g., default true, path restrictions). No side effects or prerequisites are disclosed beyond the basic render action.

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 with the primary action. It includes a compact schema definition and a key behavioral rule. However, it could be structured with explicit parameter notes, but overall it is efficient without verbosity.

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 aren't needed. However, the description fails to explain critical parameters (reencode, overwrite, allow_any_path) and lacks guidance on when to use this tool vs siblings. For a tool with 6 parameters and nested objects, more context is warranted.

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 timeline schema and mentions save_as, but does not explain reencode, overwrite, or allow_any_path. Partial coverage; not all parameters are documented in either schema or description.

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

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

The description clearly states it renders a JSON timeline to an output file, with a specific resource (timeline) and action (render). It doesn't explicitly differentiate from siblings like concat_clips or run_ffmpeg, but the timeline-composition focus is distinct enough. The inclusion of a timeline schema adds clarity.

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 context on how the timeline is structured (track 0 concatenation) but does not explicitly state when to use this tool over alternatives like concat_clips or trim_clip. It implies usage for timeline-based rendering but lacks explicit when/when-not guidance.

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

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

With no annotations, the description carries the transparency burden. It does disclose meaningful behavior: stream copy vs re-encode, with a robustness tradeoff. However, it does not mention that overwrite defaults to true, what happens on failure, or any path-related restrictions, so the disclosure is partial.

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 with no filler. The core operation is front-loaded, and the method distinction is packed compactly into the second sentence, making it easy for an agent to parse quickly.

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 five parameters, zero schema descriptions, and no annotations, this definition is not fully complete. It covers the important method decision and benefits from an output schema, but the overwrite behavior and allow_any_path guardrail are left unexplained, which could lead to incorrect 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. It adds real meaning to the 'method' parameter by explaining the two values and their tradeoffs. But it leaves inputs, output_path, overwrite, and allow_any_path semantically uncovered beyond their 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 uses a specific verb ('Concatenate') and resource ('clips'), which clearly conveys the core operation. It does not explicitly state that it produces a single output file or explain how it differs from sibling tools like compose_timeline, but the method qualifiers add useful specificity.

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 practical method-level guidance: 'demuxer' is for same-codec stream copy and 'filter' is a re-encode for more robust concatenation. However, it does not say when to choose concat_clips over sibling tools such as run_ffmpeg or compose_timeline, so tool-selection 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 provided, the description carries the full burden of behavioral disclosure. It mentions the tool is a 'free approximation' and not full color management, which is useful, but it omits details on file output behavior, overwrite semantics, path restrictions (e.g., allow_any_path), or potential failure 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 two sentences with no fluff. The core purpose and key caveat are front-loaded, making it easy to scan. Every word earns its place.

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

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

Given 8 parameters, no annotations, and an output schema that is not described, the description is too sparse. It does not explain the output file format beyond '.cube', does not clarify the meaning of size or allow_any_path, and lacks guidance on expected usage patterns. The description is inadequate for an agent to call the tool confidently without opening the schema.

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

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

Schema description coverage is 0%, so the description must explain parameters. It covers exposure, contrast, saturation, and temperature, but leaves size, title, output_path, and allow_any_path unexplained. This is insufficient for an 8-parameter tool, especially security-relevant parameters like allow_any_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 ('Generate'), a clear resource ('.cube 3D LUT'), and enumerates the creative parameters. It implicitly differentiates from the sibling 'apply_lut' by focusing on generation rather than application, and the caveat 'not DaVinci Resolve color management' further clarifies 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?

The description implies a use case (grading workflows with a free approximation) but does not explicitly state when to choose this tool over alternatives like 'apply_lut' or when not to use it. It lacks direct routing or exclusion criteria.

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, and it only contributes 'matches live build', which is a useful but minimal hint that docs are retrieved from the current binary. It does not disclose behavior for unknown names, whether the call hits the network, or any side effects.

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

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

The description is a single, front-loaded sentence with no wasted wording, and the core purpose is immediately visible. It is slightly under-specified, but structure and conciseness themselves are good.

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 the output schema filling in return-value details, the description leaves the 'kind' parameter unexplained and gives no decision aid for siblings. For a tool with no annotations and incomplete param documentation, this is not enough context 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%, so the description must document parameters itself, but it only clarifies 'name'; it never mentions the 'kind' parameter, its default of 'auto', or what values it accepts. A caller cannot determine how to set 'kind' from this description or 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 clear verb and resource ('Get detailed help for a filter, encoder, decoder, muxer, or demuxer') and adds a defining constraint ('by name (matches live build)'). It makes the object of the tool obvious, though it never explicitly contrasts itself with the sibling search_ffmpeg_docs.

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

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

There is no guidance about when to choose this tool over search_ffmpeg_docs or the other sibling tools. The 'by name' phrase weakly implies a direct-name lookup, but the description does not state that users with an incomplete name should use a search tool instead.

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

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

No annotations are provided, so the description carries the full burden. The verb 'Return' implies a read-only operation with no side effects, but it does not explicitly declare that it makes no changes. This is adequate for a simple version check but could be more explicit.

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 zero wasted words. Every word adds meaning, and the structure is immediately scannable.

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 zero-parameter complexity and the presence of an output schema, the description is complete. An agent can call this tool correctly without any additional information beyond what the schema and description provide.

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

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

The tool has zero parameters, and the baseline for 0-parameter tools is 4. There is nothing for the description to explain, and the input schema fully covers the empty parameter set.

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 explicitly states the verb 'Return' and the exact resources: ffmpeg/ffprobe versions and the MCP server version. This clearly distinguishes it from all sibling tools, which are focused on media operations, docs, or rendering.

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 when you need version information. However, it does not explicitly mention when to use it versus alternatives or provide exclusions. For a simple version probe, this is acceptable but not fully explicit.

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

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

No annotations are provided, so the description carries the full burden. The description only states what the tool returns but does not disclose whether it is a read-only operation, if it has side effects, or any caching or rate-limit behavior. For a simple informational tool this is a minor gap, but the description does not go beyond the literal function.

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, concise sentence that conveys the full purpose without any fluff. Front-loaded with the primary action and secondary content. Every word earns its place.

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

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

For a zero-parameter tool with an output schema, the description covers the essentials: what it returns. It does not need to explain return format since the output schema exists. The description is sufficient for an agent to call it correctly, though it could optionally mention that it is safe to call anytime.

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 schema coverage is effectively 100%. With no parameters to describe, the baseline is 4. The description does not need to add parameter semantics since there are none.

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 returns brief notes for the server version and a summary of FFmpeg build flags. This is specific enough to distinguish from siblings like get_version, which likely returns only version numbers. 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 explicit guidance on when to use this tool vs alternatives. It is implied that it is used when version notes or build flag summaries are needed, but no alternatives or exclusions are mentioned. Given the tool's simplicity, some guidance would be helpful but its absence is not fatal.

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

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

The word 'List' signals read-only behavior, and the description identifies the data source as sidecar JSON, which provides basic transparency. With no annotations available, it omits useful behavioral details such as what happens when the sidecar is missing, path restrictions, or the role of allow_any_path.

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

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

The description is a single focused sentence with no filler. It front-loads the key operation and object, then adds the relevant sidecar and file-type context without unnecessary elaboration.

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?

Although an output schema exists and the tool appears simple, there are no annotations and one parameter is entirely unexplained. An agent can tell what the tool roughly does, but it lacks enough context to handle path-safety or edge-case behavior confidently.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It partially explains 'target' as a media or timeline file, but it leaves 'allow_any_path' completely undefined and provides no format, path, or resolution details.

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 clear resource ('markers from the sidecar JSON'), and clarifies that the input is a media or timeline file. This makes the operation clearly distinct from siblings like add_marker, which creates markers, even though alternatives are not explicitly named.

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 intended use is implied: read existing markers associated with a media or timeline file. However, it does not state when to prefer an alternative tool, nor does it provide any exclusions or conditions such as when the sidecar file must already exist.

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 responsibility for disclosing behavioral traits. It states that it returns raw JSON and metadata, implying a read-only operation, but it never explicitly confirms that it does not modify files or have side effects. It also doesn't disclose any security implications of the allow_any_path parameter or mention error behaviors. This is a significant gap for a tool that could potentially access arbitrary paths.

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 front-loads the purpose and lists key outputs. It is efficient and free of fluff, but it lacks structure like bullet points or separate notes for parameters. Still, it earns a solid score for its brevity and clear focus.

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?

While an output schema exists (which covers return format), the description omits essential context: parameter explanations, usage scenarios, and safety notes. Given the tool has two parameters with zero schema coverage, the description should compensate but does not. The overall picture is incomplete for an agent to confidently invoke this tool, especially with allow_any_path being a potential security-sensitive option.

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 both parameters. It does not mention 'path' or 'allow_any_path' at all. The allow_any_path parameter, which likely controls security restrictions, is completely unexplained, leaving the agent to guess its semantics. The description adds no value 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 probes a media file with ffprobe and lists what it returns (streams, duration, resolution, codecs, raw JSON). It uses a specific verb and resource, making the primary function unambiguous. However, it doesn't explicitly differentiate from sibling tools like run_ffmpeg or get_ffmpeg_docs, though the probe intent is distinct enough.

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 versus alternatives. It doesn't mention that it's for metadata inspection only, or contrast it with run_ffmpeg for processing. The agent is left to infer usage from the tool name and description, which is insufficient for correct tool selection among many siblings.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses that paths outside the workspace are blocked, allow_any_path can override that, -y is only used with overwrite=true, -n is used otherwise, and shell=True is never used. This gives agents a solid safety and execution model, though some lower-level behaviors like exact output/error handling are not described.

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 short and well-structured: invocation model first, tool preference second, then critical safety and flag behavior. Every sentence earns its place with 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?

For a low-level wrapper with 5 parameters, no annotation coverage, and many sibling tools, the description covers the essential invocation, safety, and overwrite semantics. The output schema presumably covers return values. The main gaps are the lack of explanation for timeout_seconds and working_directory, but these are optional and inferable from their names.

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

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

Schema description coverage is 0%, so the description must compensate. It does add meaning for args (argv not shell string), overwrite (maps to -y/-n), and allow_any_path (path safety override). However, timeout_seconds and working_directory are not addressed at all, leaving those parameter semantics mostly to their names and defaults.

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: 'Run ffmpeg with an argv argument list (NOT a shell string).' It also distinguishes itself from sibling structured edit tools by saying 'Prefer structured edit tools when possible.' This makes the tool's scope and role immediately clear.

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

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

The description gives clear guidance to prefer structured edit tools when possible, establishing when this low-level tool should be used. It also provides important context about path restrictions and overwrite behavior. It doesn't name specific sibling tools or give an explicit when-not-to-use list, but the guidance is directionally 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 carry the behavioral disclosure burden. It does disclose that the tool runs a job and returns an exit code and output probe summary, which is useful. However, it omits side effects like file overwriting (the overwrite parameter hints at this), long-running behavior, failure behavior for missing jobs, or safety/idempotency characteristics. The description provides basic behavioral information but not comprehensive transparency.

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

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

The description is a single sentence that front-loads the action ('Run') and resource, then states the output. There is no filler, tautology, or wasted words. It is an appropriately sized and well-structured description.

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

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

This tool has 3 parameters with zero schema descriptions and no annotations. While an output schema exists and may document return values, the description is too sparse for an agent to call this correctly in a real context. It fails to explain prerequisites (the job must already be set), parameter semantics, or failure modes. For a non-trivial execution tool, this leaves too much unspecified.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It only loosely implies job_id via 'previously defined render job'. It says nothing about overwrite or allow_any_path, their defaults, or when to use them. An agent cannot deduce what overwrite=true means or when allow_any_path should be set, which is a critical gap.

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

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

The description states a specific verb ('Run'), a specific resource ('previously defined render job'), and the result ('exit code + output probe summary'). This clearly distinguishes it from set_render_job (which defines jobs) and run_ffmpeg (which runs arbitrary ffmpeg commands), so an agent can tell what this tool does without confusion.

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 'previously defined render job' implies the tool should be used after set_render_job, but it does not explicitly say that. No alternatives are named, and no conditions or exclusions are provided. The usage guidance is implied rather than explicitly stated.

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

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

With no annotations, the description must carry the full behavioral burden. It states it searches help listings, implying a read-only operation, but doesn't mention case sensitivity, regex support, or any side effects. This is adequate but minimal; it adds some context beyond a tautology but lacks depth.

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 concise sentence, front-loaded with the core purpose. No wasted words, though it could have included limit details without losing conciseness. Appropriate length for a simple search tool.

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

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

The tool is simple, and an output schema exists to cover return values. However, the description doesn't explain the role of the limit parameter or the nature of the search (e.g., exact match, fuzzy). It's minimally complete but leaves room for ambiguity about how the query is matched.

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

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

Schema description coverage is 0%, so the description should compensate. It mentions the query string but says nothing about the limit parameter. Without any schema descriptions, the agent has no guidance on the meaning or default behavior of limit, making this a weak compensation.

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

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

The description clearly states the tool searches installed FFmpeg help listings for a query string, using a specific verb and resource. It distinguishes from siblings like run_ffmpeg and get_ffmpeg_docs by narrowing to filters/encoders/decoders help listings, though it doesn't explicitly name alternatives.

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

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

No guidance is given on when to use this tool versus siblings like get_ffmpeg_docs or run_ffmpeg. The context of searching help listings is implied but no explicit when-to-use or when-not-to-use advice is provided.

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 behavioral disclosure, but it only says 'Define an export/render job'. It does not state whether this mutates state, overwrites an existing job, persists anything, or actually produces media. 'Define' hints at non-execution, but the operational behavior remains opaque.

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 tight, front-loaded sentence with no filler, and the key preset constraint is placed prominently. It is appropriately short for what it communicates, though it is somewhat underspecified.

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 five parameters, no annotations, and no schema-level parameter descriptions, the description provides only a minimal task statement. It does not cover the job lifecycle, parameter semantics, or how this differs from run_render, leaving an agent with materially incomplete information for a reliable call.

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

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

Schema description coverage is 0%, so the description should compensate by explaining parameters. It adds only the allowed preset values; it does not explain job_id, input_path, extra_args, or output_path, nor note that job_id and input_path are required.

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

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

The description identifies a concrete action ('Define') and resource ('export/render job'), and enumerates supported presets (h264_mp4, prores, webm), so an agent can tell it configures a render job rather than merely examining one. It does not explicitly contrast itself with the sibling run_render, so it misses the top score.

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

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

There is no guidance about when to call set_render_job relative to run_render or other sibling tools, nor any mention of prerequisites such as an existing input file or job lifecycle. The intention to prepare a job before rendering is implied, but that sequencing is left entirely to inference.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that an output path is written, but omits significant behavior: overwrite defaults to true and may replace an existing file, stream_copy controls re-encoding, allow_any_path restricts allowed paths, and no mention is made of ffmpeg dependency or return 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?

A single sentence with no filler, front-loaded with the core action. It is compact and scannable, though a structured mention of the trim modes could improve clarity further.

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

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

With 8 parameters, 0% schema coverage, and no annotations, the description is too thin to fully support invocation. Critical constraints—mutual exclusivity of end vs duration, default overwrite behavior, path safety flag, and time units—are missing even though an 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. It clarifies the relationship between start, end, and duration and names output_path, but leaves the other five parameters (overwrite, stream_copy, allow_any_path) and the units/format of timestamps unexplained.

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 identifies a specific verb and resource ('trim a clip') and states the two trim modes (start/end or start+duration) plus an output destination. It is clearly distinct from siblings like concat_clips, though it does not explicitly compare itself to other tools such as run_ffmpeg.

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 choose this tool over alternatives like run_ffmpeg, concat_clips, or verify_edit. The phrase 'Trim a clip' only implies intent; there are no prerequisites, exclusions, or selection conditions.

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

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

With no annotations provided, the description carries the full burden — and it does well. It discloses that the tool is deterministic, that it returns pass/fail plus diffs, and most valuably, it explains the expected_clip_count gotcha: the parameter is recorded for plan bookkeeping because a single rendered file cannot recover clip count. This prevents a real misuse where an agent assumes the tool verifies clip count from the 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?

Three sentences, front-loaded with the core purpose in sentence one, and the clip-count caveat in sentence three earns its place by disambiguating a misleading parameter name. The only slight waste is the abstract label 'deterministic verification bridge,' which adds flavor but little information beyond what sentence one 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?

The output schema covers return values, so that gap is acceptable. But for a 9-parameter tool with zero schema description coverage and no annotations, the description leaves too many parameters unexplained (allow_any_path is especially opaque). It explains the one genuinely confusing param (expected_clip_count) and the overall semantics, but an agent calling with non-default values would still be under-informed.

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 partially does. It explains that duration and resolution are the comparison dimensions, and it gives real semantic meaning to expected_clip_count. However, it leaves several non-obvious parameters undocumented: allow_any_path, duration_tolerance, max_duration/min_duration, and expected_duration vs. the duration bounds are never clarified, so an agent would still have to guess at their roles.

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: 'Compare an output file against an expected edit plan (duration, resolution)' and explicitly declares the return type ('pass/fail + diffs'). The second sentence — 'agents can assert plan vs probe results' — ties it to the probe_media sibling, making the distinction between probing (gathering facts) and verifying (asserting against a plan) clear.

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

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

The description implies when to use the tool ('deterministic verification bridge: agents can assert plan vs probe results') and positions it in a plan→probe→verify workflow. However, it never explicitly states when not to use it or names alternatives (e.g., when to use probe_media instead of verify_edit). Usage guidance is implied rather than stated.

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