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

With no annotations, the description carries the full burden. It discloses that a path is returned and that the image is copied into a refs folder, which is useful behavioral context. However, it omits whether the operation is idempotent, what happens on overwrite, permission needs, or file format constraints.

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 waste. The core action is front-loaded, and the follow-up step (upload path to ChatGPT) is a useful, compact addition.

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 tool with only 50% schema coverage and no annotations or output schema, the description does a decent job of conveying the core workflow but leaves gaps. It doesn't explain what 'refs folder' implies for the project or how the returned path should be used beyond uploading to ChatGPT.

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

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

Schema coverage is 50% – the 'note' and 'path' parameters are documented in the schema, and the enum for 'role' is evident, but 'project' has no description anywhere. The description adds examples of what a reference image could be but doesn't clarify parameter usage beyond what the schema already provides.

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 clear verb+resource: copying a reference image into the project's refs folder, with concrete examples (face photo, style sample). It doesn't differentiate from siblings like set_anchor or ingest, but the purpose itself 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?

The description implies when to use it (before prompting ChatGPT with a reference), but offers no explicit exclusions or comparison to alternatives like set_anchor or ingest. The final sentence hints at workflow context but stops short of clear when/when-not guidance.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose output shape (a prompt plus an ordered file list with the anchor first) and the 'verbatim' instruction, implying pure composition with no mutation. It does not state prerequisites (e.g., that a project bible or anchor must exist) or failure modes, leaving real gaps.

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

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

Two tight sentences with the core action front-loaded and the ordering constraint stated compactly. It wastes no words, though the terseness contributes to the semantic gaps 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 an 8-parameter, no-annotation, no-output-schema tool with 50% schema coverage, the description is too thin. It never defines 'bible', never maps inputs to outputs, and gives no guidance on how task/items/cols/rows interact, so an agent cannot reliably call it without resorting to the schema alone.

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

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

Schema description coverage is only 50% across 8 parameters, so the description is expected to compensate and does not. It loosely gestures at 'anchor' (use_anchor) and 'this request' but never explains the task enum, items, cols/rows, action, or notes semantics. The enum values and item-per-cell convention exist only in 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?

States a concrete verb and resource: compose the ChatGPT prompt from the bible plus this request, plus a secondary output of listing files to attach. It is distinguishable from image-processing siblings like slice_grid or build_spritesheet. However, jargon ('the bible', 'anchor', 'the request') is left undefined, which slightly clouds the purpose for an agent without prior context.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no named alternatives among the 11 siblings. An agent must infer that this is the prompt-authoring step, but nothing states its place in a workflow relative to process, ingest, or set_anchor.

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 the concrete artifacts produced (PNG, JSON atlas, GIF preview) plus engine compatibility, which is useful. However it says nothing about overwrite behavior for an existing sheet name, error conditions, or how 'stage' processed vs raw affects inputs.

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 the verb first, and every clause carries information (outputs, atlas format, engine targets, preview). The parentheticals make it dense but not wasteful.

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

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

For a 9-parameter tool with no annotations and no output schema, the description usefully explains returns but omits behavioral details like naming collisions, stage semantics, and layout defaults. It is adequate but leaves an agent guessing on several invocation decisions.

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 44% across 9 parameters, so the description should compensate and largely does not. It alludes to GIF preview (gif_scale) and uniform cells, but align, stage, columns, padding, and fps have no meaning added beyond their terse or absent schema descriptions.

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

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

The description states a specific verb and resource: packing frames into a sprite sheet with a companion PNG, JSON atlas, and GIF preview. It is clearly distinguishable from siblings like slice_grid or video_to_frames, though it does not name or contrast any sibling explicitly.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. An agent must infer from the required 'frames' array that this runs after assets exist, which is minimal implicit context.

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

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

No annotations are provided, so the description carries the full burden. It does disclose a real behavioral trait, that a browser download is 'moved out of Downloads', useful context absent from the schema, but it omits permissions, failure modes, and what happens to the stored asset on later collisions (beyond the schema's overwrite note).

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 that front-load the core action before enumerating sources. No filler, though the source list partially restates what the nested source schema already encodes.

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

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

For a 9-parameter tool with a nested source object, no annotations, no output schema, and 33% coverage, the description covers the primary flow but omits behavior for preview, tags, parent, chat_url, and what the tool returns. 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 coverage is only 33%, so the description must compensate. It clarifies the source parameter modes ('download', 'URL', 'local path') and the 'record its prompt' purpose, but leaves tags, parent, preview, project, and overwrite entirely to the schema.

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

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

States a specific verb (save) and resource (generated image or video into the project's raw/ or video/ folder) plus the secondary action of recording the prompt. It is more specific than the vague tool name 'ingest', though it does not explicitly distinguish itself from siblings like add_reference.

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 'Source:' sentence enumerates the three accepted input modes (browser download, URL, local path), which implies when the tool applies, but there is no explicit when-to-use/when-not guidance or routing versus alternatives such as add_reference.

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 write target, that processing is non-destructive/repeatable (always starts from raw), and that multi-asset calls are processed uniformly. It omits permission/auth needs, overwrite behavior, and what 'preview' actually does.

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, front-loaded with purpose and output before the batching rule and recipes. The telegraphic recipe syntax is dense but earns its place by giving copy-ready pipelines; no filler.

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

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

For a complex nested-tool with no output schema and no annotations, the description covers the write path, repeatability, batching semantics, and two canonical pipelines. It leaves gaps around the 'project' and 'preview' parameters and error/partial-failure behavior, but nothing critical to a first correct call is missing.

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

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

Top-level schema description coverage is 0%, so meaning must come from the description or nested fields. The description explains 'assets' (one or more), 'steps' (ordered), and gives two concrete recipes that map op sequences (remove_bg, trim, outline, fit 512 / remove_bg, trim group, pixelate shared), but never addresses 'project' or 'preview'.

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 ('run steps, in order, on the RAW files of one or more assets') plus the concrete output path 'processed/<name>.png'. This clearly distinguishes it from siblings like ingest, slice_grid, or build_spritesheet, which operate elsewhere in the pipeline.

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

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

Gives explicit when-to-use context ('Always starts from raw, so re-run with new settings freely') and a batching rule ('Pass every asset of a set in ONE call with the same steps'). It does not name alternative sibling tools or state when to choose them, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the full behavioral burden. It communicates one useful behavioral fact, that the bible is reused by every prompt and drives set consistency, but says nothing about mutation side effects, duplicate-name handling, permissions, or 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?

One sentence, front-loaded with the verb and resource, with no filler. The parenthetical rationale is slightly chatty for a tool description but it does add meaning rather than restate 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 mutating create tool with no annotations and no output schema, the description covers the what but not the operational context (failure modes, uniqueness constraints, follow-up calls). It is minimally adequate given the rich schema.

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

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

Schema description coverage is 100% and nested objects are documented in detail, so the schema itself does the heavy lifting for name/type/bible/pixel. The description adds only one semantic note, that the bible persists across prompts, which is marginal beyond what the schema already conveys.

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?

Clear verb (Create) plus resource (asset project), and it names the distinguishing artifact, the style bible. It does not explicitly separate itself from siblings like project_get or project_update, but the create verb makes the role obvious.

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

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

Usage is only implied: you create a project when starting a new asset set. There is no guidance on when to choose this over project_update, no prerequisites (e.g. does a project name need to be unique?), and no mention of what to do after creation.

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

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

With no annotations, the description must carry the full behavioral load. It mentions returned content (absolute file paths, sheets) but omits that this is a read-only operation, any permission requirements, side effects, or response structure beyond the listed items. This leaves significant behavioral gaps.

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

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

The description is a single phrase fragment that is short and front-loaded, with no verbose filler. However, its extreme brevity omits essential context, making it under-specified rather than optimally concise for a retrieval tool.

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

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

The tool needs to explain what 'project' is and that it performs a read. The description lists output contents but provides no input or usage context, and with no annotations or output schema, the definition is substantially incomplete.

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 only parameter, 'project', is a required string with no schema description, and the description never mentions it. It does not explain whether 'project' is an ID, name, or path, so the description fails to compensate for 0% schema coverage.

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 a noun phrase listing returned data (bible, anchor, references, assets, sheets) but never states the action (get/retrieve). The tool name 'project_get' supplies the verb, so an agent can infer it, but the description alone does not distinguish this from sibling tools like studio_info or project_update.

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

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

There is no when-to-use guidance, no mention of alternatives like project_create or project_update, and no prerequisites such as required project identifier format. The agent must infer usage solely from the name.

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

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

No annotations are provided, so the description carries the full burden. It does disclose one important behavioral trait — the style bible is 'merged field by field' rather than replaced wholesale. It says nothing about permissions, error behavior, or whether omitted fields are preserved, leaving a real gap for a mutation tool.

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

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

One sentence with no filler, and the mutable fields are front-loaded. Slightly cryptic phrasing ('merged field by field' in parentheses) but every clause carries meaning.

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?

A mutation tool with no annotations, no output schema, four parameters, one nested object, and only 25% schema coverage needs substantially more description. Merge semantics, reset behavior, and the meaning of clearing values are left 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 only 25% and nested objects are present. The description restates the top-level targets but adds no syntax, format, or constraint detail beyond the word 'locked' for palette. It does not compensate for the undocumented parameters.

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

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

States a specific verb (change/update) and enumerates the three mutable resources: style bible, pixel settings, and locked palette. An agent can distinguish this from project_get (read) and project_create, though the sibling relationship is implied by the name only.

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

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

No when-to-use condition, no prerequisites, and no named alternatives. The description never says this requires an existing project or when to prefer project_create instead, leaving the agent to infer everything from the name.

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 disclose the most important non-obvious behavior: the anchor persists and is applied to every later generation. However, it says nothing about whether setting an anchor replaces a previous one, whether it is reversible, or what permissions/limits apply, which are material for a state-changing 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?

One compact sentence that front-loads the action and then explains the downstream effect; there is no filler. It could be marginally tighter, but every clause earns its place.

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

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

There is no output schema and no annotations, so the description is the only source of behavioral context, and it covers purpose and effect well. It leaves gaps on parameter meanings (project, asset format) and on edge cases such as an already-existing anchor, which matters for a tool whose whole point is persistent state.

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

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

Schema coverage is only 33% (only 'stage' is documented). The description adds the qualifier that the asset must be 'approved', which is real semantic value for the asset parameter, but it says nothing about the asset identifier format or the 'project' parameter at all, so the low coverage is largely uncompensated.

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?

"Mark an approved asset as the anchor" gives a specific verb and resource, and the following clause explains what an anchor actually does (build_prompt attaches it to every later generation). An agent can distinguish this from siblings like add_reference or build_prompt without opening a schema.

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

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

The description establishes the precondition (asset must be approved) and the downstream consequence via build_prompt, which gives clear context for when to call it. It stops short of naming an alternative or stating when-not to use it, so it does not reach the top tier.

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 discloses the write target (frames/) but says nothing about the mutation semantics — overwrite behavior, the automatic '-2' copy fallback, preview defaults, permission needs, or whether existing assets are affected.

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

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

A single sentence with the action front-loaded and zero filler. Every clause carries information: the operation, the input kind, and the output location.

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 an 8-parameter write tool with no annotations and no output schema, the description is far too thin. It omits overwrite/naming collision behavior, the effect of preview, the rows/cols limits, and what the caller gets back.

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 38% (inset, names, overwrite are documented; rows, cols, asset, project, preview are not). Since coverage is below 50%, the description is expected to compensate, yet it adds no parameter meaning at all — no bounds on rows/cols, no naming rules, no preview explanation.

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 ('Cut') on a specific resource ('grid image'), and names the outcome ('each cell becomes its own asset in frames/'). The source qualifier '(from task grid/animation)' separates it from video_to_frames and build_spritesheet, but no sibling is named explicitly.

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 parenthetical source '(from task grid/animation)', which tells the agent what kind of asset is expected. There is no statement of when to prefer this over build_spritesheet (the inverse operation) or what must exist beforehand.

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

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

No annotations are provided, so the description carries the full burden. It implies a passive, read-only disclosure by listing only information it reports and taking no parameters, but it never explicitly confirms the tool is read-only, side-effect free, or cheap to call, and says nothing about return shape.

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, dense sentences with no filler; the report contents come first and the call-ordering directive closes it. The noun-list phrasing reads as a keyword dump rather than prose, 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?

With no output schema, the description is the only signal about what comes back, and it names the categories of information without any field names or structure. For an info tool an agent must parse programmatically, that leaves a real gap, though the category list is better than nothing.

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

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

The schema declares zero parameters at 100% coverage, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-level content is missing.

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 enumerates exactly what the tool reports: asset storage location, watched downloads folder, ffmpeg availability, and the project list. That is specific enough to distinguish it from siblings like project_get or ingest, though it never states a verb (e.g. 'returns') or names itself as the studio configuration query.

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?

'Call first.' is an explicit, actionable sequencing directive that tells the agent when to reach for this tool relative to the other eleven siblings. It stops short of naming alternatives or stating when not to call it, but the ordering rule is the key guidance for a 0-param info tool.

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

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

With no annotations, the description carries the full burden. It discloses the ffmpeg dependency, but says nothing about side effects (does it create a project asset?), how many frames are produced, how fps/max_frames affect output, or whether the operation is reversible.

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; the core action comes first and the prerequisite is parenthetical. Efficient, though the trailing clause about packing is slightly indirect.

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

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

No output schema and no annotations, so the description should explain the extraction's outputs and limits. It omits frame-count/fps behavior and result handling, leaving an agent guessing about the practical outcome of the call.

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% across 4 parameters. The description only indirectly ties 'asset' to an ingested video and ignores fps, max_frames, and project entirely, so it fails to compensate for the undocumented schema, including the non-obvious defaults (fps=8, max_frames=48).

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: extract PNG frames from an ingested video. It also hints at the downstream relationship ('packed like other frames'), which helps place it against siblings like build_spritesheet, but it never names an alternative to distinguish from.

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 'from an ingested video' plus '(needs ffmpeg)' implies a prerequisite (ingest first, ffmpeg available), which is useful context. However, there is no explicit when-to-use/when-not guidance and no routing to siblings like slice_grid or build_spritesheet.

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