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

With no annotations, the description carries the full behavioral burden and does well by disclosing that the operation is paid, estimates cost first, refuses over-budget jobs, and resumes submitted jobs rather than charging twice. It does not cover permissions, error behavior for invalid inputs, or return mechanics beyond the resulting asset id.

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: first the transformation and duration, then camera options, then cost behavior. Every sentence adds useful information without 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 description is substantial for a tool with no annotations and no output schema, especially around paid-job behavior. It is still incomplete for a six-parameter tool because it omits `project`, does not clarify whether `id` is an input or the produced asset identifier, and does not explain async or return behavior beyond the video asset id.

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

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

Schema coverage is 0%, so the description must document six parameters. It explains image_asset, motion, camera options and default, and the 2–12 second duration range, but leaves the required `project` parameter undocumented and makes the required `id` parameter ambiguous by describing it as the resulting asset.

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: turning an image asset into a short silent video asset with motion. It is clearly distinct from siblings like edit, draw, capture, or render, though it does not explicitly name an alternative sibling to disambiguate further.

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 description of animating an image, and the cost behavior gives useful context for when calling is safe. However, it does not state when to use this versus alternatives such as render or edit, nor does it describe 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?

No annotations are provided, so the description carries the full disclosure burden. It implies a read operation but never states read-only behavior, whether results are paginated, what permissions are needed, or what happens for a project with no assets.

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 filler. It is efficient, though the brevity comes at the cost of the missing details noted elsewhere.

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

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

For a simple one-parameter read tool with no output schema, the description at least signals the shape of returned data (kinds, sizes, durations). But with no annotations and an undocumented required parameter, an agent still lacks enough to call it 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% and the description does not clarify the 'project' parameter at all — whether it takes a name, ID, or path. Only the possessive phrase 'the project's assets' weakly ties the parameter to the 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 names the resource (a project's assets) and hints at returned attributes (kinds, sizes, durations), so an agent can infer this is a listing/inspection tool. But the verb is never stated, and it provides no differentiation from close siblings like library, import_asset, or preview.

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 call this versus siblings such as library or import_asset, nor any stated preconditions. The agent must infer usage entirely from the name and the single 'project' parameter.

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

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

With no annotations, the description carries the full burden and does real work: it discloses the viewport (phone width), the deterministic output path (assets/<id>.png), and the annotation behavior of boxing the matching sentence, including the empty-match fallback that boxes the title. It omits whether an existing asset is overwritten and whether the page load is awaited before capture.

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 action and output, with the parameter guidance tucked into parentheticals rather than a separate paragraph. Dense but every clause carries information; only the nesting of match guidance mid-sentence slightly hurts scannability.

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

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

For a 4-param tool with no annotations and no output schema, the description covers viewport, output path, and match semantics well. However, the project parameter is undefined and there is no statement about return value, overwrite behavior, or failure modes such as an unmatched phrase.

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, and it does for three of four params: id maps to the filename, url is the page, and match gets genuinely useful guidance (short exact phrase, 8-20 characters safest, empty boxes the title) that no schema field conveys. The project parameter is never mentioned, which is the remaining gap.

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

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

States a specific verb (screenshot) and resource (a web page at phone width) plus the exact output location assets/<id>.png, so the effect is unambiguous. It does not differentiate itself from similarly-named siblings like render or preview, leaving the agent to infer which produces a static evidence capture.

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 'as evidence asset' hints at a review/evidence workflow, but there is no explicit when-to-use, when-not-to-use, or named alternative among preview, render, or draw. The agent must guess whether this or render is the right tool for a given page.

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 usefully discloses the severity model — errors block render, warnings/advice are informational — but leaves unclear whether 'apply the owner's rules' mutates the project, what permissions are involved, or how results are surfaced.

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 severity semantics, then the timing. 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 validation tool with no output schema and no annotations, the description covers what it does, the severity model, and when to run it. The main remaining gap is whether it modifies project state and what the check output looks like.

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 single 'project' parameter is undocumented, so the description must compensate. It only refers to "the project" in passing without saying whether that is a name, id, or path, leaving the parameter 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?

States a specific verb (validate) and resource (the project) and adds that the owner's rules are applied. It does not explicitly distinguish itself from the sibling 'typecheck', which plausibly overlaps, 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?

"Run it after a batch of edits and before render" gives concrete timing guidance, which is real when-to-use context. No when-not-to-use or explicit alternative (e.g. typecheck vs check) is named.

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 exist, so the description bears the full burden. It implies a read-only observational tool but never says so explicitly, and gives no information about output size limits on large projects, permissions, or whether 'latest issues' is a cached or live computation. The return-content inventory is helpful but behavioral traits beyond content are largely absent.

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 returned content front-loaded ahead of the `at` modifier. It is dense but not padded; the only cost is some compressed jargon ("Time", "issues") that reads as terse rather than 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?

With no output schema and no annotations, the description does cover what the response contains, which is the key gap it had to fill. It still leaves the required `project` parameter undefined and says nothing about read-only status or output volume for large projects, so an agent could call it correctly but not 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 this well for `at`, giving accepted forms (seconds, Time like "line:4", "clip:c2.end" meaning c2's last frame) and the effect of supplying it, but `project` — the one required parameter — is never explained at all.

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 specific resource concretely — the editor window rendered as text, enumerating canvas, safe area, duration, voice lines, tracks with clips, assets and issues — which is far more informative than the bare name 'describe'. It does not differentiate from siblings such as preview, check, assets or review, which plausibly overlap with the 'assets' and 'latest issues' content it returns.

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 through the `at` conditional: omitting `at` gives the whole window, supplying it narrows to a moment. There is no statement of when to prefer this over preview, check or review, and no prerequisites or exclusions are 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?

With no annotations, the description carries the full burden, and it does disclose two high-value traits: cost ('Paid or rate-limited depending on the provider') and latency ('slow (minutes)'). It does not say what happens when `id` already exists, whether the operation is idempotent or destructive, or what form the result takes — significant gaps for an unannotated generation 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 generation action and its inputs come first, with the cost/latency caveat last; nearly every clause carries information the schema lacks. The size enumeration is long but earns its space given the 0% schema coverage, though the fragmentary phrasing ('size: an aspect ...') reads awkwardly.

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 5-parameter, unannotated, no-output-schema creation tool, the core semantics and the cost/latency warning are present, but nothing explains the `project` parameter, id-collision behavior, or where the generated asset lands. An agent could call it, but not confidently predict the side effects.

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, and it does so well for `size`: it enumerates the accepted aspect strings, gives the default and pixel dimensions, and defines the custom 'WxH' form with a 256–4096 bound. `prompt`, `id`, and `style_ref_asset` are also explained in prose, but `project` is never mentioned at all.

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 ('Generate an original image asset `id`'), and the word 'original' plus the optional style reference implicitly separates it from siblings like `edit` and `import_asset`. It never names an alternative sibling explicitly, so the differentiation is inferred rather than stated.

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

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

There is no statement of when to call `draw` versus `edit`, `animate`, or `import_asset` — the agent must guess that 'original' means new-generation rather than modification. No prerequisites (project context, asset id collisions) are mentioned, leaving selection entirely to inference.

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

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

With no annotations the description carries the full burden and does real work: it states all-or-nothing atomicity ('all apply and validate, or nothing changes'), undoability ('Every applied batch can be undone'), and non-obvious mutation semantics (add_asset replaces an existing id; update_asset deep-merges with null removing a key). It does not cover failure/error reporting or what the batch 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?

Atomicity and undo guarantees are front-loaded, followed by a compact op inventory; nearly every clause adds information. Slightly dense and run-on, but no filler 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 high-impact batch mutation tool with no annotations, no output schema, and 0% schema coverage, the description is informative on ops and transactional semantics but leaves the `project` parameter, the string form of `ops`, and the deferred `set` semantics unexplained. Adequate but with clear 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 description coverage is 0%, so the description must compensate and only partly does: it richly documents the `ops` vocabulary and even shows an inline payload shape for update_asset, but never explains the required `project` parameter, and silently ignores the fact that `ops` may be a string (a vague 'see the manual' only covers the `set` op).

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?

Opens with a specific verb and resource: 'Apply a batch of edit ops atomically', then enumerates the exact op vocabulary (add_track, update_clip, split_clip, ...). An agent immediately knows this is the mutation entry point for a project timeline, though it does not contrast itself with siblings like `check` or `preview`.

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 by the op list and the atomic/undoable framing; there is no explicit when-to-use statement or exclusion (e.g. when to call `check` first, or `preview` instead). The 'see the manual' pointer routes to a sibling but only for the `set` op, not for general 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?

With no annotations, the description carries the full burden and discloses meaningful behavior: downloads are size-capped, an existing id of the same kind is replaced, empty `kind` triggers detection, and evidence assets start with a full-picture box until edited. It does not describe return values, permissions, or error behavior for failed downloads or copies.

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 action and is dense with useful specifics. Parenthetical clauses make it slightly run-on, but every sentence adds information about supported sources, kinds, replacement, and evidence behavior.

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

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

For a 4-parameter mutation tool with no annotations and no output schema, the description covers most operational behavior well. However, it omits what the tool returns, how `project` affects the operation, and what happens on failure, 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?

Schema description coverage is 0%, so the description must compensate. It explains `source` as a local file or http(s) media URL, `kind` as image/video/audio/evidence with empty meaning auto-detect, and `id` as replaceable if the same kind exists. The required `project` parameter is never explained, leaving a meaningful gap.

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

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

The description states a specific verb and resource: copy a local file or download an http(s) media file into assets/ and register it as asset `id`. It also names the supported kinds and mentions music import. It does not explicitly contrast itself with the sibling `assets` tool, so sibling differentiation is only implicit.

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 usage context: importing local files, downloading remote media, importing music you are allowed to use, and supporting `evidence` screenshots. It does not state explicit exclusions or point to alternative tools for related operations, which keeps it 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, the description carries the burden, and it does disclose the return shape for both modes and mentions the separate @reelsmith/kit reference path — genuinely useful behavioral context. However, it never states that this is a read-only lookup, what happens if `name` does not match a known component, or whether built-in presets and user library entries are distinguishable in the output.

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 with little waste, and the listing behavior is stated first. But the structure buries the crucial `name` mode-switch mid-sentence and uses an awkward fragment ('name, source, what it is and its prop names') rather than clean parallel phrasing.

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 zero schema coverage, the description does a decent job covering what each mode returns. It falls short on the required `project` parameter, error behavior for unknown names, and any hook into the broader tool workflow, which matters for a lookup tool that feeds downstream authoring.

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 `name` well via the 'With `name`, one component in full' clause and implies listing when omitted, but the required `project` parameter is never mentioned anywhere in the description or schema, leaving half the parameters undocumented.

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

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

The description makes clear this is a component library lookup with two modes: without `name` it lists available components (name, source, description, prop names), and with `name` it returns one component in full including props schema, example props, and the source file to read as a model. The verb is left implicit and the wording is convoluted in places, but the resource and the two-mode behavior are 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 call this versus siblings like `describe` or `assets`, nor any workflow cue such as 'call this before writing a component clip' — which is clearly the intended use given the 'source file to read as a model' hint. The agent must infer the situation from the return-content description alone.

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 and no output schema, the description carries the full disclosure burden. It conveys that this is a single read-once document rather than an incremental lookup, which is useful, but says nothing about return format (markdown? plain text?), length, or whether sections can be addressed individually. For a zero-risk doc read this is acceptable, 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?

One front-loaded sentence that leads with what the resource is, then the coverage list, then the call to action — no filler. The middle enumeration ("Times", "edit ops") is a dense jargon run that costs some readability, but every clause names a real content area.

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 documentation tool with no annotations and no output schema, the description covers both what is inside the manual and when to consume it. The only real gap is the shape and size of what comes back, which matters for an agent budgeting context on a document that claims to cover every 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?

Zero parameters, so there is no parameter semantics to explain and the baseline applies. The description correctly implies the call takes no arguments by framing the manual as something you simply read.

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 reelsmith manual) and enumerates its scope concretely: editor mechanics, project format, Times, tool reference, edit ops, components, and delivery blockers. That inventory makes it distinguishable from action siblings like edit/render/check. It stops short of a crisp verb phrase (it never literally says 'returns documentation text'), but the intent 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?

'Read it once before your first edit' is an explicit timing directive that tells the agent when to call it — startup/orientation. No when-not guidance is given and no alternative is named, so an agent cannot tell from this text whether the sibling `describe` supersedes it for per-tool 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the created artifacts and that project.json starts with no tracks, plus the workspace inheritance behavior, but it does not address overwrite behavior, existing folders, permissions, errors, or return 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?

Two short sentences with zero wasted text. The core creation behavior is front-loaded, and the path/workspace-inheritance guidance follows 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 create tool with no annotations and no output schema, the description covers the core folder structure and workspace integration well. However, it is incomplete regarding parameter meanings, overwrite/existing-folder behavior, and error/return semantics.

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 three parameters. The description only implicitly identifies the required project name via <workspace>/projects/<name>; it says nothing about the title or profile parameters, leaving two of three parameters undocumented.

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

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

The description clearly states a specific verb and resource: create a project folder, and enumerates what is created inside it (project.json, assets/, voice/, script.md). It does not explicitly distinguish this from any sibling tool, though no sibling appears to be a direct 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?

It gives clear usage context by saying to place the project in <workspace>/projects/<name> to inherit the workspace's library, rules and keys. It does not provide when-not-to-use guidance or name alternatives, but the positive path guidance is concrete.

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: it discloses that this is append-only at the end of the file and that a date is added automatically, which are useful traits beyond the name. It omits whether the file/section is created if missing, whether the workspace library must exist, and what the call 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?

Three short sentences, front-loaded with the action and destination, with the alternative last. Slight redundancy in restating the file-writing fallback, but nothing 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 simple two-parameter write tool with no output schema or annotations, the description covers the action and write semantics but leaves the required 'project' argument undefined and the file-creation behavior 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 0% for two required parameters, so the description must compensate. It implies the note body ('keep it short and specific') but never explains the required 'project' parameter or how text and project 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?

States a specific verb (append), resource (a dated note), and exact destination (library/NOTES.md), plus the purpose (future work). An agent can distinguish it from file-editing siblings because the description names the alternative for restructuring.

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 the use case explicitly (a lesson, a preference, a fix for future work) and routes the agent elsewhere when the intent is headings or rewording old notes. It stops short of saying when not to record a note at all, but the alternative 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?

With no annotations, the description must carry the behavioral load; it implies a read-only retrieval of a markdown file, which is helpful. However, it does not say what happens if the file does not exist (created empty, error, or empty result), what the return format is, or how the notes relate to the required 'project' parameter.

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, front-loaded with the resource and backed by the timing cue. Minor inefficiency: the pronoun 'them' requires the reader to infer the referent is the notes.

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 read with no output schema, so the bar is low, but with zero annotation coverage the description should still state the return shape and the missing-file behavior. It covers what the notes are for but not what an agent actually receives.

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 required 'project' parameter, so the description needs to explain it and does not. Worse, the description says 'this workspace' while the schema requires a project argument, leaving the scoping semantics unresolved.

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 concrete resource (the workspace's own NOTES.md file) and its content type (what worked, what to avoid), so an agent knows what it will get back. It is clear about purpose but never distinguishes itself from the sibling 'note' tool, leaving ambiguity about which to pick.

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?

'Read them when you start' gives an explicit trigger condition, which is real usage guidance. It stops short of naming when not to use it or pointing to the sibling 'note' tool for writing, so exclusions are absent.

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 return values (PNG paths, a contact sheet, measured layout problems), a call limit ('Up to 24 per call'), and sweep behavior. Yet it does not explicitly confirm read-only safety or mention where generated PNGs are stored or whether they persist, leaving side-effect and safety context incomplete for a tool that writes files.

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 dense paragraph that front-loads the main action and key constraints. It is efficient but slightly run-on; every sentence provides value, though the parenthetical examples could be formatted more scannably.

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 complexity (3 parameters, one with a non-trivial format), no output schema, and no annotations, the description covers the essential return values and sweep behavior. It is nearly complete but omits explicit safety/read-only notes and handling for empty 'times', which would fully close the gap.

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 thoroughly explains the 'times' parameter format with examples ('seconds or Times like "line:3", "clip:c2+0.5", "end-1"') and the 'sweep' parameter's effect. The 'project' parameter is only implicitly described through context, but the complex parameter is well 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 specific verb ('Render stills') and resource ('at the given moments straight from the project'), and explicitly distinguishes itself from the sibling 'render' by clarifying 'no full render' and 'no film is made'. An agent can immediately understand this is a lightweight preview tool versus a full render.

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 clarifies that no full render occurs and contrasts with 'render' by describing the sweep mode as doing what render does before encoding but without making a film. This gives clear context for when to choose preview over render. However, it does not explicitly mention when to use this versus other siblings like 'check' or 'review', leaving some alternatives unaddressed.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it discloses the refusal condition, the text-layout measurement pass, loudness mastering, delivery checks, preservation of the previous film on failure, and a single retry for transient renderer failures. These are exactly the operational traits an agent needs before invoking a long-running mutation.

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 dense but well front-loaded: the action and output path come first, followed by preconditions, process, failure behavior, and runtime warning. Every sentence adds useful operational information without 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 long-running render tool with no annotations and no output schema, the description covers refusal behavior, write destination, failure handling, retry behavior, and runtime expectations. The main remaining gap is that the single required parameter is not given semantic explanation.

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 never explains the sole 'project' parameter. It implies the project is the film being rendered, but does not clarify accepted identifiers, format, or source. The description does not compensate for the schema's lack of parameter documentation.

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: 'Render the whole film to out/film.mp4'. It distinguishes the tool from preview by noting 'Takes minutes: preview first' and by referencing 'the same pass as preview sweep=true', so an agent can tell what this does and how it differs from the sibling preview tool.

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 usage direction: 'refuses on check errors' and 'Takes minutes: preview first', which explicitly steers the agent to preview before rendering. It stops short of naming all alternatives or stating a complete when-not-to-use policy, but the critical sequencing guidance is present.

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

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

With no annotations, the description carries the full burden, and it does disclose that the tool consumes the already-delivered film file and emits image artifacts plus a contact sheet. It omits whether files are written to disk and where, what happens if out/film.mp4 does not exist yet, and any cost or runtime characteristics.

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 no filler. It leads with the output artifacts rather than the action verb, which is slightly less front-loaded but still 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?

For a two-parameter tool with no output schema, the description conveys what the caller gets back at a conceptual level. It leaves out the dependency on a prior render and the destination of the generated frames, which an agent would need to sequence the 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?

Schema description coverage is 0%, so the description must compensate. The parenthetical '(2-24)' supplies a valid range for n that the schema lacks and implies n is a frame count; however, the required 'project' parameter is never explained in the description or the schema.

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

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

The description names the concrete artifacts produced (evenly spaced frames from out/film.mp4 plus a contact sheet) and the intent (judge the film as a phone viewer would), which is far more specific than the bare name 'review'. It does not explicitly contrast itself with siblings like preview, render, or check, 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?

'From the delivered out/film.mp4' implies this runs after a render has been completed, giving an implicit precondition. There is no explicit when-to-use/when-not-to-use statement and no routing to alternatives such as preview or check, which share overlapping territory.

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

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

With no annotations, the description carries the full burden and does well: it discloses the files written (voice.wav, voice.json with line times), the side effect of setting the project voice, caching behavior (only changed lines cost money), and the paid-operation guard that estimates first and refuses over budget. It stops short of stating what the call itself returns or how failures other than budget are surfaced.

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?

It is dense and front-loaded, leading with the verb and the payload shape before side effects and cost. The telegraphic abbreviation style ('gap_s', 'Paid:') trades a little readability for compactness but every clause carries information.

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

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

For a 3-parameter generation tool with no output schema and no annotations, the description covers inputs, side effects, artifacts, caching, and cost gating. The remaining gap is what the invocation itself returns (e.g., file handles or line times inline) versus only the on-disk artifacts.

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 and it does: 'lines' is explained as string-or-object with text/pace/emotion, pace gets accepted values plus a 0.5-2 factor range with concrete examples, emotion gets a 20-character cap and multilingual examples, and gap_s is defined as inter-line silence. This turns an opaque anyOf schema into something callable.

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 verb 'Narrate' plus the concrete output ('voice/voice.wav and voice/voice.json') makes clear this synthesizes speech for a project. It is distinguishable from siblings like animate or draw by the audio-narration focus, though it never explicitly contrasts itself with 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?

Usage is implied rather than stated: an agent can infer this is the text-to-speech step and that it 'sets the project's voice if unset'. There is no explicit when-to-use/when-not guidance or named alternative among the siblings, and the budget behavior is described as a property rather than a decision rule.

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 and does well: it discloses that it runs with the renderer's TypeScript, that only the caller's files are reported, and that out-of-scope errors are counted rather than shown. It omits whether the operation has side effects or cost/timeout characteristics, which would complete the picture for a build-like 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?

Two dense sentences with the verb and file scope front-loaded and the output behavior immediately after; every clause carries information. Slightly compressed, but 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 simple one-parameter tool with no output schema, the description explains what is returned (error list plus counts) and the scope, which is most of what matters. The unexplained 'project' argument is the remaining hole an agent needs filled 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 single required 'project' parameter has 0% schema description coverage, so the description is the only place its meaning could be conveyed — yet it never mentions 'project' at all. The agent must guess identifier format and whether it is a name, path, or ID.

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 ('type-check your own components (library/components/*.tsx)') and pins the scope to the caller's own files, which is far more informative than the bare name 'typecheck'. It does not explicitly distinguish itself from the ambiguous sibling 'check' or clarify its relationship to 'preview', so sibling differentiation is only implicit.

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?

'before a preview bundles them' gives a clear temporal context for when to call it, which is genuine usage guidance. However, there are no exclusions or named alternatives (e.g. when to use 'check' instead), so the agent must infer the boundary.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the target (`project.json`) and the mechanism (restoring a snapshot from before the specified edit batches), but does not cover permissions, reversibility of the undo, error behavior, or return 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 a single efficient sentence, with the primary action front-loaded and no unnecessary 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 undo tool with two parameters, the description explains the core state change well enough to understand the operation. However, with no annotations, no output schema, and 0% parameter description coverage, it leaves gaps around the `project` parameter and return 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 compensate. It clarifies that `steps` refers to edit batches, which adds meaning beyond the schema's integer type, but the required `project` parameter is not described or contextualized.

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 (`Undo`) and resource (`edit batches`), and specifies the effect on `project.json`. It clearly differentiates an undo operation from sibling tools such as `edit`, though it does not explicitly name an alternative tool.

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

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

Usage is implied by the name and description: use this tool to revert prior edit batches. However, there is no explicit guidance on when not to use it, prerequisites, or alternatives to consider.

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