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

Annotations only say readOnlyHint=false; the description goes well beyond that by disclosing exactly what gets written where, including that a video is decomposed into a frames directory plus a separate audio.wav. It does not cover overwrite behavior, supported formats/size limits, or failure modes, which keeps it below a 5.

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 core action, followed by a compact per-type breakdown. Every clause carries information; 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?

For a three-parameter mutation tool with no output schema, the description covers side effects and follow-up workflow thoroughly. What is missing is modest but real: return value/confirmation behavior and any constraints on acceptable file types.

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%, so the schema already documents file and name. The description adds real meaning for name by showing it becomes the footage/<name>/ directory, but the project parameter is never explained and no format or validation details are added.

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: 'Bring the user's own file into a project,' then itemizes the outcome per media type (assets/ for images and audio, footage/<name>/ plus audio.wav for video). It is clearly distinguishable from write_file/read_file siblings, though it never names those siblings to sharpen the boundary.

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 user's own file' (as opposed to generated content), and it supplies useful downstream guidance on drawing frames via shared/footage.js and wiring sound through sound.json. However, there is no explicit when-not-to-use guidance and no named alternative such as write_file for text content.

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 only readOnlyHint=false supplied, the description carries most of the burden and delivers: it discloses the written artifact, that the mixer consumes the timing/mouth-envelope data, and critically that it 'Replaces any earlier narration' — a destructive side effect an agent must know before calling. It omits failure behavior when no provider/file is available.

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 tight sentences, all front-loaded: purpose first, then the file-vs-text rule, then the output, then the replacement warning. Some domain shorthand ('vo/timing.js', 'mouth envelope') is opaque but necessary for correctness rather than 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 mutation tool with no output schema and only a single annotation, this covers the essentials: what gets written, what gets thrown away, and what inputs are required versus optional. The remaining gaps (behavior on invalid `project`, error mode when neither file nor provider is available) are real but secondary.

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 33%, so the description must compensate, and it partly does: it explains that `file` may be a recording or output from any TTS tool, and that `text`-only lines fall back to the server's env provider. It says nothing about `project` (the other undocumented required parameter) or how `gap` interacts with lines that have `at`.

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 ('Add narration') and immediately scopes it away from visual media by defining what a line is (a `file` or `text`). It also names the artifact produced ('vo/timing.js') and the downstream step ('the mixer places the clips'), which separates it from siblings like add_media. It stops short of explicitly naming the sibling to use for non-narration audio.

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?

Offers real precondition context: no voice ships with the server, and 'Current provider: none', which tells the agent that text-only lines cannot work here and files must be supplied. However, it never states when to choose this over a sibling or what to do when no provider is configured — the agent must infer that external TTS audio is the only viable path.

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=true, so the safety profile is covered and the description's job is to add context — which it does by explaining why a finished-file check differs from a still. It does not disclose cost or latency (frame extraction is likely expensive), behavior when the file is absent, or the shape of the returned metrics. Adequate but with clear gaps beyond the annotation.

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 return payload before the rationale and the parameter tip. Nothing is redundant. The phrase 'For counters pass adjacent times' is compressed to the point of needing domain knowledge to parse.

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

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

With no output schema, the description's enumeration of size/length/loudness/frames is doing useful work in place of one. But for a read-only inspection tool with an undocumented required `project` parameter and four distinct returned metric families, an agent still lacks the return format and how to target the right project.

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 parameter meaning: it adds genuinely useful guidance for `times` ('For counters pass adjacent times') that the schema does not convey. However, the required `project` parameter is never mentioned, the `file` default of final.mp4 is unaddressed, and the 8-item cap on `times` is left unexplained.

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 outputs (size, length, loudness, frames) of inspecting a finished video file, which tells an agent exactly what the tool returns. It implicitly separates itself from the `stills` and `render` siblings by explaining that a render differs from a still. The verb itself is elided in the opening noun phrase, leaving the action slightly 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 a real when-to-use rule: verify the actual rendered file rather than trusting a still, because stills skip motion blur, which effectively routes the agent away from `stills`/`preview`. It also supplies a conditional instruction for sampling ('For counters pass adjacent times'). It stops short of stating exclusions for `render_status` or what to do before a render completes.

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 readOnlyHint annotation already establishes this is a non-mutating check, so the description's main additional value is naming the three subsystems probed. It does not say whether the tool is fast or slow, whether it invokes the browser, or what happens when a component is missing — and with no output schema, the result shape is entirely undisclosed.

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, and the enumeration of checked components is efficient. It is arguably too terse rather than padded, and 'the voice setup' is vague compared to the concrete 'ffmpeg' and 'a browser'.

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 beyond readOnlyHint, the description carries the burden of explaining what a caller gets back, and it does not — an agent cannot tell whether results are per-component booleans, log text, or error codes. For a simple diagnostic tool the description is minimally viable but leaves the return contract and failure behavior unspecified.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The empty schema is consistent with the description's framing of a parameterless environment probe.

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

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

The description gives a specific verb ('Check') and enumerates exactly what is being probed: ffmpeg, a browser, and the voice setup. It is distinguishable from render/render_status/check_video as an environment diagnostic rather than a media operation, though the phrase 'can render' is slightly ambiguous about whether it verifies capability or performs a test 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?

Usage is only implied — an agent can infer this is a pre-flight check to run before rendering. There is no explicit when-to-use statement, no mention of ordering relative to setup tools like add_voice or add_media, and no disambiguation from check_video or render_status.

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 readOnlyHint annotation already establishes this is a safe, non-mutating lookup, so the description's added value is its sketch of what comes back: the rules, keep/swap guidance, and a target frame. That is genuinely beyond the annotations, but it is described obliquely and omits behavior for an unknown style name or how the frame/spec is structured.

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 capability statement first and the usage cue last; nothing is redundant. It loses a point because the compressed, metaphor-heavy wording ('One look in full', 'keep and swap') costs clarity without saving many tokens.

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 definition should sketch the response shape. It gestures at the content (rules, substitution guidance, target frame) but never says how that is structured, and it omits failure behavior, leaving the agent partially informed.

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 parameter is already documented as 'Name, alias or menu number'. The description merely restates 'Takes a name, alias or menu number', adding no new semantic detail such as format expectations or case sensitivity. Baseline 3 applies when the schema carries the parameter burden.

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 retrieval of a style's full definition, but does so in stylized phrasing ('One look in full', 'what to keep and swap', 'target frame') rather than a plain verb+resource statement. An agent can guess it fetches style rules and a frame spec, but the vocabulary is idiosyncratic and it never explicitly contrasts itself with the sibling list_styles.

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 one real usage condition: 'Read this before editing a page.' That is useful routing toward a pre-edit read. However, it says nothing about using list_styles to discover valid names/aliases/menu numbers, nor when this tool should be skipped in favor of another sibling.

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?

readOnlyHint=true already establishes this is a safe read, so the description's job is to add context — and it does, disclosing the return shape (numbered, grouped by purpose, includes a picture sheet). That is genuinely useful given there is no output schema. It does not mention size limits or whether styles can be filtered, but for a simple enumerator that is a minor gap.

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

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

Two sentences, no waste, and the behavioural intent ('show this when...') is front-loaded right after the content summary. 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?

For a zero-required-parameter read tool with no output schema, the description supplies the essential missing piece — what the result looks like. It could add pagination or scale hints if the style catalogue is large, but nothing needed to call it correctly is absent.

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

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

With a single parameter at 100% schema description coverage, the baseline is 3. The phrase 'with a picture sheet' echoes the picture parameter's effect but does not explain that it is an optional toggle (default true) or why an agent might turn it off.

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 precisely — 'every look' — and characterises the output as a 'numbered menu ... grouped by purpose, with a picture sheet'. That distinguishes it from the singular sibling get_style without needing to name it. The verb is implied by 'menu' rather than stated, so it falls just short of a perfect verb+resource framing.

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 an explicit trigger: 'Show this when the user has not picked a look or asks what is available.' That covers the common ambiguous case well. It does not explicitly say to use get_style instead once a look is chosen, so the routing to the alternative 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?

The readOnlyHint=false annotation already flags this as a mutating operation, and the description adds genuinely useful context beyond that: it returns the folder path and tells the agent to edit page.html while preserving the look. It does not disclose whether an existing folder is overwritten, whether the operation is reversible, or that brand data is written to brand.js (only the schema says that).

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

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

Two tight sentences with zero filler; the core action is front-loaded and the follow-up instruction follows immediately. Nothing could be removed without losing information.

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

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

For a 3-parameter tool with a nested brand object and no output schema, the description covers the essentials: it creates the scaffold and it returns the folder, so return-value burden is partly carried. The remaining gap is the absence of any mention of the optional brand subtree or overwrite behavior, but the schema handles the former.

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 schema already documents `style` (name, alias or menu number) and `project` (folder name under /root/anim-styles-projects or absolute path) plus the promo-only `brand` object. The description adds no additional meaning about any parameter, 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?

States a specific verb and resource: 'Start a project from a look's working starter page', which tells an agent this scaffolds a new project rather than listing styles or rendering. It is implicitly distinguishable from all siblings, but it never names a sibling or the style-selection tools an agent would use to supply the `style` argument.

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 'Start a project' - this is the entry point of the workflow - and the follow-up instruction ('edit page.html there') gives the next step. However, there is no explicit when-to-use, no prerequisites (e.g., resolve the look via get_style/list_styles first), and no statement about what happens if the project folder already exists.

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=true, so safety is covered. The description adds one genuinely useful behavioral note beyond that: the returned URL only works while the server is running, which tells an agent the result is ephemeral. It does not say whether the preview must be started, what it shows, or whether multiple previews can coexist.

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 no filler, and the core information (local URL, browser, server lifetime) is front-loaded. It is efficient, though brevity here comes at the cost of specification rather than being purely a virtue.

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 one required undocumented parameter, no output schema, and a preview-oriented purpose, the description should say what the URL points at and how long it remains valid in concrete terms. It covers the lifetime caveat, which is the most important thing, but leaves the parameter and the invocation flow 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 required 'project' parameter, so the description carries the full burden and explains nothing about it — no format, no identifier source, no example. "The page" hints at a project but never links it to the required argument.

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 is phrased as a noun ("A local URL that plays the page live in a browser") rather than stating an action, so it describes the output more than the operation. It does convey the resource domain (a live browser preview) but gives no verb and does not distinguish it from siblings such as render, stills, or render_status.

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 render, stills, or render_status, and no prerequisites or exclusions. The only conditional information is an environmental one (the URL lives as long as the server runs), not a usage 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?

readOnlyHint=true already tells the agent this is a safe read, and the description adds that only text files are handled and that reads are scoped to a project. It says nothing about behavior on a missing path, encoding, size limits, or what the response contains, so added value is modest.

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

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

A single tight sentence with the core action front-loaded. The trailing qualifier about clients is long-winded but does earn its place as usage 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?

With no output schema, no parameter descriptions, and only a readOnlyHint annotation, the definition should explain the return value (file contents as text) and failure behavior. Neither appears, leaving meaningful gaps for a two-parameter tool an agent will call blind.

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 load, and it only loosely implies that a path is relative to the given project. It never mentions the path default of "page.html", the required project parameter, or expected path format.

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 a text file") plus a scope ("from a project"), which is clearly distinct from sibling write_file. It doesn't name siblings explicitly, but the read/write split 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?

"for clients with no file tools of their own" gives a real condition for when this tool applies rather than native file access. No when-not guidance or alternative named among the other siblings, but the context is clear enough to select it.

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 declare readOnlyHint=false; the description adds genuinely useful behaviour beyond that by disclosing the synchronous/async split and the ~40 s threshold, which determines the return shape. It still omits what happens on failure, whether an existing output file is overwritten, and any cost or resource expectations for a long-running encode.

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, front-loaded with the action and followed immediately by the return semantics. Every clause carries information an agent needs, and nothing is padded.

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 cover the key return-shape ambiguity (video vs job id), which is the most important gap for this tool. However, for a mutating render job with four parameters at half coverage, it leaves out where the artifact lands, what a job id is used for, and what failure 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 description coverage is 50%: 'out' and 'sub' are documented, while 'project' and 'fps' are bare. The description adds nothing about any parameter, not even the default output file or the fps range, so the undocumented half stays unexplained in both places. 'Motion blur' only loosely gestures at 'sub', which the schema already handles better.

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

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

The description gives a specific verb and resource: 'Render the page to video with motion blur and mix the sound.' That distinguishes it from preview, stills and check_video, which are read/inspect counterparts. It does not name a sibling explicitly, so it stops just short of the top mark.

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

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

There is no explicit statement of when to choose render over preview or stills. The async note ('or a job id if it takes longer than about 40 s') implies that render_status should be polled afterwards, but that tool is never named. 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 readOnlyHint=true annotation already tells the agent this is a non-mutating call, so the description would need to add blocking semantics to earn credit. "Wait on" hints at long-poll behaviour, but the description says nothing about timeouts, whether the call blocks until completion or returns progress, what happens on job failure, or whether a job id must come from a prior `render` call.

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 short sentence with the action front-loaded and no filler. Its brevity is efficient, though it edges toward under-specification rather than tight precision.

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 should explain what "report" yields (status, progress, artifact paths, failure modes). For a blocking wait tool this omission leaves the agent unable to predict call duration or 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 0% and the single `job` parameter is documented only as `{"type": "string"}`. The description implies `job` refers to a render job, but does not state whether it is an id, a handle, a path, or where the agent obtains it, so it fails to compensate for the coverage gap.

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

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

"Wait on a render job and report it" names a verb (wait on) and a resource (render job), so the basic action is inferable. However, "report it" is vague about what is returned, and the description never distinguishes this from the sibling `render` or `check_video` tools that an agent could easily confuse it with.

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

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

There is no guidance on when to call this versus `render` (which presumably starts the job) or `check_video`. The word "wait" hints that this is the blocking/polling companion to a render call, but the agent must infer that relationship entirely on its own.

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

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

The readOnlyHint=false annotation already signals a non-read-only operation. The description adds that it renders frames into a single sheet for iterative visual QA, but it does not disclose side effects such as whether files are written, where the sheet is stored, or what project state changes occur.

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 core action and followed by actionable usage guidance. The rhetorical questions are slightly informal but still purposeful and do not waste space.

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

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

For a simple two-parameter tool with no output schema, the description conveys the output shape ('one sheet') and iterative QA context. However, it omits parameter meaning and side-effect details that an agent would need to invoke 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 coverage is only 50%, with the required 'project' parameter undocumented in both schema and description. The description adds no meaning about what 'project' identifies or how 'times' maps to rendered frames, leaving parameter semantics under-specified.

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

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

The description states a specific verb and resource: 'Render frames and return them as one sheet.' The 'one sheet' output form helps distinguish it from the generic render sibling, though it does not explicitly name alternatives such as preview or 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 gives a clear triggering condition ('after every change') and concrete evaluation criteria ('compare with the target frame', phone readability). It stops short of explicit exclusions or naming when to use preview, render, or check_video instead.

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 declare readOnlyHint=false, which is consistent with "Write." The description usefully adds the sandbox constraint that writes cannot escape the project folder, but it omits key mutation behavior: whether an existing file at the same path is overwritten, whether parent directories are created, and what encoding is used.

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

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

Two short sentences with the verb front-loaded and zero filler. The scope constraint follows immediately and nothing is repeated from the 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?

For a write tool with no output schema, zero schema descriptions, and only a readOnlyHint annotation, the description leaves important gaps: overwrite semantics, return value, and path rules. The one genuinely helpful addition is the project-folder containment rule, but that alone is not enough.

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 all three parameters, so the description must carry the load and mostly does not. It never mentions the "path" parameter (which has a default of page.html and unclear subdirectory rules), nor clarifies that "project" selects the target container and "content" is the literal text written.

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

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

The description names a specific verb and resource ("Write a text file") plus its container ("inside a project"), so an agent immediately knows the operation. It does not name or distinguish read_file, the obvious sibling, but the write-vs-read distinction is clear from the verb.

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?

"for clients with no file tools of their own" gives a conditional usage cue, and "Cannot write outside the project folder" bounds the operation. However, there is no explicit routing against siblings like read_file, add_media, or new_project, and no guidance on when writing is inappropriate.

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