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

Annotations declare non-read-only, non-destructive, closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: the new part starts empty and 'its size follows its voxels,' which tells the agent the part is defined implicitly by drawn geometry.

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

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

Three short sentences, front-loaded with the core action, followed by usage rule and next-step pointer. No filler; the parenthetical definition is valuable rather than 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?

For a two-parameter, no-output-schema creation tool, the description covers what is created, when to create one, and what to do next. It could state how the newly created part is referenced by the draw_* tools, but that gap is minor.

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%, with both 'name' and 'project' documented and exemplified in the schema, so baseline is 3. The description adds only a conceptual gloss ('one named object'), not new parameter syntax or constraints.

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 ('Add an empty part to the body') and clarifies the domain concept as 'one named object in the .vox file.' It is clearly distinguishable from siblings like remove_part, though it does not name the inverse operation 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?

Gives concrete when-to-use guidance ('Use one part for the main body; separate parts only for pieces that are separate objects in the XML') and routes the agent to the next step ('Draw into it with the draw_* tools'). It lacks an explicit when-not-to-use or a direct pointer to a named alternative.

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 a non-destructive write (readOnlyHint=false, destructiveHint=false), and the description adds valuable behavior beyond that: it creates multiple named parts (wheel_fl/fr/bl/br) in one call and warns that body geometry must not overlap the result. It does not say whether existing wheels are replaced or how name collisions are handled, which keeps it from 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 core purpose is front-loaded in the first sentence, followed by naming convention, a concrete example, and a placement warning. It is dense and mostly earns its length, though the axle-count naming enumeration is somewhat long for marginal benefit.

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 8 parameters, 6 required, no output schema and no nested objects beyond AxleSpec, the description covers naming, geometry, and the overlap constraint well. It omits what happens on failure/overlap and whether prior wheels are replaced, but nothing essential to invoking it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds genuine meaning the schema lacks: the worked example ties axles, diameter, width and inner_x together (inner_x 9, width 2 → wheels at X -11..-9 and 9..11) and explains the naming derivation across 1–4 axles. That is added value above the per-parameter text.

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 ('Add a left and a right wheel per axle, as separate parts with axle data for the XML') plus the scope of what it produces. This is clearly a higher-level semantic wheel builder, distinguishable from generic draw_cylinder/draw_box siblings 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 supplies a prerequisite constraint ('The body must not overlap the wheels: raise the body or carve wheel arches') and geometric conventions, which implicitly tells the agent when this tool applies. However, it never names an alternative (e.g. draw_cylinder for custom wheels) or states when not to use it, so routing guidance is only implied.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: the project starts empty and is persisted to the workspace, which an agent needs to know before chaining creation and drawing calls.

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 lines, front-loaded with the action and the storage location, then the format constraint the agent must satisfy, then the next-step pointer. No sentence is redundant or verbose.

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 three-parameter creation tool with no output schema and non-destructive annotations, this covers purpose, naming constraint and follow-on workflow. The only gap is error/return behavior — what happens on a name collision or what the call yields — which is minor at 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 coverage is 100%, so the baseline is 3, and the description pushes past it by supplying the naming rule for 'project' (1-40 lower-case letters, digits or '_', starting with a letter) that the schema only illustrates with an example. It adds nothing for 'kind' or 'description', which the schema already documents.

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 ('Create an empty modelling project') plus where it lands ('saved in the workspace'), so an agent can distinguish it from list_projects or project_summary at a glance. It stops short of explicitly naming the sibling tools it must not be confused with, which keeps it just under 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?

Gives concrete sequencing guidance — 'Next: define_color, then add_part and the draw_* tools' — which tells the agent when this tool belongs in a workflow and what comes after. It offers no exclusion or alternative path (e.g., what to do if the project already exists), so it is clear context without full when/when-not coverage.

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

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

Annotations already mark this as a non-read-only, closed-world tool, and the description adds real behavioral content by giving the exact cut criterion (d1/depths[0] + d2/depths[1] < 1) and what physically happens (voxels within the ellipsoid are removed/cut). It does not discuss reversibility or interaction with undo, and the default carve mode removing voxels sits in mild tension with destructiveHint=false, but the geometric behavior is well disclosed.

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

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

Front-loads the purpose, then the precise cut formula, then a single compact example; every sentence carries information. The formula is dense but earns its place by making the geometry reproducible.

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 annotations covering the safety profile, the description supplies the purpose, the cut geometry, and a concrete coordinate example. It leaves the mode/color interactions to the schema and omits undo/irreversibility notes, but nothing essential for correct invocation is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description genuinely deepens parameter meaning: it shows depths as a directional pair via the inequality and the worked example ("5 voxels down, 6 back"), and ties edges/depths together concretely. That goes beyond restating the schema.

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

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

States a specific verb+resource ("Bevel or slope edges of a block of the part") and grounds it with concrete automotive examples (windshields, hoods, rounded roofs). It does not explicitly differentiate itself from siblings like hollow_part or draw_wedge, so it stops short of a 5, but the operation 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?

Usage is only implied through examples ("windshields, hoods, rounded roofs") and a worked cabin-slope case. There is no explicit when-to-use statement, no named alternative for edge work, and no stated prerequisites, so the agent must infer context from the examples 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?

With readOnlyHint=false already covering mutability, the description adds strong behavioral context: redefining a name rewrites rgb/finish everywhere it is used, the material itself is immutable, and each material has only 8 or 16 slots. It omits what happens when slots are exhausted and carries mild tension with destructiveHint=false given the global rewrite, but the added detail is well beyond the annotations.

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

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

Front-loaded with the definition, then the semantic distinction, examples, redefinition caveat and a worked example. Nearly every sentence carries information, though the closing example partially restates fields the schema already describes, adding slight redundancy.

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

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

For a 5-parameter mutation tool with no output schema, the description covers purpose, semantics, side effects and constraints well enough to call correctly. The remaining gaps are the return behavior and slot-exhaustion failure mode, which are minor but unaddressed.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema lacks: material governs physical breakage while color/finish is purely visual, and finish 'emissive' glows for lights. This helps the agent choose values rather than merely read their types.

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 opening line gives a specific verb+resource ('Define a named color') and immediately characterizes the artifact ('a material plus a displayed color'), then ties it to the sibling family ('used by the drawing tools'). An agent can distinguish this definition-only tool from drawing siblings like draw_box or add_part 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?

It supplies concrete usage contexts ('body paint weak metal', 'windows glass', 'lights finish emissive') and makes the dependency on the drawing tools explicit, which tells the agent when this is relevant. However it never states the operational ordering (define before draw) or any exclusions, so it stops short of explicit when/when-not guidance.

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

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

With annotations already declaring readOnlyHint=false, openWorldHint=false and destructiveHint=false, the description adds real behavioral context beyond them: the exclusive `end` boundary, that 'add' replaces voxels present in the region and grows the part, and that 'carve' removes the part's voxels. Note the mild tension between 'carve removes voxels'/'add replaces voxels' and destructiveHint=false, though the existence of a sibling `undo` tool makes the non-destructive hint defensible.

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-loads the core semantics (verb, resource, half-open interval) in the first sentence, then spends the remaining lines on one dense worked example plus a single carve use-case line. The example is longer than a bare definition but it earns its place; no filler sentences about the tool's importance.

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-parameter mutation tool with no output schema, the description plus the 100%-covered schema covers coordinates, bounds, modes and color requirements well enough to invoke correctly. It does not address return values or whether coordinates outside the part's current extent are permitted, which is a minor gap given the tool's complexity and the presence of `preview`/`inspect` siblings for verification.

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

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

Schema description coverage is 100%, so the baseline is 3; the description earns an extra point by supplying a worked example that translates physical model units into integer voxel coordinates ('a body 1.6 m wide ... start [-8, 3, -20], end [8, 9, 20] (16 x 6 x 40 voxels)'), which clarifies the model frame and scale that the schema alone does not pin down.

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 family (add/paint/carve) and resource (rectangular block of cells / voxel box), and the half-open interval notation makes the geometric primitive unambiguous. This clearly distinguishes it from siblings draw_cylinder, draw_ellipsoid and draw_wedge without needing to open their schemas.

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 concrete usage context ('Carve a cabin interior or wheel arches with mode `carve`') and a fully worked example with realistic dimensions, which tells the agent the intended scale and coordinate convention. It does not, however, explicitly state when to prefer a box over the other draw_* primitives or any prerequisites (e.g. the part must already exist), so it is clear but not exhaustive.

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-open-world, non-destructive mutation, so the safety profile is largely covered. The description adds the mode semantics implied by the verb set (carve removes voxels) but says nothing about reversibility, required color, or required permissions. Note the mild tension between 'carve' (voxel removal) and destructiveHint=false, though the sibling 'undo' tool makes this plausibly a reversible edit rather than a true contradiction.

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 lines: purpose, one worked example, one exclusion. The example is dense but earns its space by pinning down several coordinate conventions at once, and the exclusion is front-loaded before the agent commits.

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, 6-required mutation tool with no output schema, the definition covers the geometry conventions and the key sibling routing. It omits the color requirement and the default mode behavior, both of which the schema covers, so nothing critical for correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already carries the parameter burden (baseline 3). The description earns above baseline by supplying a fully worked example that disambiguates the two-element center array, the axis convention, radius and span endpoints in one concrete case.

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 specific verbs (add/paint/carve) plus the resource (cylinder), and immediately differentiates itself from siblings by naming draw_box-style semantics and giving concrete use cases (pipes, headlights, exhausts, round details). An agent can tell this apart from draw_box, draw_ellipsoid and add_wheels 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?

Explicitly excludes one alternative case ('Wheels: use add_wheels instead.'), which is genuine routing guidance. It does not, however, say when to prefer a cylinder over draw_ellipsoid or draw_box, so it stops short of full when/when-not coverage.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description adds the meaningful 'what gets replaced' detail ('add' fills with color replacing voxels there, 'paint' recolors only existing voxels, 'carve' removes them). The carve wording ('removes the part's voxels') sits in mild tension with destructiveHint=false, though the undo sibling makes the edit reversible, so it reads as clarification rather than contradiction. No pagination/return-format concerns apply for a modeling op.

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, front-loaded blocks: a purpose sentence followed by a single worked example, with no filler. It loses a point only because the example's meter-to-voxel mismatch adds a small ambiguity rather than clarity.

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

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

For a drawing primitive with full schema coverage and no output schema, the description plus schema covers everything needed to invoke it: the shape definition, the three modes, the color requirement and a placement example. Nothing essential to correct invocation is missing.

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

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

Schema coverage is 100%, so the schema already documents center, radii, mode, color, part and project, and the baseline is 3. The description contributes the inclusion rule ('voxel centers inside the surface') and ties center/radii together in the example, but the example itself is ambiguous because it mixes meters ('1.2 m wide') with voxel radii [6, 4, 10] without explaining the scale factor.

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 three concrete operations (add, paint, carve) on a specific resource (ellipsoid or sphere) and defines the geometry rule ('voxel centers inside the surface'). This clearly separates it from siblings draw_box, draw_cylinder and draw_wedge without opening their schemas.

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?

Mode semantics (add/paint/carve) are stated, and the dome-on-a-roof example gives concrete placement context, but the details of each mode live in the schema, not the description. There is no explicit statement of when to pick an ellipsoid over draw_box/draw_cylinder, nor prerequisites such as the part already existing or needing define_color 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 declare non-read-only, non-destructive, non-open-world. The description goes beyond that by disclosing what each mode actually does to voxels ('add...replacing voxels there, growing the part'; 'carve removes the part's voxels inside the shape'), which is real mutation context. It does not address reversibility or authorization, keeping it at 4 rather than 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?

Short and front-loaded, with the mode variants and the geometric consequence stated first and the example last. The mid-sentence line break and the slightly awkward 'as deep as the block goes' phrasing cost a point, but there is no filler.

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

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

For a 7-parameter, 5-required mutation with no output schema, the description covers the shape semantics, the face-edge rule, and the mode effects, while the schema covers all parameter details and annotations cover the safety profile. Gaps (behavior when start/end exceed the part, response format) are minor.

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. The description still adds meaning the schema does not: it explains that the edge between faces[0] and faces[1] is the removed edge and illustrates with a face pair, clarifying how the two face arguments interact rather than just enumerating their enum 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?

States a specific verb and resource ('add, paint or carve a ramp') and precisely describes the geometry produced: the block from start..end cut diagonally. It is clearly distinct from draw_box/draw_cylinder/draw_ellipsoid in behavior, but never names or contrasts those siblings 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?

The three modes are described in the schema, and the description supplies a concrete worked example (hood sloping to the front, faces ['top','front']), which implies usage. However it never says when to choose a wedge over cut_edges or draw_box/cylinder, and gives no prerequisites or exclusions.

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

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

With annotations already declaring destructiveHint=true and readOnlyHint=false, the description adds real context beyond them: the exact write path (workspace/mods/<mod name>/), the set of files emitted, the reported warnings (missing anchors, overlapping parts, pieces that may fall apart), and the default-preserving skeleton behavior ('keeps your edits'). It does not state what happens if the target mod folder already exists, which holds it back from 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 first sentence is well front-loaded and earns its place, but the closing sentence ('Then write info.txt and spawn.txt (teardown_reference "mod_files")') is a dangling fragment that reads as a note about a follow-up step rather than this tool, muddying scope. The middle paragraph is dense but useful.

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?

There is no output schema, so the description does the work of characterizing returns by naming the generated files and the warnings emitted — good coverage for a mutation tool. It is nearly complete; the gaps are overwrite semantics for an existing mod folder and clarity on whether info.txt/spawn.txt are produced here.

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 including the skeleton enum and mod_name default are already documented. The description only echoes 'XML skeleton' and the mod folder name; it adds no format or syntax detail beyond the schema. Baseline 3 applies when the schema carries the parameter burden.

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

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

Opens with a specific verb and resource — 'Export the model as a mod folder' — and enumerates exactly what the tool produces (.vox, manifest JSON, XML skeleton). An agent can distinguish it from preview/inspect/slice_layers without opening the schema, since those do not emit a mod folder.

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 implied as the final packaging step ('the user copies it into the game's mods folder') and it points at a related tool (teardown_reference 'mod_files'), but there is no explicit when-to-use/when-not statement or a named alternative such as preview or inspect. The reader must infer that this is the terminal packaging step.

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 it is not read-only and not destructive, and the description adds useful behavioral context beyond that: the shell remains joined by faces on slopes and curves (a correctness guarantee), and openings are meant to be carved separately. It does not mention undo behavior or limits, but the added algorithmic detail is genuine 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?

Two short sentences with the core action front-loaded and the follow-up carving note second. No wasted words, though the parenthetical '(fewer voxels, interiors)' is slightly redundant with the opening 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 mutating part-editing tool with annotations covering the safety profile and a fully documented schema, the description covers what the operation produces and the natural next step. It omits any mention of undo/reversibility, but nothing critical to correct invocation is missing.

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

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

Schema description coverage is 100% (part, project, thickness all documented with examples and bounds), so the schema carries the parameter burden. The description does not add format or semantics beyond what the schema already provides, 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?

States a specific verb and resource ('Empty the inside of a part, keeping a shell') and immediately clarifies the resulting form ('fewer voxels, interiors'). This is clearly distinguishable from sibling draw_* and cut_edges tools that add or subtract geometry rather than hollowing it.

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

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

Provides clear sequencing guidance: hollow first, then 'Carve openings (doors, windows) afterwards if needed.' It tells the agent where this fits in a workflow but doesn't name alternative tools or state when hollowing is not 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 establish readOnlyHint=true and openWorldHint=false, so safety is covered; the description goes further by enumerating the exact output payload (voxels and meters, filled extent, per-material counts, palette index, face-connected pieces), which matters because there is no output schema. It also surfaces a non-obvious domain caveat about pieces held together only by edges/corners. No contradiction with the read-only annotation.

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 a one-line statement of purpose, followed by a compact breakdown of the returned fields. Both sentences carry information; there is no filler. Slightly long on the output enumeration, but 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?

For a read-only, two-parameter tool with no output schema, the description compensates well by describing the return payload in detail, which is exactly the gap an absent output schema leaves. The one remaining gap is sibling routing against project_summary, which the description never addresses.

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%: the 'part' parameter is already documented as 'Only this part; default: the whole model' and 'project' is documented with an example. The description adds nothing about either parameter, including the part-scoping behavior, so this sits at the baseline where the schema does all the work.

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

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

The name 'inspect' is ambiguous, but the description immediately resolves it: 'Describe the model in text: sizes, materials, colors and connectivity.' It spells out the returned content (voxel/meter sizes, filled extent, per-material voxel counts, face-connected pieces), so an agent knows exactly what resource is being reported. It stops short of naming how it differs from the overlapping sibling project_summary.

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 that edge/corner-touching voxels 'may fall apart when damaged in game' hints this is a model-integrity check before export, but there is no explicit when-to-use or when-not-to-use statement. None of the plausible alternatives (project_summary, preview, slice_layers) are referenced, so the agent must infer the distinction on its own.

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 and openWorldHint=false, so the safety and scope profile is covered structurally. The description adds only the workspace-scoping phrase and says nothing about pagination, ordering, or result size, so it contributes little beyond the annotations.

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

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

A single short sentence with no filler or redundancy, front-loading the action and resource. Nothing could be trimmed without losing meaning.

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 the core intent is covered, but with no output schema present the description gives no hint of return shape, ordering, or whether results are paginated. Minimum viable rather than 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?

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

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 (projects) with a scope qualifier (of the workspace), so the operation is unambiguous. It does not, however, differentiate itself from the sibling project_summary or explain how the two differ.

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 the verb 'List' – an agent can infer this is the browse-enumeration call, but the description names no alternative (e.g. project_summary) and states no conditions for choosing between them. Adequate for a trivial read-only listing, but no explicit guidance.

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

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

The annotation destructiveHint=false declares only additive updates, yet the description states 'Voxels on the replaced side are discarded,' which is a destructive update to the model. This directly contradicts the annotation, so the transparency score is pinned at 1 despite the otherwise useful disclosure of the default-plane behavior and the wheel limitation.

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

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

The core action is front-loaded in the first sentence, followed by the geometric behavior, workflow, and exception in a logical order. Four short sentences with essentially no filler, though the trailing parenthetical aside is 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?

For a mutation tool with no output schema and fully documented parameters, the description covers purpose, geometric effect, a data-loss warning, and an edge-case exclusion. The main omission is permission/error behavior and what happens if the part spans the plane asymmetrically, but the essentials are present.

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

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

Schema description coverage is 100% (each of the four parameters is documented, including the 'keep' enum mapping to X below the plane), so the schema already carries the load. The description adds only the geometry framing of the default plane X = 0 and the -8..8 example, which is modest value over the schema.

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

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

The first sentence gives a specific verb and resource ('Make a body part left-right symmetric: copy one side, mirrored, over the other side'), which is unambiguous. It partially differentiates from siblings by noting that wheel parts are handled by add_wheels, but it does not contrast against other geometry tools like move_part or hollow_part.

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 a concrete workflow ('Model details on the left side, then mirror') and a clear when-not case ('Wheel parts cannot be mirrored (add_wheels already makes both sides)'). There is no explicit statement of prerequisites (e.g., the part must already exist) or a named alternative for non-body parts, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false. The description adds operation-specific side-effect information beyond annotations: a wheel's axle moves with it, while anchors stay in place. It does not discuss reversibility or permissions, so it is useful 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?

The definition is a single front-loaded sentence with no filler. The most important information, the move action, comes first, and the parenthetical adds a compact behavioral note.

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 three-parameter mutation tool with full schema coverage and no output schema, the description covers purpose and one key side effect. It remains incomplete on when to choose this tool over siblings and on reversibility, leaving clear gaps for an agent.

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

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

Schema description coverage is 100%, with project, part, and offset each documented in the input schema. The description adds no parameter syntax, constraints, or examples beyond what the schema already provides, so the baseline of 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?

The description uses a specific verb ('Move') and resource ('a part'), and the parenthetical clarifies operation scope for wheels and anchors. It does not explicitly differentiate itself from siblings such as mirror_part or add_part, 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 when-to-use guidance, no alternatives named, and no prerequisites stated. The description only declares what the operation does, leaving the agent to infer selection context from the tool 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 declare readOnlyHint=false with destructiveHint=false, and the description usefully explains that discrepancy: the tool writes preview.png into the project folder as a side effect while modifying nothing in the model. It also documents what the image contains (rulers in model-frame meters, magenta axle/anchor markers), which is real context beyond the annotation flags. It doesn't cover output resolution/format or whether renders are cached.

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?

Purpose is front-loaded in the first sentence, followed by interpretation notes and the side-effect disclosure. Every sentence carries information an agent needs to read the resulting image, though the orientation paragraph is dense and could be tightened.

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 must convey what comes back, and it does: annotated orthographic/3-4 panels, ruler units, marker meanings, plus the saved preview.png. Enough to act on confidently; only minor details (image size, confirmable file path behavior) are absent.

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 genuine meaning for the 'views' enum values by defining orientation conventions ('front view (camera at -Z) shows the model's right side (+X) on the image LEFT'). It adds less for 'part' and 'project', which the schema already documents adequately.

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 the model as an image with several annotated views') and immediately frames scope ('Look at it after edits'). This clearly separates it from siblings like inspect, slice_layers, and export_model, which serve different purposes.

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?

'Look at it after edits' gives a clear usage context and implicitly answers when this tool is the right call. It stops short of naming alternatives or exclusions (e.g., when to prefer inspect or export_model instead), so it is a clear context rather than full routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds useful return-content detail (colors, part extents in voxels and meters, wheels, anchors), which matters because there is no output schema, but it does not disclose operational behavior such as auth needs or 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 efficiently lists the key return categories without repeating the tool name or schema details.

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, single-parameter summary tool with annotations covering safety, the description identifies the returned data categories, compensating for the absent output schema. It leaves a minor gap by not distinguishing itself from siblings such as inspect, but is otherwise sufficient.

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%; the single project parameter is fully documented with an example. The description adds no parameter syntax or constraints beyond the schema, so the 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?

"Show" is a specific verb and the object enumerates a project's colors, parts with extent units, wheels, and anchors, so the purpose is clear. It does not explicitly differentiate itself from siblings like list_projects or inspect, preventing 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 description contains no when-to-use, prerequisites, or alternative-tool guidance. Nothing tells the agent when to choose this over list_projects or inspect; it only states the output content.

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, so the safety profile is partly covered. The description adds two genuinely useful facts beyond them: the blast radius ('all its voxels') and reversibility via undo. It does not say whether removal cascades to references or fails on a missing part, so it is not a full 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?

A single front-loaded sentence with the destructive scope stated first and the recovery note in a compact parenthetical. 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?

For a two-parameter, no-output-schema mutation tool whose annotations already flag destructiveness, the description covers the essential questions: what is destroyed and whether it can be reversed. Only edge-case behavior (cascading references, missing-part errors) is unaddressed, which is 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 description coverage is 100%, with both 'part' and 'project' documented including naming examples, so the schema carries the parameter burden. The description adds no format, naming, or validation detail beyond what the schema already provides, making 3 the correct baseline.

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

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

States a specific verb (delete) plus the resource (a part) and even the scope of deletion (3all its voxels3), which distinguishes it clearly from add_part and the drawing tools. It stops short of naming a sibling, but the operation 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?

The parenthetical '(undo brings it back)' implies the recovery path and points at the sibling undo tool, giving some usage context. However, there is no explicit statement of when to choose remove_part versus alternatives such as hollow_part or teardown_reference, nor any precondition 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 cover the safety profile (mutating but not destructive), and the description adds real behavioral context beyond them: 'Anchors stay put when parts move' (persistence), exhaust smoke emission verified in-game, and null deletes the anchor (via schema). It omits overwrite/re-set behavior and permission requirements, keeping it short of 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?

Front-loads the purpose, then adds only relevant clauses. Parentheticals ('meaning not documented', 'verified in game') are a bit loose but each carries information; nothing is padding.

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-param mutation with no output schema, the description covers naming semantics, coordinate space, persistence, and deletion. Missing details like re-setting an existing anchor or name uniqueness are minor gaps rather than blockers.

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% (baseline 3), but the description adds meaning the schema lacks: the player-position convention ('official cars put it on the left, negative X'), the candid 'vital (meaning not documented)' caveat, and a concrete example value '[−4, 9, 2]'. That is genuine added value over the schema.

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

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

States a specific verb+resource ('Set a named point of the model') and enumerates what anchors represent (driver position, exhaust, lights), so the agent understands the domain. It never names or contrasts a sibling (e.g. move_part, add_part), so differentiation is implied 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 description explains the semantics of the key names (player, vital, exhaust) which implies use for vehicle rigging, but gives no explicit when-to-use or when-not-to-use compared to alternatives like move_part or add_part. Usage is inferred, not 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the output is a text grid with coordinate-labelled rows/columns and a legend mapping symbols to palette index and material, which is valuable 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?

Two compact sentences with no filler. The core action and output shape are front-loaded, and the legend/coordinate detail follows as supporting information. 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?

For a read-only inspection tool with no output schema, the description adequately explains what the agent receives (grid, coordinates, legend). The only real gap is how this output relates to the other inspection siblings, and there is no mention of the 1-8 position limit, though the schema covers that.

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

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

Schema description coverage is 100%, and the schema's axis description is richer than anything in the tool description (orientation of x/y/z views). The description adds only the notion of 'model-frame voxel coordinates' for the layer positions. This is a baseline 3: the schema already carries the parameter semantics.

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 (print) and resource (layers of the model) and specifies the output form (text grids, one symbol per voxel, '.' = empty). It is clear what the tool does, but it never contrasts itself with plausible siblings such as 'preview' or 'inspect', so an agent gets no explicit sibling differentiation.

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

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

There is no when-to-use guidance at all. With siblings like 'preview', 'inspect' and 'export_model' in the same toolset, an agent is left to infer when slicing layers is preferable to those alternatives; the description offers no conditions, exclusions or named replacements.

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 read-only and non-open-world, but the description adds that each fact includes a verification status (in-game vs. official files). This is valuable behavioral context about the output, beyond the safety hints.

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

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

Two concise sentences that front-load the purpose and then add a key detail. No wasted words, though the first sentence could be slightly clearer.

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 read-only lookup with one parameter and no output schema, the description adequately explains the tool's domain and output characteristic (verification status). It could be clearer about what 'Teardown' refers to, but overall it's complete enough.

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 schema fully documents the single enum parameter. The description does not add any semantics for the 'topic' parameter beyond what the schema provides, so 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?

The description conveys that the tool provides reference facts for writing mod XML/text files, but it lacks an explicit verb like 'returns' or 'retrieves' and doesn't clearly distinguish itself from siblings beyond the domain. The agent can infer it's a lookup tool, but the purpose isn't sharply 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?

No explicit guidance on when to use this tool versus alternatives. The phrase 'needed to write...' implies a use case, but there's no mention of prerequisites, when not to use, or which sibling to choose instead.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false, so the mutation risk is known. The description adds the genuinely new fact that the revert is irreversible ('Cannot be redone'), which the annotations do not convey and which directly affects how cautiously an agent should invoke it. It stops short of explaining scope limits such as whether undo survives a new session.

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 action first and the irreversibility warning last, where it lands hardest. Every clause earns its place and nothing is padded.

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 two-parameter tool with full schema coverage and annotations, the description covers what is reverted, on what, and that it is permanent. With no output schema it should ideally say what a successful undo returns or how failure is reported, but the core information an agent needs is present.

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

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

Schema coverage is 100% and both parameters (steps, project) carry their own descriptions, so the schema does the heavy lifting. The description's 'last edits' weakly implies the default single-step behavior but adds no format or boundary detail beyond the schema's minimum/maximum.

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 (revert) and resource (the last edits of a project), and the parenthetical '(any tool that changed it)' defines the scope of what can be undone. It is unambiguous, though it doesn't need sibling differentiation since no other tool in the list performs undo.

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 'any tool that changed it' implies this is the recovery path after a mutating tool ran, but there is no explicit when-to-use/when-not-to-use guidance, no mention of prerequisites, and no statement about how it interacts with the stack of prior edits beyond the implicit context.

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