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

No annotations are provided, so the description carries the full burden. It does disclose genuinely useful behavior – this is a mutation that always appends at the end, in_s/out_s are source-relative not timeline-relative, and a producer_id is returned. It says nothing about permissions, persistence, or what happens when out_s is omitted or lies beyond the source duration.

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

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

Three short sentences, zero filler, with the primary action front-loaded and the two clarifying facts following immediately. 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?

With no annotations and no output schema, the description does cover the operation, the unit semantics, and the return value. It still leaves gaps an agent needs to call correctly: whether the project must already exist, whether a failed path is an error or a silent no-op, and what happens if out_s is unset.

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%, but the description clarifies the two non-obvious parameters by pinning in_s/out_s to seconds in the SOURCE file, which is exactly the ambiguity an agent would hit. clip_path and project_name are left entirely to the schema, and the omitted-out_s behavior (implicitly 'to end of source') is never stated.

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

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

States a specific verb and resource: append a span of a source video to the end of the timeline. The append-to-end framing implicitly separates it from trim_clip, split_clip, and move_clip, though no sibling is ever named explicitly.

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

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

Usage is implied by 'append ... to the end of the timeline' – an agent can infer this adds new material rather than editing existing clips. But there is no explicit when-to-use, no alternatives named, and no exclusion such as 'use move_clip to reposition an existing clip'.

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 for what is clearly a write/mutation operation. 'Burn' hints at persistence, but nothing is said about reversibility, whether the overlay replaces or coexists with existing text, rendering implications, or permission requirements. Only the time-scoping behavior is disclosed.

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

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

One front-loaded sentence with a useful parenthetical defining the time unit; nothing is wasted. It is arguably too terse for a 9-parameter mutation, but there is no filler or 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?

A 9-parameter mutation tool with no annotations, no output schema, and zero schema coverage needs considerably more: required-vs-optional semantics, defaults behavior, coordinate/alignment meaning, and side effects. The description covers only the temporal bounds.

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

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

Schema description coverage is 0% across 9 parameters, so the description must compensate. It clarifies only that start_s/end_s are timeline seconds; project_name, color, bg_color, font_size, halign, and valign get no explanation, leaving the majority of the surface undocumented.

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

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

The description states a specific verb ('Burn') and resource ('a text title onto the timeline'), which is clearly distinct from clip-level siblings like add_clip or trim_clip. It stops short of naming how it differs from other overlay/effect tools, but the action 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?

There is no guidance on when to choose this over siblings, no prerequisites (e.g., whether the project must already exist), and no note on what happens if the range overlaps existing overlays or exceeds the timeline length. Usage 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 says nothing about mutation side effects, whether existing filters are overwritten, whether the operation is reversible, permission requirements, or what happens if producer_id is invalid.

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

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

The purpose is front-loaded in the first sentence, followed immediately by filter values and parameter formats. There is no filler, and the dense format is appropriate for an enum-heavy parameter mapping.

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 gives enough detail to choose a filter and construct its params, but it is incomplete for a mutation tool with no annotations and no output schema. Missing are the meaning of producer_id as the clip reference and the behavioral consequences of applying a filter.

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

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

Schema description coverage is 0%, and the description compensates well for filter_name and the nested params object by listing allowed filters and their parameter shapes. However, it never explains project_name or producer_id, leaving the required clip identifier semantics undocumented.

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

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

The description states a specific verb and resource: apply a filter to a clip. It also enumerates the exact filter types, which clearly distinguishes this tool from sibling timeline-editing tools like trim_clip, move_clip, and set_transition.

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 does not explain when to use apply_filter versus alternatives, nor does it state prerequisites such as whether the clip must already exist on the timeline. The allowed filter list implies usage but gives no routing 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says the project is 'empty', which is useful state information, but it doesn't say what happens if a project with the same name already exists, where the file is written, what is returned (e.g. a project id), or whether creation can fail. For a mutation tool with zero annotation coverage, these gaps are significant.

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 with no wasted words. The core action is front-loaded and the parameter hint follows immediately, which is an efficient structure for a short definition.

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 creation tool with no output schema, the description covers the essential action and the most important dimension choices. However, with 0% schema coverage and no annotations, the unexplained fps parameter and the absence of any statement about the result or destination leave it only minimally complete.

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

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

Schema description coverage is 0%, so the description must compensate for all four parameters. It explains the width/height intent with a concrete example, but 'fps' is never mentioned and 'name' is only implied by the tool's purpose, leaving two parameters with no semantic support beyond their 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 states a specific verb and resource ('Create a new empty MLT/Shotcut project'), which is enough to distinguish it from siblings like list_projects, project_info, and add_clip. It doesn't explicitly name a sibling alternative, but the creation-versus-inspection boundary is obvious from the wording.

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 only guidance given is about picking width/height to match the delivery format ('e.g. 1080x1920 for vertical'), which is parameter advice rather than when-to-use advice. There is no statement about when this tool should be chosen over alternatives, nor about prerequisites such as the project needing to exist before add_clip calls. Usage is implied rather than spelled out.

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. It implies a read operation by using 'Return' and describes the returned scope, but it does not explicitly confirm read-only behavior, mention permissions or prerequisites, or describe what happens if the project is missing.

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 that lists the returned components without filler. Every phrase contributes to describing the output scope.

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?

Because there is no output schema, the description appropriately explains what the tool returns in reasonable detail. However, it leaves the sole required parameter undocumented and gives no usage or behavioral context, so it is 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?

There is one required parameter, project_name, with 0% schema description coverage. The description does not mention project_name at all, so it provides no meaning, expected format, or naming guidance beyond the bare schema constraints.

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 ('Return') and resource ('the whole edit'), then enumerates the returned content (clips, source in/out, filters, transitions, titles). It is clear what the tool does, but it does not explicitly differentiate itself from related read siblings like project_info or list_projects.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as project_info, list_projects, or render. The implied usage is to inspect the full timeline, but the description provides no conditions, exclusions, 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?

No annotations are provided, so the description carries the full burden; it does disclose the important scoping traits (work directory only, .mlt extension only), which implies non-recursive and filtered behavior. It does not say what happens with zero results, whether ordering is defined, or what the entries look like (names vs. 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?

A single sentence with zero waste, front-loading the scope constraint (work directory) and the file filter. Nothing could be removed without losing information.

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

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

For a zero-param tool this is close to sufficient, but there is no output schema, so the description should say what is returned (filenames only, paths, count). That return-format ambiguity is the one real gap for an agent planning the next 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a no-argument, whole-directory listing.

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

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

States a specific verb ("List") and resource ("all .mlt project files"), plus the scope ("in the work directory"). It is clearly distinct from create_project or project_info by verb alone, though it never explicitly contrasts itself with project_info, which could also surface project data.

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 versus project_info or create_project, and no prerequisites or exclusions stated. The agent must infer that this is the discovery step before project_info or render.

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, yet it discloses almost nothing about behavior: not whether the move is destructive, whether other clips are re-indexed, whether it requires auth or an unlocked timeline, or what it returns. The only real disclosure is the 1-based indexing semantics, which is useful but thin for a mutation 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 tight sentence with the key semantic detail (1-based position) front-loaded and no filler. It is efficient, though the brevity is partly under-specification rather than pure concision.

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-required-parameter mutation tool with no annotations and no output schema, the description leaves the clip identity, side effects on surrounding clips, and failure conditions unstated. It is not sufficient to invoke confidently without guessing.

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 every parameter depends on the description. It adds meaning for to_position ('1-based position') but leaves producer_id and project_name completely unexplained, including which one actually identifies the clip being moved versus the containing project.

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

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

States a specific verb and resource ('Move a clip') plus the target concept ('new 1-based position on the timeline'), which is more than a restatement of the name. However, it never says how the clip is identified (the schema has no clip_id, only an unexplained producer_id) and gives no differentiation from siblings like trim_clip, split_clip, or remove_clip, which also act on 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?

There is no guidance on when to use this versus trim_clip or split_clip, and no prerequisites or exclusions. With several clip-mutating siblings, an agent must infer the boundary between 'move' and 'trim'/'split' entirely on its own.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Return' implies a read, but it says nothing about what 'summary metadata' actually contains, what happens if the project does not exist, or any permission requirements.

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

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

A single efficient sentence with the resource front-loaded and no filler. Its brevity is appropriate in form, though it comes at the cost of the missing detail noted elsewhere.

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

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

With no annotations, no output schema, and an undocumented parameter, the description should explain the return contents and failure behavior. It does neither, leaving the agent unable to predict the response shape of a tool whose whole purpose is returning data.

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 only parameter (project_name) is documented nowhere; the description adds only the word 'existing', hinting that the name must resolve to a real project. That is a marginal semantic contribution against a total coverage gap.

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

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

States a specific verb ('Return') and resource ('summary metadata about an existing project'), so the agent knows this is a read of project-level details. However, it does nothing to distinguish itself from siblings like list_projects or get_timeline, which an agent could plausibly confuse it with.

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

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

There is no when-to-use guidance and no mention of alternatives such as list_projects for enumeration or get_timeline for timeline content. The agent must infer the calling context entirely from the name.

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. "Ripple-delete" usefully signals that downstream timeline content shifts, but the description does not state that the operation is destructive/irreversible, what permissions are required, or what happens to effects or overlays on the removed clip.

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

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

The description is a single front-loaded sentence with no filler. It is efficient, though its brevity contributes to the missing operational details noted elsewhere.

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

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

For a destructive timeline mutation with no annotations, no output schema, and 0% parameter documentation, the description is too sparse. It discloses the ripple behavior but omits reversibility, permissions, return behavior, and how the clip is targeted.

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 two required parameters. It does not mention producer_id or project_name at all, and notably the schema exposes no explicit clip identifier, so the agent is left without guidance on how the target clip is identified.

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

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

The description gives a specific verb and resource: "Ripple-delete one clip from the timeline." This is clear and distinguishes deletion from operations like trim_clip or split_clip, though it does not explicitly contrast with the close sibling remove_segment.

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 "one clip" provides some scope, but the description gives no explicit guidance on when to use this tool instead of remove_segment, trim_clip, or split_clip. There are no stated prerequisites or exclusions for an agent to follow.

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. 'Ripple-delete' usefully implies that subsequent content shifts, but it does not say whether deletion is permanent/undoable, what happens to clips that straddle the boundaries, or whether a project lock is required for a destructive timeline edit.

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 well-formed sentence with the operation and boundaries front-loaded and no filler. Its brevity is close to under-specification rather than verbosity, so it earns a 4 rather than 5.

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

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

This is a destructive timeline mutation with no annotations, no output schema, 0% parameter coverage, and three required parameters. The description does not cover consequences, reversibility, or the project scope, which leaves real gaps an agent must guess at.

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

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

Schema description coverage is 0%, so the description must compensate for all three parameters. It clarifies that start_s and end_s are timeline positions for the span to be removed, but it never mentions project_name or the unit (seconds) explicitly, leaving the most important scoping parameter undocumented anywhere.

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

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

States a specific verb ('ripple-delete') and resource ('timeline span between start_s and end_s'), which is more informative than a bare 'remove'. However, it never distinguishes itself from the sibling tools remove_clip and trim_clip, so an agent cannot tell which removal semantics apply without further inference.

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 indication of when to use this versus remove_clip, trim_clip, or split_clip, and no prerequisites or exclusions are given. The word 'ripple' hints at a behavioral consequence but not at a usage decision.

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

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

No annotations are provided, so the description carries the full behavioral burden. It states that a video file is produced and that 'mp4-project' preserves frame size, but it does not disclose whether output_path is overwritten, whether rendering is long-running, 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?

The description is two front-loaded sentences with no filler. The preset caveat is placed immediately after the purpose, making efficient use of the short space.

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 render tool with no annotations, no output schema, and 0% schema description coverage, the description is too sparse. An agent can infer the basic call, but lacks important context about return value, overwrite behavior, and render duration.

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 only explains the 'mp4-project' preset value; it does not clarify project_name or output_path semantics, such as whether the project must already exist or whether output_path is a file path with overwrite behavior.

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

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

The description states a specific verb and resource: 'Render a project to a video file with melt.' It clearly distinguishes the export/render operation from the project-editing siblings such as add_clip and trim_clip.

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 purpose implies it is the final export step, but there is no explicit guidance on when to use it versus alternatives or prerequisites such as requiring an existing project. Usage is implied rather than documented.

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

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

With no annotations, the description carries the full burden, and it does disclose a valuable non-obvious side effect: the timeline shortens by duration_s. However, it omits permission requirements, overwrite/idempotency behavior, error conditions for non-adjacent clips, and the fact that a style parameter (defaulting to 'luma') can change the visual result entirely.

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

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

Two tight sentences with zero waste: the core operation and its side effect are front-loaded. Every clause carries information.

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

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

This is a mutation tool with no annotations, no output schema, and zero parameter documentation, yet the description covers only the core mechanic. An agent still lacks the style value set, adjacency failure behavior, and whether an existing transition is replaced — gaps an agent needs before invoking 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% across 5 parameters, so the description must compensate. It only explains duration_s (via its timeline-shortening effect) and implies from/to through 'between two ADJACENT clips'; style and project_name are entirely undocumented, and no valid style values are given.

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

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

States a specific verb+resource (a crossfade transition between two clips) and clarifies it is both a video dissolve and an audio mix, which distinguishes it from clip-editing siblings like trim_clip or split_clip. It does not explicitly name or route against any sibling tool, keeping it short of a 5.

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

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

Usage is implied through the 'ADJACENT clips' precondition and the note that the timeline shortens, which tells an agent this is a timeline-altering edit. There is no explicit when-to-use vs. alternative guidance, no statement about what happens if clips are not adjacent, and no mention of replacing an existing transition.

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 clarifies that the offset is relative to the clip's own in point, but says nothing about what happens to the resulting segments, whether the operation is destructive, or what preconditions (clip must exist, split point within bounds) apply.

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

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

A single tight sentence with the key offset semantics front-loaded and no wasted words. Its brevity is efficient, though it edges toward under-specification rather than over-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?

For a mutation tool with no annotations, no output schema, and 0% parameter description coverage, the description is too thin. It omits the identity of the clip parameter, post-split state, and error conditions an agent needs to invoke it reliably.

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

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

Schema coverage is 0%, so the description must document all three parameters. It meaningfully explains at_s (seconds after the in point), but producer_id is ambiguous — it appears to identify the clip but is never explained — and project_name is left to the schema pattern alone.

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

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

States a specific verb (split) and resource (clip) plus the offset semantics, which distinguishes it from trim_clip and remove_segment. It does not explicitly name or rule out the nearest alternative, so it falls just short of a 5.

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

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

The mechanics imply when to use it (cutting a clip into two at a point), but there is no explicit guidance on when to prefer this over trim_clip, remove_segment, or move_clip. The agent must infer the selection condition.

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

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

No annotations are provided, so the description carries the full behavioral burden and does not meet it: it doesn't say whether the trim is destructive to existing clip data, what happens if in_s exceeds out_s, or whether producer_id is a clip identifier or a media source. 'Already on the timeline' hints at a precondition but nothing about reversibility or 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?

A single clear sentence with the key qualifier ('already on the timeline') front-loaded and no filler. It earns its place, though it is thin enough that a second clause on scope would not have hurt.

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 mutation tool with no annotations, no output schema, and 0% schema coverage, one sentence is well short of what an agent needs to invoke it safely. Missing: which parameter identifies the clip, what the call returns, and what happens on invalid ranges.

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 only does so for in_s/out_s via 'source in/out points'. The two required parameters, project_name and producer_id, get no explanation at all — notably whether producer_id refers to the clip being trimmed. Units for in_s/out_s are implied as seconds only by the name.

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

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

Specific verb ('Change the source in/out points') applied to a specific resource ('a clip already on the timeline'), which separates it from move_clip and split_clip. It stops short of naming those siblings explicitly, so the differentiation is inferred rather than stated.

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 statement of when to use this versus move_clip, split_clip, or remove_segment, and no preconditions such as the clip needing to already exist. The agent must infer usage from the one-line purpose.

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