CutLuma video editor

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety bar is low. The description adds genuine value beyond them: the conditional return of a link when no editor is connected, and the fact that editing/frames/export depend on this connection.

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, front-loaded with the core check and followed by the outcome and dependency. Almost no waste, though it could be tightened slightly.

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 output schema, the description carries the return-value burden and does partial work by explaining the conditional link return. An agent knows the operation is a read-only idempotent check and what it depends on, leaving little unstated beyond exact return shape.

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 100% and the single 'project' parameter is already documented as coming from list_projects or create_project. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific check (is an editor tab listening for this project) with a clear resource and a concrete outcome (returns a link if not). It is distinguishable from most siblings, though it does not explicitly contrast with make_editor_link, which sounds closely related.

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?

'Editing, frames and export need it' gives implied usage context by naming the dependent features. However, it offers no explicit when-to-use-vs-alternative guidance, particularly against the sibling make_editor_link, which likely serves a overlapping 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?

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the bar is lower. The description adds real value beyond them by disclosing the return payload ("the id and the link the user opens so you can edit it") and clarifying that the project starts empty.

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, front-loaded with the core action, then the format options, then the return value. No filler and no repetition of the schema.

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

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

For a four-parameter creation tool with no output schema, the description usefully covers the format-vs-dimensions choice and the return values. It is slightly incomplete in leaving `name` undocumented and not stating whether width/height and format can be combined.

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 carry the parameter burden. It does add meaning for format by mapping each enum value to platforms (YouTube, TikTok, Reels, Shorts) and explains the width/height alternative, but the `name` parameter is never mentioned and no defaults or mutual exclusivity between format and width/height is stated.

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

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

The description opens with a specific verb+resource ("Start an empty project"), and the word "empty" distinguishes it from mutation siblings like edit_project and read siblings like get_project. It stops short of naming an alternative tool explicitly, so it is clear but not fully sibling-differentiated.

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

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

Usage is only implied: an agent can infer this is the entry point for creating a new project rather than opening an existing one, but there is no explicit when-to-use guidance, no prerequisites, and no named alternative (e.g., find_templates or connect_editor) for adjacent workflows.

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 already declare destructiveHint=true, non-idempotent, non-read-only. The description adds genuinely new behavioral detail: the batch is a single atomic undo step, it returns what changed or the failure reason plus the new timeline, times are in seconds, and measurement-only ops (loudness, scopes) also return data here. It does not cover permissions/prerequisites, though the confirm gate is documented in 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?

Four dense sentences, each carrying distinct information: operation model, atomic undo semantics, return behavior, and time/id conventions. Front-loaded with the core action; no filler.

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

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

For a complex batch-mutation tool with no output schema, it covers return values, atomicity, units, and id provenance. A little more on failure modes or auth requirements would fully close the gap, but what is present is sufficient 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 67%, and the opaque 'args' object has no schema description. The description compensates by explaining that args follow ops from list_edit_ops, that time args are in seconds, and that project ids come from get_project (schema says list_projects/create_project). This meaningfully disambiguates the nested action payload.

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

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

States a specific verb+resource: runs one or more edit ops from list_edit_ops in order, as one undo step. It distinguishes itself from siblings by naming list_edit_ops as the source of ops and get_project as the source of clip ids, so an agent knows this is the executor rather than the enumerator.

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?

Tells the agent the workflow: fetch ops from list_edit_ops and clip ids from get_project before calling. It gives clear context for how to use it but does not explicitly state when-not to use it versus other edit paths (e.g., create_project or editor 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?

Annotations already cover safety (destructiveHint=false, idempotentHint=false, openWorldHint=true), and the description adds substantive context beyond them: asynchronous execution with immediate job-id return, approximate duration, and concrete plan quotas (720p + watermark, 10 min cap, 10 exports/month). That is exactly the operational and rate-limit information annotations cannot carry.

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

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

Three sentences, front-loaded with the action and its effects, then the async behavior, then the constraints. No filler and no repetition of the title or name.

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 output schema, the description correctly explains the return value (job id, later a share link) and the asynchronous contract, which is the main thing an agent needs. Minor gaps remain around failure modes (quota exceeded, render errors) and whether a re-export overwrites a previous one.

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 only 40%, so the description should compensate. It partially does by tying resolution to plan tiers (720p/1080p/4K), but says nothing about fps, quality, or the share flag's semantics, leaving three of five parameters with no added meaning.

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 concrete verb and resource ('Render the project to MP4'), plus the three side effects: saved to library, share link returned, job id issued. An agent can distinguish this from siblings such as get_shared_video or get_job without opening any 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?

Explicitly routes the agent onward ('this returns a job id at once: poll get_job'), which is the key sequencing decision for a long-running operation. It does not state when *not* to use it (e.g. mid-edit, or which tool to use for a preview), so it falls short of full when/when-not coverage.

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 already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds one genuinely new behavioral fact: each result carries an 'open' link that loads it in the editor, which compensates somewhat for the absent output schema. It says nothing about pagination or how many results come back, so it does not go far beyond the 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?

Front-loaded with a clear opening clause, but it degenerates into a single run-on sentence packing ~50 categories inline. The category list does carry information the schema omits, so it is not pure padding, but the wall-of-values phrasing harms scannability and could be summarized.

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 six-parameter, zero-required discovery tool with no output schema, the definition covers the filtering dimensions well and hints at the result shape. It leaves pagination/limit behavior and the semantics of 'query' (title match vs. full-text?) unexplained, so it is viable but not 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 coverage is only 33%, and the description compensates strongly: it explains the format values with platform context, lists the full category vocabulary (which the schema leaves as an unconstrained string), and maps language codes to names. This meaningfully extends the schema, though 'query' and 'limit' remain undescribed anywhere.

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

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

Specific verb+resource ('Find animated video templates') with an explicit enumeration of the search facets (keyword, format, category, language). An agent immediately knows this is a template-discovery tool. It does not name or differentiate from any sibling, but no sibling overlaps this function, so clarity is high without routing guidance.

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

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

Usage is implied through the facet list – the agent can infer it should call this to search for stock templates – but there is no explicit when-to-use/when-not, no prerequisites, and no pointer to adjacent tools (e.g., search_cutluma or list_free_tools). Adequate but leaves routing 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered without the description. The description adds the terminal/non-terminal state vocabulary and that a result is returned, which is useful context, but it says nothing about polling frequency, job expiry, or what happens if the job id is unknown.

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

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

One sentence, front-loaded with the return payload and its enumerated states, with no filler. Every clause 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?

There is no output schema, but the description names the status values and states that a result is returned, which is enough for an agent to interpret the response shape. For a single-parameter poller this is nearly complete; only the job-id lifecycle is unaddressed.

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% for the single 'job' parameter, so the description carries the burden. It implies the job identifier originates from a prior call that answered 'running', which is genuinely useful, but it gives no format, source field name, or example value. Partial compensation earns a middle score.

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 resource (job) and precisely what it returns: status and result of an export or any async call. The parenthetical status vocabulary (queued, running, done, failed) makes the operation unambiguous. It does not need to differentiate from siblings since none of the listed tools poll jobs, but it also doesn't name any sibling, keeping it at 4 rather than 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 clause 'or any call that answered "running"' is an explicit trigger condition: use this after a prior call returns a running status. That is clear when-to-use guidance. It stops short of stating exclusions or a polling cadence, so it is not 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?

Annotations already cover the safe-read profile (readOnly, idempotent, non-destructive), so the bar is lower. The description still adds real value beyond them: the async behavior ('a long file takes a while the first time: it may answer with a job id (poll get_job)') and the cost signal ('Free'), plus output semantics (dBFS scale, −100 = silence). It does not describe pagination or the exact result shape, keeping it out of the top band.

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?

Front-loaded with the resource ('Loudness over time of a library video or sound file') before mechanism, units, use case and the async caveat. Dense but nearly every clause earns its place; the long first sentence is packed but not redundant.

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?

There is no output schema, so the description carries the return burden and does so: RMS in dBFS per step, quiet segments (pauses/dead air), loud moments, all in seconds, plus a note that long files may return a job id to poll. That covers the practical calling contract, though result length/default step count is only partially 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 coverage is 60%; the schema documents step, media and project but leaves to/from bare. The description compensates by clarifying the time axis ('all in seconds of the file') and the meaning of step readings (RMS in dBFS per step), effectively giving units to the undocumented from/to window parameters. It stops short of stating defaults or bounds for from/to.

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 resource (loudness/levels over time of a media file) and pins down the output units precisely: RMS in dBFS per step, with −100 = silence, the quiet stretches and the loudest moments in seconds. It also distinguishes itself from sibling transcript tools by noting it 'Finds where the talking is without transcribing.' An agent can tell this apart from get_media_transcript or view_media_frame without opening a 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?

Usage is implied rather than stated: 'Finds where the talking is without transcribing' hints it is an alternative to transcript tools for locating speech, and 'Free' signals cost. But there is no explicit when-to-use/when-not or named alternative, leaving the agent to infer selection between this and the transcript/frame 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 only say readOnlyHint=false and idempotentHint=true; the description explains why: new audio consumes AI time at one AI minute per minute of sound, silence is free, previously heard stretches are cached so repeats and later captioning cost nothing. It also discloses the async job-id path for long ranges and that results report AI seconds used and known stretches — behavior an agent cannot infer from the 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?

Purpose is front-loaded in the first sentence, and each following clause (cost model, caching, range narrowing, job polling) contributes unique operational information. The prose is denser and more run-on than necessary, with em-dashes and asides that could be tightened, but there is 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?

There is no output schema, and the description compensates: it states the return format (lines with times in seconds), the metadata returned (AI seconds used, which stretches are known), and the alternate return (a job id for long ranges). Combined with the cost model, an agent has everything needed 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?

Schema coverage is 100%, so the baseline is 3; the description still adds decision-relevant meaning by explaining that from/to exist to avoid transcribing (and paying for) an entire long file. The language parameter is not mentioned in the description, though the schema covers it.

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 resource and output shape: the words spoken in a library video or sound file, returned as timed lines. The 'whether or not it is on the timeline' qualifier cleanly separates it from timeline-scoped siblings such as get_transcript, so an agent can choose without opening a 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 concrete routing advice: use from/to to hear part of a long file, call get_media_levels (free) to find where sound is, and poll get_job when a long stretch returns a job id. It does not explicitly contrast with the get_transcript sibling, so it falls short of a full when/when-not 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and closed-world scope, so the safety profile is fully covered. The description adds that the response is Markdown and which paths are valid, but says nothing about missing-path behavior, auth requirements, or response size limits.

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 leads with the action and return format, then spends the rest of its length on the path list, which is the one piece of information the schema does not supply. Nothing is wasted.

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 read tool with no output schema, the description covers the action, the content type, and the valid inputs, and 'as Markdown' characterizes the return. Only absence of error/pagination behavior keeps it from a 5.

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

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

Schema coverage is 100% for the single path parameter, so the baseline is 3. The description genuinely adds meaning beyond the schema by enumerating the valid path families and slug/id patterns, effectively supplying the value set that the schema omits (no enum is defined).

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

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

States a specific verb and resource ('Read any CutLuma content page as Markdown') and then enumerates the exact route families it serves, which makes the scope concrete. It falls short of a 5 because it never distinguishes itself from siblings that cover adjacent content, such as get_pricing, find_templates, video_size_guide, or list_free_tools.

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

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

The route enumeration implicitly tells an agent when this tool applies (fetching marketing/site content by path), but there is no explicit when-to-use, when-not-to-use, or named alternative. With content-specific siblings like get_pricing and find_templates in the list, an explicit routing note would have been valuable.

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 already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds value beyond that by enumerating the fields returned (price, billing interval, limits, inclusions), which matters since there is no output 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?

Two short sentences with zero filler; the payload contents are stated first and the plan-context note follows. Nothing is repeated from the schema or annotations.

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-only, closed-world lookup with no output schema, the description is nearly sufficient: it says what is returned and gives the headline plan facts. The only minor gap is not stating the response shape (single plan list vs. nested structure).

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 no parameters, so per the baseline this scores 4. The description correctly implies a parameterless catalog read with no filtering options.

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 the specific resource and its contents: current CutLuma plans with price, billing interval, limits and inclusions. No sibling tool covers pricing, so the distinction is effectively unambiguous even without naming an alternative.

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

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

Usage is implied — an agent should call this for pricing or plan questions — and the second sentence hints at a common question (is the editor free / which plan has AI features). There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are referenced.

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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds real value beyond that: "as last saved" discloses that the data is a snapshot rather than live, and "full=true also lists caption clips" discloses a behavior toggle.

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?

Very short and front-loaded, but the opening is a verbless fragment ("Tracks (top to bottom) and every clip..."), which reads awkwardly and slightly obscures the action. No wasted words, but structure is telegraphic rather than clean.

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 output schema, the description carries the return-value burden and does list the salient fields (id, kind, start, duration). For a 2-parameter read tool this is largely complete, though it says nothing about ordering guarantees, pagination, or error 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 coverage is 50%: the 'project' param is documented in-schema, but 'full' is bare. The description compensates by explaining exactly what full=true does (includes caption clips), which is more than the schema provides. Could be a notch higher if it clarified default behavior when full is omitted.

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 title plus description make clear this reads a project's timeline: it returns tracks top-to-bottom and every clip with id, kind, start, and duration. The resource is distinct from siblings like edit_project or create_project, though the description never explicitly names 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?

"Use before editing" provides one concrete when-to-use hook, which is genuinely helpful for sequencing. However, there is no when-not guidance and no named alternative for read paths (e.g. view_media, list_edit_ops), so routing is only implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds the concrete return fields, which matters given there is no output schema, but it omits whether the link must be public, auth requirements, or error behavior for invalid links.

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 no wasted words; the resource and the returned fields are stated compactly. It is efficient though not structured into explicit use-case guidance.

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 read-only lookup whose annotations cover the safety profile, listing the return fields compensates for the absent output schema. Nothing essential to invoking it correctly 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?

Schema coverage is 100% and the single 'url' param is documented as 'The share link'. The description reinforces the expected format (cutluma.com/watch?v=…), adding modest value, but the baseline of 3 applies since the schema already carries the 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 resource ('Details of a video shared with a CutLuma link') and enumerates the returned fields, so the agent knows exactly what it retrieves. It implicitly distinguishes itself from project-media siblings (view_media, view_media_frame) by scoping to an external share link, though it never names an alternative.

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 share-link format example ('cutluma.com/watch?v=…') implies the input context, which is helpful guidance. However, it offers no explicit when-to-use/when-not, no prerequisites, and no routing to sibling lookups.

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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely non-obvious behavior: the result can legitimately be empty because clips may not yet be transcribed, and it names the remediation tools.

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, front-loaded with the primary purpose and return shape, then the fallback behavior. No filler and nothing repeated from the schema or annotations.

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 output schema, the description does the work of describing the return: spoken words with start/end in seconds. It omits how the transcript is structured (per-clip grouping, ordering, field names), which is a minor gap for a 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?

Only one parameter (project) and schema description coverage is 100%, with the schema pointing to list_projects/create_project for the id. The description adds no further meaning about the parameter, so this sits at the baseline for fully documented schemas.

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 resource ('the spoken words of the project's clips placed on the timeline') with scope detail (start/end in seconds) and conditions ('when the clips have been transcribed'). It explicitly contrasts with the sibling get_media_transcript, so an agent can distinguish the two without opening either 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?

Clearly signals the alternative path when the result is empty: use get_media_transcript (which also handles files not on the timeline) or run the addCaptions op. It doesn't state a general when-to-prefer rule up front, but the empty-result routing is concrete 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?

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuine value beyond that: the content shape of the return (name, arguments, meaning) and the session-scoping advice that the call is a one-time setup step. It does not mention catalogue size or pagination.

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 compact sentences, front-loaded with what the tool returns, followed by the one action directive. No filler or restatement of the tool name.

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 output schema, the description correctly describes the return content (name, arguments, meaning) and the call timing. It is nearly complete for a one-parameter read tool; only volume/pagination behavior is left unstated.

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

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

Schema coverage is 100% and the single 'project' parameter is fully documented in the schema. The description only implies the project context via 'the open editor' and adds no syntax or format detail, so the schema does the heavy lifting.

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

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

States a specific verb and resource ('the full catalogue of ops the open editor can run') and enumerates the categories it covers (text, captions, trims, grading, sound, effects, AI tools). An agent can distinguish this from siblings like list_projects or list_media 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?

Gives explicit timing and ordering: 'Call once per session before edit_project,' naming the sibling that depends on it. It stops short of saying what happens if skipped or how to refresh the catalogue mid-session, so it is clear context rather than full when/when-not guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context about the payload — 68 entries, each with a description, a free/plan designation, and a launch link — which is valuable given there is no output 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?

A single sentence, front-loaded with the verb and the exact count, then the three fields returned. The parenthetical example list is slightly long and trails into an ellipsis, but nothing is redundant enough to waste an agent's attention.

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 output schema, the description carries the burden of describing return values, and it does so — per-tool description, free/plan status, and link. It could note that the catalog is static or that plan labels may change, but for a zero-parameter read tool this is sufficient to call 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 takes zero parameters, so the baseline is 4. The description correctly implies a single unfiltered call that returns the full catalog, which is consistent with an empty input 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?

States a specific verb (list) and resource (all 68 single-purpose tools) and immediately enumerates the kinds of tools covered, so an agent knows exactly what category of content this returns. It does not explicitly differentiate itself from the closest sibling, get_pricing, which also carries plan information.

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

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

Usage is implied rather than stated: an agent can infer this is the catalog-lookup tool for discovering tools and their plan requirements. There is no explicit when-to-use framing and no mention of get_pricing as the alternative for detailed pricing tiers, so a routing decision against siblings is left 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description adds useful scope context (user-uploaded or recorded assets only) and the returned field set, but says nothing about ordering, pagination, or how many items come back by default.

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, resource first, no filler. The trailing 'addMedia op' reference is slightly cryptic since no such sibling tool appears in the toolset, but it costs 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?

With annotations covering safety and no output schema, the description need not explain return values, but it should explain that 'kind' narrows results and that 'limit' caps them. Those omissions leave the two optional parameters effectively undocumented across both schema and 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 carries the burden and largely fails: neither the 'kind' filter (video/image/audio) nor 'limit' (1-200) is explained. The phrase 'Videos, images and sounds' loosely echoes the kind enum values but never indicates it is a filter 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 names the resource concretely ('Videos, images and sounds the user has uploaded or recorded') and enumerates the returned fields (id, name, kind, duration), so an agent knows exactly what this returns. It does not, however, explicitly differentiate itself from close siblings like view_media or get_media_levels.

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

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

The only guidance is a forward reference to a downstream action ('Put one on the timeline with the addMedia op'), which is not a when-to-use rule. There is no statement of when to prefer this over view_media or the other media tools, and no mention of filtering or pagination behavior.

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 already declare read-only, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new context: the auth requirement (sign-in or agent key), deterministic ordering (newest first), and the fields returned. It stops short of pagination or rate-limit 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?

Two tight sentences with the resource and ordering front-loaded and the auth condition attached at the end. No filler or restatement of the title.

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 output schema, describing ids, sizes and durations is exactly the kind of return-value context needed, and the auth precondition is covered. The only real hole is pagination/default behavior around 'limit'.

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 single optional 'limit' parameter is never mentioned in the description, so no default, pagination, or truncation behavior is explained. The schema itself bounds it (1-100), which keeps this at a baseline 3 rather than lower.

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

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

States a specific verb (list) and resource (CutLuma projects) with explicit scope: only the signed-in user's projects, newest first. That scope plus the plural distinguishes it from the singular get_project sibling, though no sibling is named outright.

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?

"Needs the user's sign-in or an agent key" gives a usable prerequisite, but there is no guidance on when to pick this over get_project or search_cutluma. Usage is implied by the resource scope rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and non-open-world, so the safety profile is covered. The description usefully adds that omitting both parameters yields a blank project, but omits other behavioral context such as link lifetime, authentication requirements, or whether the link is shareable.

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

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

The purpose is front-loaded well, but the bulk of the description is a 48-value enumeration that simply restates the schema enum and adds no information. Removing that list would leave a tight, informative pair of sentences.

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, no-output-schema tool the description covers the tool and language semantics and the empty-input default, but is silent on template (beyond the schema) and on what the returned link looks like or whether it is reusable. Adequate, not 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 coverage is only 33%, so the description must compensate, and it largely does: it explains that language is a two-letter captions code and defines the default when nothing is supplied. It does not describe the template parameter at all, leaning on the schema's pointer to find_templates, and the re-listing of all 48 tool values duplicates the enum.

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 first sentence states a concrete verb and resource: it builds a link that opens the CutLuma editor with a tool or template preloaded. That is specific and actionable. It does not differentiate from siblings such as connect_editor, which also concerns editor entry, so it falls 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 explains the outcome for each input state (tool given, language given, neither given), which implies usage. However, it never says when to choose this over connect_editor or create_project, nor any prerequisite for using the link, so guidance is only implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: what a result contains (matching pages with links), that a Markdown URL provides full text, and that an editor-ready link appears where applicable. With no output schema, this return-shape disclosure is valuable.

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?

Front-loaded with the action, then a return-value sentence. The middle enumeration of corpora is long but each item earns its place by defining search scope. Slightly dense, but 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?

With no output schema, the description appropriately explains what is returned, and annotations cover the safety profile. Parameter coverage at 67% leaves only the intuitive limit undocumented, so an agent has essentially everything needed 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?

Schema coverage is 67% and both non-trivial parameters (query, kind) are already described in the schema, including the note that 'guide' covers how-to guides and playbooks. The description adds no syntax, filtering or limit semantics beyond that, so the baseline 3 applies; the self-explanatory limit (1-50) is the only undocumented field.

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 ('Search') plus the exact corpora it searches: free online tools, 'video editor for <platform>' pages, how-to guides, business playbooks, and 5030 templates. This inventory clearly distinguishes it from narrower siblings like find_templates, list_free_tools, video_business_playbooks and video_size_guide, which each cover only one slice.

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 enumeration of searchable content implies when the tool is useful (broad discovery across all CutLuma content), but there is no explicit when-to-use/when-not statement and no routing advice such as 'use find_templates if you only need templates'. Usage is inferable rather than stated.

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

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

The annotations already cover read-only, idempotent, non-destructive, and closed-world safety. The description usefully adds that each part cites its sources, that figures are published ranges rather than income promises, and how matching works for the optional topic. It does not discuss response size or pagination, but adds meaningful context beyond the 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 front-loaded with the core resource definition, then explains no-argument and with-argument behavior, then adds sourcing and disclaimer notes. The parenthetical enumeration of fourteen playbook topics is long but informative; it slightly burdens conciseness without being redundant.

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 rich annotations and a fully described single parameter but no output schema, the description still explains the return shape (business model, key facts, takeaways) and directs the agent to get_page for full text. Nothing needed to select or invoke the tool correctly appears to be missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes further by clarifying that the optional topic filters matching playbook parts and provides concrete example values such as "clipping", "YouTube pay", and "real estate", adding semantic value beyond the schema's brief field description.

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

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

The description names a specific resource—CutLuma's researched guides on earning money with video—and enumerates the covered playbook topics. It clearly distinguishes itself from the sibling get_page by stating that full text is read there, so an agent can tell what this tool returns 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 branching: omit the topic argument to get every part with model, key facts, and takeaways; supply a topic to filter matching parts. It also names get_page as the alternative for reading full text. No explicit when-not-to-use condition is provided, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the content scope (platform list plus safe-zone advice) but says nothing about the return shape or whether the optional filter changes the output format.

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

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

One tight sentence, front-loaded with the core deliverable (aspect ratio and pixel size) followed by the platform coverage and the safe-zone extra. No filler.

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

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

For a zero-parameter-required static reference lookup with no output schema, listing the covered platforms and the safe-zone advice is nearly sufficient. Minor gaps: it doesn't clarify whether omitting the filter returns all platforms or a default subset.

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 100% and the single optional 'platform' param is fully documented in the schema with examples. The description adds no format or semantics beyond that, so the baseline of 3 applies.

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

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

Names the specific resource (recommended aspect ratio and pixel size) and enumerates the exact platforms covered, so an agent knows precisely what reference data it will get. Clearly distinguishable from the sibling editor/media actions, which are all operational rather than informational.

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

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

Usage is implied by the content scope — consult this when you need platform specs — but the description never states when to call it versus simply answering from model knowledge, nor does it name any alternative. No exclusions or prerequisites given.

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 already declare readOnly, idempotent, non-destructive, closed-world reads, so safety is covered. The description adds genuinely useful behavior: the output is a visual grid of frames each stamped with its time, and that it is the fastest review path. It omits cost/size limits for large projects, but against existing annotations this is solid added 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?

Three tight sentences, front-loaded with what the tool produces and then the mode variants. No filler; every clause maps to a parameter or a distinct use case.

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 output schema, the description carries return-format burden and does describe the grid-of-stamped-frames output plus the three targeting modes. It is complete enough to invoke correctly, though the unexplained 'count' bound and behavior for very long projects 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?

Schema coverage is only 50% (from, to, count lack schema text), and the description compensates by explaining from/to as a time range and times as an alternative for exact moments, plus the clip semantics. It adds real meaning beyond the schema, though 'count' (2–16) is left unexplained in both places.

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 concrete verb+resource (a grid of frames across the project) and a clear outcome ('the quickest way to review an edit'), so an agent can distinguish it from single-frame siblings like view_frame. It does not name those siblings explicitly, so differentiation is by described behavior rather than by 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?

Gives clear mode-selection guidance: use 'times' for exact moments (e.g. both sides of a cut), use 'clip' for one clip across its length, default for whole-project overview. It stops short of naming an alternative tool (view_frame/view_media) for the exact-moment case, so the when-to-use-vs-sibling guidance is 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it returns a JPEG, it moves the playhead as a side effect, and clip mode isolates a single clip's crop/grade/effects with nothing in front or behind. The playhead side-effect disclosure is a meaningful addition.

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?

Front-loads the core purpose (composited picture as JPEG) and keeps to three compact sentences. The em-dash-heavy parentheticals are slightly dense but each clause carries distinct information (clip isolation, multicam), so little is wasted.

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 output schema, the description correctly states the return format (JPEG) and the playhead side effect. It also covers the non-obvious clip behavior. Only missing details like resolution defaults relative to the width param (which the schema already documents) keep it from a 5.

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

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

Schema coverage is 100%, so baseline is 3. The description nonetheless adds semantics beyond the schema for 'clip' — that it shows the clip's crop, grade and effects alone, with nothing over or under it — and explains that 'time' drives the playhead position. This goes beyond the schema's terse parameter text.

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

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

States a specific verb+resource: returns the composited timeline picture at a given time as a JPEG. It also distinguishes the 'clip' mode (one clip alone) from the full composite, and notes the multicam use. It does not, however, explicitly differentiate itself from close siblings like view_media_frame or view_contact_sheet.

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?

Gives clear context for use — checking framing, text, colour and layout — and a secondary use case (viewing an off-air multicam angle). No when-not conditions or named alternative tools are provided, 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: it does not place the media on the timeline and it runs in the open editor, which is a real environment constraint. It stops short of describing return shape or limits, but it clearly exceeds the annotation baseline.

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, front-loaded with what the tool produces and followed by the usage progression. Dense but every clause carries information; the parenthetical image caveat is slightly tucked away but not wasteful.

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?

No output schema exists, so the description's explanation of what is rendered (frames stamped with times) earns its place. With read-only annotations covering safety and the workflow covered, an agent has enough 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?

At 67% schema coverage, the description clarifies the from/to pairing as a narrowing mechanism, but it never mentions 'count' or 'times', the two parameters whose semantics (how many frames, exact timestamps) are non-obvious. It partially compensates but leaves real gaps.

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 exactly what the tool returns ('a contact sheet of a video... frames across the file, each stamped with its time') and distinguishes the image case, making it clearly separable from siblings like view_frame and view_media_frame.

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 prescribes a concrete workflow: look at the whole file first, then narrow with from / to, then use view_media_frame for a single moment. The alternative tool and the condition selecting it are named outright.

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 already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description usefully adds the output format (JPEG) and that it is the raw file with no crop, grade or titles, but says nothing about rate limits or return payload details beyond format.

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 compact sentence with the output format and the no-crop/no-grade caveat front-loaded. The phrasing is slightly garbled but nothing is padded or redundant.

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 image-extraction tool with full schema coverage and complete annotations, the essential mechanics are present. The critical missing piece is disambiguation from view_frame/view_media, which leaves a real selection gap for the agent.

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 100%, so the four parameters (time, media, width, project) are fully documented in the schema. The description adds no parameter-level detail such as default width or frame-selection semantics, so the baseline 3 applies.

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

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

The description conveys a specific resource and output: a single frame of a library video (or image) returned as a JPEG, uncropped/ungraded/untitled. However, it is awkwardly phrased ('one frame ... at a time in the file') and does not distinguish this tool from the sibling view_frame, which an agent must choose between.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the highly overlapping siblings view_frame and view_media. An agent has no basis from the description to pick view_media_frame over view_frame.

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