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

With no annotations, the description carries the full burden, and it does disclose output content (two images plus score/metrics) and defines the 'original' semantically via build()/original(d). It does not clarify whether images are returned inline versus written to disk, or any side effects, permissions, or pagination concerns.

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 sentences, front-loaded with the output, then defining 'original', then the export relationship – each sentence carries distinct information. It is somewhat jargon-dense ('build() loads with import_model', 'original(d)') but not 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?

With no output schema, the description usefully explains what is returned (image pair plus compare score/metrics) and clarifies the ambiguous concept of 'the original'. However, four entirely undocumented parameters leave the calling contract incomplete for an agent that must supply them.

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 four parameters (name, size, inline, variant) have no titles beyond their names and no descriptions. The description never explains what name identifies, what size values mean, what inline controls, or what variant selects, so it fails to compensate for the coverage gap.

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

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

The description concretely states what the tool produces – the original and remix images side by side, a deviation-colored original, plus compare's score and metrics – which is more than a name restatement. It implicitly distinguishes itself from the compare sibling by describing it as the visual companion to compare's deviation view. It never uses an explicit verb like 'render' or 'generate', so the action framing is slightly indirect.

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 opening 'For a remix' scopes when this applies and the mention of 'export writes the same two images when it writes PNGs' hints at an alternative path, but there is no explicit when-to-use / when-not-to-use guidance versus compare, render_preview, or export. Usage is implied 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 burden and does so well: it discloses sandboxing, timeout behavior, cache location and reuse conditions, fresh rebuild semantics, that no other files are written, per-piece timing hints, and error reporting with tracebacks. This is unusually rich behavioral context for a build tool.

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

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

The description is dense and front-loaded with the core action and reporting behavior. It is somewhat run-on and packs many details into long clauses, but nearly every clause provides useful operational context rather than 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 complex build tool with an output schema, the description covers execution environment, cache behavior, output summary, timing hints, errors, and follow-up review steps. The main gap is that it never explains the required `name` argument, which is important context for invoking the tool correctly.

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

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

Schema coverage is 0%, so the description must compensate. It explains `variant` (key from VARIANTS, 'standard' = ''), `parts` (comma-separated piece names from build(), lazy pieces skipped), and `fresh` (rebuild and replace cache), but the required `name` parameter is never described.

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

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

The description states a specific verb and resource: run the part script and report per-variant/part geometry, validity, errors, and timing. It also distinguishes itself from render_preview, section, check, and export by explaining cache reuse, though it does not clearly identify the required `name` argument's role in that purpose.

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

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

It gives clear usage context: `parts` limits which pieces are built, lazy pieces are skipped, cached pieces are reused later, and `fresh=True` rebuilds and replaces cache. It also mentions `before_printing` review steps, but does not explicitly compare when to call this versus siblings like `new_part`, `read_part`, or `diagnose_failure`.

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, and it discloses non-obvious behavior: results are computed from pieces cached by an earlier build plus per-piece findings for unchanged pieces, while fresh=True rebuilds and rechecks everything. It also notes the passing result ends with pending review steps, each with its call. It stops short of saying whether the tool mutates anything (e.g. rebuilding cached pieces on fresh=True) or what permissions/state it requires.

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 purpose is front-loaded in the opening clause, but the first sentence runs several dozen words as an unpunctuated enumeration with nested parentheticals, which is hard to parse for an agent extracting the contract. Most content earns its place; the packaging does not.

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

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

With an output schema present, return-shape detail is not needed, and the description still adds that a passing run appends version-specific review steps. For a high-complexity tool it covers caching, remote state, and sibling routing well; the only real hole is the undocumented `variant` parameter.

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

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

Schema description coverage is 0% for 3 parameters, so the description must compensate. It fully explains `fresh` ('builds and checks everything again') and `name` is self-evident, but `variant` gets no mention anywhere, leaving one parameter's semantics to guesswork.

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

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

States a specific verb and resource ('Run the print checks') and then enumerates exactly which checks run: validity, part overlap, overhangs, bridge spans, thin features, horizontal holes, bed-edge fillets, in-place gaps, Wall checks, Probes. It also names the sibling it is not (check_fit) and the condition that makes fit-checking part of this tool instead (Mates() in checks(d)).

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

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

Explicit routing guidance: use check_fit for assembly fit 'unless the script lists Mates() in checks(d)', fix every FAIL, report every WARN. It also flags the remote-server precondition (the part is not local until download_part brings it home) and when to pass fresh=True.

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 well: it explains interference categories, contact exceptions, hole alignment rules, default hole_tol 0.2, joint-pair handling, stand-in treatment, verbose output, variant scope, and build-cache behavior. It does not explicitly state read-only/non-destructive side effects, so it falls short of complete behavioral transparency.

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

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

The description is dense but front-loads the purpose and every clause carries technical meaning. It could be more readable if the nested parenthetical rules were structured separately, but length is justified by the tool's complexity.

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

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

For a complex geometric check with no annotations, 0% schema coverage, and an output schema, the description supplies substantial detection rules and parameter behavior. It still lacks explicit routing guidance and does not explain the required name argument, leaving minor gaps.

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

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

Schema description coverage is 0%, so the description must compensate; it explains hole_tol's default and meaning, fresh rebuilding, verbose listing passing pairs, and variant as one-or-all. The required name parameter is not explicitly explained, but most parameter semantics are covered.

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 purpose: checking how placed assembly pieces fit together, covering interference and hole alignment. It is clear and detailed, but it does not explicitly differentiate itself from siblings such as check or diagnose_failure.

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

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

There is no explicit statement of when to use this tool versus alternatives, nor when not to use it. The detailed rules imply it is for fit validation, but the agent is left to infer the usage context.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses that on HTTP/SSH servers the files stay remote as a temporary working copy deleted when unused, that inline=False returns only the image file (a link over HTTP), and what the image contains (green = matches, red = off). Not stated: whether the operation is read-only/side-effect-free, the response shape, or error behaviour when a file is missing.

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

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

Purpose and inputs are front-loaded, and every clause carries information — format list, threshold syntax, image meaning, remote-server caveat. It is a single dense run-on block rather than a structured list, which slightly hurts scanability for six distinct parameters, 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 six-parameter tool with no annotations and no output schema, the description is nearly self-sufficient: it names every returned metric and explains the server-side working-copy lifecycle. Gaps are minor — no error conditions, no units for the distance metrics, and no hint at output structure beyond the metric names.

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% — the properties have titles only — so the description must supply all meaning, and it does: reference/candidate formats plus path examples, thresholds syntax with a concrete 'hausdorff_mm=2,volume_rel=0.05' sample, image semantics, size values ('normal' or 'small', ~800 px wide), and inline's effect. Every one of the six parameters is explained beyond its title.

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 ('Compare a part with a reference model') and enumerates exactly what the comparison yields: bounding box, volume and surface-area deltas, mean/Hausdorff surface distances, F-score, 0-100 score and pass/fail. That is far more specific than the bare name. It stops short of 5 because it never distinguishes itself from plausible siblings such as check, check_fit or design_metrics, which an agent must still disambiguate on its own.

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

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

Gives clear operating context: inputs are workspace-relative STL/3MF/STEP paths with worked examples, thresholds are optional name=value overrides with an example string, and remote-server behaviour is spelled out. It even routes the agent to download_part for retrieving results and warns 'Never use ssh, scp or a shell on the server'. No sibling-comparison exclusions are offered, so it lands at 4 rather than 5.

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

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

With no annotations, the description does real work: it discloses that a 6-view render is written to parts/<part>/out/images/<file>_original.png (a side effect), and flags that unit analysis can reveal a wrongly-scaled file. It leaves ambiguous whether the before/after coplanar-merge tri count implies actual file mutation, and says nothing about cost/latency for what is clearly a heavyweight geometry analysis.

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 purpose sentence is front-loaded and information-dense with little true waste, but the parameter notes are packed into one run-on paragraph rather than separated, making it harder to scan for a specific parameter during invocation.

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 must define the return shape — it does name the reported measurements but not their structure, and two parameters plus the cost profile are unaddressed. Adequate for a read-style inspection tool, but not fully self-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 coverage is 0%, so the description must carry all parameter meaning. It explains part, file (including workspace-path form 'refs/x.stl'), scale ('' / factor / source unit like 'inch'), and image well, but silently omits two of the six parameters — size and inline — leaving them fully 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?

Opens with a specific verb+resource ("Inspect an original model before remixing it") and then enumerates exactly what is reported: format, units, size, volume, triangle counts, curvature, holes, repairs, license metadata, and a MODIFY/REDRAW recommendation. That is a much narrower job than siblings like measure, check, or diagnose_failure, so an agent can separate them, though no sibling is named 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?

"before remixing it" gives clear situational context — this is the reconnaissance step prior to modification/redraw. No negative guidance or explicit routing to alternatives (e.g., when to use measure or check instead) is offered.

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

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

With no annotations, the description carries the burden and usefully discloses that it changes nothing, that filament and print-time figures are rough estimates, and that suggestions cite DS-* rules. It does not describe failure behavior if check has not passed, but the read-only and estimation traits are clearly stated.

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

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

The description is dense and run-on, but it front-loads the main purpose and the metric list before moving to workflow and parameter notes. Given the complexity of the computed outputs, most of the length is justified.

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

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

An output schema exists, so the description need not enumerate return fields, and it does cover the main workflow, metrics, and most optional parameters. The missing explanation of variant is a gap, but overall it is complete enough for this complex 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%, so the description must compensate. It explains style with enumerated values and list_parts reference, explains up as a direction with default behavior, and explains as_json as a report-format switch, but it leaves variant undocumented and treats name only implicitly.

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: it computes design numbers for a printable part, then enumerates the metrics and style-triggered suggestions it returns. It also distinguishes its place in the workflow by saying it runs after check passes and before export.

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

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

It explicitly states the required sequence: "ALWAYS before export, after check passes," which tells the agent when to call it relative to sibling tools. It does not spell out when not to use it or name a direct alternative, but the workflow context is clear.

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

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

With no annotations, the description carries the full burden, and it does well: it discloses that it rebuilds pieces individually without cache, may be expensive, stops before a time limit, and names pieces it did not reach. It does not clarify whether building variants mutates project state or requires specific permissions, which is a meaningful gap for a build-running 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?

It is front-loaded with the triggering context, but the body is a single tangled, run-on sentence dense with parentheticals, which hurts scannability. Most content earns its place but should be broken into structured sentences or bullets.

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 diagnostic tool with three largely undocumented parameters, the description covers behavior, output expectations (error causes, fixes, invalid geometry, fix() results), and time-limit semantics; the existing output schema covers return structure. The main residual gap is parameter semantics and state-mutation clarity.

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

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

Schema description coverage is 0% with three parameters. The description only partially compensates: 'parts: only those pieces' gives some meaning to the parts param, and 'one variant' hints at variant, but name is unexplained and variant/parts formats and constraints are not defined. Partial coverage for an under-documented 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 and scope: a deeper diagnosis that rebuilds each piece without the cache and reports errors, causes, and fixes, plus unprintability of built pieces. It distinguishes itself from the 'short DIAGNOSIS' in failed results and implicitly from siblings like check and build_part, though the run-on delivery makes the core purpose slower to grasp than it should be.

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 deeper look after a failed or broken build' clearly establishes the triggering context and notes that failed results already carry a short diagnosis, implying this is for escalation. It does not explicitly name alternatives (e.g., check, build_part) or say when not to use it, leaving some inference about cost/usage tradeoffs.

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 so: signed link expiration, no token required, embed zip capped at 8 MB, and the fact that server-side files are a temporary working copy that gets deleted when unused. It also discloses what is always included (script and ref/) regardless of filters, which is behavior an agent cannot get from the 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?

Front-loaded with the outcome and layout, and nearly every sentence carries operational information. It is dense and mixes transport mechanics (a literal curl invocation) with routing advice, and the closing 'bring the part home with download_part' restates the opening, costing some scannability.

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 4-parameter tool with no annotations and no output schema, the description covers return locations, filtering behavior, embed fallback, and the temporary-copy lifecycle. It stops short of covering failure modes (e.g., part not found, expired link mid-download), which an agent would want before a terminal 'last step' call.

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

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

Schema coverage is 0% and every parameter is compensated: variant is defined ('standard' = ''), formats is enumerated with actual values (step, stl, 3mf, png, glb, print, hardware, bom, bom_csv) even though the schema has no enum, and embed is explained with both its 8 MB limit and its audience (clients with no network or that cannot fetch URLs).

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

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

Opens with a specific verb + resource ('bring a whole part home from a remote server') and immediately states the exact output layout (parts/<name>/<name>.py, out/, ref/). It is clearly distinguishable from siblings like read_part, write_part or export, which operate on data rather than delivering a full file package.

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 states when to use it ('call it as the last step of remote work, before reporting: a part is not done until its files are on the user's machine') and when not to ('Never use ssh, scp or a shell on the server: there is none'). It also names the transport-specific alternatives (curl over HTTP, b123d-print pull over SSH, local stdio) rather than leaving the agent to infer them.

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

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

With no annotations, the description carries the behavioral burden and does so thoroughly: it discloses caching, fresh rebuild behavior, review warn/required semantics, skip_review recording, remote temporary working copies, signed expiring links, and embed limits. It also warns never to use ssh, scp, or a shell on the server.

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 export destination and default behavior, and most details are useful. It is still long and dense, with many parenthetical clauses packed into run-on sentences.

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 8-parameter export tool with no output schema and no annotations, the description is highly complete: it explains outputs, default behavior, remote-server behavior, download links, review prerequisites, and safety constraints.

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 richly defines almost every parameter (parts, variant, formats, view, embed, fresh, skip_review), though the required name parameter is only implied through parts/<name>/ rather than explicitly defined.

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

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

States a specific verb and resource: export printable parts to a defined output directory layout. It distinguishes the operation from sibling download_part by explaining that export writes files, while download_part brings them home on a remote server.

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 says when to use it, what must happen before export (check passes, design_metrics, suggest_orientation), and how review settings affect behavior. It also names download_part as the remote retrieval alternative and instructs the agent to ask the user about unclear formats.

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 so well: it declares the tool read-only ('Reads only hardware(d): builds nothing', 'Changes nothing'), explains that identical items are merged and summed, that `count` multiplies quantities, and how unconfirmed specifications are marked. It also describes the output columns and the 'ask the user, never guess' handling.

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

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

The description is front-loaded with purpose and output shape, and almost every sentence adds needed information. It is slightly dense as a single paragraph, and 'builds nothing' and 'Changes nothing' are mildly redundant, but there is little wasted content.

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

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

For a five-parameter, read-only listing tool with no annotations, the description covers purpose, scope selection, behavior, parameter meanings, output columns, and the export alternative. An output schema exists, so return-value detail is not required, but the description still provides enough to use the tool correctly.

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

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

Schema description coverage is 0%, but the description defines every parameter: `name` for one part, `parts` for comma-separated part names (including part:variant syntax), `variant` defaulting to standard, `count` as assembly multiplier, and `format` as table or CSV. This fully compensates for the empty schema descriptions.

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

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

States a specific verb and resource: list the bought hardware declared in hardware(d) as a Markdown/CSV table. It clearly distinguishes itself from the `bom`/`bom_csv` export formats, which write the same list beside exports rather than showing it to the user.

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 says to offer it when a part declares hardware, and explains how `name`, `parts`, or neither selects the scope. It also notes the relationship to `bom` and `bom_csv` exports, so the agent can choose between display and file-export workflows.

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 load and does well: it warns that ids are only stable relative to '1 = the longest' and may renumber on changed geometry, explains the highlight side effect (also returns a picture with edges in red plus a verified selector expression), and discloses the remote-server model (temporary working copy deleted when unused). It never explicitly says the call is read-only/no mutation, which is the main remaining gap.

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

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

Front-loaded with purpose and the edge-record contents before filters, highlight, and remote behavior, and nearly every clause carries information an agent needs. It is dense and semicolon-heavy rather than cleanly segmented, which slows parsing of the parameter enumeration, but there is little pure 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 12-parameter tool with no output schema and no annotations, the description covers the return shape (edge fields), the highlight variant's extra returns (image + selector), and the remote file lifecycle. The unexplained `name`, `inline`, and `variant` parameters, plus no mention of the default limit of 200, keep it just short of complete.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: kind values (line, circle, arc, ellipse, spline), the four convexity values with meanings, near ('x,y,z' within `radius` mm, nearest first), face formats (id, side, or 'x,y,z'), highlight syntax ('3,4,7', '3-6', or list), limit, part and size are all explained. Three parameters — the required `name`, plus `inline` and `variant` — are never mentioned in the description, leaving a real gap.

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

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

Opens with a specific verb+resource (list the edges of a printable part) and immediately names the concrete use case (picking edges for a fillet/chamfer by id). It enumerates exactly what each edge record contains (id, type, length, endpoints/center+radius, convexity, adjacent faces), which makes it unambiguously distinct from list_faces and the other geometry siblings.

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?

States when to use it (to select edges by id rather than guessing a selector) and, critically, how to consume the result: 'put that in the script, never the ids (they change when the model changes)'. It also gives hard exclusions for remote operation ('Never use ssh, scp or a shell on the server'). It does not explicitly contrast with list_faces for the face-filtering case, so it is clear but not fully routing.

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

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

With zero annotations the description carries the full burden and does so: id stability rules ('1 = the largest; same geometry always gets the same ids, changed geometry may renumber'), the fact that curved faces are only counted not listed, remote-server file semantics (temporary working copy, download_part zip layout), and a hard constraint against ssh/scp. This is behavior an agent could not infer from the 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?

Front-loaded with the resource and its record fields, then parameters, then remote-server caveats — a sensible ordering. It is dense and parenthetical-heavy with a couple of run-on sentences, but nearly every clause carries operational information rather than 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 six-parameter read tool with no output schema, the description explains the returned face record fields and the remote-file lifecycle, which is the important part. The unexplained name/inline/variant parameters and the unspecified output shape of the highlight image are the remaining gaps.

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

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

Schema coverage is 0%, so the description must compensate and it only partly does: part, highlight and size are explained with defaults and accepted values, but name (the sole required parameter), inline and variant get no mention at all. Three of six parameters remain undocumented anywhere.

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

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

Opens with a specific verb+resource ('The flat faces of a printable part') and enumerates exactly what each face record contains (ids, normal, side, area, center, bbox, holes). It is clearly distinguishable from sibling list_edges and from make_template, which it explicitly feeds.

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?

States the downstream purpose ('for picking one for a face fit-test template (make_template kind='face')') and prescribes the confirmation loop via highlight before making the template. No explicit when-not-to-use or named alternative for someone who actually wanted edges, so short of a 5.

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

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

With no annotations, the description carries the burden, and 'List' plus 'settings in effect' does establish a read-only enumeration that returns current-state settings. It does not disclose pagination, result ordering, or handling of an empty workspace, so behavioral context is partial rather than rich.

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

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

A single short sentence with the action front-loaded and no filler. The trailing clause 'with the settings in effect' is vague enough to be the one weak point, but it does convey that output includes current settings.

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 takes no arguments and has an output schema, so the description only needs to say what is enumerated and roughly what comes back — both are covered. Missing are any hints about result size, ordering, or relationship to read_part, which keeps it from a 5.

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?

Zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. 'With the settings in effect' adds a small amount of framing about what the enumeration reflects but no parameter-level detail is needed.

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

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

The verb 'List' and resource 'part scripts in the workspace' are both explicit, which separates it from read_part (single) and write_part/new_part (mutation). However, 'part scripts' is slightly ambiguous against the surrounding family of part-tools, and no sibling is named to sharpen 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?

There is no statement of when to use this versus read_part, list_versions, or describe_model, and no prerequisites or exclusions. The agent must infer that this is the enumeration entry point and that read_part follows for details.

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. It does disclose useful behavior: ordering ('newest first'), the fields returned, the existence of unsaved-changes information, and an extra mode on shared HTTP/SSH servers. It omits read-only nature explicitly, list size/limits, and any permission or error behavior.

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

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

Only three sentences with no filler, and the primary behavior is front-loaded. However, the telegraphic fragments ('the Dims values that changed', 'what is not saved yet') trade clarity for brevity and require domain knowledge to parse.

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

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

For a zero-required-parameter read tool with an output schema present, the description covers both invocation modes, result ordering, and the shared-server variant. Return-value structure is handled by the output schema, so the remaining gap (pagination/limits, read-only confirmation) 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 coverage is 0%, so the description must compensate for the undocumented 'part' parameter. It does explain the semantic difference between omitting and supplying it ('numbered versions of that part'), which is real added meaning, but it never says what form the value takes (part id, name, or index), leaving the format ambiguous.

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 what the tool surfaces — saved versions with date, id, message and changed Dims values, newest first — and distinguishes the two modes (project-wide vs. a specific part). It also ties itself to restore_version, clarifying its role relative to a sibling, though it never uses an explicit verb like 'list' and relies on the name for that.

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

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

Usage is implied rather than stated: 'with part ... (for restore_version)' hints that this is the discovery step for restoring a specific part, and omitting 'part' yields project-level versions. There is no explicit when-to-use/when-not-to-use statement or named alternative besides the parenthetical reference.

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 so well: it states that files are written to specific paths, that PNG output is returned as an image unless inline=False, and that on remote servers files stay as a temporary working copy deleted when unused. It also warns never to use ssh, scp, or a shell. It doesn't cover failure modes or whether overwriting an existing template is possible.

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

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

It is front-loaded and every clause carries information, with no filler. The structure suffers, though: a single dense paragraph of nested parentheticals makes it hard to scan, especially the kind explanation, which could have been bulleted.

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 14-parameter tool with no annotations and no output schema, the description is substantially complete: it covers output locations, formats, the PNG side image, remote-server behavior, and the user-confirmation step. Only variant and the role of part remain unexplained.

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 for most of the 14 parameters: kind's three modes, at, face, plane, center, size, thickness, label, formats, base, and inline all receive meaning. However, variant is never explained and part/name are only indirectly implied, leaving real gaps in a large parameter set.

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

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

The opening sentence defines the artifact precisely: a thin test print from the real part with the same hole compensation, used to check size, holes, and mating fits. It distinguishes itself from siblings by pointing to list_faces for face confirmation and download_part for remote retrieval, though it never quite states a crisp verb+resource like 'Create a fit-test template'.

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

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

It gives an explicit precondition: confirm the face or region with the user first, using list_faces with highlight. It also explains the remote-server workflow and directs the agent to download_part. It lacks when-not-to-use guidance versus check_fit or other verification siblings, but the relevant alternative is named.

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

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

With no annotations, the description carries the full behavioral burden. It discloses useful details such as default frame behavior, optional image output, use of the build cache, and what each measurement kind returns, but it does not state whether the operation is read-only, whether it can fail, or what happens with stale cached 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?

The description is dense but front-loaded and organized by measurement kind. Each section provides actionable detail, though some sentences are run-on and relatively hard to parse quickly.

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 13-parameter measurement tool with no annotations and no output schema, the description covers the core measurement modes and many inputs well. It remains incomplete regarding several parameters and does not describe failure behavior or output shape beyond what each kind measures.

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 across 13 parameters. It explains the most important ones well: kind values, a, b, at, direction, face, face2, frame, image, and defaults for a. However, it omits meaningful explanation of name, size, inline, and variant, leaving several parameters undocumented in both places.

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

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

The description clearly states a specific verb and resource: 'Precise measurements on the built part, in mm, with the points where they were taken.' It adds a useful motivation ('check fits with numbers instead of guessing from pictures') and enumerates measurement kinds, but it does not explicitly contrast itself with sibling tools like check_fit or check.

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 through the enumerated kinds and their intended inputs, e.g. face ids from list_faces and piece names from build() or assembly labels. However, it gives no explicit when-not-to-use guidance or direct comparison to alternatives such as check_fit, leaving the agent to infer the boundaries.

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 disclose the return value ('short confirmation'), the show_code side effect, and the template backing resource. It omits what happens if the target file already exists (overwrite vs. error) and any permission or safety notes, which is a real gap for a file-creating mutation.

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

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

Front-loads what gets created and its location, then layers usage and workflow notes. Some parentheticals and trailing sentences (read_guide, confirm dimensions) make it slightly dense, but every sentence conveys actionable information.

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

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

For a complex, workflow-integrated creation tool it covers the template contents, naming, example mode, code return, and next steps. Remaining gaps are overwrite/error behavior and the unexplained description parameter; an output schema exists, so return-value detail is not required.

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 explains name (lower_snake_case, used in the path), example (copy a bundled example such as 'hole_coupon', discoverable via list_parts), and show_code (returns the new file's code). The fourth parameter, description, is never mentioned, leaving one of four 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 with the exact target path ('parts/<name>/<name>.py') and enumerates the template contents (Dims dataclass, build(d), VARIANTS, views, checks). This is clearly distinguishable from write_part (the follow-up step) and from example-copying behavior, which it also names.

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 covers when to use this tool versus the bundled-example alternative ('example: copy a bundled example instead (see list_parts)'), the required naming convention, the prerequisite ('call read_guide first'), the user-confirmation step, and the typical next tool ('write_part'). Little is left to inference.

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

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

With no annotations, the description carries the behavioral burden and discloses that the script is read without execution, which is important safety context. It also describes the returned structure in detail, though it does not mention error behavior if the part or script is missing.

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

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

The description is front-loaded with the core read operation and then details the returned contents efficiently. It is dense with semicolon-separated details but contains no obvious filler.

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

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

For a read-only introspection tool with one parameter and an output schema, the description is largely complete: it explains what is read, that the script is not executed, what is returned, and how to modify values instead. The main omission is clarifying the name parameter's exact role.

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

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

The schema contains one parameter, name, with 0% description coverage. The description does not explicitly explain that name identifies the part, nor does it give format or lookup expectations, so it does not compensate for the schema gap.

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

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

The description states a specific read operation: it exposes a part's named dimensions from the script without running it, enumerating Dims fields, derived values, and variant overrides. It distinguishes the tool from set_params by directing changes to that sibling, though it does not explicitly distinguish it from read_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 gives a clear usage context by saying the script is read without being run, and it explicitly routes modification to set_params rather than a whole rewrite. It does not explicitly state when to prefer this tool over read_part, but the read-only inspection purpose is clear.

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

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

With no annotations, the description carries the burden and does reasonably well: it discloses that the call is a one-time-per-session read of a static ruleset, and that the payload is a workflow/print-rules document. Return shape need not be explained since an output schema exists. It does not state whether the guide is cached, versioned, or fixed for the session, which would round this out.

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, each doing work: what it is, when to call it plus rationale, and what the flag does. The parenthetical resource reference is front-loaded well. Minor redundancy between the resource mention and the 'many clients never load that resource' aside.

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

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

For a one-parameter read tool with an output schema, this covers the essentials: what the content is, when to fetch it, and what the flag narrows. The only gap is that it never says whether the content changes during a session, which matters for the 'call it once' instruction.

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 define the lone parameter, and it does: essentials=True yields only the short checklist of rules most often skipped. The default/false behavior (full guide) is only implied, not stated, which keeps it below a 5 for a single undocumented parameter.

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

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

The description identifies the exact resource being fetched — the workflow and print rules — and ties it to the b123d-print://guide resource, so the agent knows precisely what comes back. It lacks an explicit verb ('retrieve'/'read'), and there is no sibling that overlaps in purpose, so no differentiation statement is needed. Clear but one step short of a model verb+resource statement.

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

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

It gives a concrete trigger ('Call it once before the first part in a session') and a rationale (many clients never load the resource), which tells the agent both when and why. It also positions the underlying resource as the alternative for clients that do load resources. No explicit 'when not to use' beyond the implied 'once', but the timing guidance is unusually actionable.

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

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

No annotations are provided, so the description carries the full behavioral burden. It only says it returns 'current code'; it does not mention permissions, side effects, error behavior for missing parts, or what 'current' means relative to versions.

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. However, its minimal structure provides little beyond the core statement.

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 (one required parameter), and an output schema exists so return values need not be described. Still, with no annotations and zero schema parameter coverage, the description leaves important invocation details unstated.

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 only parameter ('name') is not described in the schema. The description vaguely implies the parameter identifies a part script, but adds no format, constraints, or usage details.

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 ('Return') and resource ('current code of a part script'), making the action clear. It does not explicitly differentiate itself from siblings like write_part or list_parts, but the purpose is still understandable.

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 read_part versus alternatives such as list_parts, describe_model, or write_part. The description only implies a read operation without stating selection criteria 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 no annotations, the description carries the full burden and does well: it discloses the lookup nature, what is returned, the listing behavior, and the import path used by part scripts. It does not explicitly state side-effect/read-only behavior or error handling for unknown names, which keeps it from full transparency.

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 purpose and coverage, then usage semantics, then import guidance. The feature list is long but directly supports discovery and every part of the description has a clear function.

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

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

For a one-parameter lookup tool with an output schema, the description supplies the essential context: what it contains, how to list versus retrieve, what retrieval returns, and why to use it. No critical calling information 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 0%, so the description must compensate, and it does: it explains that name '' lists recipes and that a recipe name or one of its function names retrieves details. That adds substantial meaning beyond the bare string parameter.

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 resource: tested build123d recipes for common printable features, with printing notes and sources. It names concrete covered features and distinguishes the tool's role as a recipe/example lookup rather than a general guide or part reader.

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

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

It gives explicit calling behavior: empty name lists recipes; a recipe name or function name returns code, an example, and notes. It also gives a clear when-to-use instruction: use one before improvising the feature, and notes that part scripts import them.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it discloses caching/reuse of build pieces, fresh rebuild behavior, inline vs file-only return, temporary server working copies deleted when unused, and the absence of shell access.

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 purpose is front-loaded, followed by parameter guidance and remote-server warnings. Despite the length, every sentence adds operational value and there is no filler.

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

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

For a 6-parameter tool with no output schema and no annotations, the description covers return behavior and remote-server constraints well. It is nearly complete, though the required name parameter remains unexplained.

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 explains parts, size, inline, fresh, and variant well, but the required name parameter is not explicitly described, leaving one semantic gap.

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

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

The first sentence states a specific verb and output: render six named views as a PNG image. It clearly distinguishes this from sibling tools by referencing build() output, download_part, and remote-server behavior.

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

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

It gives explicit when-to-use guidance for parts, omission behavior, size choice, inline mode, fresh rebuilding, and remote-server workflow. It also names download_part as the alternative for retrieving files from the server.

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 full behavioral burden and does so: it discloses that the restore is non-destructive (saved as a NEW version, no reset, no deleted history, later-added files kept) and states a refusal condition for dirty state. This is exactly the mutation-safety context an agent needs.

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 and non-destructive guarantee are front-loaded, and every sentence carries useful information about workflow or safety. It is dense and long, but no sentence is wasted; slightly tighter phrasing would help.

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 purpose, safety, prerequisites, and the multi-step workflow including the server case. 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 0%, so the description must compensate: it explains 'version' can be a number from list_versions(part) or a commit id, which is real added meaning. 'part' is only implied by the examples (script, ref/, MEASURE.md) rather than defined, leaving a small gap.

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

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

States a specific verb and resource ('Bring a part back to a saved version') and enumerates what a part is (script, ref/, MEASURE.md). It distinguishes itself from siblings by naming list_versions as the version source and save_version as the pre-step.

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

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

Explicit prerequisites and sequencing: refuse while unsaved changes exist, offer save_version first, ask the user before restoring, then build_part and check. Even the shared-server workflow routes the agent to write_part, leaving little to inference.

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

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

With no annotations, the description carries the full burden and does so: it states where data is written ('where use_printer writes'), what happens on existing values (kept and reported as a conflict, retry with overwrite=True), the no-op semantics of empty arguments, and the workspace-wide side effect of move_flat. That is an unusually complete behavioral disclosure for a mutation 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?

Information density is high with essentially no filler, and the printer/material/formats group is front-loaded ahead of the conditional rules. The semicolon-chained run-on structure and mid-sentence capitalization ('MEASURED') make it harder to parse than it needs to be for nine parameters.

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

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

For a 9-parameter mutation tool with zero annotations, the description covers storage location, conflict/overwrite behavior, idempotency of empty calls, and the move_flat side effect; an output schema exists so return values need not be described. Nothing an agent needs to call this safely is missing.

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

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

Schema description coverage is 0% across 9 parameters, so the description must compensate entirely, and it does: formats gets a literal example ('3mf,png'), calibration gets a concrete dict example, hole_comp is explained as the slicer-corrects-holes sentinel vs. the opt-in measured value, and hole_comp_h shares that rule. overwrite and move_flat are tied to their triggering workflows rather than left as bare booleans.

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

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

Opens with a specific verb+resource: 'Save the user's first-run answers (the setup_workspace prompt)'. It also implicitly distinguishes itself from use_printer by clarifying that the printer value comes from use_printer's search rather than being created here. Slightly less than 5 because 'setup_workspace prompt' is jargon a fresh agent may not recognize, and the tool's true scope (config persistence) has to be inferred from the parameter list.

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

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

Explicit procedural rules: empty arguments change nothing, conflicts must be surfaced to the user before retrying with overwrite=True, and move_flat should only follow asking the user. It also points at use_printer as the source of printer names. No explicit 'use tool X instead of this' routing, which keeps it from a 5.

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

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

With no annotations, the description carries the full burden and does so: it names the side effect (writes to a git repo in the user's project folder), the exact file scope saved and excluded, the required user confirmation, what the result reports back ('what was saved and the changed Dims values'), and the shared HTTP/SSH server behavior where nothing runs and commands are returned instead.

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?

Dense and front-loaded — file scope, then trigger conditions, then parameters, then the server fallback — with essentially no filler. The semicolon-chained fragments make it slightly harder to scan than it could be, keeping it just short of top marks.

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?

Output schema exists, and the description still usefully says the result reports what was saved plus changed Dims values. Combined with the file-scope list, confirmation gating and the remote-server fallback, an agent has everything needed to invoke this correctly.

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

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

Schema coverage is 0%, so the description must explain all three parameters and does: message is 'what changed, in the user's words' with a concrete example format, part is 'only that part (default: all)', and start performs one-time repo initialization with a .gitignore under a stated condition. Each parameter gets meaning beyond its type and default.

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

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

States a specific verb and resource ('Save a version of the project in its version history') and enumerates exactly what is captured: each part's script, ref/ folder, MEASURE.md, adjacent .py files and b123d-print.toml, explicitly excluding out/. It is clearly separable from siblings list_versions and restore_version.

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 an explicit preconditions and exclusion rule: only after the user says yes, only after a change that built and passed its checks, and it tells the agent to OFFER 'Save this version? ...' rather than calling on its own. It also gates start=True on the user having agreed to a version history, so both when-to-use and when-not are covered.

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 discloses important behavior: inline=False returns only a file or HTTP download link, remote files are temporary working copies, and fresh=True rebuilds cached pieces. It also clearly warns not to use ssh, scp, or a shell on the server, though it does not describe permissions or error handling.

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

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

The description is dense but front-loaded with the core purpose and key parameter behavior. The remote-server caveat and download_part guidance are relevant, though the text is somewhat run-on and could be more scannable.

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

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

For a complex tool with no annotations, no output schema, and 0% schema description coverage, the description covers most operational behavior including remote file handling, caching, and inline output. It is not fully complete because name and variant are unexplained, but the overall coverage is strong enough for correct invocation in most cases.

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 explain plane, at, parts, size, inline, and fresh. However, it leaves the required name parameter and the optional variant parameter undocumented, which is a meaningful gap for an 8-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?

The description clearly states that the tool produces a cross-section PNG image with each part in its own color, which is a specific resource and output. It does not explicitly distinguish itself from sibling tools such as render_preview, but the cross-section focus makes its purpose unmistakable.

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

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

It provides useful context for when parts default to the assembly versus all printable parts, and explains caching and fresh builds. However, it does not explicitly say when to use this tool versus alternatives like render_preview or before_after, so usage guidance is implied rather than fully spelled out.

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 so well: it discloses refusals (expression-computed defaults, unknown fields, derived @property values, wrong types), the variant override path, default rebuild plus build-cache behavior, the size limit and compile requirement inherited from write_part, and that a failed build returns a diagnosis with an undo call.

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 and the minimal-diff guarantee, then constraints, then variant and rebuild behavior. Dense but every clause adds information; the nested parentheticals make the middle heavier than ideal but not 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?

For a mutation tool with an output schema, the description covers safety constraints, failure handling, and call semantics sufficiently. The remaining gap is the role of `name` and the exact meaning of `parts`, which the schema does not supply either.

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 values (field→new value map, literal defaults only), variant (override location), and rebuild (default true, build before and after) — but never explains `name` and mentions `parts` only obliquely via 'per piece'/'only those pieces'. Three of five parameters are covered.

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

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

The description opens with a precise verb and resource: change Dims values in the script in place, with a minimal-diff guarantee. That distinguishes it from write_part (whole-file write), params (read) and build_part (build only). 'Dims' is domain jargon, but the operation itself is unambiguous.

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

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

It implies usage through contrast — use variant to change an override instead of the default, and rebuild=false to skip building — but never states when to pick set_params over params, write_part, or edit-and-rebuild via build_part. The agent must infer the routing.

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

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

With no annotations, the description carries the burden and does so: 'Changes nothing' declares read-only, it states the return shape (a ranked table with Rot(x, y, z) plus how), discloses that remote-server files are a temporary working copy deleted when unused, and forbids ssh/scp. Missing: cost or runtime expectations beyond the throwaway 'in a second' remark, and any note on accuracy limits of the 'rough estimates'.

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 purpose, but the body is a run-on, telegraphic enumeration with parentheses and semicolons that reads like compressed notes rather than prose. Remote-server operational guidance is appended to a scoring description where it is only loosely related, costing the reader parse time for the value delivered.

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, no-annotation, no-output-schema tool, the description covers return shape, safety profile and remote file handling well, but leaves three parameters undefined and never clarifies the relationship between name, piece and variant. An agent could call it, but not confidently for multi-piece or variant cases.

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 only partly does: it explains load with concrete format examples ('X', 'along Y', 'XZ', '1,0,1'), piece's default ('one printable part (default: each)'), and image's side effect. The size, variant and inline parameters receive no mention anywhere, leaving three of seven 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?

Opens with a concrete verb and resource: 'Rank the ways to put the part on the bed', and enumerates the candidate set (six axis-aligned orientations plus convex-hull faces). It separates itself from siblings by naming build(d), export and download_part, though the mid-sentence enumeration of scoring criteria makes the core purpose harder to extract than it should be.

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 an explicit workflow rule ('ALWAYS before export') and a conditional trigger for the structural option ('with a load or the structural style'), plus a stated no-op case (a part already flat on the bed). It does not say when to skip it in favour of siblings like check or compare, 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?

With no annotations the description carries the full burden and does so: it names the three written artefacts (json, py snippet, png), discloses accuracy limits (about a pixel for scans, photo only if square-on/flat), and explains remote-server behavior (temporary working copy deleted when unused, use download_part, no ssh/scp/shell). That is behavior beyond anything structured.

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 and output are front-loaded, then scale modes, then outputs, then remote caveats. Dense but nearly every sentence carries information; the middle section is a long run-on that packs several parameters per clause, which slows parsing.

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 13-parameter tool with no annotations and no output schema, the description covers inputs, generated files, accuracy caveats and remote file handling. The main gap is the unexplained `inline` flag (default true), which likely governs whether the result is returned to the agent, and no statement of the immediate return value.

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

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

Schema coverage is 0%, and the description compensates by defining most parameters: dpi, grid (cell size mm), reference formats, points syntax and origin, distance, pick 'x,y', threshold range 0..1, invert direction, tolerance in mm, smooth. Only `inline` (and to a lesser degree `part`/`file` beyond path shape) is left unexplained, so it falls just short of complete.

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

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

Opens with a specific verb+resource+output: tracing a flat object in a scan/photo into a 2D outline in mm for a part script, with the source path pattern parts/<part>/ref/<file>. This clearly separates it from siblings such as measure, render_preview or upload_reference.

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

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

Gives explicit conditional selection rules: omit everything for dpi from file, use grid for a mat, reference 'card' or 'L,S', points+distance for pixel calibration, pick when the object is not the largest, threshold/invert to override automatic threshold. Also states the precondition (from upload_reference) and a verification step (check a known dimension before trusting).

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 well: it discloses the 50 MB cap, that base64 is only practical for small files because every byte is written out, that the HTTPS link needs no token but expires, and that it returns an SSH push command or a local folder otherwise. The one behavioral trait not covered is what the 'overwrite' flag does when the target file already exists.

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

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

Front-loaded with the destination and file types before the operational details, and every sentence adds information. The prose is somewhat dense and parenthesis-heavy, but 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?

Covers both the inline-data path and the out-of-band copy paths in enough detail for an agent to act and to relay instructions to the user; the output schema handles return structure. The missing piece is overwrite semantics for an existing reference 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 coverage is 0%, so the description must compensate. It explains 'part' and 'filename' implicitly through the path template and covers 'data_base64' thoroughly (whole file, base64, 50 MB limit), but the 'overwrite' parameter is never mentioned, leaving one of four params undocumented anywhere.

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

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

States a specific verb (upload) plus the exact destination ('parts/<part>/ref/<filename>') and the two artifact classes it handles (STL/3MF/STEP models vs PNG/JPEG/TIFF/BMP scans). It also distinguishes itself from siblings by naming trace_outline as the consumer of image uploads and describe_model as the follow-up step.

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

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

Gives clear context for each mode: upload a model to remix it, upload an image to trace it with trace_outline, and notes the part folder may not exist yet. It routes the agent to the next step (describe_model) but does not explicitly exclude sibling write paths like write_part or save_version.

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, but the description discloses config persistence (saved in user config or b123d-print.toml), clearing behavior ('generic' clears it), nickname calibration isolation, and a safety guardrail. Missing explicit permission requirements or reversal info, but strong for a config 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?

Dense but informative; front-loads the optional/default context. Could be improved with bullet points for parameters, but no sentence is wasted.

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

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

With an output schema present, return values needn't be explained. The description covers all parameters, persistence semantics, and a usage guardrail, making it complete for this config 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%, yet the description fully explains each of the four parameters: search finds names, name activates and persists, nickname disambiguates same-model printers, material lists options. Adds substantial meaning beyond the bare string 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 it sets an optional printer profile (default generic mode) and explains making a printer active. The action is clear and distinguishable from unrelated siblings, but no alternative tool is named (none exists).

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?

Says to only change the printer when the user asks, and describes search vs name usage. No explicit alternatives are mentioned, but the optional/default caveat provides clear context.

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

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

With no annotations, the description carries the behavioral burden and does disclose that this replaces the entire part script and requires a specific `build(d)` + `Dims`/`VARIANTS` contract. It also states prerequisite tools, but it does not describe what happens to an existing script, whether it is recoverable, or any overwrite/versioning implications. The destructive nature is implied strongly by 'Replace the whole part script' but not fully elaborated.

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

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

The description is three short sentences, front-loads the core action, then provides prerequisites and follow-up. Every sentence contributes without repetition or 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 two-parameter mutation tool with no annotations, it covers the core workflow, script contract, and adjacent tools well. Missing details about the `name` parameter and overwrite/recovery behavior keep it from being fully complete, but the presence of an output schema reduces the need to document return values.

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 explains `code` in useful detail, including the required `build(d)` contract, but it never explains what the required `name` parameter represents or how it relates to the part being written. Half of the parameters remain semantically undocumented.

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

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

The description uses a specific verb and resource: replacing the whole part script with `code`. It clearly distinguishes this tool from `new_part`, which creates the part, and `build_part`, which is the next step after writing. An agent can identify the tool's core action without opening the schema.

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

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

The description gives explicit sequencing: call `new_part` first, call `read_guide` if needed, confirm dimensions with the user, write the script, then call `build_part`. It states prerequisites and the follow-up action, leaving little ambiguity about when this tool belongs in a workflow.

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