SVG Lab

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so safety is covered. The description adds real value beyond them by enumerating the report's contents, which is important since there is no output schema.

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, leading with the verb and listing the exact fields returned. 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?

With no params and no output schema, the description must carry the return-value burden, and it does list the reported items. It could go slightly further on format or when status should be re-checked, but nothing essential 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?

The tool takes zero parameters, so there is nothing to document beyond what the schema shows; baseline 4 applies and 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?

States a specific verb (report) and enumerates the concrete content: plan, access, SVG Lab credits, action costs. Clearly distinct from every sibling (which are drawing/layout/project operations), though 'access' is a slightly vague term.

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 explicit when/when-not statement or named alternatives. Usage is only implied: the mention of 'credits left and what actions cost' hints it should be consulted before spending credits, but the agent must infer 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?

Annotations already disclose write semantics (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so safety is covered externally. The description adds the behavioral fact that preset drives sizing and overrides explicit dimensions, but says nothing about which project/artboard it lands in, defaults for name or position, or what it returns.

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

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

Two short sentences with the core action first and the sibling exclusion second — zero padding. The parenthetical '(preset sizes it)' is terse to the point of being slightly cryptic about precedence over width/height.

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

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

For a 9-parameter creation tool with no required params and no output schema, the description omits critical call-time context: default naming, default placement, background visibility behavior, and the target project. An agent could call it but would be guessing on most parameters.

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 22% (only tone and preset documented), so the description must carry the rest and largely doesn't. It clarifies the preset-versus-width/height relationship, which is genuinely helpful, but leaves x, y, name, background, and show_background entirely unexplained, including what happens when position is omitted.

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 ('Add') and enumerates the resource in user-facing terms (screen, slide, page, post), which maps onto 'artboard'. It also clarifies that presets supply dimensions in place of width/height. The only gap is that it never literally says 'artboard', leaning on the tool name to bridge that.

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 excludes a nearby sibling: anything a control opens (dropdown, filter, menu) belongs to add_hidden_ui, not here. That is a real routing rule. But it doesn't say when to use this versus set_artboard or create_layout, so the guidance is useful but not complete.

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

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

Annotations already declare non-readOnly, non-destructive, non-idempotent, closed-world, so the safety profile is covered. The description adds that the created UI is 'sized' and 'linked' beside the screen, but it doesn't explain what linking does to the document, whether existing boards are affected, or whether the call is repeatable — modest added value.

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 a clear use-when clause and zero filler. It is compact and readable, though the clustered enumeration of kinds makes it slightly dense.

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 6-param mutation tool with a nested trigger object and no output schema, the description covers purpose and placement but says nothing about the return value (e.g., the created board id) or how the trigger is resolved when both shape_ids and label are present. Adequate but with clear gaps.

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

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

Schema coverage is 83%, so the schema itself documents most parameters including the kind enum and trigger object. The description reinforces the kind list and the 'beside its screen' placement but adds no syntax or format detail beyond the schema — baseline 3 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?

States a specific verb (adds) and a concrete resource set (dropdown, side, sheet, dialog, state board) plus the placement constraint 'beside its screen'. It is distinguishable from siblings like add_artboard because the enumerated kinds are unique to this tool, though no sibling is named 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?

'Use when a control opens hidden UI' gives an explicit trigger condition that tells the agent the scenario for invoking this tool. It stops short of naming alternatives or when-not-to-use cases, so it lands just below the top band.

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

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

The annotations already declare that this is a non-read-only, non-destructive, non-idempotent mutation. The description adds useful behavioral context by saying the marks are clipped to a shape and refused on a screen. It does not explain what the mutation actually creates, how repeated calls behave, or other operational constraints, but with annotations covering the safety profile 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 short and front-loads the action, but the second sentence is awkward and unclear ('On a screen the marks are refused as a picture drawn onto it'). It is concise without being structurally complete.

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

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

For a 12-parameter mutation tool with no output schema and 0% schema description coverage, the description is too thin. It leaves most parameters unexplained and does not describe the result of the operation, so an agent would need to infer heavily from the schema.

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

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

Schema description coverage is 0% across 12 parameters. The description only names four of the five kind values and implies shape_id via 'clipped to a shape'; it does not explain ink, seed, angle, color, width, jitter, opacity, spacing, coverage, name, or the crosshatch kind. This is far from compensating for the 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?

The description gives a specific verb and resource: add hatch/stipple/facet/strata marks clipped to a shape on a drawing board. This is more than a restatement of the title, but it does not explicitly distinguish the tool from siblings such as set_pattern or scatter.

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 implied usage context by naming the drawing board and noting that marks are refused on a screen, which is a when-not condition. However, it gives no explicit alternatives or guidance on when to choose this tool over related tools like set_pattern or scatter.

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

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

Annotations declare this is a destructive, idempotent mutation, but the description does not add any behavioral context beyond the surface purpose. It does not say that shapes are moved or that their positions change, nor does it warn about destructive effects. There is no contradiction with annotations, but the description adds little.

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 wasted words. It is terse, but structurally efficient.

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 destructive two-parameter tool with no output schema, the description omits key context: how many shapes are required, what happens to the shapes' positions, and how it differs from 'align_to_artboard'. It leaves an agent with too little operational detail.

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%, yet the description does not mention 'shape_ids' or explain the 'mode' options. 'Shared edge or centre' loosely hints at the mode enum, but it does not clarify parameter meaning enough to compensate for the missing 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 gives a specific verb, 'Align', and resource, 'shapes', plus the alignment target, 'shared edge or centre'. It does not explicitly distinguish itself from the sibling 'align_to_artboard', so it falls short of a 5.

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

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

There is no guidance on when to use this tool versus alternatives such as 'align_to_artboard' or 'distribute'. It also does not state prerequisites like needing multiple shapes selected.

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

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

The annotations already declare that this is a destructive, idempotent mutation, but the description adds no behavioral context such as what positioning does to existing layout, whether it can be undone, or permission requirements. It also does not contradict the annotations.

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

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

It is a single front-loaded sentence with no filler. However, it is arguably too terse for a destructive operation with three undocumented parameters.

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 this is a destructive mutation with no output schema and zero schema description coverage, the description should do more to explain effects and parameters. It states the high-level purpose but leaves an agent without enough context to invoke it safely and 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 description coverage is 0%, so the description must compensate for all three parameters, but it only implies shapes and artboards. It does not explain `shape_ids`, the meaning of `vertical`, or how `horizontal` interacts with artboard alignment.

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 gives a clear verb and resource: position shapes relative to their artboard. The artboard-relative scope helps distinguish it from the sibling `align`, which likely aligns shapes to each other, though it does not explicitly name that alternative.

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

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

It implies the tool aligns shapes to artboards but gives no guidance on when to use it instead of `align`, `distribute`, or `fit_to_children`. There are no exclusions, prerequisites, or alternative-selection cues.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false, so the agent knows this mutates the document, but the description adds nothing about what is altered, whether changes can be undone, or where the 'suggested positions' come from. For a destructive mutation tool, that is a substantial disclosure gap beyond what annotations already provide.

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 or redundancy. It is efficient but under-specified rather than genuinely concise, 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?

A destructive, 7-parameter tool with no output schema and no parameter documentation is described in one sentence that explains nothing about inputs or effects. The description is nowhere near complete enough for an agent to invoke it safely.

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?

Seven parameters with 0% schema description coverage and the description references none of them. Critical fields like 'containment' (with child_id/parent_id, padding, vertical/horizontal enums), 'ignore_pairs', 'target', and 'min_font_size' are entirely unexplained, so the agent must reverse-engineer intent from field 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 names a concrete verb ('Move') and resource ('misaligned layout children'), which is more than a restatement of the title. However, 'suggested positions' is never defined and nothing distinguishes this from siblings such as align, align_to_artboard, distribute, normalize_spacing, or resolve_overflow.

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

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

No when-to-use guidance, no prerequisites, and no alternatives are named. The agent is left to infer that this should be called after some inspection step produces suggestions, and to guess how it differs from the many other alignment 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?

Annotations declare destructiveHint=true and idempotentHint=false, so the agent knows this mutates and is non-idempotent. The description adds only the vague persistence notion 'keep it bound' and never discloses what gets destroyed (e.g., existing content in the slot, prior binding), whether rebinding replaces an earlier binding, or how the 'detach' path behaves.

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 well-formed sentence with no padding, which is structurally clean. However, its brevity reflects under-specification rather than disciplined economy for a 6-parameter destructive tool.

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

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

A destructive, non-idempotent mutation with 6 undocumented parameters and no output schema demands far more than one sentence. The description leaves critical gaps: what mode/clip/path do, what detach reverses, and what state the document ends up in.

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% across 6 parameters, so the description carries the full burden and mostly fails. 'Artwork' and 'layout slot' loosely map to shape_ids and layout_id, but clip, mode (with its contain/cover/stretch enum), path, and detach — including the fact that detach appears to undo the binding — receive no explanation anywhere.

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

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

States a specific verb+resource combination: fitting artwork into a layout slot, plus the persistence aspect ('keep it bound'). An agent can tell this is a layout-binding operation, but the description never distinguishes it from siblings like fit_to_box, fit_to_children, place_image, or update_layout.

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 statement of when to use this versus fit_to_box, fit_to_children, place_image, or update_layout — all plausible alternatives in the sibling list. Nothing describes preconditions (does the slot need to exist? must layout_id reference a created layout?) or what happens to prior bindings.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description adds that the result is 'one new path,' but it never says whether the source shapes are consumed/deleted or retained, which is the key question for a destructive boolean 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?

One sentence, front-loaded with the operation set and result. Nothing is wasted, though the terseness leaves required meaning unstated.

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 destructive two-parameter tool with no output schema and zero schema coverage, the description omits critical information: ordering semantics for subtract/exclude, fate of the original shapes, and what identifies the resulting path.

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 carry parameter meaning, and it does not. It repeats the four enum values without explaining semantics (for subtract/exclude, order of shape_ids determines which shape is cut from which) and says nothing about shape_ids.

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 set of operations (union, subtract, intersect, exclude) on a specific resource (shapes) producing one new path, which distinguishes it from siblings like group, create_path, or clip_shapes. It does not name a sibling explicitly, so it stops short of a 5.

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

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

There is no guidance on when to use boolean_op versus group/ungroup or clip_shapes, nor on prerequisites such as needing at least two shapes or the shapes being closed paths. Usage is only implied by the op enum.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, and the description merely echoes the passive 'measure' framing without adding anything. It says nothing about how tolerance affects the result, how mismatches are reported, or what happens when no pairs are given, all of which matter for a 5-parameter geometric check with no output schema.

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

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

It is a single front-loaded sentence with no filler, which is good structurally. But one sentence is undersized relative to a tool with five parameters, two of them nested object arrays, so the brevity reads as under-specification rather than economy.

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?

Rich annotations cover the safety profile, but nothing covers the calling contract: five complex parameters with zero schema documentation and no output schema mean the agent cannot tell what to pass or what result to expect. The description does not fill that 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%: pairs, artboard, tolerance, attachments, and display_width are all undocumented in the schema, and the description explains none of them. The nested 'expect' enum (overlap/touch/clear) and 'into'/'end' attachment fields are especially opaque and untouched by the 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 verb 'measure' and the notion of parts touching give a rough idea, but 'parts' and 'what they belong to' are undefined and the description never names the actual objects (shapes, pairs, attachments) the schema exposes. It does not distinguish this from spatial siblings like align, inspect_layout, or resolve_overflow.

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 statement of when to use this versus alternatives such as align, snap_to_grid, or inspect_layout, and no prerequisites or exclusions. An agent must infer the use case entirely from the name.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. Beyond the bare reference to the WCAG standard, the description adds no behavioral context: it doesn't say whether the result is a raw ratio, a pass/fail verdict, or how thresholds are applied. That is a meaningful gap for a 5-parameter tool.

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

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

A single front-loaded sentence with no filler. It is efficiently sized, though the terseness borders on under-specification rather than tightness.

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 pure computation tool with full read-only annotations, the bar is lower, and the WCAG framing gives the agent enough to attempt a call. However, with five parameters at 0% schema coverage and no output schema, the description should say what is returned (contrast ratio vs. compliance verdict) and what the optional parameters do.

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 carry the parameter burden and it does not. 'Between two colours' loosely implies foreground/background, but target, font_size and font_weight — non-obvious parameters that clearly affect WCAG large-text threshold logic — are left completely unexplained in both schema and 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 and resource: compute WCAG contrast between two colours. It is clearly distinguishable from the 80+ sibling tools, none of which do accessibility/contrast checking. It stops short of naming what makes it distinct versus adjacent colour tools (set_style, design_tokens), but purpose is unmistakable.

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

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

There is no guidance on when to call this versus alternatives, no prerequisites (e.g. colour formats accepted), and no explanation of when the optional target/font_size/font_weight parameters should be supplied. The agent must infer usage entirely from the name.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known from structured data. The description adds no behavioral context such as whether target shapes are consumed or preserved, how masking differs from clipping, or what happens to the clip shape.

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

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

The single sentence is front-loaded and free of redundant text. It is concise, though the brevity reflects under-specification rather than a complete but compact description.

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

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

For a destructive shape operation with three undocumented parameters and no output schema, the description is too sparse. It states the high-level operation but omits parameter roles, destructive consequences, and relationship to sibling 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?

Schema description coverage is 0%, and the description does not explain any of the three parameters. It gives no indication of what target_ids, clip_id, or as_mask mean or how they interact.

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 gives a clear verb-resource pair: clipping or masking shapes with another shape. It is understandable as a shape operation, but it does not differentiate the tool from siblings such as clip_to_artboard or boolean_op.

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 like clip_to_artboard, boolean_op, or group. It only states the operation, leaving alternative selection entirely to inference.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is known; the description adds only the selection criterion (shapes crossing the frame). It does not disclose what is destroyed or altered (paths truncated? hidden? masks applied?), whether the change is reversible, or what happens to shapes not crossing the frame.

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

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

It is a single front-loaded sentence with no filler, so nothing wastes space; however, it is terse to the point of under-specification given three undocumented parameters and a destructive operation.

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 destructive, idempotent mutation with three undocumented parameters and no output schema, the description is too thin. An agent knows only the rough intent and cannot determine where to apply it or what state it leaves behind.

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 supplies no parameter information at all. The ambiguous 'artboard' parameter (integer or string, i.e. ID vs name) and 'include_clipped' are entirely undocumented anywhere, and the description does not compensate for that gap.

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

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

The verb 'clip' and the object 'shapes that cross their artboard's frame' give a rough idea, but the description never distinguishes this from the sibling clip_shapes, nor does it clarify whether 'clip' means mask, crop, or destructively cut the geometry. An agent sees two similarly named clipping tools and gets no basis for choosing.

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 statement of when to use this rather than clip_shapes, resolve_overflow, or fit_to_box, and no prerequisite or exclusion information. The only implied scope is 'shapes that cross their artboard's frame', which is a selection condition, not usage guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, no open world, so safety is covered. The description adds useful context beyond that: what the comparison returns (overlay, difference map, pixel/shape misses) and that 'candidates' draws nothing, plus that 'measure' returns a gridded crop and colour runs. Return format is implied rather than detailed.

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

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

Front-loaded with purpose and reasonably short, but the first sentence is a run-on list ('overlay, difference map, pixels off and the shape misses left') that is cryptic rather than crisp. Every sentence carries information but the phrasing sacrifices clarity for density.

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 7-param tool with nested objects and no output schema, the description covers the main comparison behavior and the measure/candidates modes adequately. Return-value specifics are only loosely implied (overlay, difference map named but not structured), leaving a minor 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 coverage is 100%, so the baseline is 3, but the description adds meaning beyond schema: it explains 'candidates' score edits without drawing and that 'measure' reads the image itself rather than comparing. These clarify two of the more subtle parameters beyond what the schema text conveys.

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

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

States a specific verb+resource: 'Measure your drawing against the picked image,' and enumerates the outputs (overlay, difference map, pixels off, shape misses). Clearly a comparison/measurement tool distinct from siblings like set_reference_image. Somewhat dense phrasing but the purpose is unmistakable.

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

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

Gives clear usage contexts: compare a drawing to score it, use 'candidates' to score edits before sending, and use 'measure' to read the picked image before/while drawing. It does not name explicit alternatives or when-not-to-use cases, but the modes and their conditions are stated.

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

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

Annotations already declare this is a non-readonly, non-idempotent, non-destructive, closed-world creation. The description adds only that icons are built-in and monoline. It says nothing about where the icon lands (current artboard?), what happens on repeat calls given idempotentHint=false, or how size/color defaults behave.

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 tight sentence with the key constraint front-loaded and no wasted words. It is efficient, though the brevity borders on under-specification rather than disciplined conciseness.

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

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

For an 8-parameter mutation tool with no output schema and zero schema descriptions, this is well short of what an agent needs — coordinate semantics, sizing units, and placement behavior are all missing. Only the icon-name lookup path is covered.

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 8 parameters, so the description carries the full burden and mostly fails. It only clarifies the 'icon' parameter by directing the agent to docs {components} for valid names; x, y, name, size, color, artboard, and stroke_width remain entirely undocumented (units, defaults, artboard vs. absolute coordinates).

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 gives a concrete verb ('Draw') and a specific resource ('built-in monoline icon'), which separates it from generic siblings like create_shapes, create_path, and draw_svg. It stops short of explicitly naming those alternatives, but the 'built-in monoline' qualifier does real disambiguating work.

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

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

Usage is only implied: the parenthetical points to 'docs {components}' for icon names, which tells the agent how to pick a valid icon but not when to choose this tool over create_shapes, draw_svg, or generate_illustration. No exclusions or prerequisites are stated.

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

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

Annotations already declare it is a non-read-only, non-idempotent, open-world write. The description adds real context beyond that: the return payload (boxes, ids, warnings) and the approval/upload workflow that keeps the user's confirmation short. No contradiction with annotations. It does not say what happens to existing layouts or how warnings should be acted on.

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, purpose front-loaded before the workflow tip. The second sentence is dense but every clause carries information about the upload path. 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?

No output schema exists, and the description does cover return values, which is good. But for a tool with a very large recursive layout-tree schema and eight loosely documented parameters, the description explains almost none of the core input structure, leaving the agent to infer it.

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

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

Schema coverage is only 25%, and the description covers just two of eight parameters: 'layout tree' maps to root, and upload_id is explained in detail. The six spatial/verbosity parameters (x, y, width, height, verbose, artboard) get no mention, and the description gives no hint about the node vocabulary inside root, which is the hard part of calling this 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?

States a specific verb and outcome: 'Build a screen or section from a layout tree', and adds what is returned (boxes, ids, measured warnings). It is clearly distinguishable from list_layouts/inspect_layout/update_layout by the word 'build', though it never names those siblings explicitly.

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

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

The only guidance is procedural: when running with a shell, offload fields to a JSON file and pass upload_id. That covers the upload path but says nothing about when to use create_layout versus update_layout or apply_layout_fixes, or what prerequisites (project, artboard) must be in place.

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

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

Annotations already declare this is a non-readOnly, non-destructive, non-idempotent mutation, so the safety bar is partly met. The description adds useful context about the user-approval tradeoff of the upload path, but omits what object is actually created, which artboard it lands on, whether repeated calls duplicate, and what a name/style_ref resolves to.

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, purpose front-loaded, no filler. The second sentence is dense but every clause (JSON file, curl to upload link, pass only upload_id, fields in the call win) carries actionable information.

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

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

For a 14-parameter, zero-required, deeply nested creation tool with no output schema and low schema coverage, the description should at least establish the coordinate model, default behavior with no points, and what is returned. Instead it covers only the upload shortcut, leaving an agent unable to call it confidently without reading the schema repeatedly.

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

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

Schema description coverage is only 14% across 14 parameters with nested objects. "Anchors with optional absolute handles" glosses points/hin/hout, but tension, tension_in/out, tangent, smooth, subpaths, closed, mirror, corner_angle, fill_handles, style, and artboard are left entirely to the field names — a large gap the description does not close.

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?

"Draw one path from anchors with optional absolute handles" gives a specific verb and resource plus the core mental model (anchors + handles). "One path" implicitly distinguishes it from batch siblings like create_shapes or draw_svg, but it never names them, so the agent must infer the boundary itself.

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 second sentence gives a concrete workflow rule (use upload_id when a shell is available so the approval box stays short), which is real usage guidance. However it says nothing about when to choose create_path over edit_path, pencil, draw_svg, or offset_path — the sibling set is dense and no routing is offered.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds useful behavioral context beyond that: an 80-item batch cap, that illustrations derive from a reference, and the shell/upload trick to keep the approval prompt short. It does not explain what happens to existing content or what the call returns, so not a 5.

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

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

Two tight sentences, front-loaded with the core action and batch limit, followed by the practical upload detail. Nearly every clause earns its place, though the shell instruction is somewhat compressed and dense.

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 3-parameter creation tool with no output schema or rich annotations, the description should close more gaps. It covers the shapes array and upload_id but leaves artboard entirely unexplained, so an agent lacks full guidance to construct a complete call.

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

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

Schema coverage is only 33%, so the description carries more burden. It names the shape kinds and explains the upload_id workflow in line with the schema, but says nothing about the artboard parameter, which is undocumented in both places, and doesn't clarify shape-item field structure beyond the enum.

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 (draw/create), resource (shapes, text, paths, pencil strokes), and a concrete capacity limit (up to 80 in one call), which distinguishes it from single-item siblings like pencil or create_path. The 'illustrations are copied from a reference' clause adds scope but is slightly tangential to 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?

Explains a workflow variant (with a shell, upload via curl and pass upload_id) but never states when to choose this batch tool over siblings such as draw_svg, create_path, or generate_illustration. Batch use is implied rather than contrasted with 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description only adds that a 'link' is returned, without format or what happens when no project is active; useful but thin given annotations do the heavy lifting.

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 waste. The core purpose and the returned link are stated immediately.

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-param read tool with no output schema, the description is nearly complete: annotations cover behavior and it notes the returned link. It could mention behavior when no project is open, but that's a minor 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?

The tool takes zero parameters, so per the baseline rule this scores 4. There is nothing for the description to clarify beyond the empty 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 ('Show') and resource ('current project') and adds that the link is returned. The word 'current' implicitly distinguishes it from list_projects and open_project among siblings, though it never names them explicitly.

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

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

Usage is only implied by 'current project' – an agent can infer it's for retrieving the active project rather than listing or opening one. No explicit when-to-use, when-not, or alternatives (list_projects, open_project) are given.

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

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

Annotations declare destructiveHint=true, yet the description never says whether defining a preset overwrites or replaces an existing style of the same name — the single most important behavior for a destructive call. The upload/approval workflow detail is useful added context, but the destructive semantics remain undisclosed.

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, front-loaded with the core purpose and with zero filler. The second sentence is dense but each clause (JSON file, upload link, upload_id, short approval) carries functional information.

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

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

For a destructive, non-idempotent-looking mutation with no output schema, the description should disclose what gets overwritten, whether style names are global or per-project, and what the call returns. None of that is present, leaving meaningful gaps given only 50% schema coverage on a nested-object parameter.

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

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

Schema coverage is 50%; upload_id is fully documented in the schema, and the description's curl workflow reinforces what that parameter is for. The styles object carries no description in either schema or description, though its nested property names (fill, stroke, opacity, stroke_taper) are largely self-explanatory.

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

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

States a specific verb and resource ('Define named style presets'), which is unambiguous on its own. However, it never distinguishes itself from siblings like set_style or list_design_styles, so an agent cannot route between the style-related tools from this text alone.

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

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

The second sentence gives a procedural hint for shell environments (write JSON, curl to the upload link, pass upload_id), which implies usage context. But there is no guidance on when to choose this over set_style or list_design_styles, and no prerequisites stated for non-shell environments.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, and openWorldHint=false, so safety profile is covered structurally. The description adds no behavioral context beyond that—it does not say whether deletion is permanent, undoable, cascading, or how missing IDs are handled.

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 two-word sentence is not concise so much as under-specified—it lacks front-loaded scope or constraints. Brevity here reflects missing information rather than efficient phrasing.

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 destructive mutation tool with a required array parameter and no output schema, the description is too thin: an agent cannot infer permanence, failure behavior, or scope of deletion. Annotations cover hints but the natural-language layer leaves meaningful gaps.

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

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

Schema description coverage is 0% for the single parameter shape_ids, and the description does not compensate: it says nothing about the ID format, whether it accepts an array batch, or what happens to invalid/unknown IDs. This is well below the baseline that high schema coverage would provide.

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?

"Delete shapes" names a specific verb and resource, so the basic purpose is unambiguous. However, it is essentially a restatement of the tool name/title with no field, scope, or sibling differentiation—nothing distinguishes it from create_shapes, clip_shapes, or other shape-mutating siblings beyond the verb.

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 when-to-use guidance, no prerequisites, and no alternatives. An agent gets no signal about whether shapes must be selected first, whether related operations (ungroup, detach_symbol) should precede deletion, or when to prefer other 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?

Annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds almost no behavioral context beyond that, such as what information is returned or how pagination/filtering affects the result.

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 single sentence is technically concise, but it is under-specified rather than efficient. It does not front-load useful details about scope, filters, or return 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 tool with five undocumented parameters and no output schema, the description is far too thin. It does not explain what describe returns, how filters are applied, or how to choose between this and related list/inspect 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?

There are five parameters with 0% schema description coverage, and the description does not mention ids, limit, offset, artboard, or name_contains at all. An agent gets no meaning beyond the bare parameter names.

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 gives a verb and resources ("Describe the artboards and shapes"), so the general intent is inferable. However, it is vague about what a "description" contains and does not distinguish this tool from siblings like list_artboards, list_shapes, or inspect_layout.

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 instead of list_artboards, list_shapes, or inspect_layout. It also gives no indication of when the filter parameters should be used.

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

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

The annotations already declare readOnly=false, destructive=true, and idempotent=true, so the safety profile is partly covered. The description adds useful approval-workflow context around the shell/upload_id path, but it never explains what the destructive behavior changes or what reset does, leaving a meaningful gap for a destructive mutation.

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

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

The description is short and front-loads its purpose in the first sentence, then uses the second for the upload_id workflow. It is efficient and earns its space, though the second sentence is dense and carries a lot of operational detail in one clause.

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 six parameters, a nested object, low schema coverage, and destructiveHint=true, the description is substantially incomplete. It covers the purpose and one upload workflow but omits the semantics and effects of most parameters, especially reset and the nested set object.

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

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

Schema description coverage is only 17%, so the description needs to compensate but does not. It explains the upload_id shell workflow, yet says nothing about the set object, reset, preset, imagery, or user_named_fonts parameters beyond the generic phrase 'the fields'.

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: 'Change the project's design tokens.' That is clear enough for an agent to understand the operation, though it does not distinguish this tool from nearby siblings such as define_styles or set_style.

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

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

Usage guidance is limited to a conditional workflow for upload_id: 'With a shell (Claude Code): write the fields to a JSON file...' It does not explain when to use design_tokens versus alternative style-setting tools, nor when to avoid it.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds the concrete outcome—conversion into editable shapes—but does not explain what happens to symbol overrides, nested symbols, the symbol link, or undo 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. It communicates the core outcome efficiently, even though other dimensions lack 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 destructive, non-idempotent one-parameter mutation, the description gives the essential transformation and annotations carry the danger warning. However, it omits important behavioral details such as the effect on symbol overrides and whether the original instance or symbol link is lost.

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

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

The only parameter, shape_id, has no schema description at all. The phrase 'one symbol instance' hints that the ID must identify a symbol instance, but the description never names shape_id, its expected format, or how to obtain it, so it only partially compensates for the 0% schema coverage.

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

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

The description gives a specific verb and resource: turning one symbol instance into editable shapes. It distinguishes the operation from siblings like make_symbol or place_symbol by focusing on converting an existing instance, though it does not explicitly contrast with ungroup.

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 implied use is reasonably clear: call this when a symbol instance should become editable shapes. However, there is no explicit when-not guidance, prerequisite that the shape must be a symbol instance, or named alternative such as ungroup or make_symbol.

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

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

Annotations already disclose readOnlyHint=false, destructiveHint=true, idempotentHint=true, and openWorldHint=false. The description adds that shapes are repositioned evenly and that at least three are involved, but it does not explain what is destroyed or how existing positions change.

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 to the stated operation, and there is no redundant restatement of the title 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?

For a simple two-parameter tool, the description establishes the core action and minimum shape count. However, it omits the axis dimension and does not clarify movement/destruction behavior beyond the annotations, so it is only minimally complete.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It indirectly conveys that shape_ids should contain at least three shapes, but it never mentions the required axis parameter or the horizontal/vertical options, leaving one of two parameters undocumented in prose.

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: space shapes evenly. It also includes the important minimum-count condition of three or more shapes. It does not distinguish the tool from siblings such as align or normalize_spacing, so it falls short of a 5.

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

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

The phrase 'three or more shapes' implies when the tool applies and gives a minimum input threshold. However, it gives no explicit when-not guidance and does not name alternatives such as align, normalize_spacing, or scatter.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and closed-world, so the safety profile is fully covered. The description adds the 'Read on its own' independence for fonts/components, but nothing about what the reference contains or how mode combinations behave.

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, front-loaded with the resource and purpose, no wasted verbiage. The '{fonts}/{components}' bracket syntax is compact but slightly ambiguous.

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 optional params, no required params, and no output schema, the description explains only a few modes. An agent can invoke it but must infer how the many parameter families (lesson vs lessons, guide vs guides, skill+reference) interact.

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 82%, so the schema largely documents the params. The description adds usage syntax for fonts and components modes and identifies 'start-here' as a guide id, but leaves tool/tools, guide/guides, skill/reference, and lesson/lessons undocumented at the description level.

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 — a reference/docs reader returning start-here guides, per-tool details, fonts, and components — which clearly distinguishes it from the editing siblings (draw_svg, add_artboard, etc.). It is clear what the tool fetches, though the '{fonts}' shorthand is slightly cryptic.

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?

'start-here' implies a recommended entry point and 'Read on its own' signals that fonts/components can be fetched standalone. However, there is no explicit when-to-use-vs-alternatives guidance or explanation of how the 11 modes relate.

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

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

Annotations already declare destructive=true, idempotent=true and closed-world, so the description's job is to add context — and it does: two refusal conditions, a resubmit-the-whole-SVG loop while differences is non-empty, and the note that upload_id keeps the user's approval box short. It does not say what the tool returns or what happens to a previously uploaded drawing when re-sent, despite destructiveHint.

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?

Only three sentences, but the first is a tangled run-on with stacked parentheticals ("however small ([] at shape_misses 0)"), and it front-loads schema-duplicating detail about differences ahead of the harder constraint. Purpose is front-loaded; readability and de-duplication are not.

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

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

For a 7-parameter, three-required mutation tool with full schema coverage and no output schema, the description covers the iterate-until-clean workflow, the upload path and both refusal gates. The remaining gap is what a successful call returns and whether it overwrites prior artboard content, which matters given destructiveHint.

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

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

Schema description coverage is 100%, so the schema already defines the viewBox requirement, the variant two-stage rule, upload_id and the per-part differences list. The description largely restates that (differences = every remaining flaw, [] at shape_misses 0), adding only the rule that watermarks/logos/captions are never listed — marginal net new meaning.

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: upload a hand-written SVG onto an image's drawing artboard, and adds a sharp qualifier (hand-written, not auto-traced) that separates it from the generation/compare siblings. It does not name those siblings (compare_drawing, generate_illustration) outright, so routing between them is inferred rather than stated.

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

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

Gives real conditions: auto-traced output (potrace, vtracer, quantising) is refused, differences must be [] before the drawing counts as finished, and variant is refused until the exact copy is done. It also prescribes the shell alternative (curl the .svg to the upload link from new_project, pass upload_id). No explicit 'use X instead when…' against siblings, which keeps it below 5.

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

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

The annotations already establish that this is a non-readonly, non-destructive, non-idempotent operation. The description adds useful behavioral context by saying it copies shapes in place or at an offset, but it does not clarify whether originals remain selected, what new IDs or names result, or what the tool returns.

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

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

The description is a single, front-loaded sentence with no wasted wording. It immediately conveys the operation and the two placement modes.

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

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

For a mutation tool with two undocumented parameters and no output schema, the description is too thin. It does not explain the required shape_ids parameter, the boolean offset semantics, or enough about the resulting copies for an agent to invoke it confidently.

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

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

Schema description coverage is 0%, so the description must compensate, but it only indirectly hints at the offset parameter and never explains shape_ids. It also does not clarify what offset=true means in practical terms, such as a fixed distance or direction.

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: copying shapes, with the option to do so in place or at an offset. It clearly describes the tool's operation, though it does not differentiate against nearby siblings such as repeat, create_shapes, or add_artboard.

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 offers no explicit guidance on when to use this tool versus alternatives like repeat or create_shapes. The phrase 'in place or at an offset' hints at two modes but does not explain when each is appropriate.

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

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

Annotations already disclose that this is destructive, non-idempotent, non-read-only, and closed-world, so the description's lower burden is partly met. It adds that changes happen 'in place' and explains the upload_id approval-shortening workflow, but it does not explain destructive scope, partial edits, or validation 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 short and front-loads the core purpose in the first sentence. The second sentence is a specialized but useful workflow note, though it is somewhat niche relative to the many parameters the tool exposes.

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 15-parameter destructive path-editing tool with nested objects and low schema description coverage, the description is too thin. Annotations cover the safety profile, but key operational semantics for most parameters and editing behaviors are left 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 only 13% for 15 parameters, so the description needs to compensate but does not. It mentions anchors/handles generally and the upload_id workflow, but gives no meaningful detail on the many point-editing parameters, coordinate_space, tension behavior, or how set/move/delete/insert operations interact.

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: 'Change a path's anchors and handles in place.' That clearly identifies an edit operation on an existing path, though it does not explicitly differentiate from sibling tools such as create_path, inspect_path, or smooth_path.

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 purpose implies this is for editing an existing path's anchors/handles, but the description gives no explicit when-to-use or when-not-to-use guidance versus sibling tools. The shell/upload workflow is a useful operational note, but it addresses only one invocation path rather than tool selection.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the safety profile is covered; the description usefully adds that a preview card and PNG link are returned. It omits the biggest behavioral trait implied by the schema: the numbered 'part'/'export_id' protocol, which suggests a multi-part, multi-call export flow that an agent cannot discover from the description.

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, which is the right shape. It is arguably over-compressed for a five-parameter tool with a staged export flow, but nothing in it is wasted.

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

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

With no output schema, five parameters, and a schema that hints at a part/export_id paging protocol, the description should explain the export sequence, how to start (part 1) and continue, and what background/outline_text do. None of that is present, so an agent would likely mishandle the multi-part flow.

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

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

Schema description coverage is only 40%, so the description must compensate, and it does not: it says nothing about 'part', 'export_id', 'background', 'outline_text', or what forms the 'artboard' identifier accepts (integer or string). Only the SVG output is hinted at, leaving four of five parameters unexplained beyond bare type info.

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 (export) and resource (artboard) plus the output format (SVG) and what comes back (preview card, PNG link). It is distinguishable from export_code and export_document by the SVG/artboard framing, though it never names those siblings explicitly.

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

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

There is no guidance on when to pick this over export_code, export_document, draw_svg or get_assets, and no preconditions (e.g. artboard must exist/be active) are stated. The agent must infer usage entirely from the name.

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

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent, closed-world operation, lowering the disclosure burden. The description adds genuinely useful context: the result is a ZIP link and the export bundles design tokens and assets. It still omits whether the ZIP is persisted, whether the link expires, and whether export is asynchronous — notable gaps for a write-ish 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?

A single compact sentence with the core action front-loaded and no filler. The parenthetical format list is dense but earns its place by conveying output options.

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 3-parameter tool with zero schema coverage, no output schema, and no sibling differentiation, the definition is too thin. An agent cannot tell what `file` or `artboards` expect, whether an export is immediate or a background job, or how the ZIP link is delivered.

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 carry all parameter meaning, yet it mentions only the format options and never maps them to the `format` parameter. The `file` parameter (what file? a project? a source?) and `artboards` selection semantics (IDs vs names, defaults) are completely 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?

States a specific verb and resource ('Export screens as code') and enumerates the supported output formats (HTML, React, SwiftUI, Compose, Flutter, SVG), which tells an agent exactly what it produces. It does not differentiate itself from siblings like export_artboard or export_document, so an agent must infer which export variant is appropriate.

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

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

No guidance on when to choose this over export_artboard, export_document, or draw_svg, nor any prerequisites (e.g., an active project or selected artboards). The agent is left to guess the selection criteria from the sibling list 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?

The annotations already declare the tool is non-read-only, non-destructive, non-idempotent, and closed-world. The description adds that output is delivered 'by link' and lists formats, but it does not explain persistence, permissions, overwrite behavior, or whether repeated exports create new links.

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

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

It is a single compact sentence with no filler, and the formats are listed immediately. The fragmentary 'by link' phrasing is slightly less clear than a verb-led sentence, so it is not fully front-loaded.

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 core resource and format options are present, and the schema covers page selection and file naming. However, given the sibling export_artboard, the description should clarify whole-document scope and link-return behavior; that missing routing context leaves a meaningful 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 coverage is 100%, so all three optional parameters are already documented in the schema. The description reinforces the format choices but adds no meaningful detail about artboards or file_name beyond what the schema provides.

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

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

The description identifies the resource (finished deck/document) and the output formats, while the title supplies the export verb. It is clear what the tool does, but it does not explicitly distinguish the whole-document export from the sibling export_artboard.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no direction to export_artboard for single artboards. The phrase 'finished deck or document' only weakly implies the post-design 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?

Annotations already disclose read-only, open-world, idempotent, non-destructive behavior; the description adds useful extra traits: Creative Commons prioritization, per-candidate licence information, exclusion of stock-agency previews, and that candidates are 'for you only.' It still does not describe result format or limits, so it is not a 5.

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

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

The description is a single front-loaded sentence with no filler, and the key scope and licensing constraints come early. The parenthetical '(illustration, query)' is slightly awkward but not harmful.

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 search tool with rich annotations and fully described parameters, the description covers purpose and content policy. However, with no output schema and no description of what a candidate result contains or how it relates to plan_illustrations, some context is still missing.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema. The description only calls out illustration and query and adds no syntax or meaning for count/style beyond the schema, making the baseline 3 appropriate.

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—'reference pictures for one planned illustration'—and scopes it with 'Creative Commons first' and 'no stock-agency previews,' which distinguishes it from stock-photo search. It lacks an explicit verb and does not name the sibling alternative, so it falls short of a 5.

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

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

It implies the usage context ('one planned illustration') and content policy (Creative Commons first, no stock-agency previews), but never explicitly says when to choose this over search_photos or generate_illustration. The alternative-selection guidance is inferable rather than explicit.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the agent knows this mutates the document. The description adds scoping detail (it operates on the active artboard and the artwork on it) but never says what is actually altered — the artboard bounds or the artwork — nor what becomes destructive about it. With annotations covering the safety profile, this partial addition merits a 3 rather than higher.

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, and the core operation comes before the optional parameter. It is arguably too terse for what it omits, but on structure and waste it performs well.

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 one-parameter, no-output-schema tool with annotations present, the description covers the essentials of what it does. The meaningful gaps are the units and effect of padding and the ambiguity against the fit_* siblings, which leave an agent guessing at invocation details.

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

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

Schema coverage is 0%, so the description is the only source of parameter meaning, and it says only 'optional padding'. It confirms optionality but gives no units (px, pt), no default, and no indication of whether padding expands or shrinks the fitted bounds — information the schema cannot supply.

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

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

States a specific verb and resource ('Fit the active artboard to the artwork on it'), which is more precise than the title alone because it names the target artboard as the *active* one. It does not, however, distinguish itself from near-siblings like fit_to_children or fit_to_box, which an agent could easily mistake for this 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?

There is no statement of when to use this versus fit_to_children, fit_to_box, resize, or align_to_artboard, all of which live in the same sibling list. The intent is inferable from the name, but the description provides no routing guidance or preconditions (e.g., whether artwork must be selected first).

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so safety is covered. The description adds one behavioral note – that placing an illustration removes its drawing board – which is consistent with destructiveHint but delivered cryptically and without explaining whether the removal is reversible or which objects are affected.

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

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

It's a single front-loaded sentence, so there's little waste, but the second clause is ambiguous and could mislead rather than clarify. The brevity comes 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 destructive, 7-parameter mutation with no output schema, the description should explain the box coordinate semantics, mode behavior, and the artboard target. None of that is present, so an agent cannot call this confidently.

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

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

Schema coverage is 0% and the description only implies that x/y/width/height define a box, without explaining them or covering shape_ids, artboard, or the contain/cover/stretch modes. With all 7 parameters undocumented and one enum unexplained, the description leaves most parameter meaning to guesswork.

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 pair of verbs (scale and move) and a resource (shapes) with a target (a box), which tells an agent what the tool does. It stops short of distinguishing itself from close siblings like fit_artboard, fit_to_children, resize, or transform, so it doesn't earn a 5.

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

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

There's no guidance on when to choose this over fit_to_children, fit_artboard, or plain transform, and no exclusions or prerequisites. The agent must infer the choice from names 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?

The annotations declare destructiveHint=true and idempotentHint=true, but the description does not explain what is destructive, what happens to the container or children, or how padding affects the result. It adds almost no behavioral context beyond the title and 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?

The single sentence is front-loaded and wastes no words. However, for a tool with three parameters including a complex padding object and a destructive annotation, it is too terse to be appropriately sized.

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 0% schema description coverage, no output schema, and a destructiveHint=true annotation, the definition is incomplete. It should explain parameter behavior, especially padding, and clarify the destructive mutation and how it relates to sibling fit 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?

Schema description coverage is 0%, and the description does not explain container_id, child_ids, or the complex padding option. It only generically mentions a container and children, leaving all parameter semantics to the 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?

It states a specific verb and resource: resize a container, with the outcome of wrapping its children. The purpose is clear, but it does not distinguish this from close siblings such as fit_to_box, fit_artboard, or resize.

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 instead of fit_to_box, fit_artboard, resize, or align. The usage is only weakly implied by the tool name and sentence.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description adds nothing beyond them — no statement about in-place mutation, undo behaviour, or whether flipping a group affects children. It also offers no hint of why the operation is flagged destructive.

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 short sentence with no padding, action front-loaded. Its brevity is efficient but borders on under-specification rather than crispness.

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 destructive, non-idempotent mutation tool with zero parameter documentation and no output schema, this description is too thin — it should state the mutation semantics and the ID source. Nothing an agent needs in order to call it safely is supplied.

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 carry the parameter burden and it does not. 'Horizontally or vertically' merely restates the axis enum, and shape_ids is never explained — no indication of format, whether IDs come from list_shapes, or whether mixed shape types are allowed.

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 ('Flip shapes') plus the two axes it supports, so the action is unambiguous. It does not differentiate from nearby siblings like mirror or transform, which could plausibly be confused with flipping.

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 rather than mirror, transform, align, or duplicate. The agent must infer the use case entirely from the name and the axis enum.

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

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

Annotations already cover safety (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false). The description adds meaningful context beyond them: it costs 500 credits and returns editable SVG, which helps the agent weigh call cost and expected output.

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 that front-loads the action, names the model, and appends cost and output in a tight clause. Nothing is wasted.

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

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

With no output schema, the description usefully states the return is an editable SVG. Combined with 100% schema coverage and annotations, an agent has what it needs to call it, though the prerequisite link to plan_illustrations could be made more explicit.

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

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

Schema description coverage is 100%, so all three parameters (prompt, artboard, illustration) are already well explained. The description adds no parameter-level syntax or format detail, which is acceptable given the schema's completeness.

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

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

States a specific verb and resource ('Draw a planned illustration'), names the model ('SVG Lab's vector model'), and specifies the output ('editable SVG from a text brief'). It doesn't explicitly name a competing sibling like draw_svg or plan_illustrations, but 'planned illustration' and 'the faster route' hint at the workflow distinction.

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

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

Implies a prerequisite workflow ('planned illustration') and that this is one option ('the faster route'), but never states when to use it versus plan_illustrations or draw_svg. The guidance is inferable rather than explicit.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds return-shape context ('as SVG or PNG files', 'a ZIP link for many'), but says nothing about how output is delivered (URLs vs. embedded data) or any failure/limits for large asset lists.

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

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

A single front-loaded sentence with no filler; the addressing modes and bulk behavior come first. The trailing 'a ZIP link for many' is slightly cryptic but dense rather than wasteful.

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

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

With four undocumented parameters, no output schema, and zero schema description coverage, the description leaves key gaps: what is actually returned (file URLs, inline data, or a ZIP), what 'scales' does, and whether zero assets requests everything or errors. For a retrieval tool without an output schema this 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%, so the description must carry parameter meaning. It covers assets, format and artboard loosely, but the 'scales' parameter is never explained (presumably PNG multipliers) and the artboard anyOf (integer vs. string) distinction between id and name is left unclear.

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

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

States a concrete verb and resource set ('Get drawings and icons as SVG or PNG files') plus the two addressing modes (asset id or artboard) and the bulk path (ZIP for many). This separates it from export_document/export_artboard, though it never names those siblings explicitly.

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

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

The phrase 'by asset id or artboard; a ZIP link for many' implies when to use single vs. bulk retrieval, but there is no explicit when/when-not or named alternative among the many export_* siblings. Usage is inferable rather than stated.

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

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

Annotations already declare destructiveHint=true, readOnly=false, and non-idempotent, so the safety profile is covered structurally. The description adds nothing behavioral: it does not say whether source shapes are consumed, whether the group is returned or named, or what happens to shapes spanning artboards — a meaningful gap for a destructive mutation.

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 words with zero waste, but this is under-specification rather than conciseness; there is no front-loaded scope, precondition, or effect statement to anchor the call.

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 destructive, non-idempotent mutation with no output schema, zero documented parameters, and no required parameters declared, the description is far too thin to let an agent invoke it correctly. Nothing explains the resulting group, its name, or its artboard.

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 three parameters (name, artboard, shape_ids), and the description supplies no meaning for any of them — notably it never says what name does or how artboard scopes the grouping. Only the loose inference that shape_ids are the shapes being grouped is recoverable from the tool name.

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?

"Group shapes" restates the tool name and title without adding specificity about what grouping means here (combining into a group node, preserving order, target container). It does not distinguish the tool from siblings like ungroup, name_group, boolean_op, or make_symbol, which an agent must choose between.

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

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

There is no when-to-use guidance, no prerequisites (e.g., shapes must be selected or share an artboard), and no mention of the natural counterpart ungroup. The agent gets no criteria for selecting this over boolean_op or create_shapes.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description goes beyond that by disclosing the concrete return content (status, seconds, and a group_id once the drawing is placed), which is the key behavioral fact an agent needs when no output schema 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?

A single compact sentence with the subject front-loaded and the returned fields trailing. Dense but not padded; only mild awkwardness in 'group_id once placed' costing a bit of readability.

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?

Because there is no output schema, the description's field list is doing useful work. However, it does not explain status values, whether results are scoped to the current project, or when an agent should re-poll versus proceed, leaving real gaps for a progress-tracking tool.

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, so the baseline is 4; there is nothing for the description to disambiguate. It correctly implies a parameterless listing rather than accepting job IDs, which matches the empty input 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 the specific resource (progress of drawings by SVG Lab's vector model) and enumerates the returned fields (status, seconds, group_id once placed). It is clear what the tool reports, though it never mentions that these jobs originate from generate_illustration/plan_illustrations, so the connection to siblings is left implicit.

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 call this: no mention of polling after starting an illustration job, no frequency advice, no statement of what happens when no jobs exist. Usage must be inferred from the name and from the neighboring generate_illustration 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?

The annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the description's 'changes nothing' is consistent but redundant. It adds no further behavioral context, such as what a measurement returns, how overlap/overflow are defined, or whether results are scoped to an artboard or selection.

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 of seven words with no filler. Every phrase contributes to the stated purpose and the read-only guarantee.

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 seven-parameter measurement tool with no output schema and no parameter documentation, the description is far too sparse. It does not explain how to scope the inspection using target/artboard/shape_ids, what containment settings mean, or what the agent should expect back.

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

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

There are seven parameters with 0% schema description coverage, and the description does not mention or explain any of them. It gives no clue how group, target, artboard, shape_ids, containment, ignore_pairs or min_font_size affect the measurement, leaving the agent to infer everything from bare types and enums.

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, 'Measure', and names three concrete resources: overlap, overflow and alignment. This distinguishes it from mutating siblings such as apply_layout_fixes, but it does not explicitly differentiate it from related inspection tools like measure_text, inspect_path or resolve_overflow.

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 'changes nothing' implies a read-only diagnostic use, but there is no explicit guidance on when to choose this tool over apply_layout_fixes, resolve_overflow, check_contrast or measure_text. No prerequisites, exclusions or alternative-selection criteria 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds only the returned content and says nothing about the preview/rendering behavior implied by params like preview, background, display_width, crop and max_size, nor about how audit affects results — a notable gap given no output schema.

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. It is appropriately terse, though that terseness comes at the cost of the missing detail noted elsewhere.

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

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

For a 10-parameter tool with nested objects and no output schema, the description is far too thin. It does not explain the crop/preview/audit options, how anchor_indices and subpath_index scope the inspection, or what a result looks like.

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 params, including nested crop and non-obvious flags like audit, corners and subpath_index. The description only alludes to 'anchors', providing no meaning for any parameter and failing to compensate for the coverage gap.

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

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

States a specific verb (read/inspect) and resource (a path) and names the returned content: anchors, handles, construction issues. That distinguishes it from mutating siblings like edit_path, create_path, smooth_path. 'Construction issues' is slightly vague but still conveys diagnostics.

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

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

No guidance on when to use this versus edit_path, smooth_path, normalize_radii, or inspect_layout. No prerequisites (does the shape need to be a path?) and no exclusions. An agent must 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds nothing beyond that — no mention of scope (current project vs. all documents), ordering, or what an artboard entry contains.

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

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

It is a single short sentence with no waste, but it is concise to the point of vacuity — it conveys no information an agent could not infer from the name.

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

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

For a zero-param read tool with rich annotations and no output schema, the agent still needs to know what identifies an artboard in the response and whether the list is scoped to the active document. The description supplies none of this.

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, so the baseline is 4. There is no parameter information the description could or should add.

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

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

The description is 'List the artboards,' which essentially restates the tool name and title without adding scope. It does not distinguish this from siblings like list_shapes, list_layouts, or describe_document.

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 rather than describe_document, list_shapes, or current_project. No prerequisites, no exclusions, no alternatives are named.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds no behavioral context whatsoever — not whether presets are built-in vs. document-local, not whether the list changes, not the shape of what comes back.

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

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

It is certainly short and front-loaded, but that brevity comes from under-specification rather than economy. The single sentence duplicates the title instead of earning its place with new 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?

No output schema exists, so the description is the only place to explain what a 'style preset' is and what the returned list contains — and it says none of that. For a discovery/list tool, the agent is left guessing about result shape and scope.

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, so there is no parameter semantics to convey. The baseline for a parameterless tool is 4; nothing is missing in this dimension.

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?

"List style presets" is a verbatim restatement of the tool name and title — a tautology. It conveys the resource but adds nothing an agent couldn't infer from the identifier itself, and gives no basis for distinguishing it from siblings like define_styles, set_style, or design_tokens.

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 call this versus the other style-related siblings (define_styles, set_style, design_tokens). The agent must infer from the name alone that this is the read-side counterpart to style mutation 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is clear. The description adds only the project-level scope and does not mention ordering, pagination, inclusion of hidden layouts, or return shape.

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

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

The description is one short, front-loaded sentence with no wasted text. It communicates the core action immediately.

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 tool with rich annotations, the definition is minimally adequate. Because there is no output schema, the description could reasonably say more about what is returned, such as layout ordering or whether all layouts are included.

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 on the description. Baseline 4 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 a clear verb and resource: listing layouts scoped to 'this project.' It does not differentiate this tool from nearby siblings such as inspect_layout or other list_* tools, which prevents a 5.

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

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

There is no explicit guidance on when to use list_layouts instead of siblings like inspect_layout, create_layout, or update_layout. Usage is only implied by the word '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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description adds only a light ownership scope ("the user's"), and says nothing about result size, ordering, or whether pagination applies — acceptable but thin given the annotations carry the burden.

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 short sentence with the subject and scope front-loaded and no filler. It is efficient, though it borders on under-specification rather than tightness — one more clause on what is returned would have cost nothing.

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

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

With no output schema and no parameters, the description is the only place an agent could learn what a returned project looks like or whether the entries carry identifiers usable with open_project. For a simple read tool this is close to adequate, but the missing link to the project-opening siblings leaves a real gap in a 70-tool surface.

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 is an empty object, so there is nothing for the description to compensate for. The baseline for a parameterless tool applies cleanly.

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 (list) and resource (the user's projects), which is unambiguous on its own. However, it gives no signal distinguishing it from nearby siblings such as current_project, open_project, and account_status, so an agent must infer the relationship between listing, opening, and the active project.

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

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

There is no when-to-use guidance at all — nothing says whether this is the first step before open_project, whether it lists all projects or only those recently accessed, or what to do if the result is empty. The only implicit cue is "the user's," which scopes the listing but does not route the agent among 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?

Annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds useful return-content context ("ids, boxes and stacking order") but does not mention pagination, filtering behavior, or result limits.

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. It is appropriately concise, though its brevity reflects under-specification handled in other dimensions rather than wasted text.

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 six-parameter listing tool with no output schema, the description is too thin. It omits filter semantics, pagination behavior, and how grouping or artboard scoping works, leaving an agent unable to use the parameters confidently.

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

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

Schema description coverage is 0%, with six parameters (all, group, limit, offset, artboard, name_contains) undocumented in both schema and description. The description does not compensate by explaining what any parameter controls.

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

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

States a specific verb and resource ("List shapes") plus the returned fields ("ids, boxes and stacking order"). It is clear what the tool does, though it does not explicitly distinguish itself from siblings like list_artboards or list_symbols.

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, nor any stated prerequisites. The listing intent is implied by the name, but no usage 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered by structured data. The description contributes nothing further — no mention of scope, filtering behavior, or what the listing contains.

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

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

One short sentence, but its brevity comes from under-specification rather than economy. It is not a concise statement of a complete idea; it is a restatement of the title.

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?

Though the tool is simple and annotations cover safety, there is no output schema, so the description should clarify what a symbol listing returns (names, ids, counts) and scope. None of that is present, leaving the 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?

The tool takes zero parameters, so there are no semantics to document; the baseline of 4 applies. Nothing in the description misleads about 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 restates the tool name and title verbatim ('List the symbols') without saying what a symbol is or what distinguishes this from siblings like list_shapes, list_layouts, or place_symbol. An agent learns nothing about the resource beyond the name itself.

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 indication of when to use this versus the many other list_* siblings or the symbol-related tools (make_symbol, detach_symbol, place_symbol). No prerequisites, conditions, or alternatives are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. Beyond that the description adds only "measured facts," with no disclosure of what is returned (image? structured facts?), how brief/critique/before_after alter behavior, or cost/latency implications of rendering. With no output schema, more burden falls on the description than it carries.

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 single sentence is front-loaded and free of filler, which is good. But for an 11-parameter, multi-mode tool it is under-specified rather than concise — appropriate sizing is not achieved.

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?

Eleven optional parameters, nested objects, no output schema, and a 36% description coverage rate demand substantially more explanation than one sentence. An agent cannot tell from this description what most flags do or what the call produces.

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

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

Schema description coverage is only 36% across 11 parameters, so the description must compensate and largely does not. Only region/reference comparison is implied; scale, brief, critique, flow, before_after, artboards, and inspect_shape are entirely unexplained in both places.

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 verb and resource ("render an artboard") and a second mode ("compare a region with a reference"), which is more than the bare name "look". But the schema reveals many more modes (brief, critique, flow, before_after, inspect_shape) that the description never hints at, so the stated purpose understates the tool's actual scope. It also does not differentiate from overlapping siblings like read_screen, compare_drawing, or export_artboard.

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 an implicit render-vs-compare split, but no explicit when-to-use, when-not-to-use, or named alternative. An agent choosing between this, read_screen, compare_drawing, and export_artboard gets no routing signal from 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?

Annotations already declare readOnly=false, destructive=false, idempotent=false, and openWorld=false, so the safety profile is covered. The description adds useful behavioral context by saying the result is reflowed onto new artboards, which suggests a non-destructive creation operation, but it does not clarify whether the source artboard changes, how device selection works, or what 'reflowed' concretely means.

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 or repetition. Its brevity contributes to completeness gaps, but as a conciseness and structure matter it is efficient.

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

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

For a mutation tool that creates new artboards from an existing screen, the description is too thin given 0% schema coverage and no output schema. It does not explain the required input artboard, the difference between sizes and devices, or what the resulting artboards contain.

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% for all three parameters, so the description must carry the burden. It vaguely gestures at devices with 'other phones and foldables' and at output artboards, but it never explains the required artboard identifier, the sizes array with name/width/height, or how devices differs from sizes.

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 and resource: it shows a phone screen on other phones and foldables, reflowed, on new artboards. That distinguishes it from plain resize or add_artboard siblings by emphasizing reflowed responsive variants on newly created artboards. The verb 'show' is a little vague, but the overall purpose is clear.

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

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

The description implies when to use it: when you want to see a phone screen adapted to other phones and foldables. It does not explicitly say when not to use it, what prerequisites are required, or which sibling tools to use instead, such as resize or export_artboard.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotent, so the agent knows this mutates state. The description adds nothing beyond that — it doesn't say whether the original shapes are consumed or replaced, whether an existing symbol with the same name collides, or how instances are created afterwards.

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 short sentence with no padding, but its brevity comes at the cost of under-specification rather than efficiency. The core action is front-loaded, which is the one structural strength.

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

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

A destructive, non-idempotent mutation with no output schema and no documented parameters needs more than one sentence. The agent cannot tell what the return value represents, whether shapes are destroyed or converted in place, or what failure modes exist.

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% for two parameters. The description only weakly implies the plural-shape input ('shapes') and never explains shape_ids format/ordering or what omitting the optional name does (auto-naming vs. error). The schema carries no meaning of its own, so the description should compensate and does not.

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

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

States a specific verb and resource: turns shapes into a symbol, which is distinguishable from group/ungroup and from place_symbol/detach_symbol/list_symbols. It does not explicitly name those siblings, but the operation itself is unambiguous.

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

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

No guidance on when to use this versus grouping shapes or creating a symbol instance, and no prerequisites (selection state, artboard context) are mentioned. The agent must infer that the shapes already exist and are referenced by id.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so 'without moving anything' mostly restates what structured data provides. The description does not explain what the reported correction consists of (units, per-shape vs aggregate, coordinates) — notable given there is no output schema.

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

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

One sentence with no filler, and the non-mutation constraint is front-loaded. But the brevity comes at the cost of under-specification rather than efficiency — it is short because it says almost nothing.

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

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

With no output schema, three undocumented parameters, and an enumeration the agent must guess at, the description leaves critical gaps: what the returned correction is, in what units, and whether shape_ids/container_id scope the result. It is not sufficient to call the tool correctly without trial and error.

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 three parameters: axis (enum both/horizontal/vertical), shape_ids, and container_id are entirely undefined in both schema and description. The description does not compensate at all — it never mentions scope, coordinate system, or what the axis restriction does to the measurement.

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 verb ('Report') and resource ('optical-centre correction') are specific, and 'without moving anything' implicitly contrasts it with the mutating sibling optical_center. It never names that sibling, so an agent must infer that optical_center is the tool that applies the correction.

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

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

There is no explicit when-to-use statement, no prerequisites, and no named alternative, despite optical_center being the obvious counterpart. The non-mutating phrasing only faintly implies a 'preview before applying' workflow; nothing routes the agent between the two 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds that measurement occurs without drawing, a useful behavioral distinction, but it omits what is returned (bounding box, line breaks, dimensions) and any dependency on current document/style 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?

A single front-loaded sentence with no filler or redundancy. It is concise and immediately states the tool's function, though its brevity leaves required detail to other dimensions.

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

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

For an 11-parameter, no-output-schema tool, the description is not complete: it does not explain the return shape or how the many typography/layout parameters affect measurement. Annotations cover safety but not the missing operational context.

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?

Eleven parameters exist with 0% schema description coverage, including content, font properties, max_width, line_height, and anchors. The description contains no parameter-level semantics and does not compensate by mapping any of these controls to the measurement result.

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 ('Measure') and resource ('text'), and 'without drawing it' distinguishes this from sibling text-drawing tools such as set_text or text_on_path. An agent can identify this as a non-rendering measurement tool without opening the schema.

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

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

The phrase 'without drawing it' implies the tool is for checking text layout when rendering is unnecessary or undesirable, but it does not name alternatives or state explicit when/when-not conditions. Guidance is implied rather than spelled out.

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