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 states that source is never modified, output is written as .aseprite with one tag per animation, and sheet export is optional. It leaves some gaps around overwrite behavior and error conditions, preventing 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?

The description is long but justified by a complex animation API, and it is front-loaded with the core read/write behavior before detailing presets and tracks. The dense semicolon-separated reference lists are useful but make it harder to scan than an ideal description.

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 tool with eight parameters, nested objects, no annotations, and no output schema, the description supplies enough behavioral and structural context to call it correctly. It still omits return value details and some top-level parameter semantics, which keeps it from being fully complete.

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

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

The description compensates substantially for 50% schema coverage by explaining source, output, padding, export, saveRecipe, and especially the nested animation structure, presets, tracks, and curves. It does not explain the top-level recipe or preview parameters, so it is strong but not complete.

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

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

The opening 'Static art -> animations' states a specific transformation verb/resource, and the description immediately names source, output .aseprite, tags, and optional sheet export. It is clearly distinguishable from sibling drawing, editing, or generation tools.

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

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

The description gives clear context for use: it reads an existing source and produces animations, and it notes 'Use padding when motion leaves the canvas.' It does not explicitly name when to choose it over siblings like generate or character, but the operating context 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 does real work: it discloses atomicity ("all-or-nothing"), a single open and single save around the batch, and that per-step path/preview args are stripped. It does not say what happens on a mid-batch failure (file untouched? error shape?), whether steps execute in order, or whether read-only ops like sprite_info/read_pixels are permitted mid-batch.

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

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

Three dense fragments: the contract, the step shape, then a runnable example. Scope and atomicity are front-loaded, and the example justifies its length by showing how cross-tool args compose.

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 batch executor with no annotations and no output schema, the return value is entirely unspecified — does it return per-step results, a preview, or just success? That gap matters because the enum mixes mutations with reads (sprite_info, read_pixels, run_lua).

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

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

Schema coverage is only 33% and the steps schema is a bare enum with additionalProperties, so the description carries the semantics: step = {op, ...that tool's args minus path/preview}, illustrated with a full example. It adds little for `path` and leaves `preview` to the schema's short note, keeping it short of a 5.

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 scope: apply many steps to one sprite in a single call. The phrase "...that tool's args" explicitly ties it to the sibling tools whose operations it bundles, so an agent can tell it apart from calling draw/edit/palette individually.

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?

Implies the use case clearly (multiple steps on one sprite, one open/one save) and shows a concrete three-step example of a typical composition. It never states exclusions such as when to prefer individual tool calls, or that steps cannot span multiple sprites/files beyond the "one sprite" phrasing.

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 burden. It discloses that the character is built on its own layer in a specific pass order and that x,y anchor the feet, but it does not state whether existing layer content is overwritten, whether path refers to a project or destination file, 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?

The description is dense but front-loaded: the purpose and process come first, then the spec grammar, then color formats. The long enumerated spec and color lists are compact and earn their place, though the prose is somewhat terse and telegraphic.

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 a complex nested spec, no output schema, and no annotations, the description covers the creative payload well but omits critical operational semantics for path, layer, frame, and return behavior. It is adequate to start building a character but not complete enough to predict side effects or result 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 coverage is only 25%, so the description must compensate. It does an excellent job documenting the complex nested 'spec' object and the x/y/scale anchoring, but leaves 'path', 'layer', and 'frame' unexplained beyond minimal schema text, leaving material gaps for a low-coverage schema.

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

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

The description states a specific verb and resource ('Build a chibi character') and gives concrete scope details (~44px at scale 1, feet at x,y, on its own layer, ordered part passes). It distinguishes itself somewhat from generic draw/create tools by describing a procedural character builder, though it doesn't name a sibling alternative.

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

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

Usage is implied by the description of building a chibi character from a detailed spec, and 'Batch op: person' hints at a batch path. However, there is no explicit guidance on when to choose this tool versus create_sprite, generate, or batch, nor any 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses import-specific behavior such as auto-downscaling pixel art, pixelating when `width`/`height` are combined with `from`, and editing the imported file rather than the original. However, it omits key mutation behavior such as what `overwrite` does when the path already exists and how `palette`/`colorMode` affect the created sprite.

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

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

The description is short and front-loaded, with no wasted filler. However, the brevity comes at the cost of clarity: "New sprite file" is a fragment, and important behaviors are compressed into a dense semicolon-separated sentence.

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 mutation tool with no annotations and no output schema, the description is incomplete. It covers import-specific behavior but does not explain path semantics, overwrite behavior, palette/colorMode effects, failure cases, or what the agent should expect after creation.

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 33%, so the description needs to compensate. It explains some semantics for `from`, `width`, `height`, and auto-downscaling, but leaves `path`, `colorMode`, `overwrite`, and most of `palette` and `background` without added meaning beyond the sparse 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 first sentence, "New sprite file," only restates the tool name rather than stating a clear verb and resource. The follow-up adds that it can import an image via `from`, so the purpose is inferable, but it doesn't explicitly distinguish this from siblings like `ingest`, `generate`, or `draw`.

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 says "Or import an image with `from`," which implies one usage mode, but it gives no guidance on when to create a blank sprite versus importing versus using `ingest` or `generate`. No prerequisites, exclusions, or alternative tools are 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 are provided, so the description must carry the full behavioral burden. It says 'Draw on a layer' but does not state whether existing layer content is preserved or overwritten, what permissions/path prerequisites apply, whether the operation is reversible, or what is returned.

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

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

The purpose is front-loaded, and most of the dense syntax detail is necessary for the complex shapes DSL. However, the description is a single wall of text with poor structure, making the extensive shape mini-language harder to scan than it needs to be.

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, unannotated mutation tool with no output schema and low schema coverage, the description explains the drawing DSL well but omits core context: required path meaning, coordinate origin, color format, layer/frame behavior, and return/side effects. It is helpful but not complete enough for confident invocation.

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

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

Schema coverage is only 30%, so the description must compensate and it does so extensively for shapes, rows, pixels, legend, and offsets. It leaves path, frame, preview, and the exact coordinate/color conventions unaddressed, but the complex DSL parameters are well explained.

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: 'Draw on a layer', and names the three input modes (shapes, rows, pixels). It is clear what the tool does, but it does not differentiate itself from siblings such as edit or create_sprite.

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

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

It explains the order of shapes/rows/pixels and gives subtype-specific advice like 'Use eye for every eye so glints agree', but it gives no guidance on when to choose draw over edit, create_sprite, generate, or other sibling tools. There are no exclusions or explicit selection criteria.

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 meaningful action behavior such as 'all cels unless layer/frame' for replace, outline defaulting to darkest color, and split cutting parts onto their own layer, but it does not state that the tool mutates the file at path, whether changes are reversible, or how preview/return behavior works.

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 pipe-delimited reference is information-dense with little wasted prose, but it is an unstructured wall of text that is not front-loaded with purpose. Grouping exists for 'finishing' actions, yet overall readability is poor for a 17-action 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?

For a complex 17-action mutation tool with no annotations and no output schema, the description covers many action-specific details and defaults. It still omits top-level semantics such as what path points to, what preview does, and safety/return context, leaving important 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 60% and the action enum values have no schema descriptions, but the description supplies detailed per-action sub-parameters and defaults, e.g. fill{x,y,color,contiguous?}, mirror{mode:...}, and scatter{...}. It adds substantial meaning beyond the top-level schema, though path, preview, and top-level layer/frame semantics remain lightly 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 enumerates many pixel-editing actions such as fill, replace, mirror, outline, shade, and quantize, so the broad purpose is inferable. However, it never states a clear high-level sentence like 'edit the sprite at path' or explicitly distinguishes this tool from siblings like draw or layer.

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 provides action-specific hints, such as running simplify before adding 1px details and using split for rigging, but it gives no guidance on when to choose edit over sibling tools like draw, layer, or preview. There are no explicit when-not-to-use conditions or alternative-tool routing.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses output formats and the spritesheet condition, but omits important export behavior such as file overwrite semantics, destination requirements, permissions, and failure modes.

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

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

The description is two tightly written sentences with no wasted text. The main export formats are front-loaded, followed by the spritesheet condition and frame indexing note.

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 8 parameters, a nested `sheet` object, no annotations, and no output schema, the description is too sparse to fully prepare an agent. It covers output formats and one indexing rule but leaves most parameter semantics and file-writing behavior unexplained.

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 13% across 8 parameters. The description adds useful meaning for `sheet` and notes that frames are 1-based, but it does not clarify required `path` vs `output`, `tag`, `layer`, `scale`, or `splitLayers`, leaving most parameters under-specified.

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

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

The description states a specific verb and resource: export image formats (png/gif/sequence) or a spritesheet with JSON when `sheet` is set. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as `preview` or `batch`.

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

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

The only conditional guidance is 'when sheet is set,' which explains spritesheet mode but not when to use this tool versus alternatives like `preview` or `batch`. There is no explicit when-to-use, when-not-to-use, or prerequisite information.

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, yet it discloses no behavior beyond action signatures. It never says that 'delete' irreversibly removes frames, whether 'add' inserts relative to an existing frame, whether operations mutate the file on disk, or what the response contains. The only behavioral hint is the presence of a 'copyFrom' argument on add.

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 a single line with zero filler and the action signatures are grouped coherently with pipe separators. However, the terseness crosses into under-specification — braces, '?' markers and bare key names are unexplained notation that costs the reader more effort than the bytes it saves.

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-capable tool with no annotations, no output schema, and zero schema descriptions, the description leaves out effects, return values, and error conditions. The action-to-parameter mapping is the only thing filled in, which is not enough for an agent 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 description coverage is 0%, and even 'path' and 'action' — the two declared properties — are unexplained. The description does add real value by mapping which extra keys belong to which action (count, after, copyFrom, durationMs, frames, name/from/to/direction), but it gives no meaning, types, units, or defaults for any of them (e.g. is durationMs per frame or total?).

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 machine-style list of action signatures (add/duration/delete/tag) rather than a statement of what the tool does. There is no verb+resource phrase such as 'manage animation frames of a sprite', so the agent must infer the domain from the tool name and sibling set. It is not a tautology, but it never explicitly states the resource being manipulated.

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 guidance, no prerequisites (e.g. does the sprite/tag need to exist?), and no mention of alternatives. The sibling 'animate' plausibly overlaps with frame manipulation and the description does nothing to disambiguate.

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 the required env token, that prompts run in parallel (cost/time implication), that raw outputs are retained in outDir so re-ingest avoids paying again, that image is upscaled onto a solid background before sending, and that imageField is auto-detected. It does not cover failure modes, rate limits, or what happens on partial batch failure.

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

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

Front-loaded with the core action and credential requirement, then parameter-specific notes in short clauses. Dense but telegraphic fragments ('Videos need ffmpeg. Ideas: ...') cost some readability, though almost 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 9-param, nested-object tool with no output schema and no annotations, the description covers the external dependency, cost model, output retention, the ingest handoff, and model selection. An agent has enough to invoke it correctly on the first attempt.

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 44% across 9 params, so the description must compensate, and it largely does: describe, image, prompts, outDir, imageField (auto-detected field), input (model inputs) and ingest are all explained, including the nested image rendering behavior. Only preview is left unexplained, keeping it below 5.

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: generate frames with any Replicate model, then clean them into pixel art via ingest. It names a sibling (ingest) as the downstream step and implicitly separates itself from create_sprite/draw by being model-driven. The generic name 'generate' is only disambiguated by the description body, not the first clause.

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 concrete operational guidance: set REPLICATE_API_TOKEN, use describe=true to list a model's inputs first, one prediction per prompt for per-pose batches, and ffmpeg for video. It offers example model IDs matched to use cases (pixel animation vs pose edit). No explicit when-not-to-use or comparison against create_sprite/animate, so it falls short of 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 full burden and does disclose key traits: the run appends to path if it already exists (an additive write, one tag per call), background removal is applied, and video input requires ffmpeg. What it omits is return behavior (no output schema exists) and any failure/overwrite semantics when path conditions differ.

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

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

The purpose is front-loaded in the first clause and the pipe-delimited shorthand for source/size/align variants is an efficient compression of what would otherwise be verbose prose. The telegraphic style ('| sheet{path,cols,rows,count?}') is borderline cryptic and slightly hurts first-pass comprehension, 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 16-parameter tool with nested objects, no annotations and no output schema, the description covers sources, sizing, alignment, and append behavior, but it never states what the call returns (a tag, a path, a preview?) and leaves layer, durationMs, and preview undocumented. An agent could likely invoke it, but not predict its result 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?

At 31% schema coverage across 16 parameters, compensation is required and the description largely delivers: it gives the shape of the three source variants (frames | sheet{path,cols,rows,count?} | video{path,fps?,start?,duration?}), explains the three sizing strategies (height | scale | reference sprite, with how reference matches height/palette/canvas/feet), and defines each align enum value. Remaining gaps (layer, tag beyond 'one per call', durationMs, preview) keep it off a 5.

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: turning frames from images/video/sheets into a cleaned pixel-art animation, enumerating the pipeline steps (background removal, palette pull, grid snap, speck drop, alignment, tagging). This clearly separates it from siblings like create_sprite, generate, and animate, which start from other inputs. It stops short of 5 because the name 'ingest' itself carries no meaning and the sentence is dense enough to require a second read.

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?

Source options (frames vs sheet vs video) and the ffmpeg requirement imply when the tool applies, but there is no explicit 'use this instead of X' routing against siblings such as create_sprite, generate, or frames. The align modes are named but the conditions under which an agent should prefer one are only suggestively described ('keeps source motion; video').

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 discloses almost nothing: delete, clear, and merge_down are plainly destructive operations yet irreversibility, undo availability, and effect on existing layer content are unstated. Names imply mutation but no behavioral context is added.

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 extremely short with no filler, which is good, but the signature-style notation is under-specified rather than concise — a reader must already know the semantics to parse it. Front-loading is fine but readability suffers.

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 five-action mutation tool with no annotations, no output schema, and low schema coverage gets only a one-line signature string. Nothing covers return values, error behavior for a missing layer, or how path scopes the operation, so an agent cannot reliably call it.

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 25%, so the description must compensate, and it does partially by mapping per-action parameters (name/group?/parent?/below?/opacity? for add, rename?/visible?/opacity? for update, frame? for clear). However the required 'path' parameter is never explained, and the meaning of 'below' or 'frame' stays undefined.

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 notation lists specific verbs (add, update, delete, clear, merge_down) against the layer resource, so the domain is inferable. But it never plainly states that this tool manages layers within a sprite, and 'clear{layer,frame?}' or 'below?' are cryptic without prose. It distinguishes itself from draw/edit/frames only by the resource name.

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

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

No guidance on when to choose add vs update vs merge_down, no prerequisites, and no mention of alternatives among the many siblings (draw, edit, frames). The action list implies the options exist but says nothing about selecting between them.

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 does disclose the one mutating path (set=true writes colors, extracted, and ramps into the sprite palette), which is the key risk signal. It stops short of saying whether the existing palette is replaced or merged, and gives no information about side effects or 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?

Mode information is front-loaded and each clause carries a distinct fact, with no filler. The pseudo-BNF shorthand (extract{max}, ramps:[{...}]) is dense to the point of being cryptic, which costs a point on clarity but not on efficiency.

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 five-parameter, nested-object tool with no annotations, no output schema, and low schema description coverage, so the description has to do a lot. It covers most modes but leaves extract.frame undocumented, does not explain what a non-set call returns, and does not clarify combination semantics when multiple mode parameters are passed together.

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 20%, so the description must compensate, and it largely does: it documents ramps defaults (steps=5, hueShift=20, contrast=1), the meaning of extract.max, the colors preset/hex form, and the set flag. It omits the nested extract.frame parameter and does not describe the top-level path or how path relates to extract for non-sprite images.

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

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

Names a specific resource (palettes) and enumerates the concrete modes: read current, extract dominant colors, generate ramps, and set. It is telegraphic rather than prose, but an agent can determine what the tool does and that it is not a sibling tool like draw 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?

'No args: current palette' establishes the default call, and 'set=true writes colors+extracted+ramps' implies the modes can be combined. However, there is no explicit statement about when to use extract versus colors versus ramps, whether the modes conflict, or when to pick this over a 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?

No annotations are supplied, so the description carries the full burden. It discloses rendering behavior (zoom, checkerboard transparency, pixel grid, default scale fitting maxSize) but never states the return form (presumably an image), whether the tool is read-only, or what happens with invalid paths, leaving real gaps for an 11-parameter 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?

It is short and front-loads the core behavior, but the telegraphic fragment style ("frames="all" contact sheet; tags=true one row per animation") compresses to the point of ambiguity and forces re-reading.

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 11 parameters, no annotations, no output schema, and 27% schema coverage, the description should carry more. It omits the return type entirely and says nothing about five parameters, leaving too much for the agent to infer before calling.

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 27%, and the description adds meaning for about five of eleven parameters (frames, tags, tag, reference, referenceRect). It leaves path, grid, frame, layer, and scale unexplained beyond the bare schema types, so it compensates only partially 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?

"See the sprite: zoomed, checkerboard transparency, pixel grid" names a concrete resource and the rendering features, so an agent knows this produces a visual preview rather than data. It never differentiates itself from siblings like read_pixels, export, or sprite_info, which prevents a 5.

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

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

The description covers option-level usage (frames="all" for a contact sheet, tags=true for one row per animation, tag=name) and a specific workflow for reference images ("check every pass against it"), but says nothing about when to call preview instead of read_pixels, sprite_info, or export.

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 does disclose meaningful behavior — output is a character grid with a legend, transparency renders as '.', output is flattened unless a layer is named, and a region can be cropped. It says nothing about failure modes, permissions, or how large a grid can get, which matters for a pixel dump.

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 short and front-loads the return format, but the phrasing is telegraphic fragments ('Flattened unless layer. Optional region.') that force the reader to reconstruct the meaning. Nothing is wasted, yet the compression costs parseability.

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 7-parameter tool with no annotations, no output schema, and only 29% schema coverage, the description is too thin: path and frame are unexplained and the region parameters are only hinted at. It covers the return shape but not enough of the call contract.

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 29%, so the description must compensate; it does explain layer (default flattening) and gestures at x/y/width/height via 'region'. Path, frame, and the exact region semantics remain undocumented in both the schema and the description, so the compensation is partial.

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

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

States a concrete verb+resource: it reads pixels and returns them as a char grid plus legend, and it specifies the encoding (draw rows format, '.'=transparent). It does not distinguish itself from adjacent siblings like preview or export, which likely also produce a view of the sprite, so an agent can't fully rule out alternatives from the description alone.

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?

'Flattened unless layer' and 'Optional region' implicitly tell the agent when to pass layer or a region, but there is no explicit when-to-use/when-not framing and no named alternative (preview, export) is offered. Usage must be inferred.

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 nearest-neighbor resampling for scale mode and anchor options for canvas mode, but it omits whether the operation mutates or overwrites a file, permission needs, and any return behavior.

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

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

The description is extremely compact and packs useful syntax into one line, but the pseudo-BNF format is cryptic and lacks a plain-language lead. It is concise but not well structured for quick agent comprehension.

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 no annotations, no output schema, and 0% schema description coverage, the description should explain path semantics and mutation behavior. It only partially covers mode-specific parameters and leaves essential context missing for safe invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the mode enum and mode-specific options (factor, width/height, anchor), which is valuable, but it never explains the required 'path' parameter or its relation to input/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 tool name 'resize' plus the scale/canvas syntax implies an image/canvas resize operation, but the description never states a clear verb and resource. It does not differentiate from sibling tools or explicitly identify what is being resized (sprite, canvas, file).

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

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

The description lists mode-specific options but gives no guidance on when to choose 'scale' versus 'canvas'. There are no prerequisites, exclusions, or alternatives mentioned.

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?

Without annotations, the description carries the full burden. It discloses important behaviors like the default saving side effect ('Saves unless save=false'), the return value, and available globals, but omits critical context for a code-execution tool: sandboxing, permissions, error handling, and timeouts.

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 purpose and then adds only useful details. Every sentence—covering API version, globals, return value, and save behavior—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 code-execution tool with four parameters, a nested object, no output schema, and no annotations, the description covers the basics (what it runs, what globals are available, what it returns, and the save default) but leaves significant gaps around error behavior, execution environment, and parameter details.

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 partially does by mapping the path parameter to the sprite global and the params parameter to the params global, and by explaining the save flag's effect. However, it does not clarify the format of path or the allowed contents of the params object, leaving gaps for a 4-parameter tool with a nested object.

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 Aseprite Lua (API 1.3)'. The purpose is clear, but it does not differentiate itself from sibling tools like generate or batch, leaving the agent to infer that this is a generic escape hatch.

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

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

Provides no guidance on when to use this tool versus the many domain-specific siblings. It does not say whether this is for custom operations not covered elsewhere, nor does it mention any prerequisites or exclusions.

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 returned fields and the effect of palette=true, but omits whether the tool is read-only, requires an existing file, or can fail.

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-loads the returned fields. It is terse but not padded, though the fragmentary structure leaves it slightly under-specified.

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 info tool with no output schema, it lists the main return fields and explains the palette flag. However, it leaves the required path parameter and usage context 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 coverage is 0%, so the description must compensate. It explains palette=true adds palette colors, but does not describe the required path parameter or what path refers to.

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

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

The description specifies the sprite metadata returned: size, mode, layers, frame durations, and tags, with an optional palette addition. This makes the tool’s purpose clear, though it does not explicitly differentiate it from siblings like palette or read_pixels.

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

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

There is no guidance on when to use this tool versus alternatives such as palette or read_pixels. The only usage-like detail is the local effect of palette=true, not tool selection guidance.

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