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

Annotations already flag destructiveHint=true and readOnlyHint=false; the description builds on that by explaining the state effects of 'move' and 'link' and clarifying that 'set' modifies position/opacity. No contradiction with the annotations; the added semantics go beyond the structured hints.

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: the definition and op list come first, then focused detail on the non-obvious move and link operations. No filler, no repetition of schema content.

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-op, 12-parameter tool, the description covers the core concept and the most confusing workflows, while an output schema exists so return values need no explanation. Minor ambiguity remains around 'clear' vs 'delete' and 'copy', but the essential guidance is present.

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 approximately 50%, so the description is expected to help clarify undocumented parameters. It adds op-level context (position/opacity for 'set', frames for 'link', between-frames movement for 'move'), but leaves dx/dy, toFrame/toLayer, and the parameter implications of 'clear'/'delete'/'copy' implied rather than stated. Adequate, not thorough.

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 a defined resource ('Manage cels — one layer's image on one frame') and enumerates the full operation set. The definition clearly distinguishes cels from sibling tools like layer or frame, and the move/ink examples clarify what the resource represents.

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 concrete when-to-use guidance for the two least obvious operations: 'move' for shifting a limb between frames without redrawing, and 'link' for sharing an image across frames to keep a static part in sync. It doesn't name excluded sibling tools explicitly, but the scenarios give an agent enough context to select the right cel operation.

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 description discloses behavior beyond the annotations: operations are applied as a single undoable action, paletteLock snaps colors perceptually before writes, ops run in array order, and the tool cannot silently widen the palette. This gives an agent a clear model of side effects and sequencing, especially useful since the annotations are all false and uninformative.

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 focused sentences: first states what it does, second gives the critical batching/undo guidance, third covers ordering and palette safety. Every sentence earns its place with 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 tool with 11 op types and 8 parameters, the description covers the essential behavioral model: batching, undo, paletteLock, and execution order. The rich input schema and output schema cover parameter details and return values, so the remaining gaps (e.g., selection-only clipping, createCel behavior) are adequately handled by schema descriptions rather than requiring narrative.

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 baseline applies. The description reinforces paletteLock semantics and op ordering, but these are also present in the schema ('Applied in order, in one transaction', 'Snap every colour to the nearest palette entry'). It adds little genuinely new meaning beyond the structured 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 and resource: 'Apply a batch of drawing operations to one cel'. The list of supported ops (pixels, line, rect, fill, etc.) makes the tool's scope unmistakable and clearly distinguishes it from sibling tools like frame, layer, or transform.

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 clear usage direction: batch aggressively, treat one whole sprite as a normal call, and rely on the single-undo behavior. It also explains when paletteLock should be kept at its default. It does not explicitly name alternative tools for non-drawing actions, but the operational guidance for how to use the tool is strong.

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 mark destructive/read/write, so description doesn't need to repeat safety; it adds the critical side-effect boundary: exporting writes files but does not save the working document, and aseprite saves a copy. It also reveals atlas output content (per-frame and per-tag data), which annotations do not convey.

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 filler; first sentence carries the core action and op menu, second covers the key layout guidance and the save distinction. Front-loaded and every phrase 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?

Given 12 parameters and a schema with 92% coverage plus an output schema, the description need only supply orientation and decision criteria, which it does. The only omitted details (paraminterplay around layers/tags/trim) are already in the property descriptions.

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 92% schema description coverage, baseline iss met; description adds a layer beyond schema by explaining what each op produces and directing the agent to sheetType and byTag for layout control. This helps select among enum values without reopening 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?

Description opens with a specific verb+resource ('Write game-ready files') and enumerates each op with its output type, distinguishing export from document-saving. It also identifies spritesheet as the engine-consumable format, making the tool's purpose concrete.

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?

States a clear use case for spritesheet ('what an engine actually consumes') and explicitly names the alternative for a different need ('use sprite_manage op save for that'). The when-not boundary (exporting does not save) is explicit, so an agent can route correctly.

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 indicate destructive behavior, and the description adds useful context about durations being milliseconds and about using count for bulk addition. However, it does not disclose side effects such as index shifting after deletion or reorder behavior, relying partially on the destructive hint.

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

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

The description is compact and front-loaded with the main purpose. The extra guidance on durations and count is useful and earns its place, though the contact-pose analogy is slightly stylistic rather than essential.

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 multi-operation tool with nine parameters, the description gives useful tips but does not map operations to their relevant parameters. An agent may still need to infer which parameters apply to each op, though the schema and output schema help fill some 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?

With 67% schema coverage, the description adds meaning for count and durations, which are otherwise under-documented. It does not fully compensate for all undocumented parameters like durationMs, but it provides valuable context for the most nuanced timing-related 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?

The description clearly identifies the tool as managing animation frames and lists the supported operations. It is specific enough to distinguish from siblings like layer or cel, but it does not explicitly differentiate itself from those sibling 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 implies usage for frame-related operations and offers practical tips for count and durations. However, it does not explicitly state when to prefer this tool over siblings, nor does it provide exclusions or conditions for when not to use 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 already supply destructiveHint=true, so the description does not need to restate destructiveness. It adds valuable context that batch is undoable and that layer management must happen before animation frames, but it does not disclose what delete/merge actually destroy or how irreversible operations behave outside batch. No contradiction with annotations.

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

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

Three dense sentences: an operation list, a batch directive, and an animation best-practice warning. Each sentence earns its place and the most actionable guidance is front-loaded. The operation enumeration is long but necessary for a multi-op 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 an 11-op, 12-param tool with zero required parameters, this description is incomplete. It never states which parameters each operation needs, how a target layer is identified for rename/delete/set/activate, or how reorder/group/merge combine with index, names, and parent. An agent would still have to guess the op-parameter contract, so the tool is not fully callable from this description 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?

The description adds meaning to the batch parameter and clarifies 'set' as visibility/opacity/blend/lock, plus gives a concrete layer-naming pattern. However, with schema description coverage at 50%, it fails to map operations to parameters such as name vs newName, index for reorder, or names for merge/group. The schema partially compensates, but the description does not close the gap.

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

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

The first sentence clearly identifies the resource ('Manage layers') and the explicit operation list ('list', 'create', 'rename', 'delete', etc.) gives a concrete boundary. It does not explicitly contrast with sibling tools such as frame or cel, so it misses the top score, but the purpose is unmistakable.

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 strong usage context: use batch to run several operations in one undoable action, building a rig in one call is normal, and layer parts should exist before frames to avoid costly pixel splitting. It does not list exclusions or when to prefer sibling tools, but the practical guidance 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?

The description discloses substantial behavioral details absent from the annotations: preview is a nearest-neighbour upscaled PNG around 1024px, ascii is capped at 64×64 and includes a colour legend and rulers, filmstrip composites every frame because vision models only read the first frame of a GIF, and diff uses specific glyphs for unchanged/erased/changed pixels. These details go far beyond the readOnlyHint and openWorldHint annotations and help the agent predict exact tool 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 long but tightly organized as a bullet list where each operation is a single line with purpose and output. The opening one-liner sets scope, the ops cover the full tool vocabulary, and the closing workflow sentence ('Draw, then look, then fix') earns its place by reinforcing when to invoke the tool. No filler is present.

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

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

Given the tool has 8 parameters, an output schema, and read-only annotations, the description covers the essential operational context: what each op returns, when to use each, size limits, and a recommended loop. The description is complete enough for an agent to select and invoke the tool correctly without needing supplementary documentation.

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 high at 88%, so the schema already documents most parameters. The description adds significant semantic value by explaining what each op value means and how parameters like region interact with ascii's size cap. It stops short of explaining every parameter's edge case, but the combination of schema and description is strong.

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

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

The description opens with a clear verb and resource ('See what is actually on the canvas') and then enumerates four concrete operations with distinct outputs: preview, ascii, filmstrip, and diff. This clearly distinguishes the tool from siblings like read_pixels and validate by scoping it to visual inspection of the sprite/canvas.

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?

Every operation is paired with an explicit use case ('Use for overall read', 'Use to verify precise pixel positions', 'The only reliable way to review an animation', 'Use it to confirm exactly what an edit touched'). The description also gives a workflow directive ('Draw, then look, then fix') and warns against reporting a sprite finished without looking, making selection criteria explicit.

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

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

The description goes beyond the bare annotations by describing operation effects: 'set' writes or replaces, 'ramp' appends a hue-shifted ramp, and 'analyze' reports palette issues. However, it does not disclose which operations are destructive or how replacing/remapping affects existing pixels, leaving meaningful behavioral gaps for a mutation-capable tool.

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

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

The bulleted operation list is well organized and front-loaded, making the tool's capabilities scannable. The closing 'Decide the palette before drawing' advice is useful, though the artistic commentary about machine-made pixel art is slightly extraneous and could be trimmed without losing operational clarity.

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 tool with 11 parameters, six operations, and an output schema, the description plus schema provide a complete picture. The description covers each operation's purpose, key inputs, and output highlights, while parameter details are handled by the high-coverage schema. The workflow warning also helps the agent apply the tool correctly.

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

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

With 91% schema coverage, the schema already documents most parameters, so the baseline is 3. The description adds value by mapping operations to their relevant inputs, e.g. 'load' reads .gpl/.hex/.pal/.png files, 'preset' lists bundled palettes, and 'ramp' describes base-colour behavior. This enriches parameter understanding beyond the raw 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 clearly states the tool's resource and action: 'Read and shape the sprite's palette,' and enumerates six distinct operations with concrete outcomes. It does not explicitly contrast itself with nearby siblings like 'recolor', but the operation list makes the scope understandable.

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 practical workflow guidance: 'Decide the palette before drawing. Retro-fitting one onto finished art means repainting,' which tells the agent when in a workflow this tool belongs. It does not name alternative tools or explicitly say when not to use it, so it falls short of full routing guidance.

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

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

The description discloses key behavioral traits beyond annotations: the tool returns a readiness condition (`ready`), instructs halting when false, and reveals that all editing tools depend on the open window. The readOnlyHint annotation is consistent with the check/report behavior, and no contradiction exists.

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 sentences with no filler. The core purpose is front-loaded, followed immediately by the critical usage directive and consequence. Every clause contributes actionable 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 zero-parameter preflight tool, the description is complete: it names the operation, gives the call order, provides the failure condition, and explains the underlying dependency. An output schema exists to describe the return values, so no additional return-format detail is needed.

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 zero parameters and 100% schema description coverage, the baseline is 4. The description does not need to explain parameters, and it fulfills the requirement by adding no irrelevant parameter detail.

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 ('Check') and resource ('Aseprite is connected') and adds the reporting function ('report what this session can do'). This clearly distinguishes preflight as a connectivity/session-check tool from sibling editing tools like layer, draw, and transform.

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

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

Explicitly instructs 'Call this FIRST in any pixel-art task' and provides the stop condition ('stop if ready is false'). It also explains why this matters, that every editing tool writes into the user's open Aseprite window with no useful fallback, giving the agent a clear decision rule and rationale.

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 annotations already declaring readOnlyHint=true and openWorldHint=false, the safety profile is covered. The description adds meaningful behavior beyond annotations by specifying the exact return structure ('list of distinct colours plus a row-major index grid') and a performance/cost hint ('look is cheaper'). This gives an agent useful expectations about result shape and relative cost, going beyond the safety annotations.

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

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

Three sentences with zero filler: the first defines the operation and output, the second gives concrete use cases, the third names the cheaper alternative for visual inspection. Information is front-loaded and every sentence earns its place, making the description efficient and scannable.

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

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

For a read-only tool with five optional parameters, a nested region object, and an output schema, the description is fully sufficient. It covers the result format, when to use the tool, and when to prefer a sibling. The schema handles parameter details and an output schema exists, so nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100%, so the input schema fully documents all five parameters, including defaults and fallback behavior (e.g., 'Omit to use the active frame'). The description does not add parameter-specific details, but its mention of 'row-major index grid' and 'rectangular region' clarifies the semantics of the region and output. Baseline 3 is appropriate because the schema carries the parameter-documentation 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 opens with a specific verb and resource: 'Read a rectangular region as structured data: a list of distinct colours plus a row-major index grid.' This precisely states both the operation and the output format, leaving no ambiguity about what the tool does. It also differentiates from siblings by contrasting with 'look' ('For eyeballing, look is cheaper'), making the tool's niche clear.

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 explicitly tells an agent when to use this tool: 'Use this when you need to compute over pixels (sample a palette from art, find a silhouette edge, copy a region) rather than just look at them.' It then names the alternative ('look') and the condition for choosing it ('For eyeballing'), giving direct routing guidance instead of leaving it to inference.

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

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

Annotations already signal readOnly=false and destructiveHint=false; the description adds meaningful behavioral nuance beyond that: it operates on distinct colours in one pass, produces a single undo step, and enforces palette legality by intent. This helps set expectations about scope and side effects.

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 well-structured with a front-loaded summary, a compact bulleted list of operations, and a closing note on the undo-step behavior. Every sentence earns its place, and the format is easy for an agent to scan.

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 12-parameter tool with an output schema and 83% schema coverage, the description covers the behavioral essentials: the five modes, when to use them, palette constraints, region scope, and single-undo-step behavior. The schema handles parameter defaults and valid ranges, so nothing critical is missing.

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

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

Schema coverage is high (83%), but the description adds semantic value beyond the schema by explaining perceptual concepts such as 'shadows cool, highlights warm', 'CIELAB distance', and 'value check'. It also clarifies that amount is a ramp step and how each op relates to the relevant 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?

The description opens with a specific verb and resource: 'Change colours in a region by intent, staying palette-legal.' It then enumerates five concrete operations (shade, snap, replace, hue_shift, desaturate), which clearly distinguishes this tool from siblings like draw or palette.

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?

Each operation is paired with a use case, e.g., 'shade' is recommended instead of picking a darker hex by hand, and 'desaturate' is useful for a value check. It does not explicitly name sibling tools as alternatives, but the intent-based guidance is strong enough for an agent to decide when to invoke 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?

With only readOnlyHint:false and openWorldHint:false in annotations, the description carries the behavioral burden and delivers: importing places the image on a locked, semi-transparent layer above the art, size changes use nearest-neighbour resampling, and a photo scaled to 32×32 is explicitly characterized as a silhouette starting point. This discloses mutation, layer placement, transparency, and resampling behavior that annotations alone cannot convey. No contradiction with the annotations.

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

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

Roughly 4 sentences, purpose-first: main goal, compact op list with embedded semantics, and a single closing caveat that earns its place by preventing misuse. No fluff or repetition of the schema. The op list is dense yet scannable.

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 tool with 9 parameters, 4 ops, and an output schema (so return values need not be described), the description covers the ope semantics, the laryal behavior, opacity context, and a size-related quality warning. Minor gaps remain: 'remove' and 'list' behaviors are left to the reader's inference, and the relationship between opacity and the import op is only implicit. This is solid but not exhaustive.

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 56%, so the schema partially documents parameters (size, sprite have descriptions), and the description adds genuine meaning to the critical required parameter `op` by explaining what each enum value does behaviorally. It also aligns 'semi-transparent' with the opacity parameter. Other parameters like x/y are positional and self-evident with defaults, so the lack of dedicated parameter prose is acceptable, though a 5 would require systematically richer guidance for opacity and size.

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

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

The description opens with a specific verb+resource pair ('Bring an external image into the sprite as a reference layer') and gives the concrete use cases (tracing proportions, sampling colours). The four ops are each given a one-line semantic ('import' places a locked, semi-transparent layer; 'sample_palette' reads colours without importing), which clearly delineates the tool's scope from siblings like palette, layer, and 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?

The description conveys clear context for each op: import is for placing a reference layer, sample_palette is for reading dominant colours 'without importing', list and remove round out lifecycle management. It also gives a practical caveat about when an import result is acceptable (a starting point, 'never a finished sprite'). It does not explicitly name sibling alternatives or state when-not-to-use, so it stops 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?

Discloses that the tool reads or changes the active selection and that the selection subsequently scopes drawing, transforms, and recoloring. This adds behavioral context beyond the annotations, which already flag readOnlyHint=false and idempotentHint=true. No contradiction with annotations.

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

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

Two tight sentences front-load the purpose, list all operations, and provide a cost/benefit rationale. Every phrase earns its place with no filler or redundancy.

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

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

Given the output schema and annotations, the description sufficiently covers the conceptual model and op variety. Minor details like how mode combines with the existing selection or how rect coordinates are specified are left to the schema, which is acceptable for a tool with rich structured metadata.

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 descriptions already cover frame, layer, amount, sprite, color, and contiguous, and the enum values are self-explanatory. The description adds meaning only for the 'color' operation ('select every pixel matching a colour'). With schema coverage at 70%, the description provides modest additional value but does not compensate for undocumented params like rect and mode.

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 or change the active selection') and enumerates all nine operations. The selection resource is clearly distinct from sibling tools like layer, draw, transform, and recolor, so an agent can tell them apart without opening the schema.

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

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

Explains that a selection scopes draw, transform, and recolor, and that it is usually cheaper and safer than masking by hand. This gives clear contextual guidance for when to use the tool, though it does not explicitly name sibling alternatives or state when not to use 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?

The readOnlyHint annotation already signals a safe read operation, and the description adds useful behavioral context: reading full state before editing prevents file corruption from guesswork. No contradictions with annotations exist.

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 carry the essential information with no filler. The core purpose is front-loaded in the first sentence, and the second sentence provides a high-value usage warning that 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 read-only inspection tool with an output schema, the description is complete: it enumerates what state is available, signals when to call it, and explains why it matters. Missing details like optional parameter behavior are already covered by the input 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 67%, with 'sprite' and 'includePalette' already documented in the schema. The description itself adds no additional parameter-level guidance, and 'includeSlices' lacks schema documentation, but its meaning is reasonably inferable from the name and the return-state list.

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

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

The description clearly identifies the tool as returning the full structured state of a sprite, enumerating dimensions, color mode, palette, layers, frames, tags, slices, and selection. It is specific about the resource and content, but it does not explicitly distinguish itself from sibling tools like 'look' 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?

The description gives a clear when-to-use instruction: 'Read this before editing.' It also explains why using it beforehand matters by warning against guessing layer names or frame counts. It does not mention alternatives or when not to use it, so it stops short of a 5.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this tool can mutate state. The description adds one meaningful behavioral detail: canvas resize preserves existing pixels and uses an anchor to position them. It does not go further to explain what 'close' does to unsaved changes or that 'save' overwrites files, but the destructive annotation covers the general risk and the schema's 'force' parameter says to ask the user before discarding changes.

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—two sentences—and front-loads the action verb set before listing operations. The operation list is organized and scannable, and the resize note earns its place by adding targeted behavior not obvious from op names alone. There is no fluff or repetition.

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

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

For a tool with nine operations and nine parameters, the description gives a solid overview but leaves meaningful gaps: it never explains what 'set_properties' changes, nor does it map which parameters belong to which operation (e.g., 'new' likely needs width/height/colorMode, while 'open' needs path). The schema's per-parameter descriptions partly fill this, and an output schema exists, but the description itself still requires the agent to infer operation-parameter pairings. This is adequate but not complete.

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

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

Schema coverage is 67%, and the description does add value by defining what 'list' returns (open documents) and by explaining the anchor's role in canvas resize. The schema already documents path, force, sprite, colorMode, pixelAspect, and anchor, leaving op, width, and height unduscussed in both schema and description; however, op is self-describing via its enum and width/height are intuitive integers. Overall the description complements the schema but does not fully compensate for the minimal param guidance on op-specific required inputs.

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

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

The description uses specific verbs ('Open, create, focus, resize, save and close sprites') and names the resource (sprites in the running Aseprite session), which gives an agent a clear subject and action set. It also enumerates all supported operations, making the tool's scope explicit and distinguishing it from sibling tools that operate on layers, frames, or cels. The title alone is generic, but the description fully specifies what the tool does.

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 sets a clear context—operations inside the running Aseprite session—and gives a list of operations, which implicitly tells an agent this is the sprite-management entry point. However, it does not explicitly state when to prefer this over siblings like sprite_info or layer, nor does it call out exclusions such as 'for layer-only changes use the layer tool.' The resize guidance ('keeps existing pixels — pass an anchor') is useful but is op-level instruction, 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.

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

Annotations already signal readOnlyHint=false and destructiveHint=true, so the mutation profile is known. The description adds no further operational behavior such as whether update/overwrite existing tags, what delete removes, or lifecycle consequences beyond saying untagged spritesheets are unusable — which is workflow context, not tool 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?

Three short sentences, front-loaded with the core definition, then ops, then workflow guidance. The 'pile of frames' phrase is evocative but slightly ornamental; otherwise every part 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?

This is a high-complexity multi-op tool (9 params, 4 operations, an output schema) and the description does not specify op-parameter contracts, e.g. what create requires vs update vs delete. The 'tag before export' guidance and annotations help, but an agent still cannot reliably decide the correct param set for each op from this definition.

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 contributes the key model that tags are named frame ranges, giving meaning to name/from/to, and it restates the op enum. However, it does not map which parameters are valid for each operation, nor explain newName or direction; with only 56% schema coverage, that leaves meaningful gaps.

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

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

The description identifies the resource ('animation tags') and explains what tags are (named frame ranges imported as 'idle', 'walk', 'attack'), and it enumerates the supported operations. It is clear enough to distinguish from sibling frame/cel tools, though 'Manage' is somewhat generic and the target sprite is implied rather than stated.

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

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

It gives clear operational context: 'Tag every cycle before export', telling the agent when tags must be maintained. It does not explicitly name alternatives or say when not to use this tool, so it falls short of fully explicit 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?

With minimal annotations (readOnlyHint false, openWorldHint false), the description carries the burden and largely meets it: it discloses mutating operations (create_layer, stamp, pack, export) and reveals output side effects such as produced files (Tiled .tsj, Godot .tres, JSON, packed PNG). It does not explicitly mention file overwriting or undo implications, but the operational effects are clear enough for an agent.

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 dense sentences, front-loaded with the tilemap-layer scope and then enumerating operations efficiently. There is no fluff, though the packed operation list would benefit from slight structural separation for readability. Every sentence earns its place.

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

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

For a 12-parameter, 6-operation tool, the description gives a solid overview of available operations, outputs, and the preflight prerequisite. The presence of an output schema covers return-value expectations. It lacks a per-op parameter matrix, but the combination of op parentheticals, schema field descriptions, and preflight guidance is sufficient for initial correct usage.

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 moderate at 58%, and the description adds operation-level meaning (e.g., what each op achieves) rather than parameter-level syntax. It does not elaborate on undocumented parameters such as 'name', 'tileWidth', or 'tileHeight', and per-op required-parameter combinations are left implicit. This aligns with a baseline score of 3: helpful but not comprehensive.

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 explicitly identifies the resource (Aseprite tilemap layers) and lists six specific operations with clarifying parentheticals: 'get' returns a packed image plus indices, 'stamp' places tiles by grid coordinate, 'pack' deduplicates a mockup, and 'export' writes Tiled/Godot/JSON formats. This scope clearly distinguishes the tool from sibling tools like 'layer' or 'export' by focusing on tilemap-specific workflows.

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 states the tool is for tilemap layers and adds a concrete prerequisite: it requires an extension build advertising the 'tileset' feature and advises checking preflight first. It does not explicitly name sibling alternatives or when-not-to-use cases, but the tilemap-layer scope provides clear contextual boundaries.

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 indicate the tool is not read-only and not destructive, so the description does not need to restate that. It adds useful behavioral context: arbitrary rotations can visually ruin pixel art, non-90° angles need allowLossy, and scaling is nearest-neighbour/integer-only. This goes beyond the structured annotations and helps the agent choose safe settings.

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 carry the behavior, the op list, and the key constraints without wasted words. The core action is front-loaded, and the caveats follow naturally. The em-dash and short clauses keep it scannable.

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 13-parameter tool with six ops, the definition could explain outline and crop_to_content more explicitly, but the schema covers most parameter meanings and an output schema exists. The description properly highlights the only genuinely dangerous behaviors (lossy rotation and scaling). The remaining gaps like thickness are minor and inferable from op name plus schema bounds.

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 already describes most parameters, including axis, angle, color, scope, factor, and allowLossy. The description adds conceptual rationale for rotation and scale constraints, but does not explain dx/dy semantics, thickness, frame, layer, or sprite. With 69% schema coverage, the description only partially compensates 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?

The description opens with a specific verb phrase ('Move, flip, rotate or scale pixels') and enumerates all six operations by name. It names the resource ('pixels') and the operation set precisely, which clearly separates it from siblings like draw or recolor. Even without mentioning sibling tools, an agent can identify this as the geometric-transform tool.

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

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

It gives implicit usage guidance by listing operations and warning that non-90 rotation and non-integer scale require allowLossy. However, it never says when to prefer an alternative tool or when not to use this one. The limits it mentions are parameter-level constraints, not cross-tool routing guidance.

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

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

Annotations already mark readOnlyHint=true, and the description consistently describes a non-mutating lint operation. It adds meaningful behavioral detail by stating the tool reports 'concrete, located problems' and evaluates an entire checklist, including animation-level concerns, so the agent knows it will get diagnostic evidence rather than a binary pass/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 core behavior is stated in the first sentence, and the long checklist sentence is dense but every item maps to a real check an agent can act on. The closing guidance is memorable and earns its place by defining the tool's purpose as evidence over optimism.

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

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

For a read-only diagnostic tool with three optional parameters, the description plus a fully-covered schema and an output schema leave no major gaps: the agent knows what the tool checks, when to call it, that it is non-destructive, and that results are located reports rather than opinions.

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 has 100% description coverage, so the baseline is 3, but the description earns an extra point by expanding the meaning of the check names into concrete concepts (off-palette colours, stray pixels, broken outlines, banding, volume drift). This helps an agent decide which subset of checks to request, even though it does not name the parameters explicitly.

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?

Description opens with a precise verb and object: 'Lint a sprite against pixel-art rules', then enumerates the specific rule categories it checks. It clearly distinguishes itself from related siblings like preflight by framing the output as evidence-based completion assessment rather than a generic validation step.

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

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

Explicitly instructs when to run: 'Run this before telling the user a sprite is finished,' giving an unambiguous trigger. It does not name an alternative tool to use instead in other situations, so it stops short of full when/when-not guidance.

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