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

With no annotations, the description carries the full burden and does disclose the most important behavioral trait: partial-failure semantics (colliding or invalid parts are skipped and reported, the rest still place). That is genuinely non-obvious and valuable. It stops short of stating idempotency, whether a failed batch is retryable, or permission requirements, so it is strong but not exhaustive.

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, zero filler, with the core action front-loaded and the failure/return behavior following. Every clause 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?

An output schema exists, so return-format detail is largely covered (the description still notes new part ids). The main gap is usage context relative to siblings and any prerequisite/safety expectations for a mutation tool with no annotations.

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 top-level 'parts' parameter has no schema description, but the nested PartSpec fields (part, color, y, rot) are documented in the schema. The description adds only the cardinality hint 'one or more', which is marginal beyond what the schema provides, so a baseline 3 is 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?

States a specific verb+resource ('Place one or more parts') with batch scope made explicit. It is immediately distinguishable from siblings like list_parts, remove_parts, and check_model without opening any 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 description says nothing about when to reach for this tool versus alternatives. There is no mention of check_model for pre-validation, undo for reversal, or new_model/open_model as prerequisites, leaving the agent to infer placement context entirely.

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

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

With no annotations, the description carries the full burden and does add non-obvious geometry semantics: orientation orientation and the plate/brick tradeoff. But it says nothing about whether the tool clears existing bricks, whether it requires an open/current model, how large a mosaic can be, or what happens on failure — significant gaps for a mutating build 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?

Two dense sentences that front-load the purpose and then the orientation/kind semantics; nothing is wasted. The telegraphic 'image top = back' phrasing is compact but slightly cryptic without further context.

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?

An output schema exists, so return values need not be described. But for a 10-parameter mutation tool with zero annotation coverage and only two of ten parameters addressed, the definition is not complete enough to call confidently — placement, cropping, sizing, and limit behavior all remain opaque.

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 10 parameters are present, so the description must compensate. It does explain 'kind' and 'orientation' meaningfully, but x, y, z, crop, width, height, image_path, and max_colors receive no explanation at all — notably crop's expected format and max_colors' quantization behavior are left entirely undocumented.

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

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

States a specific verb and resource ('Build a picture directly as a mosaic in the current model'), which is concrete and actionable. It does not name or contrast with the closest sibling, image_to_grid, so an agent must infer the difference between building a mosaic directly and converting an image to a grid.

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 implicitly guides when to pick each orientation and kind value ('plate gives fine vertical detail, brick is sturdier'), which is useful selection guidance. However there is no explicit when-to-use-this-vs-alternatives statement, no mention of prerequisites such as needing an open model or how it relates to image_to_grid, and no exclusions.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Check' strongly implies a read-only analysis, and the output schema covers return values, but the description does not explicitly state side effects, permissions, or that the model is not modified. It does add useful domain definitions of floating and loose groups.

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 parenthetical definitions that earn their place by clarifying the two structural failure modes. There is no redundant or 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 no-argument check tool with an output schema, the description explains what structural conditions are detected, which is the core semantic need. It omits usage timing and whether it targets the currently loaded model, but the output schema covers return details and the tool is otherwise simple.

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 are no parameter semantics to document. Per the baseline rule for a 0-parameter tool, a 4 is appropriate because the schema cannot be enriched further from 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 description gives a specific verb ('Check') and resource ('structure'), then defines the two diagnostics: floating groups and loose groups. It is clearly not a generic model operation, though it does not explicitly differentiate itself from siblings like describe_model or render_model.

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, prerequisites, or alternatives are provided. The description only defines the categories it checks; it never states when an agent should call this tool versus inspecting the model another way.

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

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

With no annotations, the description carries the full burden. It usefully discloses rendering conventions (first row = back, uppercase letters = legend colours) and the levels/all_levels switching behaviour, and 'Summarise' implies a non-mutating read. But it never states this is read-only, what happens with an empty or invalid level list, or whether output is text or image.

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 what the summary contains before the parameter semantics. The parenthetical footnote on row ordering is dense but earns its place; nothing is redundant.

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

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

An output schema exists, so return shape need not be restated, yet the description attempts it anyway. The real gap is `list_all_parts`, which is undocumented everywhere, plus the absence of any read-only/mutation disclosure for a tool with zero annotations.

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 there are three parameters, so the description must compensate. It explains `levels` and `all_levels` adequately but says nothing about `list_all_parts`, leaving one of three parameters undocumented in both schema and 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?

States a specific verb (Summarise) and resource (the model) and enumerates the outputs: bounds, part counts, colour maps. It does not, however, distinguish itself from siblings that also surface model contents (list_parts, list_colors, render_model), so the agent must infer the boundary.

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

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

The description gives a conditional for one parameter (maps shown for `levels`, or every level when all_levels is set), which implies usage, but never says when to reach for this tool versus list_parts, list_colors or render_model. 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses output granularity (one build step per level) and a real failure mode plus its cause/fix (missing parts -> legacy_ids=True). However, it never says where the file lands when path is null, whether an existing file is overwritten, or what the call returns on success/failure.

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

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

Three short sentences, front-loaded with the primary action and format, followed by workflow and a conditional tip. Every sentence adds something; the only mild excess is the UI navigation path, which is nonetheless actionable.

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

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

The tool is simple and an output schema exists, so return values need not be restated. Still, with 0% schema description coverage and a null-defaulting path parameter, an agent lacks what it needs to predict where the file is written or whether it clobbers an existing file.

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 both parameters. It does explain legacy_ids well with a concrete example (3023 instead of 3023b), but path is left completely unexplained despite defaulting to null, leaving half the parameters opaque.

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: write the model as an LDraw .ldr file, with the added detail that it is one build step per level. That is enough to separate it from adjacent siblings like render_model, image_to_grid, or describe_model. It does not name any sibling explicitly, so it lands just short of the top mark.

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 supplies concrete downstream workflow (import via Mecabricks Workshop > File > Import) and a conditional remedy: if parts come in missing, re-export with legacy_ids=True. That is real use guidance rather than a bare 'call this to export'. It does not state when not to use it, but no sibling export tool exists to route away from.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses auto-packing, skipping already occupied cells, staggered seams, per-layer height depending on kind, and coordinate placement. It still omits mutation/reversibility details, permission needs, and failure 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 front-loaded with the core action and then structured into compact paragraphs covering layers, legend, placement, and upright mode. Despite its length, the detail is necessary for a nested map-based tool and every sentence contributes.

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-parameter tool with nested arrays/objects, no annotations, and no schema descriptions, the description is strong and covers the essential map format and placement behavior. It misses some parameter edge semantics and explicit model-context behavior, but the output schema covers return-value details.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the layers matrix orientation, legend mapping with examples, x/z as front-left corner, y as layer offset, kind height behavior, and upright mode. Gaps remain for 'tile' in kind and integer legend values.

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

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

The first sentence states a specific verb and resource: 'Build volume from colour maps, automatically packed into bricks/plates/tiles.' This distinguishes the tool from generic part addition or mosaic conversion. It does not name siblings, but the resource and packing behavior make the purpose 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?

The description gives use context only for the upright mode ('Handy for mosaics and facades'), implying when that variant is useful. It never states when to use fill_layers over alternatives such as build_mosaic, image_to_grid, or add_parts, so routing guidance is incomplete.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses the output representation (rows of letters, transparent -> '.') and the crop coordinate convention, but says nothing about palette quantisation behaviour, max_colors clamping, or whether the result is returned vs written to a file.

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

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

Four tight sentences, front-loaded with the core action, then the two highest-value parameter notes. No filler, though the cell/height sentence is densely packed and slightly awkward.

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?

An output schema exists so return values need no prose, and the description supplies workflow context. With 7 parameters, zero schema descriptions, and no annotations, however, an agent still lacks guidance on palette, max_colors, and sizing interplay, leaving real gaps for a transform tool of this complexity.

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 7 parameters, so the description must compensate. It explains crop's format and cell's enum meaning, but leaves width, height, palette, max_colors, and image_path entirely undocumented in both places, covering well under half the parameters.

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

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

States a concrete verb+resource ('downsample a picture into rows of colour letters') and names the downstream consumer, fill_layers, which lets an agent place it in a workflow. It does not distinguish itself from build_mosaic, a sibling that plausibly covers a overlapping end-to-end 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?

'ready for fill_layers' implies a pipeline position, and the crop/cell notes hint at intended uses (top-down maps vs upright walls). But there is no explicit when-to-use or when-not, and no mention of build_mosaic as an alternative for the same job.

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

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

No annotations are provided, so the description carries the burden, and it does disclose a real behavioral trait: results are filtered to solid colours unless include_special is set. It says nothing about result cardinality, ordering, or whether 'special' colours are a separate code space, leaving gaps for a zero-annotation 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?

Two short fragments, front-loaded with the resource and return fields. Nothing is padded, though the telegraphic style leaves gaps that a few more words could have closed at low cost.

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?

An output schema exists, so return values need no explanation, and the default-filter behavior is covered. However, with no annotations and an unexplained 'search' parameter, the definition is adequate but not complete for correct invocation.

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

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

Schema description coverage is 0%, so the description must document both parameters. It explains include_special's effect well, but the 'search' parameter is never mentioned or clarified (matching on code vs name? substring vs exact?), leaving half the parameters undocumented 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?

States a specific verb (List) and resource (LDraw colours) and even names the returned fields (code, name, hex), which lets an agent distinguish it from list_models/list_parts at a glance. It stops short of explicitly contrasting with those siblings, so it is clear rather than exceptional.

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 include_special clause implies the default context (solid colours) and when to override it, which is useful implicit guidance. There is no explicit statement of when to reach for this tool versus the other list_* siblings or any prerequisite/exclusion.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only enumeration but says nothing about ordering, scope (all models vs. working directory), pagination, or what 'saved' excludes, all of which matter for an enumeration tool with zero annotation coverage.

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 four-word sentence is front-loaded and waste-free, but it is terse to the point of under-specification rather than efficient conciseness. Nothing is padded, yet nothing beyond the bare minimum is stated.

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 output schema means return values need no explanation, and with zero parameters the surface area is small. Still, with no annotations an agent gets no confirmation of read-only safety or the scope of 'saved' models, leaving the description just barely adequate.

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

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

The tool takes zero parameters and the description introduces none, so there is no parameter semantics to misrepresent. Baseline 4 applies for a no-parameter tool.

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 (saved models), which is enough to distinguish it from siblings like list_parts and list_colors by resource type. However, it doesn't clarify what 'saved' means versus unsaved/in-memory models, which matters given siblings like new_model and open_model.

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 open_model, check_model, or describe_model, nor any prerequisite or context. The agent must infer usage purely from the verb '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?

No annotations are provided, so the description carries the behavioral burden. It adds useful domain context (size measured in studs along x/z and height in plates) for a low-risk read tool, but says nothing about ordering, pagination, limits, or what a category match returns beyond the 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?

Two sentences, front-loaded with the primary listing behavior before the search alternative, and the size-unit clarification is genuinely useful. Minor density but 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?

With an output schema present, return values needn't be described, and both zero-required parameters are addressed. The description is complete enough to call the tool correctly; only ordering/pagination behavior is left unspecified.

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, and it does reasonably: it spells out the valid category values (brick, plate, tile, slope, round, misc) and explains that search matches words in the part title, with an example. It could more explicitly tie 'category' to the curated set, but the mapping is clear.

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/search) and resource (curated parts / LDraw library), enumerates the categories covered, and clearly names the two modes so it is distinguishable from list_models and list_colors.

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 each mode applies: bare listing of curated categories vs. searching the whole library by title words, with a concrete example ('window 1 x 2'). It gives clear context but no explicit exclusions or named alternatives.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose two important traits: it replaces the open model (destructive side effect) and models autosave (so existing work is persisted rather than silently lost). It stops short of describing reversibility (undo exists as a sibling) or any confirmation/error behavior.

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

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

A single, front-loaded sentence with no wasted words; the destructive effect is placed immediately after the action. It is arguably terse to the point of omitting needed parameter context, but as structure it is clean.

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?

An output schema exists, so return values need no explanation, and the description covers the key side effect and autosave behavior. The gap is parameter semantics plus any note on recoverability (undo is a sibling), which leaves the agent under-informed for a no-annotation mutation 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?

Schema description coverage is 0% and two parameters exist (required 'name', optional 'description'), yet the description says nothing about either. It does not explain what the name is used for or whether description has any constraint, leaving both undocumented in both schema and 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?

States a specific verb and resource ('start a new empty model') and distinguishes itself from open_model by emphasizing 'empty' and 'new'. However, it never names the sibling it contrasts with, so differentiation is implicit rather than explicit.

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

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

The parenthetical clarifies the effect on the currently open model, which implicitly tells the agent when this is appropriate versus open_model, but there is no explicit when-to-use or when-not-to-use guidance relative to any sibling.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not describe whether opening replaces the current model, what happens if the name is not found, or any permissions or side effects. The description adds almost no behavioral context beyond the basic action.

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 states the action and required identifier 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?

An output schema exists, so return values need not be explained. For a simple one-parameter tool, the description is minimally adequate to call it, but it leaves gaps around behavior, error cases, and parameter format that an agent might need.

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 single parameter is only documented in the schema as 'Name' with type string. The description adds 'by name' and ties the name to a previously saved model, but it does not specify format, case sensitivity, or any constraints. This is minimal compensation for the complete lack of schema-level parameter 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 states a specific verb ('Open') and resource ('previously saved model') with the scope 'by name.' It distinguishes the tool from obvious siblings like new_model and list_models, though it does not explicitly name alternatives.

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

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

The phrase 'previously saved model' implies this tool is for reopening existing models rather than creating new ones, which gives some context. However, it does not explicitly state when to use this tool versus alternatives or list any exclusions.

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

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

With no annotations at all, the description carries the full behavioral burden for a destructive operation. It does not say whether removal is reversible, that an 'undo' sibling exists, what happens when both ids and region are supplied (union vs intersection), or how an empty argument list is 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?

A single sentence with zero filler, and the key scoping words ('by id and/or') are placed early. Every clause 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?

An output schema exists, so return values need not be explained, but for a destructive tool with zero annotations and a 0%-described schema the description should cover reversibility, the undo path, and the combined-parameter semantics. Those omissions are significant for a mutation 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?

Schema coverage is 0% and the Region sub-object's coordinate fields carry no descriptions, so the description does real work: it establishes that 'region' is a grid region and that its bounds are inclusive, and that parts *touching* the region (not just contained in it) are removed. It stops short of defining the overlap predicate precisely or clarifying the union semantics of the two parameters together.

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 verb (remove) and resource (parts) and states the two selection modes, so the agent knows exactly what the tool does. It does not explicitly contrast itself with siblings like add_parts, but there is little risk of confusion since no other sibling deletes geometry.

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 id and/or ... region' implies the two mutually usable invocation modes, which is more than nothing. However, it gives no guidance on when to prefer this over alternatives such as 'undo', no prerequisites, and no warning about calling it with neither selector.

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

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

No annotations are provided, so the description carries the full responsibility. It usefully discloses two non-obvious behaviors: parts are simplified (round and non-catalog parts render as boxes) and reference_image prepends the source picture as the first panel. However, it says nothing about whether output is an image, a file path, or a side effect, which is important for a render tool with zero annotation coverage.

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

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

Front-loaded with the core action, then dense but relevant detail about views and reference_image. Slightly run-on with the inline angle list, but every clause carries information.

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

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

No output schema exists, so the description should clarify the return form, and it does not say whether rendering produces an image file, a path, or an inline preview. Combined with the undocumented 'size' parameter, the definition is adequate for calling but incomplete for predicting the result.

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

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

Schema coverage is 0%, so the description must compensate. It does well for two of three parameters: views enumerates the valid named angles and the 'azimuth,elevation' degrees form, and reference_image's effect is explained. The 'size' parameter is never addressed, leaving a gap at this coverage 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?

States a specific verb+resource ('Render a preview sheet'), which is clear enough to distinguish it from the other model/part manipulation siblings. It does not name an alternative rendering/inspection tool, nor contrast with describe_model or check_model, so sibling differentiation is only implied by the noun 'preview sheet'.

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 documents default views but never states when to reach for this tool versus describe_model or check_model, nor any preconditions (e.g., a model must be open). Usage is only implied by the 'preview' framing.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a mutation and a single-step scope via 'the last,' but does not disclose whether undo is itself reversible, whether repeated calls walk back further, how deep the undo history goes, or how failures are surfaced.

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 efficient, though its brevity borders on under-specification for a state-mutating operation rather than being 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?

An output schema exists, so return values need not be described, and there are no parameters to cover. What remains missing for a zero-annotation mutation tool is undo breadth, stack behavior, and the no-op/error case, leaving the definition just barely adequate.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter information is missing because none exists.

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 ('Undo') and scopes it to 'the last building action,' which tells an agent this is a single-step reversal, not a general history reset. It does not, however, distinguish itself from siblings like remove_parts or new_model, nor clarify which of the many building operations it can reverse.

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 versus other corrective tools (e.g., remove_parts), no mention of prerequisites, and no statement about what happens when there is nothing to undo. The agent must infer all usage context.

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