Server Quality Checklist

Tool Scores

• pixel_flood_fillB
  3.4/5.0
  Behavior4/5

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

  Adds context beyond annotations: specifies connectivity rule ('exactly match seed'), return format ('JSON {canvas, seed, color}, plus rendered image on preview'), and failure format ('Error: ...'). Annotations already indicate destructive and idempotent; description complements without contradiction.

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

  Conciseness4/5

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

  Two concise sentences with a third clarifying return values; no fluff. Could use more structured formatting (e.g., bulleted return fields) but overall efficient.

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

  Completeness2/5

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

  Missing critical detail about connectivity (4- vs 8-directional). Does not explain that the canvas file is modified (implied by destructiveHint). Return format is mentioned but key names are uncertain. For a complex operation, more precision is needed.

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

  Parameters2/5

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

  Schema coverage is 0%, meaning description does not formally describe parameters. While it implicitly references seed (x, y) and color in the main text, it omits path and preview. Schema provides parameter descriptions, but description should compensate for low coverage and does so only partially.

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

  Purpose5/5

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

  Describes a specific verb ('flood-fill') on a specific resource ('contiguous region containing (x, y)'), explicitly distinguishing from sibling tools like pixel_replace_color or pixel_draw_pixels by naming the flood-fill algorithm and seed-based filling.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool vs. alternatives. The phrase 'like a paint bucket' implies a use case but does not mention other tools or provide when-not-to-use conditions.

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

• pixel_replace_colorB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint: true and idempotentHint: true. The description adds the return structure (JSON with fields and preview option) and error handling. It does not contradict annotations. However, it does not explicitly state that the canvas file is modified in place, though that is implied by 'across the canvas' and 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.

  Conciseness4/5

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

  The description is three sentences and well-structured: first sentence states the core action, second adds use cases, third covers return value and error. There is no fluff, and it is front-loaded with the main purpose.

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

  Completeness3/5

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

  The description covers return format and error, but does not explain whether the canvas is modified in place (though annotations indicate destructive). It also doesn't mention idempotency despite the hint. With no output schema, the description partially fills the gap by listing return fields. For a simple color replacement tool, this is adequate but not comprehensive.

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

  Parameters3/5

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

  The input schema provides descriptions for all parameters (find, path, preview, replace) with format hints. The description adds that matching is exact RGBA, which is helpful but not critical. Since schema descriptions are present and detailed, the description does not add significant new semantics beyond clarifying exact matching.

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

  Purpose4/5

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

  The description clearly states the action ('Replace every pixel of one exact color with another across the canvas') and the resource (canvas). It mentions 'palette swaps and recoloring sprites' for context, but does not explicitly distinguish from sibling tools like pixel_flood_fill or pixel_apply_palette. The purpose is clear and specific.

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

  Usage Guidelines3/5

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

  The description gives a usage indication ('Useful for palette swaps and recoloring sprites') and notes exact RGBA matching. However, it lacks guidance on when not to use this tool versus alternatives, or prerequisites such as the canvas file needing to exist. No explicit when-to-use versus when-not-to-use.

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

• pixel_scale_canvasA
  3.9/5.0
  Behavior4/5

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

  The description adds detail beyond annotations: nearest-neighbor sampling, crispness conditions, return format including optional preview, and error message. Annotations already indicate destructive behavior, and description aligns without contradiction.

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

  Conciseness5/5

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

  The description is concise with four sentences, each serving a purpose: action, quality conditions, return value, error handling. No unnecessary words.

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

  Completeness4/5

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

  The description covers key aspects: algorithm, quality trade-offs, return structure, optional preview, and error handling. It misses explaining in-place modification (implied but not explicit), but annotations fill part of that gap.

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

  Parameters4/5

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

  The schema descriptions cover all parameters (high coverage), but the description adds value by explaining how width/height ratios affect pixel quality and the preview parameter's effect. This extra context justifies a score above baseline 3.

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

  Purpose4/5

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

  The description clearly states the tool rescales canvas and art using nearest-neighbor sampling, and distinguishes itself by specifying the algorithm and crispness conditions. However, it does not explicitly contrast with sibling tools like pixel_resize_canvas.

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

  Usage Guidelines3/5

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

  The description provides context for use in squash-and-stretch animation frames but does not specify when not to use or mention alternative tools. It lacks explicit guidance on selection among siblings.

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

• pixel_transform_canvasA
  3.9/5.0
  Behavior4/5

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

  Beyond the annotations (destructiveHint=true), the description adds key behavioral details: 'in place' modification, dimension swap on 90-degree rotations, the return JSON structure, preview behavior, and error format. These complement the annotations without contradiction.

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

  Conciseness4/5

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

  The description is concise and front-loaded with the purpose. It uses a short list and a clear return format paragraph. However, it could be slightly more structured (e.g., using sections).

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

  Completeness4/5

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

  For a simple transformation tool, the description covers operation types, side effects (in-place, dimension swap), return format on success and failure, and the preview flag. With no output schema, it adequately documents the return. It could specify whether changes persist to the file, but overall it's fairly complete.

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

  Parameters3/5

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

  Although the context indicates 0% schema description coverage, the actual schema includes descriptions for path and preview. The description adds value by listing all operation enum values explicitly. However, it does not explain path or preview beyond what the schema already provides, so the added value is modest.

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

  Purpose5/5

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

  The description clearly states 'Flip or rotate the entire canvas in place' and lists all five operations explicitly. This verb+resource pairing is very specific and distinguishes the tool from siblings like pixel_shift_canvas, pixel_resize_canvas, and pixel_scale_canvas.

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

  Usage Guidelines3/5

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

  The description does not provide explicit guidance on when to use this tool versus alternatives like pixel_shift_canvas or pixel_scale_canvas. It only describes what it does, leaving the agent to infer usage context.

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

• pixel_view_framesA
  4/5.0
  Behavior4/5

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

  Annotations already indicate read-only and idempotent behavior. The description adds value by stating nothing is written to disk, describing the visual layout (neutral gray backdrop, thin separators), and specifying return format (text summary plus image) and error handling. This goes beyond 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.

  Conciseness5/5

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

  The description is concise (3 sentences), front-loaded with the key action and purpose. Each sentence adds value without redundancy.

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

  Completeness4/5

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

  Given the tool's moderate complexity, complete schema descriptions, and annotations, the description covers purpose, behavior, output, and error format. It lacks example usage or limits on frame count beyond schema, but overall is comprehensive for a read-only operation.

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

  Parameters3/5

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

  The input schema already has good descriptions for all three parameters. The tool description adds minor context (same-size constraint, order, layout detail) but does not significantly extend schema semantics. With high schema coverage, baseline 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb ('Render') and resource ('canvases as one filmstrip image') and clearly states the purpose: reviewing animations or sprite sets. It is distinct from sibling tools like pixel_view_canvas (single canvas) and pixel_export_spritesheet (export format).

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

  Usage Guidelines3/5

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

  The description implies usage for reviewing animation/sprite sets 'at a glance' but does not explicitly state when to use or avoid this tool, nor does it mention alternatives like pixel_view_canvas or pixel_onion_view.

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

• pixel_outline_spriteA
  4.1/5.0
  Behavior4/5

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

  The description adds context beyond annotations: it explains that the outline occupies transparent pixels without altering the art itself, describes the return format (JSON with canvas, color, pixels_outlined; image on preview=true), and mentions error handling. Annotations indicate destructive and idempotent hints, which the description supports.

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

  Conciseness5/5

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

  The description is well-structured and concise: it starts with the main action, explains a key nuance (canvas edge), specifies return format, and ends with error handling. Every sentence contributes meaningful information.

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

  Completeness4/5

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

  Given the tool's complexity (outlining with options for corners and preview), the description covers the core behavior, an important edge case, return values, and error handling. It lacks detail on idempotency or multi-call behavior but is otherwise complete for typical use.

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

  Parameters2/5

  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 for parameter meaning. However, the description does not address individual parameters; it only mentions return fields. The input schema already provides basic descriptions for each parameter, but the tool description adds no extra value for parameter semantics.

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

  Purpose5/5

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

  The description clearly identifies the verb and resource: 'Draw a 1px outline around all opaque art on the canvas.' It distinguishes this tool from siblings by mentioning it as 'the classic finishing pass' and referencing a prerequisite step (pixel_resize_canvas) for edge cases.

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

  Usage Guidelines4/5

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

  The description states when to use the tool ('finishing pass') and gives a clear condition for when to first use pixel_resize_canvas (if the sprite touches the canvas edge). However, it does not explicitly exclude alternative tools or scenarios.

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

• pixel_copy_regionA
  4.2/5.0
  Behavior5/5

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

  The description goes well beyond annotations by explaining mode behavior ('over' composites respecting transparency; 'replace' overwrites including alpha), clipping for out-of-bounds coordinates, return JSON structure, preview feature, and error format. Annotations indicate destructive and idempotent, which the description aligns with. No contradictions.

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

  Conciseness5/5

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

  The description is very concise, consisting of four sentences that front-load purpose and use cases, then detail mode behavior, clipping, return values, and error handling. Every sentence adds value without redundancy.

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

  Completeness4/5

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

  For a complex tool with modes, clipping, preview, and return values, the description covers all critical aspects. It lacks only a minor detail on the format of the rendered image when preview=true. No output schema exists, but the description compensates by detailing the JSON structure. Annotations provide additional safety context (destructive, idempotent).

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

  Parameters3/5

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

  The input schema already provides descriptions for all parameters (e.g., 'Source region left edge X', 'Region width in pixels', etc.), so schema coverage is high. The description does not add new parameter-specific information beyond what the schema gives. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the verb 'copy', the resource 'rectangular region', and scope 'from one canvas onto another (or within the same canvas)'. Use cases like moving limbs, stamping, compositing further clarify purpose and distinguish it from sibling tools like pixel_draw_pixels or pixel_transform_canvas.

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

  Usage Guidelines3/5

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

  The description lists specific use cases (moving limbs between frames, stamping repeated parts, compositing) which imply when to use the tool, but it does not explicitly mention when not to use it or compare with alternatives. No direct exclusions or alternative tool names are provided.

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

• pixel_create_canvasA
  4.2/5.0
  Behavior4/5

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

  The description discloses key behaviors: true-size canvas, automatic parent directory creation, refusal to replace without overwrite=true, and return format (JSON plus optional preview image). Annotations are sparse, so the description adds valuable transparency beyond them.

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

  Conciseness5/5

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

  The description is concise with no redundant sentences. It is well-structured: purpose, size advice, behavioral notes, and return info, all front-loaded for quick comprehension.

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

  Completeness4/5

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

  Given the tool has 6 parameters and no output schema, the description covers essential aspects: purpose, size recommendations, automatic directory creation, overwrite behavior, preview option, and return format. It lacks details on error types and background initialization, but overall is fairly complete.

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

  Parameters3/5

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

  Despite 0% schema description coverage, the description mentions overwrite and preview parameters explicitly. However, it does not explain path, width, height, or background parameters, relying on the schema's own descriptions. This partial coverage limits the added value.

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

  Purpose5/5

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

  The description clearly states 'Create a new pixel art canvas saved as a PNG file,' which is a specific verb+resource pair. It distinguishes itself from siblings like pixel_draw_pixels and pixel_export_png by focusing on canvas creation.

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

  Usage Guidelines4/5

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

  The description provides guidance on canvas size ('keep sprites small') and suggests using pixel_export_png for upscaling later. It also clarifies that overwriting requires overwrite=true, giving clear context for when to use this tool over alternatives.

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

• pixel_draw_lineA
  4.2/5.0
  Behavior4/5

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

  Annotations indicate destructiveHint=true. The description adds useful behavioral details: endpoints may lie outside canvas, 'transparent' erases, and return value includes a rendered image when preview=true. These go beyond annotations.

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

  Conciseness5/5

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

  The description is three sentences: purpose, edge case/behavior, and return value. No wasted words, front-loaded with the core action.

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

  Completeness4/5

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

  No output schema exists, but the description explains the return format (JSON with canvas, line, color, plus image on preview) and failure case. It covers the endpoint clipping behavior. Lacks details about modification semantics (e.g., does it update the file?), but overall adequate.

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

  Parameters4/5

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

  Schema property descriptions exist (e.g., 'Start X'), but overall schema description coverage is 0%. The description adds meaning: endpoints can be outside, transparent erases, and preview returns image. It does not cover thickness or path explicitly, but provides key context.

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

  Purpose5/5

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

  The description explicitly states 'Draw a straight line between two points on a canvas,' which is a specific verb+resource. It distinguishes from siblings like pixel_draw_rect and pixel_draw_ellipse by focusing on lines.

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

  Usage Guidelines3/5

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

  The description does not explicitly state when to use this tool versus alternatives. Usage is implied by the tool's purpose, but no when-not-to-use or alternative comparisons are provided.

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

• pixel_duplicate_canvasA
  4.2/5.0
  Behavior4/5

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

  Annotations provide minimal behavioral info (readOnlyHint=false, destructiveHint=false). The description adds value by disclosing that it refuses to overwrite unless overwrite=true, and describes the return JSON structure, which annotations do not cover.

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

  Conciseness5/5

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

  The description is concise (two sentences), front-loads the primary purpose, and includes essential behavioral details without redundancy. Every sentence adds value.

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

  Completeness4/5

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

  Given the presence of an output schema (not shown but indicated), the description adequately explains the tool's behavior and return format. It covers the key aspects for a copy tool, though it could mention that the destination must end in .png (already in schema).

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

  Parameters3/5

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

  The input schema already provides descriptions for all parameters (path, dest_path, overwrite). The description does not add further semantic detail beyond what the schema offers, so scores baseline 3.

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

  Purpose5/5

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

  The description uses the specific verb 'Copy' and resource 'canvas', clearly indicating the tool duplicates a canvas. It distinguishes from siblings like pixel_create_canvas (create new) by specifying it copies from an existing canvas.

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

  Usage Guidelines4/5

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

  Explicitly states it is 'the standard way to start the next animation frame', giving clear usage context. Also notes the overwrite constraint. However, it does not explicitly list when not to use or name alternatives.

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

• pixel_canvas_infoA
  4.3/5.0
  Behavior4/5

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

  Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds value by specifying the exact JSON structure returned, the limit of top 16 colors, and the error format, going beyond 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.

  Conciseness5/5

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

  The description is concise: two sentences, front-loaded with the core purpose, and every sentence adds value. No unnecessary words.

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

  Completeness5/5

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

  Given the single simple parameter, clear output schema, and comprehensive annotations, the description covers all needed details: purpose, return format, limits, and error handling.

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

  Parameters3/5

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

  The schema provides a description for the 'path' parameter ('Canvas file path ending in .png'), so the description does not need to add param details. The tool description adds no additional parameter guidance beyond the schema's baseline.

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

  Purpose5/5

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

  The description uses a specific verb 'Report' and clearly identifies the resource (canvas's dimensions and color palette). It distinguishes the tool from rendering tools like pixel_view_canvas by stating 'without rendering it'.

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

  Usage Guidelines4/5

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

  The description implies usage for when you need metadata without rendering, and mentions error handling. However, it does not explicitly state when not to use it or provide alternatives among siblings.

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

• pixel_view_canvasA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral details: upscaling behavior (nearest-neighbor to ~512px), return format (text summary plus image), and error handling ('Error: ...'). This goes beyond 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.

  Conciseness5/5

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

  The description is three sentences, with the purpose front-loaded in the first sentence. Every sentence adds necessary information: purpose, scaling behavior, usage context, return format, and error handling. No redundant or ambiguous language.

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

  Completeness5/5

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

  For a simple view tool with one required parameter and no output schema, the description is complete. It covers the action, when to use, scaling behavior, return type (text+image), and possible error. No gaps remain for an agent to understand and invoke it correctly.

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

  Parameters3/5

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

  The input schema provides descriptions for both parameters (path and scale), so the tool description does not need to repeat them. The description mentions 'unless an explicit scale is given', which implicitly refers to the scale parameter but adds little beyond the schema's description. Given schema coverage is effectively high (schema has descriptions), baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool renders a canvas as an image to see its current state. It uses a specific verb ('Render') and resource ('canvas'), and the sibling tools list shows other view-related tools, but this one is distinct as it shows the current state. The description also provides usage context ('after a series of edits').

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

  Usage Guidelines4/5

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

  The description explicitly says to use this tool after a series of edits to check work, giving clear context. However, it does not mention alternatives or when not to use it, though the sibling tools include other view functions like pixel_view_frames. Still, the provided usage guidance is helpful.

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

• pixel_shift_canvasA
  4.4/5.0
  Behavior4/5

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

  Annotations already indicate destructiveHint=true, and the description adds detail: pixels lost at edges, vacated space transparent, wrap re-entry behavior, and return JSON structure. This goes beyond annotations.

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

  Conciseness5/5

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

  The description is two sentences, front-loading the action, then covering wrap and return. No wasted words; every sentence adds value.

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

  Completeness4/5

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

  Covers main behavior, wrap option, preview, and return JSON. With no output schema, it explains return structure. Missing explicit mention of parameter limits but schema covers that.

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

  Parameters4/5

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

  Schema descriptions cover each parameter, but the tool description adds context for 'wrap' (re-entry from opposite edge) and clarifies what happens without wrap. It also mentions preview and return value.

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

  Purpose5/5

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

  The description clearly states the tool shifts the canvas by (dx, dy) pixels and provides specific animation use cases (bobbing, jumping, sliding). It contrasts with sibling tools like pixel_transform_canvas by focusing on quick translation.

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

  Usage Guidelines4/5

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

  The description gives concrete example uses (animation frames, scrolling backgrounds) and explains the wrap behavior. It does not explicitly say when not to use, but the context is clear enough for an agent to decide.

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

• pixel_apply_paletteA
  4.5/5.0
  Behavior4/5

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

  Discloses RGB distance matching, alpha preservation, transparent pixels untouched, and return format. Annotations already provide idempotent and destructive hints; description adds useful details about pixel handling and failure response.

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

  Conciseness5/5

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

  Two sentences with no wasted words. Front-loads purpose, then details behavior and return value. Efficient and structured.

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

  Completeness5/5

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

  Despite no output schema, the description fully explains return format (JSON with fields and error case). Covers purpose, behavior, parameters, and return value comprehensively.

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

  Parameters4/5

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

  Input schema provides descriptions for all parameters; description adds value by mentioning preview returns a rendered image. The description does not repeat schema details but complements them.

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

  Purpose5/5

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

  Cleary states the tool snaps opaque pixels to nearest color in a palette, with specific verb 'snap' and resource 'every opaque pixel'. Distinguishes from siblings like pixel_replace_color and pixel_flood_fill by describing a unique use case: enforcing a consistent game palette.

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

  Usage Guidelines4/5

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

  Implicitly indicates when to use (enforce consistent palette, clean up stray colors) without explicit exclusions or alternative tool names. Provides clear context of usage from the description.

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

• pixel_draw_ellipseA
  4.5/5.0
  Behavior4/5

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

  Annotations already indicate destructive and idempotent behavior. The description adds that drawing 'transparent' erases, describes the return JSON structure, and notes error format. This goes beyond annotations to inform the agent about side effects and output.

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

  Conciseness5/5

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

  The description is four sentences, front-loaded with the main action, and covers key usage details without redundancy. Every sentence adds value, making it efficient for an agent to parse.

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

  Completeness5/5

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

  Given there is no output schema, the description adequately explains the return value (JSON fields) and failure case. It covers all important aspects of a simple drawing tool, leaving no major gaps.

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

  Parameters4/5

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

  Although the input schema provides descriptions for all parameters, the tool description adds conceptual context: the bounding box meaning, the relationship between width/height and circles, and the preview toggle. This aids understanding beyond the schema's individual field descriptions.

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

  Purpose5/5

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

  The description clearly states the tool draws 'a filled or outlined ellipse inside a bounding box on a canvas', with specific detail on how equal width/height yields a circle. This distinguishes it from siblings like pixel_draw_rect and pixel_draw_line, which draw different shapes.

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

  Usage Guidelines4/5

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

  The description explains the bounding box coordinate system, the effect of 'transparent' color, and the preview option. While it doesn't explicitly contrast with siblings, the context is sufficient for an agent to understand when this tool is appropriate.

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

• pixel_draw_rectA
  4.5/5.0
  Behavior4/5

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

  The description adds behavioral details beyond annotations: it specifies the return JSON structure, optional preview rendering, and the erasure effect of 'transparent'. It does not contradict the readOnlyHint=false, destructiveHint=true, idempotentHint=true annotations.

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

  Conciseness5/5

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

  The description is concise (5 lines), front-loaded with the core action, and includes essential details like return format and error handling. Every sentence serves a purpose.

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

  Completeness5/5

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

  Given the simple nature of the tool, the description covers behavioral expectations, coordinate system, special color handling, output format, and error behavior. It is sufficient for an agent to use correctly.

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

  Parameters4/5

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

  The description clarifies coordinate semantics (top-left, pixels) and the effect of color='transparent'. The schema individually describes each parameter, but the description adds overarching context that the schema lacks.

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

  Purpose5/5

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

  The description clearly states it draws a filled or outlined rectangle on a canvas, specifying behavior for coordinates and size. It distinguishes itself from sibling tools like pixel_draw_line or pixel_draw_ellipse by being rectangle-specific.

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

  Usage Guidelines4/5

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

  The description explains coordinate conventions (top-left), pixel units, and the special 'transparent' erasure behavior. It does not explicitly list when not to use this tool or mention alternatives, but the context is clear enough for typical use cases.

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

• pixel_export_spritesheetA
  4.5/5.0
  Behavior4/5

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

  Adds behavioral traits beyond annotations: left-to-right, top-to-bottom layout, no padding, source canvases untouched, and return/error format. No contradiction.

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

  Conciseness5/5

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

  Two concise paragraphs, front-loaded with purpose, no fluff, every sentence informative.

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

  Completeness5/5

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

  Thorough for a simple tool: purpose, layout, behavior, return values, and error format covered, with good annotations and schema.

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

  Parameters4/5

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

  Adds meaning beyond schema by explaining columns placement and return format; schema already describes parameters clearly. Good compensation for 0% coverage signal.

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

  Purpose5/5

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

  Clearly states it packs same-size canvas PNGs into a spritesheet grid, specifying layout and distinguishing from siblings like pixel_export_png and pixel_slice_spritesheet.

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

  Usage Guidelines4/5

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

  Provides context ('ideal for game engines') and implicitly indicates when to use, but lacks explicit exclusions or when not to use.

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

• pixel_draw_pixelsA
  4.6/5.0
  Behavior5/5

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

  The description adds substantial behavioral details beyond annotations: out-of-bounds handling, transparent color erasing, batch default color, return JSON structure, and preview behavior. It aligns with annotations (destructive, idempotent) and adds context.

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

  Conciseness5/5

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

  The description is efficient: first sentence states purpose, then details. It uses bullet points for return format and examples, no redundant fluff. Every sentence adds value.

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

  Completeness4/5

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

  Given the tool's complexity (4 parameters, batch behavior, preview, error handling), the description covers key behaviors. It lacks explicit mention of output schema (but none exists) and path format, but schema compensates. Sufficient for an AI agent.

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

  Parameters4/5

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

  While the schema provides descriptions for each parameter, the tool description adds context: default color behavior, transparent as eraser, out-of-bounds skipped, and preview returns image. It doesn't cover every parameter (e.g., path format) but adds meaningful explanations.

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

  Purpose5/5

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

  The description clearly states 'Set individual pixels on a canvas in one batch' with a specific verb ('Set') and resource ('pixels on a canvas'). It distinguishes this tool from siblings like pixel_draw_line and pixel_draw_rect by focusing on individual pixel manipulation in batch operations.

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

  Usage Guidelines4/5

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

  The description advises batching multiple points per call ('one call per sprite region, not one call per pixel'), providing clear usage guidance. It also mentions that out-of-bounds points are skipped, but does not explicitly state when to use alternatives or when not to use this tool.

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

• pixel_export_gifA
  4.6/5.0
  Behavior5/5

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

  The description adds behavioral details beyond annotations: 'Transparency is preserved as GIF binary transparency (alpha <= 128 becomes transparent). Source canvases are untouched.' It also describes the return JSON structure and error format, which aligns with idempotentHint=true and destructiveHint=false.

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

  Conciseness5/5

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

  The description is concise and front-loaded: the first sentence states the main purpose, followed by brief clarifications on behavior and return values. No extraneous text.

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

  Completeness4/5

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

  The description covers key aspects: input constraints, transparency behavior, return format, and error handling. However, it omits details on the scale parameter and out_path validation, which are present in the schema but not reinforced.

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

  Parameters4/5

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

  Despite 0% schema description coverage in the context signal, the input schema itself contains detailed descriptions for all properties (e.g., scale, duration_ms). The tool description adds clarity by explaining the role of ping_pong and per-frame durations, complementing the schema.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Combine same-size canvas PNGs into a looping animated GIF.' It specifies the action (combine), input (canvas PNGs), and output (GIF), distinguishing it from sibling tools like pixel_export_png and pixel_export_spritesheet.

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

  Usage Guidelines4/5

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

  The description explains when to use parameters like ping_pong for idle/bounce loops and notes that source canvases are untouched. However, it does not explicitly compare against alternatives like pixel_export_spritesheet or state when not to use this tool, so it lacks explicit exclusions.

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

• pixel_export_pngA
  4.6/5.0
  Behavior5/5

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

  Beyond annotations (idempotentHint=true, destructiveHint=false), the description adds that the source canvas is untouched, parent directories are created, and failure returns 'Error: ...'. This provides concrete behavioral detail without contradiction.

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

  Conciseness5/5

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

  The description is a short paragraph (3 sentences) with the core action first, then usage guidance, then return format. Every sentence adds value; no extraneous information.

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

  Completeness4/5

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

  The description covers main purpose, key behavior, parameter usage, and return format/error. It doesn't mention file overwrite behavior, but idempotentHint implies deterministic output. Given the tool's simplicity and rich schema, the description is sufficiently complete.

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

  Parameters4/5

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

  The input schema already describes each parameter (path, scale, out_path). The description adds context: upscale is nearest-neighbor, scale 1 is true-size, and out_path is the destination. This supplements schema descriptions without being redundant.

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

  Purpose5/5

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

  The description states the tool exports a canvas as an upscaled PNG with nearest-neighbor pixels. It clearly specifies the resource (canvas) and output format (PNG), distinguishing it from siblings like pixel_export_gif and pixel_export_spritesheet.

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

  Usage Guidelines4/5

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

  The description advises using scale 1 for game-ready true-size assets and larger scales for display or sharing, which guides parameter selection. However, it does not explicitly contrast against sibling export tools or state when to choose this tool over pixel_export_gif.

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

• pixel_onion_viewA
  4.6/5.0
  Behavior5/5

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

  Discloses key behavioral traits beyond annotations: 'Nothing is written to disk', opacity percentages (35%, 20%, 12%), ordering of ghosts, tint effect for silhouettes, and return format ('text summary plus the rendered image', 'Error: ...' on failure). Annotations already indicate readOnly and idempotent, but description adds concrete details.

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

  Conciseness5/5

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

  Three succinct sentences covering purpose, ordering/opacity, tint, safety (no disk writes), and return/failure format. No redundant information; every sentence adds value.

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

  Completeness4/5

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

  Covers return value (text summary + image), error format, and core logic for a 4-parameter tool with no output schema. However, does not mention the 'scale' parameter or auto-fit behavior, which would help a user understand display size control. Overall adequate but slightly incomplete.

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

  Parameters4/5

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

  Description adds meaning for 'previous_paths' (most-recent-first ordering, fading percentages) and 'tint' (silhouettes, prevents color overlap). However, 'scale' is not mentioned despite being optional with auto-fit behavior. Given 0% schema description coverage, the description compensates partially but not fully for all parameters.

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

  Purpose5/5

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

  Description clearly states 'Render the current frame over faded ghosts of up to 3 earlier frames — onion-skinning, the standard way to judge motion between animation frames.' The verb 'render' and specific resource 'current frame over faded ghosts' precisely define the action, and the purpose 'judge motion' distinguishes it from siblings like pixel_view_canvas.

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

  Usage Guidelines4/5

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

  The description implies usage when needing to judge motion between animation frames ('standard way to judge motion'). It provides context but does not explicitly exclude alternative tools or state when not to use it. Sibling pixel_view_canvas exists but is not contrasted.

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

• pixel_resize_canvasA
  4.7/5.0
  Behavior5/5

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

  The description fully discloses behavior: existing art is unchanged, new space is transparent, anchor determines placement, and it explains the return format including JSON and preview image. Annotations already indicate destructiveHint=true, but the description adds valuable context about what exactly happens.

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

  Conciseness5/5

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

  The description is concise, using four sentences to convey all key information. It front-loads the core purpose and includes an example and return format without unnecessary words.

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

  Completeness5/5

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

  Given no output schema, the description fully explains the return JSON structure and error handling. It covers all necessary behavioral aspects for an agent to use it correctly.

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

  Parameters4/5

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

  The input schema already has descriptions for all parameters, so the description's role is lighter. However, the description adds practical context (e.g., anchor='bottom' keeps feet planted, preview returns rendered image). This adds value beyond the schema definitions.

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

  Purpose5/5

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

  The description clearly states it changes canvas bounds without scaling art, using a specific verb and resource. It distinguishes itself from the sibling pixel_scale_canvas by explicitly noting that pixel sizes are unchanged, making the purpose highly specific.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool (grow or crop canvas) and explicitly points to pixel_scale_canvas as an alternative for rescaling art. It also gives a concrete example with anchor. However, it does not explicitly state when not to use it beyond the mentioned alternative.

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

• pixel_slice_spritesheetA
  4.7/5.0
  Behavior5/5

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

  The description goes beyond annotations by detailing the scan order (left-to-right, top-to-bottom), handling of partial tiles, naming pattern, behavior of skip_empty, and the exact JSON response structure. It adds significant value beyond the annotations, which only indicate idempotency.

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

  Conciseness5/5

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

  The description is only 5 sentences, front-loaded with the core purpose, then followed by concise details. Every sentence provides necessary information without redundancy.

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

  Completeness5/5

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

  Given the tool's complexity and the presence of an output schema, the description fully covers input behavior, edge cases (partial tiles, transparent tiles), and output format. It also mentions error responses, making it complete for an agent to use.

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

  Parameters4/5

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

  Despite the input schema having descriptions for all parameters, the context signals indicate 0% coverage, so the description must compensate. It explains the grid size, naming pattern, and skip_empty behavior, which adds meaning beyond the schema's individual parameter descriptions.

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

  Purpose5/5

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

  The description explicitly states the tool splits a spritesheet PNG into individual frames, using the verb 'split' and the resource 'spritesheet PNG'. It distinguishes itself from sibling tools like 'pixel_export_spritesheet' which does the reverse operation, making the purpose very clear.

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

  Usage Guidelines4/5

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

  The description says 'the way to bring existing game assets in for editing or re-animation', implying when to use it. However, it does not explicitly state when not to use it or compare it to alternatives, which would make it a 5. Still, it provides good contextual guidance.

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