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

With no annotations, the description carries the full burden, and it delivers: discloses the GATE refusal condition, the dressed-frame compositing behavior (rigid rotation with DRAW_ORDER/draw_after/overhang preserved), the rigid-pivot pose model (not freehand redraw), and the 'does not finalize' trait. This is rich behavioral disclosure well beyond the minimum.

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?

Long but dense and organized with labeled sections (GATE, DRESSED FRAMES, Pose model). Almost every sentence carries new information. Minor redundancy: 'Does not finalize — call finish_frame_animation next' appears twice. For a tool this complex the length is justified.

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?

Comprehensive for a 7-param, pipeline-dependent tool: purpose, prerequisites, parameter semantics, gate conditions, pose model, dressed-frame behavior, and next step are all covered. Since an output schema exists, return-value documentation isn't needed. Only scale and name/animation_name go lightly explained, but these are self-evident or defaulted.

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

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

Schema coverage is 0%, and the description fully compensates: provides a concrete rotations example, lists all 9 joints, explains 'Angles are absolute degrees from rest', gives sign conventions ('negative hip ≈ forward, positive knee ≈ flexion'), constrains plan_id ('must match the locked plan'), and clarifies output_dir. frame_index is scoped via '0..7'. This is model compensation for an undocumented 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?

Opens with a specific verb+resource+method ('Draft one animation frame (0..7) with hierarchical joint rotations'). The pipeline context distinguishes it from siblings plan_animation (planning) and finish_frame_animation (finalizing), so an agent can tell exactly where this tool fits.

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?

Explicit when-to-use rules: requires plan_animation to have succeeded AND user OK of the user_facing_summary. Names exclusions ('Jumping straight to rotations is forbidden'), the compose_character prerequisite when a design exists, and the next step (finish_frame_animation). Also directs to get_joint_docs for rotation semantics. Nothing is left to inference.

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

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

With no annotations, the description carries the behavioral burden. It does disclose the main effect (blanking the design layer to a transparent PNG) and a secondary effect (refreshing its reference). However, it does not explain whether this is destructive to existing pixel data, what 'reference' means in the pipeline, or any ordering/constraints around the operation.

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

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

The description is a single front-loaded sentence with no filler. Every phrase contributes: the action, the target layer format, and the reference refresh. It is concise, though it sacrifices some contextual detail that other dimensions need.

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

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

For a mutating tool with four parameters, no annotations, and no parameter-level documentation in the description, this is incomplete. An agent cannot infer what 'name', 'plan_id', or 'output_dir' control, nor what 'refresh its reference' implies for the rest of the outfit pipeline. The output schema may describe returns, but the input behavior is under-specified.

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

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

Schema description coverage is 0%, and the description does not compensate. It never explains the required 'name' and 'slot' parameters, nor the optional 'plan_id' and 'output_dir'. The word 'slot' appears but merely echoes the schema property name, adding no semantic value beyond the JSON structure.

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 clear action ('Blank') applied to a specific resource ('one slot's design layer') and gives a concrete outcome ('transparent PNG' and refresh reference). It does not explicitly name sibling tools, but the reference to a slot's design layer distinguishes it from generic tools like clear_rect or clear_output_root.

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

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

There is no guidance on when to use this tool versus alternatives such as clear_rect, prepare_outfit_slot_reference, or fill_parts_on_slot. The description implies a use case—clearing a slot before reworking it—but does not state conditions, prerequisites, or exclusion criteria.

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

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

With no annotations, the description carries the behavioral disclosure burden. It clearly communicates the state-changing effect (clearing the override and restoring the default), but does not mention idempotency, whether it affects the persistence of other settings, or what happens when no override is set. This is adequate for a simple reset operation but not fully transparent.

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

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

The description is a single, well-structured sentence that front-loads the primary action and immediately clarifies the effect. Every word earns its place; there is no redundancy or irrelevant detail.

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

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

For a simple, parameterless reset tool with an output schema, the description covers the essential behavior: what is cleared and what the resulting state is. It does not address edge cases like clearing when no override exists, and it does not explicitly position itself as the inverse of set_output_root, but these are minor gaps given the tool's simplicity.

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

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

The tool has zero parameters and schema description coverage is 100%, so the schema fully captures parameter semantics. The description adds no parameter-level detail, but the baseline of 4 for a zero-parameter tool is appropriate since no compensation is needed.

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 a specific verb ('Clear') and resource ('session output override'), and states the outcome ('restore <cwd>/output default'), making the tool's function unambiguous. It clearly differentiates from siblings like set_output_root and get_output_root by describing the reset operation.

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 usage context is implied: this tool is for undoing a previous output-root override and returning to the default. However, it does not explicitly name alternatives or state when not to use it, and the sibling contrast with set_output_root is left implicit.

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

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

With no annotations provided, the description must fully disclose behavior. It states that the tool erases transparently and restricts to the design layer, which is useful, but it does not disclose side effects such as whether existing pixels are lost irreversibly, how the 'scale' parameter affects bounding box interpretation, or interactions with layers. The description adds layer-scoping detail but leaves behavioral gaps.

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

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

The description is a single, concise sentence that front-loads the key constraint (design layer only, never body). There is no redundancy or filler. It earns its place by clearly communicating the most important behavioral constraint in minimal words.

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's complexity (9 parameters, 0% schema coverage, no annotations), the description is not sufficiently complete. It lacks any explanation of return values despite an output schema existing, does not explain parameters, and does not mention edge cases like out-of-bounds rectangles or the role of 'scale'. The description covers the core purpose but leaves the agent under-informed for correct invocation.

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

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

Schema description coverage is 0% and the description adds no parameter-specific meaning beyond mentioning 'rectangle'. With 9 parameters, including optional ones like 'plan_id' and 'output_dir' that are not self-explanatory, the description fails to guide the agent on what each parameter means. It does not compensate for the schema's lack of comments, leaving the agent to infer from names alone.

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 action (erase) and target (a rectangle on the design layer only, never body). It distinguishes from similar drawing tools like fill_rect and stroke_rect by specifying transparency and layer restriction. However, it does not explicitly name sibling tools that might be alternatives for erasing on other layers.

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 erasing on the design layer but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives such as clear_outfit_slot for clearing entire slots, nor does it state conditions that should lead to choosing another tool. The layer restriction ('never body') gives some context but not enough 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 no annotations present, the description fully discloses side effects and behavior: it writes design/compose_preview.png, inserts design layers full after draw_after with no clip-to-body, and notes that build_frame_animation refuses without this compose preview and rigid-rotates design PNGs. This goes well beyond a minimal 'compiles the character' statement.

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 definition is dense but front-loaded with the core formula and required ordering, then uses labeled gates to organize the workflow. Nearly every sentence carries a distinct piece of information, though the repeated emphasis on animation ordering is slightly redundant.

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 pipeline complexity and absence of annotations, the description covers prerequisites, side effects, gates, and downstream failure modes exceptionally well. It stops short of full completeness only because the parameter semantics are left entirely to the schema, which itself has no 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?

Schema description coverage is 0% and the description does not define any of the four parameters (name, scale, output_dir, include_skipped). The tool reference to the preview file does not clarify parameter behavior, so the agent must guess what include_skipped or output_dir actually control.

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 concrete specification: 'Compose dressed rest = base body + design layers' and labels it 'required before anim,' giving an agent a clear verb, resource, and pipeline position. This distinguishes it from sibling generation/animation tools such as generate_character and plan_animation.

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

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

It provides an explicit GATE: 'call after painting layers... BEFORE plan_animation,' plus a soft-gate caveat for missing shading plans and a HUMAN EDIT GATE after return. This directly tells the agent when to invoke the tool and what to do next.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does state a side effect (drawing on design/layers/<slot>.png) and that a reference preview is refreshed, but it does not disclose whether drawing overwrites or overlays pixels, what coordinate system is used, whether color/thickness/scale affect behavior, or if the operation is reversible.

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

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

The description is a single compact sentence with no fluff and the action is front-loaded. However, it is under-sized relative to a tool with 11 parameters and several sibling drawing tools, so it is concise at the cost of substance.

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, no annotations, and many similar siblings, this description is far from complete. It does not explain parameter meaning, expected coordinate/color formats, when to use it, or what the output schema contains, leaving an agent to guess.

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

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

Schema description coverage is 0%, so the description must explain the 11 parameters, but it only implies slot through the file path. x0/y0/x1/y1, color, scale, thickness, plan_id, and output_dir receive no semantic explanation beyond their titles.

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

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

The description names a specific action ('Draw a line') and identifies the target resource as a per-slot PNG in design/layers, with a follow-on preview refresh. It is clear about what the tool does, though it does not explicitly distinguish itself from sibling geometry tools like stroke_rect or fill_ellipse.

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

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

No guidance is given for when to call this tool instead of the many other drawing tools (fill_rect, stroke_rect, paint_pixels, etc.), nor any context about prerequisites or coordinate assumptions. The only hint is the tool's name and the bare action in the description.

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

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

With no annotations, the description carries the full burden. It discloses that the tool writes two files (contact sheet and preview GIF) to a specific path, that the GIF scale is locked to 90×128, and that it runs automatically under certain conditions. It does not detail error handling or side effects beyond file writes, but the provided context is substantial.

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 logically organized: purpose first, then requirements, outputs, a constraint, and an auto-run note. It is not overly verbose, and each sentence adds necessary information. The structure is clear and front-loaded with the primary function.

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?

It covers prerequisites, outputs, and a critical constraint, which is good. However, it leaves parameter semantics for three of four parameters unexplained, and does not mention error conditions or whether files are overwritten (implied by 'rebuild'). An output schema exists, which may cover return values, but the description alone is not fully complete for all aspects of 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 0%, so the description must compensate. It implicitly explains animation_name via the output filenames, but provides no meaning for name, output_dir, or duration_ms. The description does not mention how output_dir interacts with the default path, leaving agents to guess.

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 rebuilds a horizontal contact sheet and looping preview GIF for an animation, which is specific and distinct. It mentions prerequisites and outputs, but does not explicitly contrast with sibling tools, though the auto-run note hints at a relationship with finish_frame_animation.

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

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

It provides clear usage context: requires finished frame_00.png through frame_07.png, and explicitly warns not to invent a per-clip scale. It also notes that the tool runs automatically when finish_frame_animation locks frame 7, which implies when manual invocation may be unnecessary, though it doesn't name alternative tools.

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

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

With no annotations, the description carries the behavioral burden, and it does communicate the core effect: a filled ellipse is drawn in the design layer. However, it does not disclose whether existing pixels are overwritten, how color/scale are applied, or what other side effects occur.

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

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

A single front-loaded sentence with no filler. Every word contributes the core shape, geometry, and target layer.

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?

Despite having an output schema, the tool has 10 parameters, 7 required, and no schema descriptions or annotations. The description only covers geometry and location, leaving most parameters, preconditions, and side effects undocumented.

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

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

Schema description coverage is 0%, and the description only clarifies x, y, width, and height via 'bounded by'. Required parameters name, slot, and color, plus optional scale, plan_id, and output_dir, are left unexplained.

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

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

The description uses a specific verb ('Fill') and resource ('an ellipse bounded by (x,y,width,height)') and names the target ('design layer'). This clearly differentiates it from sibling tools like fill_rect, stroke_rect, and draw_line.

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 implies the tool is for drawing a filled ellipse onto the design layer, but it does not explicitly state when not to use it or mention alternatives such as fill_rect for rectangles. Usage is inferred rather than directly guided.

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?

Since no annotations are provided, the description carries the full burden. It discloses that the base body is never modified, that it performs a 'flat local fill only' (no shading), and that it uses the character part map. It also forbids external image generators. These are non-obvious behavioral traits beyond the tool's basic function, making it highly transparent.

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 longer than average but every section adds value: it starts with the core purpose, then lists parameter semantics in bullet format, then gives usage guidance and restrictions. The structure is front-loaded and scannable. It could be slightly tighter, but the detail is justified given the tool's complexity.

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?

Despite 9 parameters and no annotations, the description covers the essential operational context: default behavior, parameter formats, sibling alternatives, shading caveats, and prohibited actions. An output schema is present, so return values are covered. An agent has enough information to invoke this tool correctly and safely in the wider pipeline.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the key parameters: parts (with naming examples), part_ids (as integer ids from get_part_ids), color (hex or RGBA array), and part_colors (object with overrides). It also explains Omit behavior. However, it leaves scale, plan_id, and output_dir undocumented, though these are likely secondary. The main parameters are covered well.

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-resource pair: 'Fill body-part silhouettes onto design/layers/<layer>.png'. It explicitly states the tool replaces Shell/PIL scripts and names the mechanism (character part map), making its purpose unmistakable and distinct from sibling tools like fill_rect or paint_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 provides explicit when-to-use guidance: it specifies that for shading one should 'use plan_shading + paint_* after outfit paint' and for adding details use 'fill_rect / draw_line / paint_pixels'. It also explains the default behavior when parts/part_ids are omitted and flags forbidden actions (Shell scripts). This gives clear direction against alternatives.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does reveal a side effect ('refresh body-under ref') and a clipping/boundary behavior ('Overhang past body OK'), but it does not state whether existing pixels are overwritten, whether the operation is reversible, or what coordinate system x/y use.

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, information-dense lines: the core action and side effect, the color format, and the usage preference. No filler 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?

The description covers the core purpose, target layer, color, and preferred use case, which makes the tool callable. However, with 10 parameters and no annotations, important details like scale's effect, coordinate origin, and output handling remain implicit. The output schema covers return values, so omitting them is acceptable.

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

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

Schema description coverage is 0% across 10 parameters. The description usefully clarifies color syntax ('hex / [r,g,b,a] / transparent') and the slot path, but leaves scale, plan_id, output_dir, and coordinate semantics undocumented.

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

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

The description names a specific operation and resource: 'Fill a rectangle on design/layers/<slot>.png', and adds the side effect 'refresh body-under ref.' It clearly distinguishes itself from ellipse/stroke/flood-fill siblings by specifying the shape and target.

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?

'Prefer this or paint_from_commands for blocky pixel-art clothing shapes' provides explicit when-to-use guidance and names an alternative. It also adds boundary context with 'Overhang past body OK,' though it doesn't state when to prefer stroke_rect or fill_ellipse instead.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the exact artifacts written (frame_XX.png, poses/frame_XX.json), additional files created when frame 7 finishes, and refusal behavior for invalid plans. No contradiction exists 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?

Four dense sentences, each earning its place: purpose, gate, writes, and workflow sequence. The gate is front-loaded and the structure makes the conditions easy to parse.

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

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

The description covers the workflow, prerequisites, side-effect files, and animation-name conventions, which is strong for a multi-step file-writing tool. It falls just short of complete because a required parameter (`name`) is still semantically undefined and `output_dir` is not contextualized.

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?

It adds real meaning for animation_name (directory/name prefix), frame_index (the XX in file paths, 0..7), and plan_id (must match the stored plan). However, the required `name` parameter is never explained, and `output_dir` is also left undefined, so with 0% schema coverage the description only partially compensates.

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 action ('lock the current draft frame as final') and target location ('under anims/<animation_name>/'), then details the concrete writes. It also distinguishes finish from its sibling build_frame_animation by framing it as the second half of a build→finish workflow.

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

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

Gives explicit gate conditions: refuses without a valid plan.json, requires plan_animation to have run and the summary to have been shown, and requires optional plan_id to match. The closing 'repeat build→finish for frames 0..7' tells the agent exactly when in the pipeline to call this tool.

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

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

With no annotations, the description carries the full burden for behavior. It mentions 'Large fills return a warning field' and that the tool is 'Optional,' but it does not disclose side effects such as overwriting existing pixels, permission requirements, or rate limits. Some useful behavioral context is added, but significant gaps remain.

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 reasonably concise, with the core purpose front-loaded in the first sentence. The usage warning is valuable and earns its place, though the standalone 'Optional.' adds little information and could be integrated elsewhere.

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

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

Given 8 parameters, 0% schema coverage, and no annotations, the description is insufficiently complete. It does not define the purpose of most parameters nor explain when flood_fill should be used (only when it should not be used). The presence of an output schema helps with return values, but the missing parameter semantics and usage context create a significant completeness gap.

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

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

Schema description coverage is 0%, so the description must compensate, but it only references (x,y) as the seed point and does not explain name, slot, color, scale, plan_id, or output_dir. The meaning of most parameters remains undocumented, leaving agents to guess from parameter names alone.

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

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

The description states a specific verb and resource: flood-fill connected pixels on the design layer from (x,y). It clearly differentiates from siblings by advising against flooding the entire body silhouette and pointing to fill_rect / paint_pixels / paint_from_commands for shapes, making the tool's distinct role evident.

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 explicitly warns against using flood_fill as the sole outfit designer and names alternative tools (fill_rect, paint_pixels, paint_from_commands) for shape creation. This gives agents clear when-not-to-use guidance and directs them to the appropriate alternatives, leaving little 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?

No annotations are present, so the description carries the burden. It discloses the input source, output destination, and that output includes separate layers and composed previews. However, it does not say whether outputs are overwritten, what scale does to the result, or what happens when masks are missing.

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 import behavior and routing note are concise, but the opening sentence 'Author shared naked side-view idle as full separate layers + composed previews' is awkward and largely redundant with the clearer second sentence. Structure can be tightened by removing or rewriting it.

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 an output schema, return values are covered, and the source/destination and sibling routing are specified. The main completeness gap is scale semantics and any prerequisite about the masks, which prevents fully informed invocation.

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

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

Schema description coverage is 0%, so the description must explain the parameters. It connects output_dir to the output path, but it never explains scale or its default effect, leaving one of only two parameters semantically undocumented.

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 action and resource: imports user-authored 90x128 masks from spritemcp/base/ into output_dir/base_idle_90x128/. It also differentiates itself from generate_character by saying to prefer that tool for named characters.

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 tells the agent to prefer generate_character for named chars, and the 'imports user-authored... masks' phrasing implies this tool is for base idle generation from those masks. This is clear routing guidance relative to the relevant sibling.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It clearly states the side effect: 'Writes <output_root>/characters/<name>/base/' and lists the written artifacts. It also explains the output_dir override behavior relative to set_output_root. It does not mention overwrite or idempotency, but it is reasonably transparent for a creation 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 description is compact and front-loaded. Each sentence earns its place: purpose, shared-skeleton constraint, output location, optional override, and required ordering. There is 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?

The description covers the core workflow, output path, and ordering, and an output schema exists so return-value details are not needed. However, with 0% schema coverage and three parameters, a key parameter (`scale`) remains undocumented, leaving a real gap in the complete calling contract.

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

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

Schema description coverage is 0%, so the description must explain parameters, but it only explains output_dir. The required `name` parameter is implied via the output path, and `scale` is completely unexplained beyond its default value. An agent cannot know what `scale` controls or how it affects output.

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

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

The description opens with a specific verb and resource: 'Copy the SHARED naked side-view armature into a named character folder.' It also differentiates from siblings like generate_base_idle and generate_pivots by stressing that all characters share the same authored 90x128 base idle and pivots and that agents should not invent a per-style skeleton.

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 an explicit sequencing cue: 'Call once before plan_outfit / animation.' It also warns against inventing a per-style skeleton, which implicitly tells the agent not to use per-character skeleton generation. It could be stronger with an explicit named alternative, but the usage context is clear.

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

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

With no annotations, the description carries the transparency burden, and it does well: it discloses the plan_outfit requirement, the no-clipping behavior, and the fact that this tool does not perform painting but imports or re-syncs. It could add more about overwrite behavior or failure cases, but the key behavioral traits are covered.

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, front-loaded with the main purpose, and every sentence earns its place: optional role, preferred alternative, concrete usage, limitation, and gate/warning. The three short paragraphs are easy 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?

The description covers the tool's role, alternatives, gate, and a key behavioral limitation, which is good for contextual understanding. However, it leaves several parameters undefined and uses jargon like 'body-under ref' without elaboration, so an agent may still be uncertain about required inputs and their exact meaning.

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

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

Schema description coverage is 0%, so the description must compensate for the six parameters. It explicitly explains design_image_path (RGBA PNG input), and plan_outfit is mentioned as a gate, but it leaves name, slot, scale, plan_id, and output_dir mostly unexplained. Only the slot shows up implicitly in layers/<slot>.png.

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+resource: import/finalize a design layer and refresh body-under refs. It clearly distinguishes itself from the preferred MCP paint tools by positioning itself as the optional import/re-sync path rather than a generation or painting 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 explicitly names the preferred alternatives (paint_pixels, fill_rect, paint_from_commands), states when to use this tool instead (importing an existing RGBA PNG or re-syncing refs), and gives a hard gate (requires plan_outfit). It also tells the agent what not to do: never use Shell/PIL or GenerateImage for the layer.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only says 'compute,' implying a read-like operation, but it doesn't mention whether it mutates the base map, requires prior generation, or has side effects. The shared base idle map is mentioned but its state or prerequisites are not explained.

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 with no filler. The purpose is front-loaded, and the routing advice is succinct. It earns a high score for economy of expression.

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

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

The tool has an output schema, so return values are covered, but the description omits parameter explanations, behavioral side effects, and any prerequisites (e.g., how the 'shared base idle map' is created). For a tool with two optional parameters, this is insufficient for an agent to call it correctly without external knowledge.

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

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

Schema description coverage is 0%, and the description provides zero information about 'scale' or 'output_dir'. The agent cannot infer what values to pass or what effects they have, leaving a critical gap for correct invocation.

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 ('compute') and a clear resource ('articulation pivots on the shared base idle map'). It also names a sibling tool (generate_character) for a distinct scenario, making the purpose unambiguous and differentiating it from alternatives.

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 explicitly advises 'Prefer generate_character for named chars,' which tells the agent when NOT to use this tool. However, it doesn't fully spell out when to use this tool (e.g., for unnamed characters or custom pivots), but the guidance is clear enough for most cases.

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

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

With no annotations, the description carries the full burden. It discloses the 'locked' nature (implying immutability), the read operation, and the error condition when plan_animation hasn't been called. It does not mention whether it has side effects, but since it's a read of a locked file, that is implicitly safe. It also hints at return values (plan_id, user_facing_summary) without detailing the format.

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

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

The description is extremely concise—two sentences—front-loading the core purpose and immediately adding the relevant usage condition and error case. No wasted words; every sentence 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?

The tool has an output schema, which likely covers the return format, so that is not a gap. The description explains the error condition and the intended timing. However, it omits parameter explanations (as noted), which is a significant missing piece for an agent to invoke it correctly. Given the presence of an output schema and the read-only nature, it is not severely incomplete, but the parameter gap reduces completeness.

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

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

Schema description coverage is 0%, so the description must compensate by explaining parameters. It fails to do so: it never explains what 'name', 'animation_name', or 'output_dir' mean. The mention of plan_id and user_facing_summary gives partial context but does not map them to any parameter. An agent would be left guessing that 'name' is likely the character name and 'animation_name' the specific animation, but this is not explicit.

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 action ('Read the locked plan.json') and the resource it operates on (a character animation plan). It also distinguishes itself by mentioning the use case relative to build_frame_animation and the error condition if plan_animation was never called, making its purpose 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 explicitly says to use it before build_frame_animation when you need the plan_id or to re-show user_facing_summary, providing a specific when-to-use condition. It also implies an ordering dependency ('Errors if plan_animation was never called'). However, it does not mention alternative tools for other plan types, but within the animation workflow this is sufficiently clear.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It explains default resolution from cwd, optional env seeding, and redirect mechanisms, which is valuable context beyond the tool name. It does not explicitly state that the tool is read-only, but the getter name and content make that inferable.

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 four short sentences with no filler. The first sentence summarizes what is returned, and the following sentences add concrete path and redirection details that an agent needs.

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 no-parameter getter with an output schema, the description covers the default root, env override, redirect options, and subdirectory layout. It does not fully define 'style ref' or enumerate all common subdirs, but the information provided is sufficient for correct use.

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

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

The tool has zero parameters and 100% schema coverage, so there are no parameter semantics to document. The description appropriately focuses on behavior and return contents rather than 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 identifies the resource as the active output root, style ref, and common subdirs, and the name confirms it returns default path information. It is distinguishable from get_output_root because it covers more than just the root, though it does not explicitly contrast itself with that sibling.

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 explains when the default applies and how to redirect output via set_output_root or output_dir, which gives useful context. However, it does not explicitly state when to choose this tool over get_output_root or set_output_root, leaving some inference to the agent.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does convey the core output (a fixed ordering for side-view composition), which is useful behavioral information. However, it does not state that the tool is read-only, mention side effects, or clarify whether the order depends on current state. Since the description communicates the primary behavior but lacks explicit safety or state details, a 3 is appropriate.

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

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

The description is a single concise phrase that front-loads the essential information (the specific draw order). Every word contributes meaning, with no redundancy or extraneous detail.

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 is a simple 0-parameter query with an output schema, the description adequately conveys the returned content. However, it lacks usage context, such as when this order is relevant in the composition pipeline or how it relates to other tools, which slightly reduces completeness from an agent's operational perspective.

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

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

The tool has zero parameters and the schema description coverage is 100%, so there is nothing for the description to add about parameters. Per calibration, 0 params warrant a baseline of 4, and the description does not need to compensate for any parameter documentation 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 clearly identifies the tool as providing the side-view draw order and lists the specific sequence (far limbs, torso/head, near legs, near arms). It uses a specific resource and scope, though it doesn't explicitly name a sibling alternative, making it slightly less distinct than a fully differentiated definition.

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

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

No guidance is given about when to use this tool versus alternatives like compose_character or get_outfit_plan. The description only states what the order is, not the context or prerequisites for calling it, leaving the agent to infer when it applies.

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

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

With no annotations, the description carries the behavioral disclosure burden. It discloses the constant result and index bounds, which is valuable. It does not explicitly state that the tool is side-effect-free, but the 'get' prefix and query-oriented wording make this a minor gap.

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

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

The entire description is one tight sentence that leads with the core result and adds the precise constant and range. Every element contributes useful information with no waste.

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 getter with an output schema present, the description is complete. It gives the value, the fact that it is constant, and the valid index range, so an agent can call and interpret the result 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?

The tool has zero parameters, so there is no parameter semantics burden. The description's mention of indices 0..7 is relevant to the returned value rather than parameters, and the baseline for zero-parameter tools applies.

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

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

The description states exactly what the tool returns: the number of frames per character animation. It also adds the concrete value 8 and the valid index range 0..7, making it unambiguous and distinct from other 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 phrase 'per character animation' gives clear context that this is the tool to consult when frame-count information is needed. No sibling tool appears to duplicate this responsibility, and no explicit exclusions are necessary.

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

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

No annotations exist, so the description carries the full behavioral burden. It does not confirm that the call is read-only, describe side effects (even the absence of them), or mention ordering or scope; it only lists output fields. 'get' in the tool name hints at safety, but the description does not.

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

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

The description is extremely compact and contains no filler; every word names a meaningful piece of data. It is slightly fragile because it is a subject-less fragment, but it earns its length.

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 read with an output schema, the field list is useful and return values are covered by the schema. However, the description does not state what set of joints it covers, when to use it, or how it differs from get_joints, leaving some inference to the agent.

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

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

The tool has zero parameters, so there is nothing for the description to add about arguments. Baseline 4 applies because parameter semantics are not applicable.

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

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

The description names a specific resource (joint docs) and lists the fields it exposes (name, parent, child, and rotated parts). It is clear enough once combined with the 'get_' verb in the tool name, but it never explicitly states 'returns' or contrasts with sibling get_joints, so it misses the top score.

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

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

There is no guidance about when to call this tool rather than get_joints or any other sibling. The description is a bare field list with no exclusions, prerequisites, or decision context.

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

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

No annotations are present, so the description carries the behavioral disclosure burden. The 'get' prefix and the spec-oriented wording imply a read-only retrieval, but the description does not explicitly state that there are no side effects or mention any other behavioral constraints.

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

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

The description is a single front-loaded phrase with no wasted words. It communicates the core resource and key attributes compactly.

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 getter with an output schema, the description is technically sufficient: an agent can invoke the tool without arguments and understand the general shape of the result. However, it does not provide enough surrounding context to distinguish when this tool should be chosen over related joint or part tools.

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

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

The tool has zero parameters, so the baseline is 4 and the description is not required to explain parameter semantics. It still adds useful context by naming the output fields (name, parent part, child part), which reinforces what the returned specs contain.

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 resource (joints) and the content (hierarchical specs with name, parent part, child part), so the purpose is understandable. It does not explicitly differentiate get_joints from siblings like get_joint_docs or get_part_ids, so it stops short of full sibling differentiation.

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

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

There is no guidance on when to use this tool versus alternatives such as get_joint_docs or get_part_ids. No usage context, prerequisites, or exclusions are provided.

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

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

With no annotations provided, the description carries the full burden. It discloses the return format, response size capping, the opaque_only escape hatch, and the fact that the tool is non-mutating. This is strong behavioral disclosure, though it does not explain the exact cap or error 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 tight sentences. The purpose is front-loaded, followed by return format, size limits, and non-mutating behavior. Every sentence earns its place and there is no filler.

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

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

For a read-only tool with an output schema, the description covers the essentials: what is read, what is returned, and that it is safe. However, with no annotations and 0% schema description coverage, it leaves several parameters unexplained, so an agent may not confidently know how to fill name, plan_id, or output_dir.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that 'slot' appears in the file path and that 'opaque_only' reduces response size, but it leaves most of the 9 parameters undefined, including the required 'name' and the optional 'plan_id' and 'output_dir'. The description adds some meaning but does not adequately document the parameter set.

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 specifies a verb ('sample'), a resource ('design/layers/<slot>.png'), and a region-based scope. It also signals that this is for reading pixels before modification, which distinguishes it from sibling mutation tools like set_pixels, paint_pixels, and flood_fill.

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

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

The phrase 'for read-modify workflows' gives clear context for when this tool is appropriate, and 'Does not modify the layer' rules out destructive misunderstandings. It does not explicitly name alternative tools, but the context is sufficient for an agent to infer when 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Read' clearly signals a read-only operation, and 'locked' hints at an important constraint, but the description does not explain what 'locked' means, what happens if the plan is missing, or how the output directory is resolved. It is adequate for a simple getter but lacks deeper behavioral context.

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

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

The description is a single short sentence that front-loads the action and resource. There is no filler or redundant restatement of the tool name. Every word earns its place, even if the word 'locked' introduces some ambiguity.

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

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

The tool is simple and has an output schema, so the return shape may be covered elsewhere, but the description leaves out important operational context: what `output_dir` does, when this tool is appropriate, and what 'locked' means. Given the low parameter coverage and absent annotations, the description is not complete enough for an agent to reliably use all options.

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

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

Schema description coverage is 0%, so the description must compensate, but it only adds 'for a character outfit,' implying that the `name` parameter identifies a character. The `output_dir` parameter is not explained at all, including when it should be set or how it affects the lookup. This is a meaningful gap for an optional parameter with no schema description.

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 ('Read') and specific resource ('the locked design/plan.json'), further scoped by 'for a character outfit.' This clearly distinguishes it from siblings like plan_outfit or get_animation_plan, even without naming them. The only minor ambiguity is the word 'locked,' but it does not obscure the core purpose.

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

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

There is no guidance about when to use this tool versus alternatives such as plan_outfit or get_animation_plan. The description also does not mention prerequisites, such as whether the plan must already exist or whether this should be called after planning. The intended usage must be inferred from the tool name and siblings.

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

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

With no annotations provided, the description carries the full burden and does well by specifying that the tool returns the current effective value and that this value may come from a session override or the default. 'Return' also strongly implies a non-mutating operation, which is appropriate for the 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 description is a single, front-loaded sentence with no filler. Every phrase adds value: 'absolute', 'currently in effect', and '(session or default)' all clarify the exact behavior.

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 parameterless getter with an output schema, the description is complete. It identifies what is returned, the scope of that value, and the read-only nature of the operation, leaving no ambiguity for an agent to select or invoke it.

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

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

The tool takes zero parameters and the schema already reflects that with 100% coverage. The baseline of 4 applies because there are no parameters for the description to clarify.

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 the specific verb 'Return' with a clearly defined resource: the absolute output root currently in effect, including the session-or-default distinction. This clearly identifies it as the getter counterpart to the sibling tools set_output_root and clear_output_root.

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 makes clear this is the tool to call when you need the current effective output root, and its 'Return' semantics distinguish it from mutation siblings like set_output_root and clear_output_root. It does not explicitly name alternatives, but the context is unambiguous for a no-parameter getter.

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

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

With no annotations provided, the description must carry the full behavioral disclosure. It states the map is 'stable' but does not explicitly indicate that this is a read-only operation with no side effects. Since it is a getter, this is likely safe, but the description does not state it, leaving room for ambiguity about potential state changes or permissions.

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

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

The description is a single, tightly worded sentence that conveys the essential purpose without any filler. It is appropriately front-loaded, with the core idea of a stable mapping immediately 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?

For a tool with no parameters and an existing output schema, the description provides sufficient context by specifying the scope ('base idle template'). It does not enumerate the parts or the id format, but these are likely captured in the output schema. The description is complete enough for an agent to understand what to expect.

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

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

The tool has zero parameters, so schema coverage is trivially complete. The description adds value by explaining the output: a mapping from part names to integer ids. It does not need to describe parameter semantics since there are none, and the baseline for 0-parameter tools is 4.

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 returns a stable mapping from part names to integer ids for the base idle template. It identifies the resource and the specific nature of the output, which distinguishes it from generation or planning tools among the siblings. However, it lacks an explicit verb like 'retrieves' or 'returns', though the intent 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?

There is no guidance on when to use this tool versus alternatives. While the name and description imply it is a lookup for part ids, it does not mention contexts where it should or should not be used, nor does it point to any sibling for alternative scenarios. An agent would have to infer usage from the name alone.

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

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

No annotations exist, so the description carries the disclosure burden. It discloses output style ('one-step-darker,' 'No soft gradients') and sequencing, but it doesn't state whether the tool reads from current context or mutates anything; for a getter the risk is low, but the input source is unstated.

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 three short lines, front-loads the core formula, and uses a concrete example rather than prose. Every sentence contributes either purpose, usage, or an exclusion, 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?

Given zero parameters and an output schema, the description supplies the key workflow context: after plan_shading and before paint_*. The only notable gap is that the source of the 'local flat color' input is left implicit, but the workflow placement makes it reasonably inferable.

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 input schema has zero parameters, so there are no parameter names or descriptions to augment; the 0-param baseline is 4. The description's 'Local flat color →' hints at implicit state-based input, but no parameter-level semantics are needed.

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 concrete transformation ('Local flat color → one-step-darker shadow roles') and names the domain ('style-lock shading'), so an agent can infer it returns shade roles and hex values. It is distinguishable from shading-plan getters by its reference to paint_* and 'after plan_shading,' though it does not explicitly say 'returns a 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?

It explicitly tells the agent when to consume the output: 'Use these roles / hex values with paint_* after plan_shading.' The 'No soft gradients' line adds an exclusion, but no alternative tool is named for cases where this palette is unsuitable.

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

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

No annotations are provided, so the description must carry the behavioral disclosure burden. It communicates read-only intent and a 'locked' precondition, but it does not say what happens if the file does not exist, whether the call can fail, or whether output_dir changes 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 a single front-loaded sentence with no filler. Every word 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?

The description is too sparse for an agent to safely decide when to call it and how to interpret the parameters. It does not explain the 'locked' precondition, the role of output_dir, or how this read relates to the surrounding shading-plan workflow, even though an output schema exists.

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

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

Schema description coverage is 0%, and the description only weakly hints that 'name' refers to a character. It never explains what output_dir controls, leaving that parameter semantically undocumented beyond its schema type and default.

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 a concrete read operation on a named artifact ('shading_plan.json'), scoped to a character. It is distinct from siblings like plan_shading or get_outfit_plan because it names the locked design file directly.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as plan_shading or get_outfit_plan. The word 'locked' implies a precondition, but no when-to-use or when-not-to-use context is provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the call is read-only, what it returns, or whether invoking it has any side effects; the word 'Permanent' hints at persistence but leaves the actual behavior opaque.

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

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

The description is a single concise sentence with no filler, and the core concept is front-loaded. However, it is cryptic and prioritizes brevity over clarity, which slightly reduces its value as a navigation aid.

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

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

With no parameters and an output schema present, the tool is trivial to invoke and return-value documentation is not required. Still, the description leaves gaps about the tool's precise purpose and when it should be selected, making it minimally complete but not fully contextualized among related tools.

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

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

The tool has zero parameters and the input schema is empty, so the baseline of 4 applies. The description adds no parameter-level detail, but none is required for invocation.

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 'Permanent view + layering rules (side profile; far behind, near in front)' identifies the resource and explains the concept, and the tool name supplies the 'get' verb. However, it reads as a definition rather than an explicit statement of the operation, such as 'Retrieves the current view lock', and it does not differentiate the tool from siblings like get_draw_order or get_layer_pixels.

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

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

There is no guidance on when to use this tool versus alternatives. The description does not mention any context, preconditions, or exclusions, nor does it reference the related layering and draw-order tools that an agent might need to distinguish it from.

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

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

Without annotations, the description carries the full behavioral burden. It makes the basic behavior clear through 'List' and lists the returned information, and it adds a useful invariant: `allow_overhang` is always true. However, it does not disclose whether `output_dir` causes any file writes or side effects, which is relevant given that parameter 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 appropriately sized and front-loaded. The first sentence quickly establishes the operation and output content; the second adds one useful domain invariant. No filler or redundant phrases are 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?

Despite having an output schema, the tool's description is incomplete for safe invocation. The meaning of `name` and `output_dir` is absent, there is no usage context relative to siblings, and no guidance about side effects. The core purpose is clear, but key call-time details are 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 0%, and the description fails to explain either parameter. `name` and `output_dir` are completely undocumented, and the only mentioned term `allow_overhang` is not a schema parameter. The agent must guess what values to pass.

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 ('List') on a clear resource ('design layers') and enumerates the exact contents: 10 export names, parent/body parts, paint status, and paths. It does not explicitly differentiate itself from siblings like list_outfit_slot_specs, but the resource is distinct enough to infer.

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

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

No when-to-use guidance is provided. The description does not mention when this tool is appropriate over siblings, what `name` should be, or any preconditions. The agent must infer context from the tool name and sibling list.

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

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

With no annotations, the description carries the behavioral burden. It discloses meaningful traits: no style presets, exact layer names, pose-parent structure, body_parts underlay usage, paint targets always being the 10 layer files, and per-layer overhang allowance. This goes well beyond the tool name.

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 information-dense, with a useful lead statement followed by concrete enumeration of the layer names and key structural properties. The long name list is necessary content, and there is no filler.

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

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

For a zero-parameter list/query tool, the description covers the essential domain context: what slots are, their names, their internal structure, and constraints like overhang and paint targeting. It could be more complete by explicitly stating return shape, but an output schema exists to cover that.

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

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

The tool has zero parameters and schema coverage is 100%, so there are no parameter semantics to document. Baseline 4 is appropriate because the description focuses entirely on what the returned specs represent.

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 name says 'list outfit slot specs' and the description explains that these specs are the 10 structural design layers, explicitly naming them and noting there are no style presets. This is clear enough for an agent to know the tool is about retrieving/describing outfit slot layer structure, though it does not explicitly differentiate itself from the sibling list_outfit_layers.

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

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

There is no guidance about when to use this tool instead of related tools like list_outfit_layers, generate_outfit_slot, or prepare_outfit_slot_reference. The description only states facts about layers; it does not say when this tool is the right choice.

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

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

With no annotations provided, the description carries the behavioral burden. It discloses that this reflects the live MCP process, provides a concrete expected count, and gives diagnostic behavior for a misconfigured state. It stops short of stating the exact return shape, but the presence of an output schema reduces the need for that detail.

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 purpose is front-loaded in one crisp sentence, and the extended diagnostic note is directly relevant to the tool's intended use as a registration check. The list of expected tools is somewhat long but serves as concrete verification criteria, though it could have been slightly trimmed without losing the key examples.

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's low complexity, zero parameters, and available output schema, the description covers everything needed: what it returns, the expected baseline, the failure mode, and the recommended recovery action. Nothing essential is missing for an agent to decide when and how to invoke it.

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

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

The tool takes zero parameters, and the schema confirms this with an empty properties object. The description adds no parameter-specific confusion and correctly implies that calling it requires no arguments. This matches the zero-parameter baseline.

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 states the exact action and resource: 'Return every tool name registered on this live MCP process.' This is a specific verb+resource pair and clearly distinguishes the tool from the domain-specific sibling tools, which operate on characters, pixels, and animations rather than listing the tool catalog.

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 frames this as a cold-start check, specifies the expected tool count (45), names tools that must be present, and gives the exact failure condition ('Cursor shows ~28 tools or paint_* are missing'). It also tells the agent what to do ('restart SpriteMCP') and what NOT to do ('do not fall back to Shell/API/GenerateImage'), making the usage boundaries unambiguous.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool opens a localhost web UI, writes only to design/layers/<layer>.png and never base/, and requires a compose_character re-run after Apply. This is strong transparency, though it does not mention whether the call blocks until the user finishes or what happens with the port/browser options.

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 core purpose, then flows naturally into usage, side effects, and follow-up steps. Every sentence adds necessary information; there is no filler 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?

Given that an output schema exists and the tool is a local UI launcher, the description covers the essential workflow, side-effect scope, and path resolution. The main gap is the lack of detail on port and open_browser parameters, but these are optional and less critical to correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate for all four parameters. It only adds meaning for output_dir via 'Resolves paths via session output_root / output_dir', and vaguely relates name to 'all 10 EXPORT_LAYER_NAMES'. The port and open_browser parameters are left entirely unexplained.

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

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

The description states a specific verb ('Open'), a specific resource ('local manual pixel editor for design layers'), and labels it as a 'human edit gate', which clearly distinguishes it from programmatic pixel-editing siblings like paint_pixels and set_pixels. The first sentence alone is enough for an agent to know what this 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 gives explicit sequencing: 'Call AFTER compose_character when the user wants to edit pixels by hand' and 're-run compose_character before plan_animation'. This provides clear context for when to use the tool, though it does not explicitly name 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?

With no annotations, the description must carry the full burden. It discloses that it performs a single save and reference refresh, which is a behavioral trait. It also lists the allowed operations and a restriction. However, it doesn't describe side effects, permissions, or the nature of the mutation beyond painting. It lacks details about reversibility, overwriting, or error handling.

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

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

The description is extremely concise: three sentences, front-loaded with purpose, followed by command format, use case, and a restriction. Every sentence earns its place with no fluff.

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 complexity (6 params, complex commands array, output schema exists), the description covers the main concept but lacks essential details. It doesn't explain the command argument structure beyond the op field, nor how to specify coordinates, colors, or other attributes. It also doesn't mention how the batching works or the implication of a single save. The output schema may cover return values, but input usage is incomplete.

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

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

Schema coverage is 0%, so the description must explain parameters. It only explains the 'commands' parameter format (list of {op, ...} with allowed ops). It does not describe 'name', 'slot', 'scale', 'plan_id', or 'output_dir'. These are left entirely to the schema, which has no descriptions. This is insufficient for an agent to correctly fill all 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 states the tool's purpose: batch painting commands on one slot with a single save and reference refresh. It lists the specific operations supported, distinguishing it from individual paint tools. The phrase 'Batch paint commands' is a specific verb+resource that immediately conveys what it 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?

It provides context by saying it is 'Preferred for multi-step pixel-art' and mentions specific use cases like silhouette and belt/cross details. It also forbids external generators, guiding usage. However, it doesn't explicitly state when to use this tool instead of calling individual paint commands (e.g., for single commands), though the 'batch' nature implies that.

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

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

With no annotations, the description carries the full behavioral burden. It discloses side effects ('Writes the design layer only; refreshes refs/<slot>_ref.png') and the follow-up action of reading preview_paths. It omits failure/error behavior and permission requirements, but it is transparent about mutation and scope.

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 logically ordered: target path, item format, coordinate semantics, side effects, follow-up, and forbidden alternatives. Every sentence contributes information 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?

The description provides strong operational detail and the output schema covers return-value structure. However, given six parameters and zero schema description coverage, the unexplained required 'name' parameter and the relationship to sibling pixel tools leave an agent with non-trivial ambiguity.

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

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

Schema coverage is 0%, so the description is the only source of parameter meaning. It usefully explains the 'pixels' item structure and color formats, and implies 'slot' through the path, but it leaves the required 'name' parameter and the optional 'scale', 'plan_id', and 'output_dir' parameters unexplained.

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

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

The description states a specific verb ('Paint') and a precise target ('design/layers/<slot>.png') plus the required paint path, so the agent understands the primary action. It does not explicitly differentiate this tool from sibling pixel-editing tools like set_pixels or paint_from_commands, though the wording 'individual pixels' and 'design layer only' narrow the scope.

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: this is the designated pixel-painting path, it should be followed by reading preview_paths, and Shell/PIL and GenerateImage are explicitly forbidden alternatives. It does not explain when to choose this over closely related sibling tools such as set_pixels, fill_rect, or clear_rect.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It is quite transparent: it states that the tool validates and stores the plan, returns plan_id and user_facing_summary, and sets next_step to 'show summary, then build frames'. It also emphasizes that the agent must author the plan. It does not explicitly mention what happens on validation failure, but the essential behavior is disclosed.

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 clear opening directive and bullet points for the plan keys. It is dense but each sentence carries meaningful information. It could be slightly trimmed (e.g., the 'next_step' sentence) but overall it is appropriately concise for a tool with this complexity.

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 that an output schema exists (context signal) and the description explains the return values, plan requirements, and next steps, the tool is contextually complete. It also mentions contrast_with and differing from sibling clips, covering the input semantics for that parameter. An agent has enough information to call this tool correctly and understand the workflow.

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 input schema has 0% description coverage, so the description must compensate. It thoroughly explains the 'plan' parameter's structure (required keys like beats, silhouette_story, differs_from, weapon_or_style_notes) and indirectly references contrast_with. However, it leaves the other parameters (name, animation_name, intent, output_dir) unexplained. While some may be self-explanatory, the description does not fully mitigate the lack of schema documentation.

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 purpose: it validates and stores an animation plan, and it is required before generating frames. It distinguishes itself from sibling tools like build_frame_animation by stating that it must be called first and that joint rotations should not be attempted without it. The verb and resource are explicit.

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 provides explicit usage guidance: it is REQUIRED before any frames, and the agent must author the plan rather than reusing unrelated clips' plans. It also instructs to show the returned user_facing_summary and wait for confirmation before calling build_frame_animation. This effectively tells when to use and when not to.

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

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

With no annotations, the description carries the full burden. It discloses that it saves to characters/<name>/design/plan.json, returns plan_id and user_facing_summary, enforces overhang rules, and prohibits baking shading in later paint steps. It also clarifies that lower_* includes hands/feet for gloves/boots, which is a nuanced 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 comprehensive and well-structured with sections, but it is long. Every sentence adds value—the overhang rule, layer semantics, and forbidden actions are all necessary. It is front-loaded with the requirement and workflow, so an agent can quickly grasp the purpose. Slightly more conciseness would be ideal, but no filler exists.

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 planning tool with nested objects and no annotations, the description covers the entire workflow, parameter structure, output format, and constraints. It even notes the next steps and expected behavior. The output schema exists, so return values are not required, but the description provides enough for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It details the required plan keys (overall_look, slots with all 10 layer names) and their structure ({skip, visual_notes}). It explains the brief parameter via examples ('samurai') and the name parameter implicitly. It also covers output_dir implicitly by mentioning the save path.

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 'REQUIRED before painting clothes: lock an outfit plan from a free brief,' which is a specific verb (lock/plan) and resource (outfit plan) with clear context. It distinguishes itself from siblings by being the planning step in a defined workflow, and it states the agent authors the plan from the brief, not hardcoded styles.

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

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

The description explicitly states when to use it ('REQUIRED before painting clothes'), gives the full workflow sequence (plan_outfit → prepare_outfit_slot_reference → paint → plan_shading → shadow → compose_character), and provides exclusions ('Do NOT invent if-samurai code paths', 'FORBIDDEN: Shell/PIL scripts'). It also tells the agent to show the summary to the user before painting.

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

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

With no annotations, the description provides the full behavioral burden: it saves to design/shading_plan.json, returns plan_id and user_facing_summary, validates the plan, and requires waiting for user confirmation before painting. It also communicates style constraints that affect the plan's content ('never rewrite base; do not strip eyes').

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 each section earns its place: the mandatory order, required plan schema, style rules, and post-call behavior are all essential. Bulleted structure and front-loaded recommendation make it easy 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 complex tool with a sparse schema and no annotations, the description covers the necessary input format, behavioral contract, output, and interaction protocol. It even mentions where to find color guidance (get_shade_palette). Nothing needed to call the tool 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 0%, so the description must compensate. It does so thoroughly for the core 'plan' parameter, specifying required keys, allowed values, and an alternate structure. However, it does not explicitly explain the top-level 'name', 'brief', or 'output_dir' parameters, though these are simpler and partially inferable.

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 action ('author the plan') and resource ('shading_plan.json'), and makes clear this tool 'validates and stores' rather than paints. It also anchors its position in the pipeline ('after flat outfit paint', before painting shadows), which distinguishes it from sibling tools like paint_pixels, compose_character, and get_shading_plan.

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 explicitly says when to use it ('RECOMMENDED after flat outfit paint'), when it is not strictly required ('Soft gate: compose_character does NOT refuse without shading'), and the expected sequence ('plan_shading → paint shadows → compose'). It also instructs the agent to wait for user OK before using paint_*, leaving no ambiguity about follow-up steps.

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

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

With no annotations, the description carries the burden, and it does disclose the write side effect, the underlay being alignment/proportions only and not a clip mask, and the transparent paint target. It does not, however, state overwrite behavior, prerequisites, failure modes, or whether scale/output_dir change the output path.

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

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

The description is dense but efficient, leading with the mandatory use, then output path, key semantics, an example, and the allowed paint tools. Each sentence adds information, though the mix of conceptual semantics and workflow instructions could be better separated.

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?

It is complete enough to make the basic required call with name and slot and to understand the generated artifact, and an output schema exists for return values. It is incomplete for optional parameters (scale, plan_id, output_dir) and does not explain how the reference integrates with plan_outfit or generate_outfit_slot.

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

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

Schema description coverage is 0%, so the description must compensate, but it only defines 'slot' (one of the 10 export layer names) and implicitly shows 'name' in an example. scale, plan_id, and output_dir are left undefined.

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

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

The description states a concrete outcome: it writes design/refs/<layer>_ref.png as a mandatory preparation step before painting, with body-part underlay and design layer semantics. It distinguishes the tool from paint/fill siblings by framing it as the reference-preparation step and naming later paint 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?

It explicitly says 'MANDATORY before/during paint' and prescribes the follow-up workflow using fill_parts_on_slot, fill_rect, draw_line, paint_pixels, and paint_from_commands. It also gives an exclusion ('never Shell/PIL or GenerateImage'), though it does not contrast with sibling generate_outfit_slot or plan-related alternatives.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says it will 'paint' a pattern; it does not disclose side effects, whether files are written, whether existing output is overwritten, or what happens when output_dir is null.

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

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

A single sentence with no filler. The core action, resource, and destination are front-loaded and compactly expressed.

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

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

The tool is simple, but with no annotations and no parameter details, the description leaves an agent uncertain about default behavior and side effects. It is too terse to be fully actionable in isolation.

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 0% description coverage on its only parameter, output_dir. The description does hint that output_dir is the base location by saying 'under output_dir/demo/', but it does not explain the null default, path semantics, or relationship to the output root.

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

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

The description names a specific action ('Paint'), a concrete resource ('tiny palette test pattern'), and a target location ('under output_dir/demo/'). It is clear what the tool does, though it does not explicitly distinguish itself from sibling paint_* tools beyond the 'demo test pattern' framing.

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

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

The description gives no guidance about when to run the demo versus using other tools, nor does it mention any prerequisites or alternatives. The agent must infer that this is a test/demo utility.

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

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

No annotations exist, so the description carries full burden. It discloses resolution to absolute path, directory creation, persistence, non-movement of existing files, redirect of new writes only, per-call override, and default when unset. It does not mention error handling or permission requirements, but the described behaviors are thorough for a setter.

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 yet information-dense. The main purpose is front-loaded in the first sentence, followed by essential behavior and a concrete example. Every sentence earns its place with no 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 tool's simplicity and the presence of an output schema (signal shows has_output_schema=true), the description covers all critical aspects: what it does, how it behaves (persistence, override, default), and provides an example. Nothing essential is missing for an agent to call it 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?

Schema coverage is 0% and the parameter is only named 'path'. The description adds meaning by explaining it resolves to an absolute path, gives an explicit example with a Windows-style path, and notes it creates the directory. This goes well beyond the bare 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 ('set') and resource ('where character/outfit/anim output is written') for this MCP session. It clearly distinguishes from sibling get_output_root (retrieves) and clear_output_root (resets). The scope is unambiguous.

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

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

Provides clear context: persists until process exit or clear_output_root(), and per-call output_dir overrides. It implicitly tells when to use (to change global output location) but does not explicitly say 'use this when you need to redirect all output' or exclude alternatives beyond the override. Still, the guidance is concrete and actionable.

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

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

With no annotations, the description must fully disclose behavior, but it only states it sets pixels on the design layer. It doesn't mention mutation side effects, required permissions, or the output format. The word 'set' implies a write operation but no specifics are given. Minimal disclosure for a tool that likely modifies state.

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

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

The description is a single concise sentence with no wasted words, earning a pass for brevity. However, the brevity borders on under-specification; it prioritizes being short over providing necessary details. It is structured clearly but lacks substantive 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?

The tool has 6 parameters, 3 required, an output schema, and no annotations. The description is far from adequate: it does not explain the pixel format, the role of 'name' and 'slot', or what the output represents. For a complex painting tool, this is critically incomplete.

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

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

Schema description coverage is 0% and the description gives no information about any of the six parameters. It only mentions {x,y,color} conceptually, but does not map to the 'pixels' array format, 'name', 'slot', or other fields. Without any parameter explanation, the agent cannot infer how to correctly populate the 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 clearly states it's an alias for paint_pixels and specifies the action: setting {x,y,color} on the design layer. This distinguishes it from other painting tools like fill_rect or draw_line, though it references an existing sibling rather than describing its own unique function. It's clear but relies on the alias reference for full clarity.

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

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

No guidance is provided on when to use set_pixels vs. the original paint_pixels. The description only says 'Alias for paint_pixels' without explaining whether they are interchangeable, which one to prefer, or any context for selection. Lacks any usage context or exclusions.

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

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

It discloses the write location ('Writes under output_dir/reference_grid/') and return value, which is meaningful behavioral context. However, with no annotations, it leaves out side-effect details such as overwrite behavior, directory creation, and what happens when style_ref is null.

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

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

Two short sentences with no filler. The core action is front-loaded, and the output location plus return type are stated efficiently. 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?

The tool has four optional parameters, no annotations, and no parameter descriptions. The description is too minimal to fully support correct invocation: parameter semantics and usage context are missing, despite the output path and return type being clear.

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

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

Schema description coverage is 0%, so the description must compensate. It indirectly explains style_ref and output_dir, but scale and readable_scale are entirely unexplained, leaving the agent without enough information to set these parameters correctly.

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

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

The description states a specific verb and resource: 'Upscale the style-ref PNG onto a visible per-pixel grid.' It also clarifies the output artifact ('Returns path strings for grid PNGs'), making the tool's role distinct from drawing/editing siblings like paint_pixels or fill_rect.

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 no guidance on when to choose this tool over alternatives, nor does it mention any exclusions or prerequisites. It only describes the operation itself, leaving the agent to infer appropriate usage.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the basic operation and adds the 'outfit design layer' context; it does not mention side effects, persistence, whether prior content is overwritten, coordinate-system details, or whether a slot/layer must be prepared first. For an unannotated tool this is a thin disclosure.

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

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

The description is a single efficient sentence that front-loads the core action and target layer with no filler. It is appropriately brief, though the brevity borders on under-specification given the tool's complexity.

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

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

With 11 parameters (7 required), zero annotations, and 0% schema description coverage, this description is far from complete. The output schema exists, but the definition still leaves the agent guessing about coordinate semantics, color format (string vs integer array), thickness units, and what 'output_dir' and 'plan_id' control. The description needs substantial elaboration to be adequate.

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

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

Schema description coverage is 0%, and the description adds no meaning to any of the 11 parameters (x, y, width, height, color, thickness, scale, slot, name, plan_id, output_dir). The description must compensate for the undocumented schema, and it does not explain a single parameter's purpose, units, or interaction.

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 ('Stroke (outline)') and resource ('rectangle on the outfit design layer'), which clearly distinguishes it from siblings like fill_rect and clear_rect. It is unambiguous about what the tool does, though it doesn't explicitly name a sibling for contrast.

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 provides no guidance on when to use this tool versus alternatives such as fill_rect, draw_line, or clear_rect. There are no contextual conditions, prerequisites (e.g., whether a layer must exist), or exclusions, so an agent has no help choosing among the many drawing tools in the sibling list.

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

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

With no annotations, the description carries the behavioral disclosure burden, and it does so well: it declares non-write behavior, explains the input heuristic (design-layer alpha vs body-part geometry), and lists the exact fields returned. The only notable gap is that the purpose of the output_dir parameter is not disclosed; it may write files, but the description only says it doesn't write pixels.

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: the core purpose and non-writing guarantee appear first, followed by algorithmic context, return shape, and workflow placement. Every sentence adds useful information without redundant restatement of the tool name or schema.

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

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

The workflow context and output shape are well covered, but the description is not sufficient for correct invocation because all three parameters are undocumented. An agent would likely know why to call this tool but not precisely how to fill name, band_height, and output_dir, which is a significant gap given the absence of annotation support.

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

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

Schema description coverage is 0% and the description does not compensate: it never explains name, output_dir, or band_height. The terms 'band hints' and 'band_height' are loosely related, but there is no explicit parameter-level documentation, leaving the agent to guess what value each argument should take.

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 a specific verb ('Propose') with a specific resource ('underside / far-limb shade band hints') and immediately clarifies that it does NOT write pixels, which distinguishes it from painting tools. It also names the structured output (layer, bbox, sample_pixels, reason) and positions itself relative to sibling plan_shading, so an agent can tell what this tool is for.

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 places the tool in a workflow: it is an optional helper before plan_shading, and its results are filtered by the agent before painting with MCP tools. It clearly implies when to use it, but does not state hard exclusion criteria beyond 'does NOT write pixels', so it falls just short of a full when/when-not prescription.

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