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

With no annotations provided, the description carries the full burden and only reveals a prerequisite (CapCut closed) and the basic operation. It does not disclose side effects, error conditions, or whether the project is modified in-place, leaving notable gaps for a tool that alters a project file.

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

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

The description is two sentences with no wasted words, stating the purpose first and then a key prerequisite. It is highly front-loaded and easy to parse, earning every sentence's 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?

This tool modifies a CapCut project without annotations or an output schema, and the description omits important behavior such as how the project file is changed, failure modes, or handling of existing tracks. The prerequisite about CapCut being closed is useful but insufficient for safe operation given the tool's complexity.

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

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

The schema covers 60% of parameters (file, project, trackName), but the description adds no direct parameter explanations. The operation context implies startSeconds and durationSeconds refer to timeline placement, yet their units and behavioral meaning are not explicitly clarified, so the description only partially compensates for the undocumented parameters.

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

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

The description clearly states the action (adds), the object (an already-rendered clip), and the destination (a CapCut project on its own track). This distinguishes it from siblings like render_overlay or compose_overlay, which likely handle rendering or composition. The specific scope makes the purpose unambiguous.

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

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

The description implies usage for already-rendered clips and notes the prerequisite that CapCut must be closed, but it does not explicitly name alternatives or state when not to use this tool. It provides some context but lacks explicit exclusions or comparison to sibling tools, leaving the 'when vs alternatives' guidance 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.

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

With no annotations provided, the description must fully disclose the tool's behavior. It does list the exact checks performed and the verdict types, which is good. However, it does not explicitly state that the tool is read-only/does not modify the project, nor does it explain what happens after a 'refuse' verdict (e.g., whether the write is blocked). This leaves some ambiguity, so the description earns a moderate score rather than higher.

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

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

The description is two sentences. The first sentence is dense but information-packed, listing all major checks and the verdict scale. The second sentence is a direct imperative on usage. Every word earns its place; there is no padding 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?

Given the tool has one parameter and no output schema, the description provides substantial context: it lists the checks performed, the verdict values, and the explicit instruction to run before writing. It does not describe the return format or error behavior, but for a pre-write guard with this level of detail, it is almost complete. The lack of output schema is partially mitigated by the verdict enumeration.

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 100%: the parameter 'project' has a description 'Path to the project folder or its draft_content.json'. The tool description adds context that this project is checked for compatibility, but it provides no additional syntax, formatting, or constraint details beyond the schema. Baseline 3 is appropriate because the schema already fully documents the parameter.

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

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

The description clearly states the tool's purpose: to produce a verdict (ok/warn/refuse) on whether a project is safe to modify. It enumerates specific checks (CapCut vs JianYing, upstream write guard, editor running, storage-mirror agreement, lint errors, ffmpeg/ffprobe). This distinguishes it from sibling tools that perform modifications (add_overlay, render_overlay) or inspection (inspect_project).

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

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

The description explicitly says 'Run this before writing,' which is a clear directive for when to use the tool. It doesn't explicitly list alternatives or when not to use it, but the context of sibling write tools implies it's a pre-flight check for those operations. This is sufficient guidance for an AI agent to sequence the tool appropriately.

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

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

No annotations are present, so the description must carry the full burden. It does state the key behavior: rendering a transparent overlay and adding it to the project. However, it lacks details about side effects, reversibility, or whether existing overlays are modified. This is a moderate disclosure but with clear gaps.

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

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

The description is two sentences, front-loaded with the primary action and followed by the key alternative. Every word earns its place; there is no redundant 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?

With 13 parameters, a rich schema, and no output schema, the description provides enough context for correct invocation: it names the operation, the project mutation, and the alternative tool. It omits error handling or explicit side-effect warnings, but the schema covers parameter details and the purpose is clear, making it adequate.

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 85%, which is high, so the baseline is 3. The description adds no parameter-specific semantics beyond what the schema already provides, and the schema includes defaults and enum explanations, so the description does not need to compensate.

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 renders an overlay and adds it to the project at a specific time. It distinguishes itself from the sibling render_overlay by noting the common case for using render_overlay separately, making the purpose unambiguous.

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

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

The description explicitly provides a usage guideline: use render_overlay separately when the same graphic is reused across projects. This gives a clear when-not-to-use scenario and implies compose_overlay is for one-off overlays, effectively covering the main alternative.

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

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

With no annotations, the description discloses important behavioral details: whole-word case-insensitive highlighting, byte-offset correctness for non-Latin scripts, and the prerequisite that CapCut be closed. It does not mention potential overwriting of existing tracks, but the provided depth is above average.

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 five concise sentences, each adding distinct value: core function, preset options, highlighting behavior, offset correctness, and the prerequisite. It front-loads the main action and avoids 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?

For a 9-parameter tool with nested objects and no output schema, the description covers key aspects: input types, segmentation, styling presets, highlighting, encoding correctness, and usage condition. It does not explain return values or interaction with existing caption tracks, but those are minor gaps given the tool's import nature.

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 78%, so most parameters are already documented. The description adds meaning for 'preset' by listing choices and explains the case-insensitive behavior of 'highlight', but it does not elaborate on parameters like trackName, colorCycle, or timeOffsetSeconds, which are left to 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 clearly states the tool converts an SRT file or raw text into a styled text track with one segment per cue. It specifies the resource (SRT), the action (import as styled track), and distinguishes it from siblings focused on overlays or restyling existing captions.

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 the name and context: importing new subtitles. The description notes a prerequisite ('Requires CapCut to be closed') but does not explicitly contrast with alternatives like restyle_captions or add_overlay, nor does it state 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?

No annotations are provided, so the description carries the full burden. It explicitly states 'Read-only', disclosing the safety profile, and describes what data is returned, which is valuable behavioral context beyond the schema.

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

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

The description is two concise sentences, front-loaded with 'Reads a project', and every phrase adds value. No redundancy or fluff.

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

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

The tool is simple with one parameter and no output schema. The description sufficiently covers what is returned (duration, resolution, tracks, subtitles, material buckets) and the read-only nature, making it complete for an agent to select and invoke.

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 100% and the only parameter 'project' is fully described in the schema. The description does not add extra meaning to the parameter itself, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Reads') and clearly states the resource (a CapCut project) and what it does. It distinguishes itself from siblings by focusing on inspecting one project's internals rather than listing projects or modifying them.

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

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

The description implies usage: inspect a single project when you need its details. It doesn't explicitly mention when not to use it or alternatives, but the context and sibling names make the use case clear.

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

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

With no annotations, the description carries the burden of behavior disclosure. It states the tool 'Lists' projects and mentions the returned fields (folder, path, last-modified time), implying a read-only operation. However, it does not explicitly state it is non-destructive or mention any access implications, leaving some uncertainty about 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, well-structured sentence that front-loads the action and resource. Every word earns its place, with no wasted text 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?

Given the tool's simplicity (no parameters, no output schema, no annotations), the description is fully sufficient. It tells the user what the tool lists and what information is provided, leaving no critical gaps for effective use.

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, so the schema coverage is trivially 100%. The description does not need to explain parameters; it instead adds value by describing the output fields, which is useful for understanding what the tool returns.

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

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

The description uses a specific verb and resource ('Lists CapCut projects') and specifies the scope ('local draft store'), making the tool's purpose unmistakable. It differentiates from sibling tools like inspect_project, which presumably operates on a single project, and editing tools like add_overlay.

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 clearly implies this tool is for enumerating available projects in the local draft store, providing the context needed to choose it over alternatives. It does not explicitly exclude other tools, but the listing function is so distinct that no exclusion is necessary.

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 discloses important behavioral traits: real alpha channel, ProRes 4444 format, ffmpeg requirement, and rendering time in tens of seconds. This goes beyond the schema, though it omits potential side effects like output file overwriting.

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

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

The description is four short sentences, each adding distinct value: purpose+format, output+next step, dependency, and performance. It is front-loaded and contains zero filler.

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

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

For a rendering tool with no annotations and no output schema, the description covers key operational constraints (ffmpeg, time, alpha channel) and points to the next step with add_overlay. It leaves out some details but benefits from high schema coverage, making it sufficient 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 high at 91%, so the baseline is 3. The description does not add parameter-specific explanations beyond what the schema already provides; it only references the output path concept without detailing style or timing parameters.

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

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

The description clearly states the tool renders an animated overlay with a ProRes 4444 alpha channel, and explicitly distinguishes it from CapCut-authored graphics. It also mentions returning the file path, making the action concrete and unambiguous.

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

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

It implies use when CapCut cannot author the motion graphics and directs the user to place the output with add_overlay, establishing a workflow. However, it does not explicitly state when not to use it or name alternative rendering tools.

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

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

With no annotations, the description discloses key behavioral traits: it applies changes globally to 'every caption at once,' requires CapCut to be closed, and supports a dryRun preview. It also notes upstream limitations (font family and position are not supported). This goes beyond the schema and provides useful safety and scope information, though it does not detail exact file modifications or reversal options.

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 succinct and front-loaded: the first sentence states the purpose and scope, followed by presets, animation guidance, and exclusions. Every sentence adds value without redundancy, making it easy for an agent to quickly grasp the tool's function and constraints.

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

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

The description covers the tool's purpose, presets, animation source, unsupported features, and operational requirements (CapCut closed, dryRun). Despite the absence of an output schema and annotations, it provides enough context for an agent to understand when and how to invoke the tool, and what to expect in terms of scope and limitations.

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

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

The schema covers 67% of parameters, but the description enriches meaning by explaining the overall effect (styles are applied project-wide), naming valid presets, and pointing to a command for animation slugs. It also clarifies why certain parameters (font, position) are absent, aiding interpretation. The description effectively compensates for the schema's gaps, although individual schema property descriptions already handle some 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 clearly states the tool's core action: applying a unified style and optional animation to every caption. It enumerates the style attributes (outline, shadow, background plate, etc.) and distinguishes it from sibling tools that handle overlays or subtitles by framing it as the batch operation editors would otherwise do by hand.

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 context: it is a batch operation to replace manual per-caption editing, and it explicitly lists unsupported aspects (font family, on-screen position) to steer users toward manual work or other tools. It also provides operational guidance (CapCut must be closed, use dryRun to preview), though it does not directly name alternative tools for the unsupported cases.

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