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 states a mutation ('add') but does not disclose whether this replaces an existing Fusion composition, whether it requires a supported clip type, what side effects it has on the timeline, or whether it is undoable. For a mutating tool with zero annotation support, this is a significant gap.

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

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

A single, front-loaded sentence with a specific verb and object. The key scoping condition ('at the playhead') appears early, and there is no filler. This is appropriately concise.

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 no parameters and an output schema exists, a short description could suffice, but several operational questions remain: What happens when no clip is at the playhead? Does it create a new Fusion comp or open an editor? Is there a prerequisite timeline page? These gaps make it incomplete for a mutation tool without annotation support.

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 are zero parameters, so the schema has nothing to define. The description correctly implies the tool operates on the current clip at the playhead without additional inputs. The baseline for zero-parameter tools is 4, and no parameter information is needed.

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 action – adding a Fusion composition – and a precise target: the clip at the playhead. It is clearly distinct from siblings like resolve_get_fusion_comps or resolve_get_fusion_tools, which inspect existing comps, and from creation tools like resolve_insert_title. An agent can tell what it does without opening the schema.

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 when-to-use or alternative routing. The description implies usage through the verb 'add' and the positional condition 'at the playhead', but it does not instruct the agent to verify a clip is present or to consider competing tools like resolve_insert_title. This is implied usage, not clear 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 behavioral disclosure burden. It usefully reveals the legacy frame=0 playhead behavior and explains that other frame values are timeline-relative, which goes beyond the schema. It does not describe side effects, overwrite behavior, or duration units, but the core quirk 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?

Two sentences, both purposeful: the first defines the operation and the critical frame behavior, the second routes to an alternative. It is front-loaded and contains no filler.

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

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

The output schema exists, so return values do not need explanation. The description covers the core operation and the important frame=0 quirk, but for an unannotated five-parameter tool it omits the relationship to resolve_add_marker_at_playhead and does not clarify duration semantics. It is adequate but not fully 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 missing parameter documentation. It only explains the frame parameter's playhead-vs-timeline behavior; name, note, color, and duration rely entirely on their names and defaults. Duration's units and boundary behavior are left ambiguous.

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 operation: 'Add timeline marker' with a specific verb and resource. It also adds frame-position semantics that differentiate default playhead placement from timeline-relative placement. It does not explicitly contrast with the closely named sibling resolve_add_marker_at_playhead, which costs it full marks.

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 one explicit routing instruction: use resolve_create_chapter_markers to explicitly address frame zero. However, it does not mention the overlapping sibling resolve_add_marker_at_playhead or provide broader guidance about when to prefer this tool over that one.

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 behavioral burden. It does disclose that the operation creates a marker at a precise playhead and highlights drop-frame timecode support, which is a useful edge-case behavior. However, it does not mention side effects such as duplicate markers, prerequisites like an open timeline, or whether existing markers are affected.

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 the core action front-loaded. 'Including drop-frame timecode support' is a relevant qualifier rather than filler, and there is no unnecessary 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 simple three-parameter mutation with no output schema, the description gives enough to understand the core action, and the drop-frame timecode detail adds useful context. Still, it omits guidance on when to prefer this over resolve_add_marker, and with no annotations, the safety and side-effect profile is left largely to inference.

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, but it says nothing about the `name`, `note`, or `color` parameters. The schema's titles and defaults provide some structure, yet the description adds no semantic detail about what these values mean, what format is expected, or why `name` is 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 names a specific verb and resource: 'Add a marker at the exact current playhead', which clearly distinguishes it from generic marker tools like resolve_add_marker. The added detail about drop-frame timecode support further narrows the purpose. An agent can understand exactly what this tool does without reading the schema.

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 'at the exact current playhead' provides clear contextual guidance: use this tool when a marker should be placed precisely where the playhead is now. It does not explicitly contrast with resolve_add_marker or state when not to use it, though the playhead-specific framing strongly implies that distinction.

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 only lists parameters and defaults, but does not disclose key behaviors such as whether the job starts immediately, whether it requires a loaded timeline, or what happens on failure. This is a significant gap for a queue-adding 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 clean docstring with a front-loaded purpose and a concise parameter list. Every line earns its place, with no fluff or repetition. It is structured for quick scanning.

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

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

The description covers all parameters adequately but misses workflow context: e.g., that this only queues a job and does not start rendering, or how to combine it with resolve_start_render. With an output schema present, the return value is likely documented elsewhere, but the missing operational context keeps this from being 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?

With 0% schema description coverage, the description compensates well by explaining each parameter's purpose and default semantics (e.g., '0 = use project setting', 'Leave empty for project default'). This adds meaning beyond the schema's bare names.

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 opening line clearly states the action ('Add a custom render job to the render queue') with a specific verb and resource. It distinguishes from siblings like resolve_start_render by focusing on adding to the queue, though it does not explicitly contrast with those 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?

The description gives no guidance on when to use this tool versus alternatives like resolve_start_render, resolve_quick_export, or resolve_render_for_youtube. It only describes the parameters, leaving the agent to infer the appropriate use case.

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 reveals that analysis is native, faces are opt-in, and it does not query a search index. These are meaningful behavioral traits. It could mention whether the operation is asynchronous and how to check results, but the current information is substantial given the absence of annotations.

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, with four short sentences that front-load the core purpose and then add prerequisite and behavioral notes. Every sentence adds value, and there is no fluff or redundancy. It is efficient and well-structured.

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 4 parameters, no output schema, and no annotations, the description covers essential purpose and prerequisites but omits expected follow-up actions (e.g., how to know when analysis is done, whether it returns a result). It also doesn't clarify parameter interplay or potential side effects. While not incomplete to a dangerous degree, it leaves gaps that an agent might need to infer.

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

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

Schema coverage is 0%, so the description must compensate. It directly explains 'identify_faces' as opt-in and indirectly references 'better_mode' through the 'Faster/Better Extras' prerequisite. However, it does not explicitly map each parameter to its role (e.g., what better_mode does, how clip_name vs folder_path interact). The description provides hints but leaves key parameter semantics partially ambiguous.

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: 'Analyze a clip or folder for IntelliSearch.' It distinguishes the tool from siblings like resolve_reset_intellisearch by emphasizing it starts native analysis and does not query a search index. The purpose is unambiguous and easily separates it from related operations.

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 clear context: prerequisites ('Needs Faster/Better Extras'), opt-in behavior for face identification, and a clear distinction from search queries. However, it does not explicitly mention alternatives or when not to use it, such as when to use reset_intellisearch or other analysis tools. The guidance is helpful 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?

With no annotations, the description must carry the behavioral burden. It usefully discloses that the operation is an analysis that writes slate markers and requires the AI Slate ID Extras package, but it does not describe failure behavior, how existing markers are affected, or what a successful run returns.

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 main action is front-loaded, and the Extras prerequisite is presented as a clear terminal caveat.

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 essential action, target, outcome, and prerequisite, which is adequate for a simple tool. But with no annotations and no output schema, it omits expected return values, marker placement specifics, and behavior when the Extras requirement is unmet, so it is not fully complete.

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

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

The phrase 'on a clip or folder' maps to clip_name and folder_path and implies they are alternatives, which adds meaning beyond the bare schema. However, it does not clarify interaction/precedence between those parameters or define marker_color behavior beyond the schema's title and default, leaving 0% schema coverage only partially compensated.

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 ('Run ... analysis') and resource ('on a clip or folder'), and states the observable result ('add slate markers'). This distinguishes it from sibling analysis/marker tools and makes the tool's purpose 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 implies usage by naming the target and outcome, and it gives a hard prerequisite ('Requires AI Slate ID Extras'). However, it does not explicitly explain when to prefer this over related sibling tools such as resolve_analyze_intellisearch or resolve_add_marker.

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 only says "Add" and describes parameter semantics; it does not disclose side effects on the current timeline, whether the operation is destructive or reversible, what happens if no current timeline is open, or what errors/status the caller should expect. This is a significant gap 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?

The description is compact and well-structured: a one-sentence action statement followed by a concise Args block. There is no filler, and the parameter details are front-loaded and easy to scan.

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

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

For a simple three-parameter tool with an output schema, the parameter semantics are well covered. However, the description omits prerequisites (e.g., a loaded project/current timeline), what "append" means in terms of timeline placement, and how failures are surfaced. These omissions matter more because annotations are absent.

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

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

The schema has 0% description coverage, and the description fully compensates. It explains clip_name, specifies track_index is 1-based, documents media_type numeric meaning and defaults, and adds a practical example (b-roll preserving interview audio). Every parameter gains meaning beyond the raw schema.

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

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

The description states a specific action and resources: "Add a clip from the media pool to the current timeline." This clearly identifies what the tool does and where it applies. It does not explicitly distinguish itself from similar siblings like resolve_insert_broll or resolve_replace_clip, so it stops 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 description gives one useful parameter-level guideline ("Use 1 for b-roll to preserve interview audio") and implies this is for appending media to a timeline. However, it does not say when to prefer this tool over siblings, when not to use it, or what state the timeline/project must be in.

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 burden. It discloses the page requirement and the fact that it targets the playhead clip, which is useful behavioral context. However, it does not mention whether the operation is destructive, whether it modifies the node graph irreversibly, or what the output/return value is. With no annotations, this is a moderate gap.

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

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

The description is compact and front-loaded with the core action and target. The example LUT paths and Args section are useful and not redundant. It could be slightly tighter, but every sentence earns its place.

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

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

For a two-parameter tool with an output schema present, the description covers the essential context: what it does, where it operates (Color page), and how to specify the LUT. It does not explain the return value, but the output schema likely covers that. It also doesn't mention failure modes (e.g., invalid LUT path), but overall it is sufficiently complete for an agent to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains lut_path as 'LUT file path (relative to Resolve's LUT directory or absolute)' and node_index as 'Node to apply LUT to (1-based, default: 1)', adding meaning beyond the bare schema types. It also gives example LUT paths. This is strong compensation, though it could clarify the default node behavior more.

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 ('Apply'), a specific resource ('a LUT to a clip's node graph'), and a precise target ('the clip at the playhead'). It clearly distinguishes itself from sibling tools like resolve_get_lut or resolve_export_lut, which are about LUT retrieval/export rather than application.

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 a clear prerequisite ('Must be on the Color page') and provides concrete example LUT paths, which helps the agent know what values to pass. It does not explicitly state when to use this tool versus alternatives like resolve_create_color_version, but the context is clear enough for a color-grading operation.

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 carries the full burden of behavioral disclosure. It states the action 'send' but does not reveal whether this is a read-only operation, whether it modifies any state, what side effects occur, or what the response entails. An agent cannot infer safety or expected behavior from this text.

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, clear sentence with no fluff. It conveys the essential function without unnecessary words, achieving high conciseness and clear structure.

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 has an output schema (not shown but indicated true). The description does not explain what 'current frame' means or any prerequisites, but the operation is self-explanatory enough. With no annotations, more context would be helpful, but the minimal description is borderline sufficient for such a basic action.

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 implies the single parameter 'question' via 'visual question answering,' making the parameter obvious, but it does not explicitly describe the parameter's format, constraints, or examples. For a single trivial string parameter, this is minimally adequate.

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: 'Send the current frame to Moondream for visual question answering.' It specifies a verb, a resource (current frame), and the purpose (VQA). While it doesn't explicitly differentiate from sibling tools like resolve_describe_frame, the intended function is unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of conditions, exclusions, or comparisons to sibling tools. The description is purely functional and gives no context for decision-making.

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 burden. It discloses key behaviors: dry-run by default, original timeline unchanged, overlapping ranges allowed, and tracks behavior. However, it does not explain the effects of parameters like dry_run, open_variant, or carry_markers, nor does it mention return values or potential side effects. The description covers the core non-destructive nature but leaves significant behavioral aspects unspecified.

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 reasonably concise, about four sentences, and front-loads the main action. It mixes parameter explanations inline but remains readable. It could be better structured with separate sections for parameters, but it is not overly verbose and wastes little 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 tool with 9 parameters, no annotations, and no output schema, the description is incomplete. It covers the core operation and two parameters, but leaves out many parameters that affect behavior (e.g., dry_run, open_variant, carry_markers). It also doesn't specify what the function returns or any error conditions. An agent cannot fully understand how to use this tool correctly based on the description alone.

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 'remove' (format with start_seconds, end_seconds) and 'tracks' (all vs spine) in detail, but ignores the other 7 parameters (dry_run, open_variant, carry_markers, min_keep_seconds, spine_track_type, new_timeline_name, spine_track_index). This leaves the majority of parameters undocumented, which is inadequate for a tool with 9 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 cuts listed ranges from carried tracks into a new timeline, which is a specific verb-resource pair. It distinguishes itself from sibling tools like resolve_build_rough_cut by emphasizing 'text-based / manual editing' and explicitly mentioning it creates a new timeline. The example with caption cues from resolve_get_transcript further clarifies its intent.

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 clear usage context: it's for text-based/manual editing, and gives an example of using caption cues for removing filler words. It implies it should be used when precise manual cuts are needed, but does not explicitly name alternatives or state when not to use it. However, the example and the distinction from automatic tools are enough to guide an agent reasonably.

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 behavioral burden and does well: it reveals that a new timeline is created, ambiguous or existing names are rejected, planning mode is the default, and transcript-based inference is not performed. It does not detail what happens on success or when dry_run is false, but the key behavioral traits are 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?

Four short, front-loaded sentences with no filler. Every sentence adds a useful constraint or behavioral fact, and the most important action appears immediately.

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

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

For a 3-parameter mutating tool with no output schema or annotations, the description is mostly sufficient: it defines the required inputs, the uniqueness constraint, the ordering semantics, and the planning default. A little more about the actual execution result would improve completeness, but an agent can select and invoke the tool correctly from this description.

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: 'clip_names' maps to complete media clips in supplied order, 'name' maps to a new, non-existing timeline name, and 'Defaults to planning only' clarifies the dry_run parameter. It could be more explicit about each parameter, but it adds meaningful semantic context.

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

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

The description opens with a specific verb and resource: 'Assemble complete media clips in supplied order into a NEW timeline.' This clearly identifies the tool's core purpose and distinguishes it from siblings that append to an existing timeline or infer cuts from a transcript.

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 context: this is for ordered assembly into a new timeline, rejects ambiguous media and existing timeline names, and does not infer cuts from a transcript. It makes the when-not explicit, though it stops short of naming the alternative tool to use for transcript-based cuts.

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 only states the action (classify audio) and scope, but does not mention side effects, whether it modifies the project, if it is a long-running operation, what the output is, or any requirements (e.g., must have a project loaded). The description is too sparse to inform the agent about the tool's behavior beyond the basic 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 a single, concise sentence that front-loads the core action and scope. Every word is useful, with no redundancy or filler. It is appropriately brief for a tool with only two optional parameters and no complex logic described. The structure is clean and efficient.

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

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

Given the absence of annotations and output schema, the description is expected to provide more contextual completeness. It does not explain what 'classify' produces, where results are stored, whether it returns data, or if it has any prerequisites (e.g., must have an open project or timeline). It also does not mention error conditions or the effect of both parameters being set. For a tool with two optional params, the description is minimal and leaves many operational questions unanswered, making it incomplete for an agent to use 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. It does add some semantics: 'one clip' maps to clip_name, and 'current/specified folder' maps to folder_path. It also implies that folder_path can be empty to use the current folder. However, it does not clarify behavior when both parameters are provided, the meaning of 'classify' in this context, or any defaults beyond what is in the schema. It adds some value but leaves ambiguity.

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

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

The description clearly states the tool's purpose: 'Classify audio' with a specific resource and scope. It distinguishes itself from siblings like resolve_transcribe_audio and resolve_clear_audio_classification by focusing on classification rather than transcription or clearing. The mention of 'one clip, or the current/specified folder AND nested folders' gives precise operational 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 gives some usage context by specifying the two modes (single clip vs. folder), which implies when each parameter should be used. However, it does not explicitly compare to alternatives or state when not to use this tool. For example, it doesn't say 'Use this instead of transcribe_audio for classification.' There is no exclusion or alternative guidance, so the agent is left to infer the appropriate context from the name and siblings.

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

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

With no annotations provided, the description must carry the full behavioral disclosure burden. It mentions the scope (clip or folder recursively) but does not state whether the operation is destructive, reversible, requires permissions, or has any side effects. For a mutation tool, this is a significant gap.

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

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

The description is a single sentence that directly states the core functionality and scope. It is concise and front-loaded with the action, with no unnecessary detail. It could be slightly more structured to clarify parameter usage, but it is efficient overall.

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 (two optional params, no output schema, no annotations), the description covers the basic intent but lacks details on parameter interaction and edge cases (e.g., both params empty, which folder is 'current'). It is minimally adequate but not complete enough to guarantee correct invocation without additional context.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'one clip' and 'current/specified folder' which roughly map to clip_name and folder_path, but it does not explain parameter precedence, what happens if both are empty, or how the 'current' folder is determined. The mapping is partial and leaves ambiguity.

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

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

The description states a clear action (Remove audio classification) and specifies the target scope: one clip or a folder including nested folders. It distinguishes between these two modes, making the purpose unambiguous. However, it does not differentiate this from sibling tools like resolve_clear_transcription or resolve_classify_audio, which could be confused in intent.

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 does not mention when classification removal is appropriate, nor does it exclude cases where other tools (e.g., resolve_clear_transcription) would be better. The usage context is only implied by the verb 'remove', leaving the agent to infer.

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 does disclose that the operation is destructive ('Delete') and highlights the recursive scope ('AND nested folders'), which is valuable. However, it does not state irreversibility, required project context, or what happens when both clip_name and folder_path are supplied.

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 that front-loads the action and scope with no filler. Every phrase contributes meaning, and the alternative scopes are clearly separated.

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

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

The description is not complete enough for a destructive tool with no output schema and no annotations. It does not clarify parameter priority, the meaning of 'current' folder, prerequisites like a loaded project, or what result the agent should expect. This ambiguity could lead to incorrect invocation when both parameters are relevant.

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 meaning by connecting 'one clip' to clip_name and 'current/specified folder AND nested folders' to folder_path. Yet it leaves ambiguity about which parameter takes precedence, what 'current' means, and whether the two parameters can be used together.

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 ('Delete transcription') and clearly scopes the action to 'one clip' or a folder including nested folders. It is immediately distinguishable from siblings like resolve_clear_audio_classification and resolve_get_transcript because it targets transcription deletion specifically.

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 resolve_clear_audio_classification or when to prefer folder-scoped vs clip-scoped deletion. The description implies the use case but does not state exclusions, alternatives, or prerequisites.

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 states the action (create) but does not disclose side effects, whether the bin is created in the currently loaded project, what happens if the name already exists, or whether it requires an open project. For a mutation tool with zero annotation coverage, this is a significant gap.

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

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

The description is very short and front-loaded with the action and resource. The Args section is redundant with the schema but not harmful. It earns its place with no wasted words, though the Args block could be considered unnecessary repetition.

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

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

The tool has a simple schema (1 param) and an output schema exists, but the description lacks context about the required state (e.g., a loaded project), error conditions, and the meaning of the return value. For a mutation tool with no annotations, this is incomplete. The output schema may cover return values, but the description doesn't explain when this tool is appropriate or what prerequisites must be met.

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 explain the 'name' parameter ('Name for the new bin'), which adds meaning beyond the schema's bare 'Name' title. However, it doesn't specify constraints like uniqueness, allowed characters, or whether nested paths are supported. Baseline 3 is appropriate because the description adds some value but not rich detail.

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 ('Create') and resource ('a new bin (subfolder) in the media pool'), which clearly distinguishes it from sibling tools like resolve_import_media or resolve_create_timeline. It could be slightly more explicit about the media pool context, but the parenthetical clarification helps.

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 no guidance on when to use this tool versus alternatives, nor any prerequisites (e.g., must have a project loaded, must be in the media pool). The context is implied by the name and description, but there are no explicit exclusions or alternative tool references.

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

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

With no annotations, the description carries full behavioral burden and does so well: it states that clips and audio are not changed, that a subtitle track is added, that the native true/false result is unreliable, and exactly what counts as success. This gives an agent crucial expectations 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 compact and front-loaded with the core purpose, then adds behavioral caveats and a workflow hint, then packs parameter notes into one line. Every sentence contributes useful information with minimal waste, though the parameter line is slightly dense.

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 purpose, side effects, success criteria, a next-step recommendation, and several parameter meanings—substantial for an agent. But with no annotations and no output schema, the unexplained parameters and lack of a return/error contract leave notable gaps for reliable 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 coverage is 0%, and the description does add meaning for language, preset, and chars_per_line (listing concrete preset values and explaining '0 = preset default'). But dry_run, gap_frames, and line_break are not explained at all, leaving half the parameters under-specified.

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: auto-caption the CURRENT timeline with Resolve's speech recognitionropolitan, adding a subtitle track. It also clarifies the scope ('CURRENT timeline') and gives the resulting effect, making the tool's purpose unmistakable.

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 (current timeline, Studio requirement) and a follow-up step (use resolve_get_transcript), so an agent can infer when this tool fits. However, it never explicitly contrasts this with sibling tools like resolve_transcribe_audio or states when not to use it, leaving selection guidance partly implicit.

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 and does meaningful work: it discloses that validation happens for the complete batch before any write, that frame positions are timeline-relative integers, and that no transcript or speaker-time inference is performed. It does not describe return values or failure behavior, so it is not maximally transparent.

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

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

Four short sentences deliver the action, entry contract, validation behavior, and non-goals. The information is front-loaded and every sentence contributes something that the schema and annotations do not already provide.

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 input contract, coordinate frame, and validation atomicity, which is enough for invoking the tool with correct arguments. However, there is no output schema and no statement about what the tool returns (success, created marker IDs, count) or how failures are surfaced, so an agent cannot fully predict the result.

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

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

Schema description coverage is 0%, and the description compensates by defining the structure of each chapters entry: frame as a timeline-relative integer, name as a string, and note as an optional string. It does not explain the color parameter beyond the schema default, but color's meaning is reasonably self-evident and it is optional.

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 precise action ('Create markers') with a specific input source ('supplied chapter/speaker boundaries') and gives the per-entry shape. It also distinguishes this tool from nearby transcription or inference tools by explicitly noting that it does not extract transcripts or infer speaker times.

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

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

The description implies the tool is for cases where chapter/speaker boundaries already exist and tells the agent not to use it for transcript extraction or speaker-time inference. It does not explicitly name alternative tools or provide full when-not-to-use conditions, but the context is clear enough for good routing.

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 states that a version is created, implying a mutation, but gives no details about side effects, requirements (e.g., active project/timeline), error conditions, or reversibility. This is a significant gap for a state-changing 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 extremely concise: one primary sentence followed by a bullet-point argument list. The main action is front-loaded, and every sentence earns its place without 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 simple creation tool, the description covers the core operation and parameter meanings. However, it omits behavioral context such as error handling, preconditions (e.g., clip at playhead), and return value expectations. Since an output schema exists but is not described, the agent lacks full guidance on what to expect after calling the tool.

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

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

The description adds meaningful context beyond the raw schema: it names the 'name' parameter and explains that 'version_type' uses 0 for local (default) and 1 for remote. This clarifies the integer values and their semantics, which the schema does not provide. However, it does not elaborate on what 'remote' implies.

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 verb 'Create' and the resource 'new color version on the clip at the playhead', making the primary action unambiguous. It is specific enough to distinguish from sibling tools like resolve_load_color_version and resolve_list_color_versions, though it does not explicitly name those 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?

There is no guidance on when to use this tool versus alternatives such as loading or listing color versions. The description only explains what the tool does, not the context or prerequisites (e.g., a clip must be present at the playhead) or when to prefer it over 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 behavioral burden. It does disclose a meaningful side effect, 'Creates a recovery timeline first,' which is useful. However, it does not explain whether the operation is destructive, how the recovery timeline is used, or what happens to the original clips.

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 short sentences with no filler. The primary action is front-loaded, and the recovery-timeline side effect earns its place as important behavioral context.

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

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

Despite having an output schema, this is a mutation tool with no annotations and no parameter descriptions. The description leaves key invocation details ambiguous, such as how to specify the range, whether the range is inclusive, and whether a valid timeline must be loaded. It is not complete enough for an agent to call it correctly without additional inference.

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 the four undocumented parameters. It offers only the phrase '1-based video-track range,' which hints at track_index/start_clip/end_clip semantics but does not explain defaults, inclusivity, or what end_clip=0 means. This is insufficient for reliable parameter selection.

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 ('Create a compound clip') and the specific scope ('from a 1-based video-track range'). This distinguishes it from sibling tools like resolve_create_timeline or resolve_build_rough_cut, and it is not a tautology of the tool name.

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

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

No guidance is given about when to use this tool versus alternatives, nor are any preconditions or exclusions mentioned. The agent must infer that it applies to the current timeline and that no other tool is more appropriate.

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 burden of behavioral disclosure. 'Create a new project' conveys mutation but says nothing about side effects, whether an existing project with the same name is rejected or overwritten, or whether the new project becomes the current project.

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 front-loaded with the purpose. The Args section is redundant but not verbose, and there is no unnecessary filler for a one-parameter 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 definition is minimally viable for invoking the tool: it names the action and the single required parameter, and an output schema exists. However, with no annotations and no behavioral context, it leaves gaps around side effects and when creation is appropriate.

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

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

Schema description coverage is 0%, and the description only restates that 'name' is the name for the new project. This adds minimal meaning beyond the schema's property title and fails to address constraints, uniqueness, or formatting expectations.

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 a specific verb and resource: 'Create a new project.' This distinguishes it from sibling create tools like resolve_create_bin and resolve_create_timeline, and 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 use this tool versus alternatives such as resolve_list_projects or resolve_load_project. It does not state prerequisites, exclusions, or context in which creation is appropriate.

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 states that a timeline is created, but does not disclose whether an open project is required, whether the new timeline becomes the current timeline, or what side effects creation has beyond the creation itself.

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, front-loaded with the core action, and contains no filler. The Args block is minimal and easy to parse.

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

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

For a one-parameter creation tool with an output schema, this is minimally adequate: the agent knows what to call and what argument to pass. But the missing project prerequisite and post-creation state (e.g., whether the timeline becomes current) leave meaningful gaps, especially with no annotations to fill them.

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 Args section documents the single parameter as 'Name for the new timeline,' adding slight context beyond the schema's bare 'Name' title. However, with 0% schema description coverage, it does not compensate with constraints like uniqueness, allowed format, or relationship to the current 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?

The description opens with a specific verb and resource: 'Create a new empty timeline.' The qualifier 'empty' clearly distinguishes this from sibling tools like resolve_duplicate_timeline and resolve_append_to_timeline.

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 when-to-use or when-not-to-use guidance is provided. With many timeline-related siblings, the agent gets no criteria for choosing this tool instead of duplicate_timeline, append_to_timeline, or create_project.

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 does well by stating the default ripple behavior, that linked peers remain, and that a recovery copy is created. A slightly higher score would require more detail about the recovery copy lifecycle or confirmation of irreversibility, but these disclosures are already strong.

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 deliver the core purpose and key behaviors with no filler. The most important information, what the tool does, comes first, and each subsequent sentence adds a distinct behavioral detail.

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 has an output schema, so the description does not need to explain return values. Behavioral coverage is good, but parameter ambiguity remains: a caller still does not know exactly how clip_index, track_type, and track_index identify the target clip. This is a meaningful gap for a destructive operation.

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

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

The schema has 0% description coverage, so the description must compensate for all four parameters. It adds meaning only to the ripple parameter via 'defaults to non-ripple' and vaguely implies 'exactly one' relates to clip_index. It does not explain clip_index semantics, track_type values, or track_index addressing, leaving the agent to infer critical targeting 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+resource: 'Delete exactly one clip,' which unambiguously identifies the operation and scope. Adding 'exactly one' distinguishes it from bulk operations, and no sibling tool overlaps with clip deletion, so the purpose is clear without needing to 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?

The description clearly frames when to use this tool: when a single clip needs to be deleted. It also notes the default non-ripple behavior, which gives context for typical usage. However, it does not explicitly state when not to use it or name alternatives, so it stops short of full 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?

With no annotations provided, the description carries the full burden. It discloses that no arguments cause no changes, and that removed marker records are returned for restoration. It also clarifies frame semantics ('exact timeline-relative frame (including zero)'). These are useful, though it does not discuss permissions or side effects; still, the behavior is adequately transparent for a simple delete 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?

Two concise sentences, each adding value: the first states the action and selection criteria, the second clarifies the no-op behavior and the return value. There is no wasted wording.

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 delete tool with two optional parameters and an output schema (which likely documents the return format), the description covers the essential behavior. It mentions the 'All' option and frame semantics that are not apparent from the schema. It is complete enough for an agent to call the tool correctly without additional documentation.

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 maps 'color' and 'frame' to the properties, indicates that 'All' is a valid color value, and explains frame is timeline-relative and can be zero. However, it does not specify whether color and frame can be combined or the expected format of the color string, leaving some ambiguity.

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

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

The description states a specific verb ('Delete') and resource ('markers') and lists the selection criteria (color, All, frame). It clearly distinguishes from sibling tools like resolve_add_marker and resolve_get_markers by its explicit delete operation, making its 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 clearly indicates what the tool does, so an agent can infer when to use it. However, it does not explicitly mention when not to use it or name alternatives like resolve_add_marker or resolve_get_markers, leaving the usage context implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It only states the basic action and mentions the 'detail' parameter, but does not disclose whether the operation is read-only, involves network calls or latency, or has any side effects. For a tool with no annotations, this is a notable gap.

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

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

The description is extremely concise—one sentence plus a brief parameter hint—and front-loads the core purpose. There is no fluff or redundancy; 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?

The tool has a simple input (one optional parameter) and an output schema that defines the return value, so the description does not need to explain output details. It covers the essential action and parameter guidance, but could be slightly more complete by mentioning any prerequisites (e.g., having a loaded timeline) or the nature of the caption generation. Overall, it is sufficient for the low complexity.

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

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

The description adds meaning to the single 'detail' parameter by specifying the allowed values ('short or normal'), which the schema does not include as an enum. This goes beyond the schema's generic string type and helps the agent select an appropriate value.

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

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

The description clearly states the action (send frame to Moondream) and the output (caption), distinguishing it from sibling vision tools like resolve_detect_in_frame (detection) and resolve_ask_about_frame (question answering). The verb and resource are specific, making it 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 a straightforward use case (getting a caption for the current frame) but does not explicitly state when to prefer it over alternatives or when not to use it. No exclusionary or comparative guidance is given, but the context is clear enough that an agent could infer its purpose.

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

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

With no annotations, the description carries the full burden. It discloses that the frame is sent to an external service (Moondream) and that the output is bounding boxes, which is useful. Yet it does not mention side effects, latency, failure modes, or whether the operation is strictly read-only, so transparency is only partially adequate.

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 packs the action, target, method, and output without any filler. Every word contributes value, making it highly concise and easy to parse.

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 (one parameter) and has an output schema, so the description does not need to explain return values. It conveys the core invocation context—acting on the current frame and using a description of objects—sufficiently for an agent to call it correctly. Minor gaps like prerequisite state or error handling are acceptable given the schema richness.

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

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

The schema provides only a type and title for object_description with 0% description coverage. The tool description compensates by stating that the tool detects 'described objects', clearly linking the parameter to the natural-language description of what to detect. This gives the agent the essential meaning, though it lacks examples or input-format 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 states a specific action ('Send the current frame to Moondream') and a specific result ('return bounding boxes') for detecting described objects. It is clear about the tool's purpose but does not explicitly contrast it with siblings like resolve_describe_frame or resolve_ask_about_frame, so it falls short of full differentiation.

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 wording implies usage: call this when you want to detect objects in the current frame based on a description. However, there is no explicit guidance on when to prefer this over other vision tools or any exclusions, leaving the agent to infer the appropriate context.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states the tool is read-only and requires ffmpeg, which are key constraints. It also explains behavior across detect_on modes and the meaning of threshold_db=0 calibration. It does not disclose potential failure modes (e.g., missing ffmpeg) or performance characteristics, but the provided information is substantive and goes beyond 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 sentences with no wasted words. It front-loads the primary action and constraints, then adds mode explanations and output context. 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?

Given the tool's complexity (7 parameters), lack of annotations, low schema description coverage, and no output schema, the description is incomplete. It does not explain all parameters, does not describe the output format beyond scale, and omits potential prerequisites (like ffmpeg version). An agent may need to probe or fail before understanding full behavior.

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

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

Schema description coverage is 0%, so the description must define parameters. It explains detect_on (carried vs spine) and threshold_db (0 = calibrate per clip), but does not cover tracks, audio_stream, spine_track_type, spine_track_index, or min_silence_seconds. For a 7-parameter tool, this leaves most parameters semantically undefined, requiring agents to guess or inspect the schema (which is also minimal).

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: 'Find dead air on the current timeline' with a specific verb ('Find') and resource ('dead air on timeline'). It also distinguishes itself from siblings by adding 'with ffmpeg (read-only; needs ffmpeg)' and describing modes. No other sibling tool focuses on silence detection, so this tool is unique within the set.

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 explicit context for when to use different detect_on modes ('carried' vs 'spine') and explains calibration with threshold_db=0. It also mentions that return values are timeline-relative, aligning with resolve_get_transcript captions. However, it does not explicitly compare with alternatives like resolve_tighten_silence or state when not to use this tool, leaving some room for inference.

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

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

With no annotations provided, the description carries full behavioral burden. It discloses the irreversible nature (no enable call, restart required) and the broad scope (ALL tasks). This is strong transparency for a simple tool, though it could specify whether existing queued tasks are canceled or simply prevented from running.

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 filler. The primary action is front-loaded, and the critical caveat (irreversibility) follows immediately. 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 no output schema, the description covers the essential facts: what it does, its scope, and the reset mechanism. It could mention the return value (if any) or side effects on ongoing tasks, but it is sufficient for an agent to call it correctly.

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

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

The tool has zero parameters, so the baseline for this dimension is 4. The description correctly focuses on behavior rather than parameters, adding no unnecessary detail. The schema already reflects the lack of arguments.

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

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

The description clearly states the action ('Disable') and the resource ('ALL Resolve background tasks'), with a specific scope ('for this application session'). It is unambiguous and distinguishes itself from other resolve_* tools by describing a global session-level operation rather than a task-specific one.

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 does not provide explicit when-to-use guidance or mention any alternatives. While there are no obvious sibling tools that perform a similar disable operation, the description could have suggested typical scenarios (e.g., 'when you want to prevent background tasks from interfering'). It implies usage through its action but does not actively route the agent.

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 only states that it duplicates the current timeline, but fails to disclose any side effects, such as whether the duplicate becomes the new current timeline, whether it is saved to the project, or whether it is a full copy or a reference. Given the tool is mutating (duplication), the lack of behavioral details is a significant gap.

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

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

The description is very short and front-loaded with the action. The docstring-style 'Args' section is clear for the parameter, but the overall description is under-specified for a tool with no other documentation. It is concise but not enough structure to compensate for missing usage and behavioral info.

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 that there is an output schema (though not provided) and only one optional parameter, the tool is low complexity. However, the description is incomplete: it does not indicate what the return value is (e.g., success status or the new timeline ID), which is important for the agent to understand the result. The output schema may cover this, but the description should at least mention it. Also, no mention of error conditions (e.g., if no current timeline 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%, and the input schema only lists a 'new_name' property with a default of ''. The description adds some meaning by noting that new_name is optional and defaults to original + ' Copy', which is helpful. However, it doesn't specify the exact naming format or constraints (e.g., if characters are sanitized), and since coverage is 0%, the description should compensate more fully for the single 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 says 'Duplicate the current timeline' but the tool name is 'resolve_duplicate_timeline'. This is essentially a tautology of the name, restating the action without adding specificity about the resource or context. The description is misleading: 'Duplicate the current timeline' does not clarify what the tool does relative to other timeline tools; it just repeats the purpose implied by the name.

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 tool versus alternatives like 'resolve_create_timeline' or 'resolve_copy_timeline' (if it existed). The description does not mention any context for duplication, such as prerequisites (e.g., current timeline must exist) or whether it duplicates all contents or just the name. It does not exclude any scenarios, leaving the agent to infer when duplication is appropriate.

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 the core side effect by specifying an output .cube file at an absolute path. It does not discuss overwrite behavior, prerequisites for the current clip, or failure modes, but the main write action is clear enough for a straightforward export 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 two compact parts: a front-loaded purpose sentence and a terse args list. There is no filler or repetition beyond what is needed to document the parameters.

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

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

For a simple two-parameter tool with an output schema and full parameter descriptions, the description is nearly complete. The main residual gap is that 'current clip' is not defined and no usage alternative is given, but the operation and its inputs are sufficiently clear.

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

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

Since schema description coverage is 0%, the description fully compensates by defining output_path as an absolute .cube path and enumerating the allowed export_type values (17pt, 33pt default, 65pt). This adds real meaning beyond the bare schema types and default.

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 opening sentence names a specific verb (export), a specific resource (LUT), and a source scope (current clip's grade). This cleanly separates it from sibling tools like resolve_apply_lut and resolve_get_lut, which involve applying or retrieving rather than creating a .cube file.

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 conveys when the operation is relevant (exporting a LUT from the current grade), but it gives no explicit guidance on alternatives or exclusion conditions. It does not mention that resolve_apply_lut and resolve_get_lut are for other LUT operations, so usage is only implied by the purpose statement.

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 states 'Export' which implies file creation, but doesn't disclose whether existing files are overwritten, what happens if output_path is invalid, or any permissions needed. It also doesn't mention that exporting might affect the timeline state (though it likely doesn't). The description is too thin to fully inform behavior.

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

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

The description is concise, with a clear purpose statement and a structured Args section. Every sentence provides useful information, and the format options are listed compactly. It's slightly thin but well organized.

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 (2 params, one required) and the presence of an output schema, the description is mostly adequate. However, it lacks usage context (when to choose this over other export/render tools), error behavior, and prerequisites (e.g., a loaded timeline). These gaps prevent it from being fully complete.

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

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

The description adds meaningful parameter detail beyond the schema: it specifies output_path as an absolute path and enumerates the allowed format values with a default. This compensates for the 0% schema description coverage, though it doesn't add constraints like file extension rules or format-specific notes.

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 exports the current timeline to an interchange format, listing specific formats (fcpxml, edl, csv, aaf, otio). This is specific enough to distinguish from related tools like resolve_export_lut (which exports LUTs) and resolve_quick_export (which renders for delivery). However, it doesn't explicitly contrast with these siblings, so it's not a perfect 5.

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

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

No guidance is given on when to use this tool vs alternatives. It doesn't mention conditions like 'use this for interchange formats' or 'use resolve_quick_export for final render'. The agent is left to infer usage from the purpose, which is insufficient for a tool with 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?

Annotations are absent, so the description carries the full burden. It discloses key behaviors: case-insensitive matching, substring-based search on both name and metadata, and scope across all bins. It also notes the return format. However, it does not mention that the operation is read-only (implied by 'find'), nor does it explain the effect of the 'limit' parameter or whether both name and metadata criteria are combined with AND/OR. The phrase 'and/or' is ambiguous, leaving behavioral expectations unclear for edge cases.

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 exactly two sentences with zero fluff. It front-loads the core action, then adds return-value context and a clear caveat. Every phrase contributes value: 'case-insensitive', 'substrings', 'across all bins', 'exact names, media IDs and folder paths', and 'Not visual search' are all purposeful. It is exemplary in brevity and information density.

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 0% schema parameter coverage, the description must carry the entire burden. It provides the essential purpose, return information, and a key exclusion, but lacks explicit parameter documentation (especially limit) and does not address usage scenarios relative to other search tools. The ambiguous 'and/or' and lack of guidance on combining criteria make it incomplete for a tool with three optional parameters.

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 implies that 'query' is for name and 'metadata' for metadata substrings, but does not explicitly map each parameter. It completely omits 'limit', which has a default of 50 and likely controls result count. The structure of the metadata object (keys/values) is not explained, leaving the agent to guess the expected format. This is insufficient given the absence of schema descriptions.

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

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

States a specific verb ('Find'), a concrete resource ('shots' / media clips), and precise matching semantics ('case-insensitive name and/or metadata substrings across all bins'). It also explicitly contrasts with visual search, distinguishing it from sibling resolve_find_shots_by_visual_description. The return values ('exact names, media IDs and folder paths') further clarify intent. This is a clear, purpose-driven description that leaves no doubt about what the tool does.

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 a clear context: it searches across all bins, and explicitly excludes visual search ('Not visual search'). This is an effective when-not rule, but it does not name the alternative tool (resolve_find_shots_by_visual_description) or mention other relevant siblings like resolve_list_media or resolve_find_timeline_clip. The guidance is helpful but not exhaustive, lacking explicit recommendations for when to choose this over other search 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 present, the description carries the full burden and does so thoroughly. It discloses cloud transmission, one-frame-per-clip sampling with a 50-clip ceiling, the possibility of misses, analysis of the visible composite including overlays/upper tracks, temporary playhead/page movement, and restoration-status reporting.

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?

Four compact sentences deliver purpose, mechanism, limitations, side effects, and return information with no filler. The key sampling limitation is front-loaded, and every sentence contributes useful 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?

Given that there are no annotations and no output schema, the description still covers method, side effects, return summary, and limitations well. The only notable gap is the missing explicit parameter semantics, which keeps it from being fully self-contained.

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 parameters. It clearly conveys object_description via the airplane example and hints at sampling limits, but max_clips and track_index are never explicitly tied to behavior. An agent cannot tell exactly how track_index changes the analysis or how max_clips interacts with the stated 50-clip ceiling.

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: 'Look for objects such as an airplane in timeline shots using Moondream.' It clearly distinguishes this from single-frame tools by framing it as a search across timeline shots, and the closing 'not exhaustive source-media search' further differentiates its 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?

It gives clear context: this searches timeline shots by sampling one midpoint frame per clip, and it explicitly warns it may miss objects. It also states a when-not: it is not an exhaustive source-media search. However, it does not name a specific sibling tool to use instead, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond a simple 'find' by detailing critical input semantics: timecode format ('absolute HH:MM:SS:FF'), seconds as elapsed since timeline start with a concrete example, end-frame exclusivity, and how track_index=0 searches all tracks. These details reveal how the tool interprets parameters and behaves, which is valuable 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 extremely concise: two sentences with no redundancy. The first sentence states the core purpose, and the second packs essential parameter semantics without padding. It is well-front-loaded and every clause adds information, 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 the tool has 5 optional parameters, no output schema, and no annotations, the description covers input semantics for time-based and track-index search but leaves gaps. It does not describe the return value (e.g., list of clips or a single clip), what happens on no match, or possible values for 'track_type.' This is a moderate level of completeness that allows a basic call but leaves some uncertainty for edge cases.

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

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

The schema has zero description coverage, so the description must compensate. It does so by explaining the meaning of 'timecode' and 'seconds' with formats and an example, clarifying 'track_index' behavior, and implying 'track_type' via 'selected type.' This is a meaningful layer of explanation above the raw schema, though it does not fully cover 'query' or enumerate 'track_type' 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?

The description states a clear purpose: 'Find clips by name and/or position.' This is a specific verb ('find') with a clear resource ('timeline clips') and distinguishes itself from siblings like resolve_find_media_clip (which targets the media pool). It also clarifies the scope ('timeline') through the tool name and description, leaving no ambiguity about what it does.

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 no guidance on when to use this tool versus alternatives. It does not mention scenarios, prerequisites, or when not to use it (e.g., when looking in the media pool instead). While it implies usage by describing search methods, it lacks explicit comparisons or conditions that would help an agent choose it over other resolve find tools.

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

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

With no annotations, the description carries the behavioral burden. It usefully discloses the non-destructive nature and the prerequisite, but it does not describe output/return behavior, failure modes, or what happens when the 350-character limit is exceeded. This is adequate but not rich.

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 focused sentences with no filler. The primary action and the key constraint ('leaving the timeline untouched') are front-loaded, and the prerequisite and character limit follow efficiently.

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

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

For a relatively simple 3-parameter tool, the description covers purpose, output location, side-effect absence, prerequisite, and an input constraint. It lacks explicit return/result description and more parameter detail, but it is functionally complete enough for an agent to invoke the tool correctly.

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

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

Schema coverage is 0%, so the description must compensate for parameter meaning. It adds a character limit for 'text' but says nothing about 'voice' or 'filename' beyond their raw names. The schema only provides types and defaults, leaving the agent to guess filename expectations and voice value semantics.

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

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

States a specific verb ('Generate'), a concrete resource ('a speech clip'), and the target location ('into the media pool'). Also distinguishes itself by explicitly saying 'leaving the timeline untouched,' which separates it from timeline-modifying siblings.

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

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

Provides clear context: the tool is for speech generation into the media pool without touching the timeline, and it notes a prerequisite ('Requires AI Speech Generator Extras'). It does not explicitly name alternatives or exclusion cases, so it stops short of a full 5.

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

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

No annotations are provided, so the description carries the full behavioral burden. It states the operation is a getter and describes the return format, which implies read-only behavior, but it does not disclose failure behavior, error handling, or any environment dependencies.

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 front-loaded with the primary purpose. The Args line adds the only necessary parameter detail, and the return note is useful without being verbose. Every sentence earns its place.

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

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

For a one-parameter getter with an output schema, the description is mostly complete: it states the input and the kind of returned data. It lacks explicit mention of the prerequisite that a project/media pool must be loaded, but the phrase 'in the media pool' provides partial context.

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

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

Schema coverage is 0%, but the description compensates by explaining that clip_name is a clip in the media pool. This adds relevant context beyond the bare schema property name, though it stops short of specifying naming requirements or edge cases.

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: 'Get detailed properties of a media pool clip.' It further specifies the return payload with concrete examples (duration, resolution, codec, fps), which makes the tool's scope clear and distinguishes it from sibling tools like resolve_get_clip_transform.

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 no guidance on when to use this tool versus alternative sibling tools such as resolve_list_media or resolve_find_media_clip. It also does not mention prerequisites like requiring an active project or loaded media pool.

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 explaining behavior. 'Read' correctly signals a non-mutating operation, and the 1-based indexing rule plus playhead fallback adds important behavioral context beyond the bare tool name. It omits error/edge-case behavior, but the output schema likely covers returns.

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 that states the operation, the resource, and the selection modes with no filler. Every clause adds useful 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 read-only getter with only two optional parameters and an output schema available, the description is sufficient for correct invocation. It covers the selection mechanism and indexing convention; return-value details are delegated to the output schema, as appropriate.

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 by explaining that the two integer parameters are 1-based track/clip indices and that omitting them refers to the playhead. This gives meaningful semantics to the otherwise bare parameter names and default 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?

The description uses a specific verb ('Read') and a clear resource ('clip transform values'), and it specifies the two selection modes: playhead or explicit 1-based video track/clip indices. This cleanly distinguishes it from siblings like resolve_set_clip_transform and resolve_get_clip_properties.

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 conveys when the tool applies: reading transform values, either at the playhead or by providing explicit track/clip indices. It does not explicitly mention alternatives or when not to use it, but the invocation context is unambiguous.

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 behavioral disclosure burden. It transparently states that the tool returns the page name and lists all possible values ('media, cut, edit, fusion, color, fairlight, or deliver'). The word 'Get' also clearly implies a read-only operation with no mutation of application state.

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

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

The description is extremely efficient: one sentence states the action and result, and a second sentence lists the possible return values. There is no redundant information or filler.

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

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

For a simple no-parameter getter, the description is fully sufficient. It names what the tool does and enumerates the valid return values, and an output schema is provided to confirm the structure. Nothing needed for correct invocation is missing.

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

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

The tool has zero parameters, so there is nothing to document beyond what the empty schema already shows. The baseline of 4 applies because no parameter semantics are needed.

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 a specific verb ('Get') and resource ('currently active DaVinci Resolve page'), and explicitly enumerates the possible return values. It is easily distinguishable from the sibling resolver tools, especially resolve_open_page, which changes the page rather than querying it.

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 makes the use case evident: call this when you need the name of the currently active page in DaVinci Resolve. It does not explicitly mention alternatives or exclusions, but for a read-only state getter the context is clear enough.

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

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

With no annotations, the description must carry the behavioral burden. It discloses that this is a read operation ('Get') and enumerates the returned data, but it does not explicitly state that it has no side effects, requires no active project, or what happens if no timeline is current. The return-value mention is useful but the safety/state implications are left implicit.

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 short sentences with no filler. The core purpose is front-loaded, and the return content is summarized in a compact list. Every sentence earns its place.

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

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

For a zero-parameter getter, the description is largely complete: it names the resource and the key returned fields, and an output schema exists for exact return structure. It does not mention error cases or prerequisite state (e.g., an open project), but these are minor gaps for a simple query tool.

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

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

The tool takes zero parameters, so the description has no parameter meaning to add. The input schema is empty and coverage is 100%, and the baseline for 0-parameter tools is 4; the description appropriately focuses on the operation rather than adding irrelevant parameter 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 clear verb ('Get') and a specific resource ('the current timeline'), and names concrete return fields (name, timecode, track counts, start/end frames). It is unambiguous about what the tool does, though it does not explicitly contrast itself with sibling tools like resolve_list_timelines.

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 reasonably implied: call this when you need details about the currently active timeline. However, there is no explicit guidance about when not to use it or how it differs from related tools such as list_timelines or get_playhead, leaving much 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?

No annotations are provided, so the description must carry the full burden. It discloses the return format (JSON with comp names and count) and the targeting logic, but does not mention edge cases like empty tracks or missing clips, nor any side effects. This is adequate for a read-only listing tool but not exhaustive.

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 main purpose, followed by parameter explanations. The Args section is moderately compact, though it could be more succinct. No wasted words, but the formatting could be improved for readability.

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 moderate complexity (2 parameters, no required params) and the presence of an output schema, the description covers the essential behavior and parameters. It doesn't need to detail return values since the output schema exists. It lacks edge-case handling but is sufficient for typical 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?

Schema coverage is 0%, so the description must compensate. It explains that 0 means use playhead and 1-based indexing for both parameters, which adds meaning beyond the schema. However, it does not explain the difference between track_index and clip_index beyond their positional roles, leaving some ambiguity about how they interact.

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 that the tool lists Fusion compositions on a timeline clip and targets the clip at the playhead by default. This is specific enough to distinguish it from siblings like resolve_add_fusion_comp and resolve_get_fusion_tools, though it does not explicitly name 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?

It explains that track_index and clip_index can be set to 0 to use the playhead, which is the primary usage pattern. However, it does not provide explicit when-not-to-use guidance or name alternatives, though the default behavior is 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?

There are no annotations, so the description carries the full burden. It discloses the action (listing tools), the return format (JSON array with type and name), and the scoping (clip at playhead, comp index). It does not explicitly state it is read-only or describe error behavior, but 'List' strongly implies no side effects. The description adds context beyond the schema by specifying the 1-based indexing and the playhead requirement.

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

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

The description is extremely concise—two sentences, each earning its place. The purpose statement is front-loaded, followed by a brief parameter explanation and a clear return-type summary. There is no fluff 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 simple tool with one parameter, the description is quite complete. It states what it lists, where (clip at playhead, comp index), and the output shape. It does not mention edge cases like 'no clip at playhead' or 'invalid comp index', but given the simplicity and the presence of an output schema (even if not fully shown), these gaps are minor. The description covers the essential context an agent needs to invoke it correctly.

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

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

Schema coverage is 0%, so the description must compensate. It fully explains the only parameter: 'comp_index' is a Fusion comp index, 1-based, with a default of 1. This adds meaning beyond the schema, which only provides the type and default without explaining what the index refers to or its base. The description also clarifies the context in which the parameter applies (clip at playhead).

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 a specific verb ('List'), a specific resource ('all tools in a Fusion composition'), and a precise context ('on the clip at the playhead'). It distinguishes itself from siblings like resolve_get_fusion_comps (which lists comps) and resolve_add_fusion_comp (which adds a comp). An agent can immediately understand what this tool does.

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 clear context for when to use it (requires a clip at the playhead with a Fusion composition, and accepts a comp index). However, it does not explicitly mention alternatives (e.g., resolve_get_fusion_comps for listing comps) or state any exclusion criteria. It is clear but lacks explicit 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?

No annotations are provided, so the description carries the behavioral burden. 'Get' implies a read-only operation and 'currently applied' suggests no mutation, but the description does not explicitly state side effects, failure cases (e.g., no LUT applied, invalid node index), or any access prerequisites.

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 brief and front-loaded with the main purpose, followed immediately by the parameter clarification. Every sentence adds value without 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?

This is a simple one-parameter getter with an output schema available, so the description is mostly sufficient. It could clarify what happens when no LUT is set or when the node index is invalid, but for a read-only query these are minor gaps.

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

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

The input schema has no description for node_index)Skip, and schema coverage is 0%. The description compensates by explaining that node_index is 1-based and defaults to 1, which is meaningful. It still leaves some ambiguity about what 'node' means, but the single parameter is largely covered.

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 precise read operation: get the LUT currently applied to a node on the clip at the playhead. This clearly distinguishes it from related operations like apply_lut or export_lut, which have different intents.

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 does not provide explicit guidance on when to use this tool versus alternatives such as resolve_apply_lut or resolve_export_lut. The reader must infer that this is the read-only counterpart to applying/exporting LUTs.

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

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

With no annotations provided, the description carries the full burden. It does explicitly say the operation is a read and specifies the keying scheme, which is useful. However, it does not mention dependence on the current timeline, error behavior, or any side-effect-free guarantee beyond the word 'Read'. No contradiction exists.

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. Every word contributes: 'Read' indicates operation type, 'timeline markers' indicates resource, and 'keyed by timeline-relative frame' clarifies the 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?

For a zero-parameter read tool with an output schema present, the description covers the essential semantics: what is being read and how markers are keyed. A minor gap is not explicitly stating that it operates on the current timeline, but that is likely implicit in the Resolve tool family context.

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

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

The input schema has zero parameters and 100% schema coverage, so the baseline of 4 applies. The description adds meaningful context about what is being read and how it is keyed, even though no parameter-level explanation is needed.

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

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

The description states the verb 'Read', the resource 'timeline markers', and the key 'timeline-relative frame'. This clearly differentiates it from marker-mutating siblings like resolve_delete_markers, resolve_add_marker, and resolve_create_chapter_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?

The read verb implies this is the tool for inspecting markers rather than creating or deleting them, but there is no explicit when-to-use guidance or named alternatives. The intended usage is clear enough from context, yet no exclusions or conditions are 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?

Annotations are absent, so the description carries the entire burden of behavioral disclosure. It only says 'get', implying a read operation, but does not disclose what happens if no timeline is loaded, whether the timecode format is standard (e.g., HH:MM:SS:FF), or if any side effects exist. The output schema exists but the description itself offers no explicit behavioral guarantees.

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 that is completely front-loaded, stating exactly what the tool does without any filler. It earns its place and is appropriately sized for a simple getter with no parameters.

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

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

Given the tool's simplicity (no parameters, output schema present), the description is nearly complete. It could explicitly note that it refers to the current playhead on the current timeline, but that is strongly implied by sibling tools and the tool's name. The output schema covers return values, so the description doesn't need to repeat them.

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 schema coverage is 100% by default. The description adds no parameter semantics because there are none to explain. Per the baseline for 0-parameter tools, a 4 is appropriate – the description accurately labels the purpose and there is nothing missing regarding 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?

States a specific verb ('Get'), resource ('playhead'), and detail ('timecode position'). Clearly distinguishes from sibling tools like resolve_set_playhead or resolve_add_marker_at_playhead, which modify or add at the playhead rather than merely read its position.

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

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

Provides no guidance on when to use this tool versus alternatives. There is no mention of the read-only nature or conditions under which it is appropriate, such as requiring an open project and current timeline. The presence of siblings like set_playhead implies use cases but they are not articulated.

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?

There are no annotations, so the description carries the burden of behavioral disclosure. It does add value by specifying that it returns JSON and names key fields, which is not evident from the name alone. However, it does not state whether a project must be loaded, whether the operation is read-only, or what happens if no project is open. For a simple getter, the read-only implication is strong, but the prerequisites remain unspoken.

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 short sentences with no filler. The main action is stated first, followed by the return format and representative content. Every sentence contributes meaningful 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 zero parameters and an output schema available, the description is nearly complete. It communicates the primary purpose and return shape. The only minor gap is the absence of explicit note about requiring an open/current project, though that is largely implied by 'current project.' Overall, an agent has enough to call this correctly.

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

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

The tool has no parameters, so the baseline is 4. The description correctly avoids inventing parameter-related details, and there is nothing more to explain in the input schema. This is appropriate for a zero-parameter tool.

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 clear, specific action ('Get all settings') on a clear resource ('the current project'). It also lists representative returned fields, and the name/description naturally distinguishes it from sibling set_project_setting. The purpose is unmistakable.

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 makes the use case clear: retrieve all settings for the current project. However, it does not explicitly mention when not to use it or point to alternatives like set_project_setting, which would be the natural comparison. The usage is implied rather than explicitly guided.

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 burden. It discloses the return format (JSON with status, progress, completion state) but does not explicitly state that the operation is read-only or non-blocking, nor does it mention error conditions or dependencies on prior render initiation. The 'Get' verb implies safety, but it is not explicitly stated.

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

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

The description is two sentences, front-loaded with the core purpose, and contains no superfluous words. It is highly efficient and well-structured.

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, has no parameters, and has an output schema that likely details the return structure. The description covers the purpose and key fields, which is sufficient for an agent to invoke it. It lacks mention of any prerequisites or when to use it in a workflow, but that is minor for a getter with an output schema.

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

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

The tool has zero parameters, so the description needs to add no parameter meaning. According to the rubric, a tool with 0 parameters gets a baseline of 4, and the description does not need to compensate for any missing schema 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 action ('Get the status') and the resource ('all render jobs'), distinguishing it from siblings like resolve_get_status (general status) and resolve_wait_for_render (blocking wait). It is specific 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?

The description implies usage for checking render status but provides no explicit guidance on when to choose this over alternatives such as resolve_wait_for_render or resolve_get_status. There is no mention of exclusions or prerequisites.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It states that it returns a JSON object with specific fields and implies a read-only operation via the verb 'Get', but it does not explicitly state that it has no side effects or side effects, nor does it mention any error conditions or connection requirements. It adds the return field list, which is useful, but it does not fully disclose behavioral traits.

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 long, with the core purpose front-loaded ('Get current DaVinci Resolve status') followed by a concise list of return fields. Every sentence adds value, and there is no redundancy or filler. It is highly efficient and easy to scan.

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

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

The tool is simple (no parameters, a clear read-only status getter). The description explains the return fields, and an output schema exists (though not shown) to provide structured detail. It does not mention error handling or connection prerequisites, but for a status query these are minor. The description is sufficient for an agent to call it correctly in most contexts.

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%. According to the rubric, the baseline for 0 parameters is 4. The description does not need to add parameter semantics since there are none, and it appropriately focuses on the return value instead.

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 verb 'Get' and the resource 'current DaVinci Resolve status', and specifies the included elements (version, project, timeline, page). It is unambiguous about its purpose. However, it does not explicitly distinguish itself from the sibling tool resolve_get_current_page, which is a more specific status getter, so it misses the top score for sibling differentiation.

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 no guidance on when to use this tool versus alternatives like resolve_get_current_page or resolve_get_playhead. It does not mention any prerequisites, conditions, or exclusions. An agent would have no explicit basis to choose this over its siblings beyond the general purpose.

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 behavioral burden. The verb 'List' implies a read-only operation, and the return-shape statement ('Returns JSON array of clips...') adds some transparency. However, it does not explicitly state side-effect freedom, error behavior, or what happens with invalid track_type/track_index values.

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

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

The description is compact and well-structured: a one-line purpose, a terse Args block, and a one-line return note. Every sentence earns its place with 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?

The description covers parameter semantics and mentions the return shape, but given an output schema already exists, that return mention adds limited value. It lacks usage context, sibling differentiation, and behavioral caveats, leaving the description only partially complete for a simple read tool.

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

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

Schema description coverage is 0%, so the description must explain the parameters. It does this well by enumerating valid track_type values ('video', 'audio', 'subtitle'), noting the 1-based nature of track_index, and providing defaults – all beyond the bare schema type definitions.

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 ('List') and resource ('all clips on a specific track'), making the core purpose clear. It does not explicitly differentiate from siblings like resolve_get_clip_properties or resolve_find_timeline_clip, but the 'all clips on a track' phrasing is enough to avoid major 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?

No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or scenarios where a sibling tool would be more appropriate, which is a notable gap given the large sibling set.

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 transparency burden and delivers: it explains timestamp semantics (timeline-relative seconds vs absolute frames), version requirements, scope ('0 = all' tracks), and the side effect of writing files via output_path. This is thorough behavioral disclosure beyond what structured data provides.

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 dense, purposeful sentences with no filler; the main action is front-loaded and source-specific details are grouped clearly. The compact formatting conveys a high amount of information without wasted words.

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 source selection, prerequisites, formats, and file output, which is substantial for an unannotated tool. However, it is incomplete for a 7-parameter tool: there is no output schema, and media_id/clip_name/max_entries are not defined, leaving clip-source invocation ambiguous.

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

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

Schema coverage is 0%, so the description must compensate. It documents source, format, output_path, and subtitle_track (including 0=all), but leaves media_id, clip_name, and max_entries unexplained, creating gaps for clip-source selection and output limiting.

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

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

The description opens with a specific verb and resource: 'Read transcript TEXT with timing,' then distinguishes two clear sources (captions vs clip). It obviously separates this tool from siblings like resolve_transcribe_audio and resolve_create_captions, so an agent can identify it without opening the schema.

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

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

It gives explicit prerequisite conditions per source: captions requires resolve_create_captions, and clip requires resolve_transcribe_audio. It does not explicitly name alternative tools or negative cases, but the mode-specific guidance is strong and actionable.

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

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

With no annotations, the description carries the burden of explaining side effects alert, and it does state the core behavior: importing into the current bin and returning successful clip names. However, it does not disclose duplicate handling, unsupported file types, or failure behavior beyond returning names.

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

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

The description is compact and organized with Args and Returns sections. Every sentence earns its place, and the key purpose is front-loaded.

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

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

For a single-parameter import tool with an output schema, the description covers purpose, parameter semantics, and return behavior. It is complete enough for normal use, though edge-case behaviors and alternative tool selection are not addressed.

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

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

Schema description coverage is 0%, but the description adds meaning by specifying absolute file paths and providing an example. This compensates for the bare schema definition of 'file_paths' as an array of strings.

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 ('Import') and resource ('media files') and locates the action in the 'current media pool bin.' This clearly distinguishes the operation from siblings like resolve_list_media or resolve_find_media_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 description gives no explicit guidance on when to use this tool versus alternatives, nor does it list exclusions or prerequisites. It only states the action and parameter, leaving usage decisions 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 provided, the description carries the full burden. It discloses key behavioral traits: 'defaults to dry-run', 'Rejects overlap, locked tracks and FPS mismatch', and 'Creates a recovery copy before an actual insertion'. While it does not mention the return format or success signaling, it covers the most critical behaviors for safe invocation.

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, both dense with information. The primary purpose is front-loaded, and the second sentence covers behavioral constraints and safety. There is no waste; every clause adds value.

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

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

Given 7 parameters and no output schema, the description is incomplete. It does not explain most parameters, what the function returns, or when to prefer this tool over siblings. An agent would struggle to correctly populate all arguments without additional knowledge.

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 only hints at 'record_frame' (via 'Absolute record frame') and 'dry_run' (via 'defaults to dry-run'), but leaves clip_name, duration_frames, track_index, media_id, and source_start_frame unexplained. The description adds minimal meaning beyond the schema's property names.

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 a specific verb and resource: 'Insert video-only B-roll into an EMPTY interval on an existing video track.' It distinguishes from siblings like resolve_insert_title or resolve_replace_clip by emphasizing 'video-only' and 'EMPTY interval', leaving no ambiguity about the tool's primary function.

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

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

The description implies usage for empty intervals ('EMPTY interval') and video-only content, but it does not explicitly name alternatives or conditions when not to use this tool. It lacks an explicit 'when-to-use' vs 'when-not-to-use' guidance, so an agent must infer the appropriate context.

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

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

With no annotations, the description carries the disclosure burden. It adds non-obvious behavioral context by stating that size/position are validated and that partial failures can be reported after creation. It does not elaborate on rollback or side effects, but the core mutation and failure behavior are 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?

Two short sentences with the core action first and the caveat second. Every clause earns its place and there is no redundancy or filler.

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

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

The output schema covers return values, and the description gives the essential insertion and failure behavior. However, it does not state prerequisites such as an open timeline or a set playhead, nor clarify the coordinate system, so the tool is usable but not fully self-contained.

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

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

Schema description coverage is 0%, and the description only gestures at 'size/position' without defining units, valid ranges, coordinate system, or how position_x/position_y relate to the playhead. It adds less meaning than the parameter names and defaults already convey.

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 the exact action: 'Insert Text+ at playhead.' The verb-resource pair is precise, and the playhead qualifier distinguishes it from title-modification tools like resolve_modify_title_text and marker tools like resolve_add_marker_at_playhead.

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

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

Provides no explicit when-to-use guidance or comparison to alternatives. It does not tell the agent to use this for new titles instead of resolve_modify_title_text, nor mention any prerequisite such as setting the playhead first via resolve_set_playhead.

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 clearly signals a read-only list operation and specifies the return payload ('JSON with version names and current version'). It also documents the local/remote version distinction, which is meaningful behavioral context.

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

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

The description is compact and well-structured: a one-sentence purpose, a one-line parameter explanation, and a one-line return note. No extraneous content, and the key purpose is front-loaded.

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

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

For a simple one-parameter list tool with an output schema, the description is nearly complete. It covers operation, parameter semantics, and return shape. It does not mention error cases (e.g., no clip at playhead) or prerequisites, but these are minor gaps given the tool's simplicity.

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

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

Schema description coverage is 0%, leaving the description solely responsible for parameter meaning. It fully explains version_type with '0 = local versions (default), 1 = remote versions', adding semantic value that the bare schema lacks. For a single-parameter tool, this is complete.

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

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

The description states a specific verb ('List') and resource ('all color versions on the clip at the playhead'), making the tool's function immediately clear. It also distinguishes itself from siblings like resolve_create_color_version and resolve_load_color_version by focusing on enumeration rather than creation or loading.

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—whenever the agent needs to see available color versions on the current clip—but it does not explicitly contrast it with alternatives or state when not to use it. The version_type explanation adds operational context but not decision 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 full burden. It discloses that the tool lists clips, shows the current bin by default, supports navigating to a subfolder, and returns JSON with folder name, clips, and subfolders. This provides useful behavioral context. However, it does not explicitly state that it is read-only, nor does it mention error behavior or edge cases (e.g., invalid path). While it's obvious that listing is non-destructive, the lack of explicit safety information prevents a higher score.

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 tightly scoped paragraphs. The opening line states the purpose, then it covers the parameter and return format without fluff. Every sentence earns its place, and the most important information is front-loaded. No redundancy with schema or annotations (since none exist).

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 (one optional parameter) and the description covers the key aspects: default bin, navigation, and return structure. It mentions the JSON output includes folder name, clips, and subfolders, which is sufficient for an agent to know what to expect. There is an output schema present (though not shown), so the description need not detail every field. Minor gaps remain (e.g., exact metadata format), but overall it is complete for typical 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?

Schema description coverage is 0%, so the description must compensate. It does so excellently: the Args section explains that folder_path is optional, gives an example ('B-Roll'), and clarifies the default behavior when empty. This adds meaning well beyond the raw schema, which only has a type and default. All parameter semantics are covered.

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 clear verb ('List') and resource ('clips in the media pool') without ambiguity. It also specifies default behavior ('Shows the current bin by default'), which helps distinguish from other browsing tools. However, it does not explicitly compare with any sibling like resolve_find_media_clip or resolve_import_media, so it doesn't fully leverage sibling differentiation. Still, the purpose is immediately obvious.

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 via the folder_path parameter ('Navigate to a subfolder') and says 'Leave empty for current folder,' which gives context. But it does not explicitly state when to choose this tool over alternatives, nor does it mention any exclusions or prerequisites. For a simple list tool, the context is moderately clear 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It does state that it returns a JSON array of project names, which is helpful. However, it does not explicitly confirm this is a read-only, non-destructive operation, nor does it mention any edge cases or side effects (e.g., requiring a project to be open). The information is minimal but not contradictory.

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 that are front-loaded with the key action and scope, followed by the return type. There is no filler or redundancy; every word adds value.

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

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

The tool is simple and has an output schema. The description already states the return format ('JSON array of project names'), which is sufficient for an agent to understand the result. It does not elaborate on error conditions or environmental prerequisites, but for a straightforward list operation this is not critical.

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 description does not need to explain parameter semantics. The schema is empty and offers no additional meaning. The description's focus on 'list all projects' is sufficient and aligns with the baseline for parameterless tools.

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 clear verb-resource pair ('List all projects') with a specific scope ('current database folder'), and the tool name itself distinguishes it from siblings like resolve_create_project or resolve_list_timelines. It is unambiguous about what it does.

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

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

The description states the tool lists projects but provides no explicit guidance on when to prefer it over alternatives or any exclusions (e.g., 'use X for filtered lists'). However, given the simple purpose, the usage is largely implied; it does not actively mislead.

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 bear the full burden. It states the tool returns JSON with preset details, which implies a read-only operation, but it does not explicitly claim non-destructive behavior or disclose any potential side effects or prerequisites. The description is adequate but not fully transparent.

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

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

The description is concise and front-loaded with the primary purpose. It consists of two short sentences, though there is slight redundancy in repeating 'standard and Quick Export' in both sentences. It is still efficient and easy to scan.

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

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

Given zero parameters and the presence of an output schema, the description is complete. It clearly states what the tool does and what it returns. There are no missing details needed for an agent to call it correctly.

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

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

The input schema has zero parameters, so there are no semantics to explain. The baseline for 0 parameters is 4, and the description doesn't need to add parameter information. It correctly focuses on output.

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 lists all available render presets, explicitly mentioning both standard and Quick Export types. This makes the resource and scope unambiguous, distinguishing it from other list tools like list_projects or list_timelines.

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 about when to use this tool versus alternatives. The purpose implies it is used to retrieve render presets, but no context is given such as 'before rendering' or 'to check available options'. It falls short of explicit usage 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 disclosure burden. It explicitly states the read-only list behavior and what the JSON array contains. It does not mention failure modes such as requiring an open project, but this is minor for a zero-parameter list 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 composed of two focused sentences: the first states the action and scope, the second specifies the output shape. There is no fluff or unnecessary detail, and the core purpose is front-loaded.

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

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

For a zero-parameter enumeration tool with an output schema available, this description is complete. It identifies the resource, limits it to the current project, and summarizes the returned data. Nothing required to invoke the tool correctly is missing.

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