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

Annotations indicate readOnlyHint=true, which is consistent with the description (no mention of side effects). The description details the output format (plain-text summary + JSON report) and explains the behavior of each parameter, adding transparency beyond annotations.

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

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

The description is well-structured with an introductory sentence, a bullet-like list of checks, output format, and parameter details. It is somewhat lengthy but every sentence adds value. Minor redundancy could be trimmed, but overall it is clear and organized.

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

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

Given the tool complexity (7 parameters, output schema present, no required params), the description covers all aspects: purpose, checks, output, and detailed parameter explanations. It provides sufficient context for an AI agent to invoke 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%, so the description fully compensates by explaining each parameter's purpose, default, and format (e.g., build_volume as 'X Y Z' string). It adds clear semantic meaning that the schema alone lacks.

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

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

The description clearly states the tool's purpose: analyzing a build123d shape for FDM printability using augura. It lists specific checks (overhangs, manifold/watertight, etc.), distinguishing it from sibling analysis tools like design_audit or health_check which have different scopes.

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 outlines when to use the tool (for FDM printability analysis) and lists the checks performed. It does not explicitly mention when not to use it or alternatives, but the specialized focus implies appropriate usage. It provides enough context for an AI agent to decide.

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

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

Annotations only provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description discloses far more: writes to a private sibling file, runs a written-and-reimported gate, replaces the filename only on PASS, deletes the candidate on FAIL, preserves existing output, and defers snapshot saving until after promotion. This is rich behavioral context beyond the annotations, with no contradiction.

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

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

The description is dense but efficiently ordered: what it does, how it does it, failure behavior, snapshot behavior, return summary, and usage guidance. It is front-loaded with the core purpose, though the single long paragraph could be broken into shorter sentences for easier scanning.

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 atomic operation, coverage is strong: it details PASS/FAIL semantics, snapshot timing, preservation guarantees, return content, and when to prefer this tool over alternatives. The output schema covers return structure, so the description does not need to duplicate that. The main gap is object_name semantics and exact error scenarios, but overall it is sufficiently complete for selection and invocation.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It clarifies snapshot_name ('the geometry snapshot is saved only after promotion') and gives some meaning to filename ('replaces filename only on a fully verified PASS'). However, object_name is never explained, leaving one of the three parameters without semantic grounding.

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

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

The description opens with a specific verb-resource pair: 'Atomically promote a gate-clean STEP as the safe output/checkpoint.' It also explicitly contrasts itself with batching export() and save_snapshot(), so an agent can distinguish it from those siblings without opening the schema.

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

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

It explicitly states when to use the tool: 'Use this instead of batching export() and save_snapshot() for scored floors and final candidates.' This gives both a clear use case and the named alternatives, leaving little to inference.

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

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

The annotations set readOnlyHint=true, and the description does not contradict this. The description implies the tool observes state without modifying it, but does not explicitly state that there are no side effects or any other behavioral traits. With annotations already providing the safety profile, the description adds no new transparency beyond operational details.

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

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

The description is well-structured with a brief introduction followed by line-separated explanations for each kind. It front-loads the unified purpose. While it is somewhat verbose (occasionally repeating 'a and b' and 'b is required'), each sentence contributes value. The structure makes scanning for the appropriate kind easy.

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

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

Given the tool's complexity (four kinds, six parameters) and the presence of an output schema, the description covers the main usage scenarios comprehensively. It explains parameters, required inputs for most kinds, and output format for snapshot. It does not detail return structure for shape/fit/align, but the output schema likely covers that. No major gaps are apparent.

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 carries the full burden. It explains the role of parameters 'a', 'b', 'kind', 'axis', 'mode', and 'format' in context of each kind. However, there is a slight inconsistency: the description states 'b is required' for shape, fit, and align, but the schema lists 'b' as optional (default empty). Despite this, the description adds significant meaning beyond the bare schema, earning a 4.

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

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

The description clearly states it is a 'Unified comparison tool' and elaborates four distinct kinds (shape, fit, align, snapshot) with specific resources (named shapes, session state). Each kind has a concise purpose statement, such as 'compares two named shapes from show() by volume/bbox/topology'. The description effectively distinguishes the tool from siblings by focusing on comparison operations.

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

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

The description provides clear context for when to use each kind (e.g., shape for geometry comparison, fit for spatial relationships). However, it does not mention when not to use this tool or compare it to sibling tools like 'measure' or 'analyze_printability'. No explicit guidance on alternatives is given, which limits its helpfulness for agent decision-making.

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

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

The description transparently says it saves a PNG and returns a saved path, which implies a filesystem write. However, the annotations set readOnlyHint=true, indicating the tool does not modify the environment. This is a direct annotation contradiction, so the behavioral transparency score must be 1.

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 tight sentences with no filler. The core action is front-loaded, parameter constraints are compact, and the limitation/anti-goal statement is placed at the end without waste.

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

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

For a 5-parameter crop tool with an output schema, the description covers the essential geometry semantics, scale limits, return value, and a clear statement of non-goals. The main gap is the unexplained autocontrast parameter, but the description is otherwise enough for correct invocation in normal 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?

With 0% schema description coverage, the description must carry parameter meaning, and it does for the most important ones: bbox_px is defined as exact source-image [x0,y0,x1,y1] and scale is bounded to 0.25..12. It also hints at output behavior via the returned PNG path, but it does not explain autocontrast or the output_path default.

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

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

The description starts with a specific verb and object: 'Save one model-selected raster drawing region at readable scale.' It also differentiates the tool from analytical siblings by explicitly stating it performs no OCR, feature recognition, or geometry inference, so an agent knows exactly what this tool is for.

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

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

The description clarifies that this is a 'mechanical crop only' and lists what it does not do, which implies when to use it rather than recognition or inference tools. It does not explicitly name alternative sibling tools, but the boundary it draws gives practical usage guidance.

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

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

Annotations already declare readOnlyHint=true. The description adds behavioral details: return format, default values, and constraints (minimum slices). No contradictions.

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, no wasted words. First sentence states action, second defines output, third provides usage context. Front-loaded with the essential 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 read-only tool with 3 parameters and an output schema, the description covers purpose, parameters, use cases, and return type. No missing information needed for proper invocation.

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

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

Schema has 0% description coverage; the description fully compensates by explaining each parameter's meaning, allowed values (X/Y/Z for axis), defaults, and constraints (min 2 for num_slices).

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

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

The description clearly states the tool computes cross-sectional areas along an axis, with specific verb and resource. It includes return format and parameter details, but does not explicitly distinguish from sibling tools like 'measure' or 'clearance'.

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

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

The description provides clear use cases (detecting voids, wall-thickness variation, verifying cross-section profile) but does not mention when to avoid this tool or suggest alternative tools from the sibling list.

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

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

Disclosures are consistent with readOnlyHint annotation, stating live session is never mutated. Details subprocess execution, wall-clock budget, partial reports, and definitions of 'brittle' and 'inconclusive'. Provides high behavioral transparency beyond annotations.

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

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

Description is dense but well-organized: starts with purpose, then process, then output format, definitions, limitations. Every sentence adds value; no redundancy. Could be slightly more concise but front-loaded effectively.

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

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

Given presence of output schema, description provides complete context: input parameters, process, return format with fields, known limitations, and edge cases. No gaps remain for an AI agent to understand tool behavior.

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?

Despite 0% schema description coverage, the description explains both parameters: epsilon as relative nudge (0<epsilon<1, default 10%) and max_params as cap on parameters audited. Adds meaning beyond schema defaults.

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?

Description clearly states the tool audits a session program as a design, surfaces numeric parameters, and tests robustness. It distinguishes from siblings like `script` or `validate` by its specific focus on parameter robustness analysis.

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 describes when to use (to audit design robustness) and includes limitations (only literal-valued top-level names, budget constraints). Advises hoisting if no parameters found. Could be more explicit about when not to use compared to specific siblings, but still strong.

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?

Beyond annotations (destructiveHint, idempotentHint), the description discloses concrete side effects: discarding namespace, objects, snapshots, releasing the worker subprocess, and that the next call transparently starts a fresh session under the same handle. It also specifies the HTTP-only context. No contradiction with annotations.

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

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

The description is three sentences: first states the core action, second explains post-condition, third gives usage guidance. It is front-loaded and every sentence provides distinct value without redundancy.

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

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

For a destructive, zero-parameter tool, the description covers the action, the complete set of effects, the intended use case, the alternative, and the operational prerequisite. With an output schema present and strong annotations, no further details are needed.

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

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

The schema has zero parameters, so the baseline is 4. The description adds meaning by clarifying that 'THIS client's' session and 'session handle' are involved, though no parameter syntax is needed. With 100% schema coverage (vacuously), the description does not need to explain any params.

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 ('Close THIS client's CAD session') and resource ('session'), and explicitly lists consequences (discarding namespace, objects, snapshots, releasing worker subprocess). It also distinguishes itself from sibling 'reset' by clarifying that reset clears geometry while keeping the session.

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 ('when abandoning a model entirely') and when not to ('prefer reset() to clear geometry while keeping the session'). Also notes the HTTP/session-handle prerequisite, giving clear context for appropriate invocation.

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

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

The annotations indicate that the tool is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false), but the description adds crucial behavioral details: it is transactional, performs validation steps (exact material change, hole recognition, outer envelope check), and on failure registers no result. It also explains the 'protected_refs' semantics and the default behavior of replacing the source. This goes beyond the annotations, though it does not clarify the exact nature of the transaction rollback or side effects on failure, which could be a minor gap.

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

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

The description is a single dense paragraph that front-loads the main purpose and constraints, then details the validation and parameters. It is efficient with words, but the density of technical terms (e.g., 'annular volume change', 'outer envelope') might reduce readability, though not excessive. It earns a 4 for being appropriately concise and structured.

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

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

Given the tool's complexity (mutation with validation, multiple side effects, and output schema present), the description covers the core behavior: transactional execution, validation steps, parameter semantics, and failure handling. The output schema exists, so return values need not be described. The main missing piece is clarity on the exact input format of 'handle' (though it hints at a @feature handle) and the exact meaning of 'outer envelope' validation, but these are minor given the presence of the output schema and annotations.

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

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

The input schema has 0% description coverage, so the description must compensate. It explains that 'protected_refs' is a JSON list of other hole handles and that the target cannot be protected, and mentions 'result_name' can preserve the original under a new name. However, it does not explain the 'handle' parameter format (beyond saying 'current @feature handle') and does not specify units or constraints for 'diameter' (e.g., must be positive, affects radius). This is a moderate improvement over the schema, but significant gaps remain.

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

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

The description clearly states the verb ('resize') and the resource ('one plain cylindrical through hole identified by a @feature handle'), and specifies the strict constraints (no counterbores, spotfaces, countersinks, or multiple constituent faces). While it distinguishes from general hole-finding tools by focusing on editing a specific feature, it does not explicitly name a sibling tool for comparison, so it loses a point for lack of explicit differentiation.

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

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

The description provides clear context on when to use the tool: it is for resizing a single hole with specific geometric constraints, and it implies that other tools (like find_holes or edit via script) might be alternatives, but it does not explicitly state when not to use it or which sibling to prefer. The lack of explicit alternatives prevents 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?

Disclosures beyond annotations: describes error fix hints, behavior of show/measure/find_edges, and notes that open()/os remain blocked. No contradictions with readOnlyHint=false and destructiveHint=false.

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?

Very long description listing many built-in functions. While all info is valuable, it lacks conciseness and could be structured with bullet points. Every sentence earns its place but overall length reduces clarity.

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

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

Covers error handling, built-in functions, safety notes, and analysis primitives. Output schema exists so return values not needed. Missing explicit mention of session persistence across calls, but otherwise comprehensive.

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?

Only parameter 'code' is not directly described in schema (0% coverage). Description compensates by explaining what code does, but doesn't specify format or constraints like length. Baseline 3 due to low coverage and some context added.

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?

Clearly states 'Execute build123d Python code in the persistent session' with specific verb and resource. Distinguishes from siblings like 'script' by emphasizing persistence and error fix hints.

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

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

Provides explicit usage context: errors include fix hints, and gives examples of built-in functions and when to use 'compare' for standalone calls. Lacks explicit when-not-to-use but offers clear alternatives.

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

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

Beyond the minimal annotations, the description richly discloses behavior: atomic promotion, restoration of the prior active model on failure, required result assignment, timeout/size/root constraints, snapshot behavior, and provenance output. This is far more than the annotations alone provide.

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

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

The description is dense and on the longer side, but it is logically organized and every clause adds operational value. The core purpose is front-loaded, followed by failure semantics, parameters, constraints, and workflow guidance.

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

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

Given the tool's complexity, the description covers execution semantics, error conditions, parameter behavior, safety constraints, return value, and recommended workflow. An output schema exists, so detailed return-value documentation 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 description coverage is 0%, but the description compensates thoroughly. It explains that path points to a UTF-8 .py file under an allowed read root, that result_name requires/registers a specific Shape or BuildPart variable, and that snapshot saves the promoted geometry checkpoint.

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

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

The description clearly states the verb and resource: execute a canonical build123d .py file and atomically promote its result. It is specific enough to be distinguished from most siblings, though it does not explicitly contrast itself with the similarly named 'execute' sibling.

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

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

It gives an explicit usage context: 'Use this for substantial generation revisions: edit model.py, execute_file(), then validate/measure/render/export through MCP.' This tells the agent when to choose this tool, but it does not state when not to use it or name alternatives such as 'execute' or 'script'.

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?

Beyond the annotations (which only indicate idempotent, non-read-only, non-destructive), the description discloses critical behaviors: single-object vs assembly export, label propagation in STEP, 2D/3D format limitations, error on mixing, and a final echo of geometry metrics as a sanity check. This is rich, non-obvious context that annotations do not provide.

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

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

The description is long but every sentence adds value, covering formats, use cases, error conditions, and export behavior. It's slightly dense and could be broken into paragraphs for readability, but it is not wasteful. The core purpose is stated upfront, making it well-front-loaded.

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

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

Given the tool's complexity (multi-format export, object selection, assembly handling, error cases, and result verification), the description covers all necessary aspects. The output schema exists, so not explaining return values is acceptable. The description is complete enough for an agent to select and invoke 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%, but the description fully explains the 'format' parameter (allowed values, 2D/3D mapping, comma-separated lists) and 'object_name' ('*', named object, default current shape). It even clarifies implications of the filename through context. The description adds substantial meaning beyond the bare schema.

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

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

The description opens with 'Export model' and goes on to specify the exact resource (model) and action, then elaborates on format options and behavior. It clearly distinguishes itself from siblings like render_view or save_snapshot by focusing on file export with format-specific details.

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

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

The description provides explicit guidance on when to use each format: 'use step for downstream CAD interop instead', 'Use dxf for engineering-drawing handoff', 'svg for embedding in docs/wikis', and notes 3mf is for slicers. This gives clear context and alternatives, satisfying the 'when/when-not/alternatives' criterion.

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

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

The description states 'read-only and diagnostic,' consistent with the readOnlyHint annotation, and adds valuable behavioral context beyond the annotation: the tool reports target-selection/edit evidence, is not proof of a requested target, and lists what it will output. No annotation contradiction exists.

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

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

The description is dense but every clause earns its place: the first sentence defines the tool's result and the specific evidence items, and the second sentence gives usage timing, scope, and a crucial caveat. It is front-loaded with the main action and contains no redundant 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 diagnostic tool with an output schema, the description covers purpose, usage timing, output contents, and caveats, which is largely complete. The main gap is the lack of guidance around the object_name parameter and how the tool selects the target, leaving a small but relevant invocation ambiguity.

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

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

The only parameter, object_name, has 0% schema description coverage and the description never mentions it. An agent receives no guidance on what object_name refers to, whether it is optional given its default '', or how it affects the search. The parameter name is somewhat self-explanatory, which prevents a 1, but the description fails to compensate for the low schema coverage.

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

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

The description names a specific verb and resource ('Find candidate bored bosses') and enumerates the exact evidence reported, including bore opening location, axes, diameter/depth, cap faces, and construction advice. It also distinguishes this tool from generic boss-finding via 'whatever its outer profile' and from final proof via 'not proof of the requested target.'

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

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

The description explicitly says to use this tool 'before lengthening any boss that carries a bore' and notes it is 'read-only and diagnostic, not proof of the requested target,' giving clear context and a limitation. It does not name alternative sibling tools, so the guidance is strong but not maximally explicit about when NOT to use it in favor of another tool.

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

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

The description discloses the output format (JSON with count and boss details) and the read-only nature (consistent with readOnlyHint). Adds behavioral context beyond annotations.

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

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

Two sentences, front-loaded with purpose, then output format. No wasted words.

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

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

Given the one parameter and explicit output schema in the description, the tool definition is fully informative for an agent.

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

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

With 0% schema parameter coverage, the description explains the single parameter 'object_name' as a session object defaulting to current shape, compensating for missing 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?

The description clearly states the tool recognizes external cylindrical bosses, including on turned parts, with filtering for local bosses. It differentiates from siblings like find_holes by specifying boss detection.

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 mentions filtering for local bosses, implying when to use, but does not explicitly state when not to use or provide alternatives.

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

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

Despite readOnlyHint already declaring this is a read-only operation, the description adds important behavioral detail: all 24 proper rotations are considered, mirror readings are excluded, tolerances are 0.1 mm or 1%, unmatched values are flagged, and empty/truncated recognition is not treated as proof of absence. No contradictions with annotations.

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

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

The description is dense but each clause adds meaningful information about matching semantics, tolerance, rotations, and output handles. It opens with the main action before diving into qualifier and tolerance details.

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

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

For a tool with complex geometric matching behavior, the description covers the crucial semantics: rotations, bounding-box-relative sides, tolerance, absence-handling, and feature-handle return. An output schema exists, so return details are not required; the one notable gap is the undocumented object_name parameter.

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

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

Schema coverage is 0%, so the description must explain parameters. It does explain qualifiers (axis, side, value_field) and stated_value semantics in detail, and kind is implied by the feature list, but object_name is never described. This is partial compensation, not 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?

The description names a specific verb ('List') and a concrete set of resources (hole, boss, polygonal boss, slot, chamfer, fillet), and specifies the return of exact @feature handles. It is clear enough to identify the tool's function, though it does not explicitly contrast with similar sibling finders like find_holes or find_bosses.

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 about when to use find_candidates versus the many find_* siblings, nor any when-not-to-use guidance. The behaviour (qualifiers, tolerance, rotations) implies a measurement/candidate-matching use, but the agent is left to infer context.

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

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

Annotations already mark readOnlyHint=true, and the description adds valuable behavioral details: excludes drill-point cones and edge chamfers, returns specific JSON structure, and explains the default for object_name. No contradictions.

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 multi-sentence but each sentence adds distinct value: purpose, definition, exclusions, return format, parameter. It could be slightly more concise, but it is well-structured and front-loaded.

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

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

Given the low complexity (1 parameter, output schema present, readOnlyHint), the description is complete. It explains what countersinks are, what is excluded, JSON return structure, and parameter behavior. No missing critical information.

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?

With 0% schema description coverage, the description fully compensates by explaining the single parameter 'object_name': it references a named object from show() and defaults to current shape. This provides essential meaning beyond the schema's type and 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?

The description clearly identifies the tool's purpose: recognizing countersinks on a session object. It specifies the resource (session object), the action (recognise), and explicitly distinguishes from the sibling tool 'find_holes', which reports only as plain openings.

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

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

The description provides context on default behavior (current shape) and contrasts with 'find_holes', but does not explicitly state when to use versus other shape analysis tools like 'find_bosses' or 'analyze_printability'. It implies usage for countersink detection but lacks explicit alternatives.

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

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

Annotations declare readOnlyHint=true, and the description aligns (read-only analysis). Beyond annotations, the description adds value by explaining default behavior (current shape), output structure, and that holes belong to at most one pattern. It does not contradict annotations.

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

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

The description is extremely concise with three sentences, front-loading the core purpose and pattern types, then efficiently covering output and behavioral caveats. No superfluous 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?

Given the tool's simplicity (one optional param, read-only, defined output schema), the description is mostly complete, covering pattern types, output structure, and hole assignment. Minor gaps remain, such as precision of 'identical-spec holes' and handling of no patterns, but overall it provides sufficient context for correct selection.

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?

With 0% schema description coverage, the description partially compensates by explaining that object_name defaults to the current shape. However, it does not fully detail parameter constraints, such as required format or existence checks, leaving gaps for the agent.

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

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

The description clearly states the tool identifies hole patterns (bolt_circle and linear_array) on session objects. It distinguishes itself from the sibling tool 'find_holes' by focusing on pattern detection rather than individual holes, and it mentions that each hole belongs to at most one pattern, reinforcing its specific scope.

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

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

The description implies the tool is for pattern detection and defaults to the current shape, but it lacks explicit guidance on when to use it versus alternatives like 'find_holes'. The note about make_drawing annotating automatically hints at redundancy, but no clear when-not or alternative comparisons are provided.

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

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

Annotations indicate readonly, and the description adds significant behavioral detail: grouping of coaxial cylinders, exclusion of threads and non-cylindrical features, and how countersinks are handled. This adds value beyond annotations.

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

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

The description is reasonably concise for the detail provided, front-loading the purpose. Some details about output JSON could be abbreviated, but overall structure is effective.

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

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

Given the tool has one optional parameter, an output schema (partially described), and sibling tools, the description thoroughly covers behavior, return format, and recognition rules, leaving little ambiguity about what the tool does.

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

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

Schema coverage is 0%, and the description only mentions that object_name defaults to the current shape. It does not explain how to specify other objects, the expected value type, or constraints, leaving substantial ambiguity.

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

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

The description clearly states the tool recognizes drilled holes, defaults to the current shape, and lists specific grouping rules. It distinguishes from sibling tools like find_countersinks and find_bosses by detailing what is and isn't recognized.

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 mentions parameter defaulting but provides no explicit guidance on when to use this tool over siblings or when not to use it. Usage context is implied but not stated.

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

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

Annotations already declare readOnlyHint=true, so the tool is safe. Description adds behavioral details: tests specific capabilities and returns JSON with ok/error per capability. No contradiction.

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

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

Three concise sentences: purpose, what it tests, return type, usage advice. No wasted words, front-loaded with key action.

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?

Completely adequate for a zero-parameter tool with output schema. Description covers purpose, tested capabilities, and response structure.

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?

No parameters exist; schema coverage is 100%. Description adds no parameter info because none needed. Baseline score of 4 for zero-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?

Description states specific verb 'Verify' and resource 'render and export dependencies', listing exact tests (PNG, SVG, STEP, STL). Distinguishes itself from siblings by being a health check for dependencies, not a manipulation or analysis tool.

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

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

Explicit usage context: 'Run at session start if you suspect a missing dependency.' Does not mention when not to use or alternatives, but provides clear trigger for invocation.

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

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

The description goes far beyond the annotations (readOnlyHint=false, destructiveHint=false) by detailing side effects: the shape becomes both the named object and current_shape, multi-object 3MF creates aggregate and member entries, STL imports yield a shell (volume=0), and 3MF solids require caller validation via returned fields. This provides essential behavioral context.

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

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

The description is detailed but every sentence serves a purpose: purpose, parameters, state change, multi-object behavior, format caveats, and usage tips. It is front-loaded with the main action and progressively adds necessary detail without waste.

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

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

The description covers all critical aspects: formats, parameters, session state, output characteristics (per-member summaries, solids/volume fields), and post-import actions. It is comprehensive enough for an agent to use the tool correctly and anticipate common pitfalls.

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?

With 0% schema description coverage, the description fully explains both parameters: path (absolute/relative) and name (with default filename stem). This compensates entirely for the schema's lack of 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?

The description clearly states the tool imports CAD files (STEP, STL, 3MF) as named objects, with explicit format extensions. It distinguishes this from sibling tools by focusing on the import action and resulting session state, making it unambiguous.

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

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

The description provides clear context for when to use this tool, including post-import workflow (render_view, measure, compare) and a specific Z-fighting avoidance scenario. It lacks explicit 'when not to use' or alternative import tools, but the guidance is strong enough for correct usage.

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

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

Beyond the readOnlyHint annotation, the description discloses what each mode inspects and reports: per-object bounding boxes, face/edge counts, annotation metadata, structural lint, page size, layer ids, text positions, and element counts. It also discloses deprecation behavior ('calling it explains the replacement') and mode-switching behavior.

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

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

The description is front-loaded with the deprecation warning and purpose, and it is well-structured with numbered modes and an Args section. It is fairly long and includes two code blocks, so it is not maximally concise, but every section earns its place given the migration guidance and two modes.

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

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

For a two-parameter deprecated tool with a readOnly annotation and an output schema, the description covers purpose, mode selection, parameter semantics, return contents, deprecation behavior, and migration path. Nothing critical is missing for an agent to call it correctly or decide to use the replacement.

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

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

The schema has 0% description coverage, but the description fully compensates with an Args section defining objects as comma-separated object names defaulting to all and limited to session mode, and svg_path as the path to an SVG file that switches to SVG mode. The code examples add further semantic clarity about annotation labels.

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 deprecation notice and then states a specific verb and resource: 'Structured bbox and annotation report for a 2D drawing.' It further clarifies two distinct modes, session and SVG, which separates it from siblings like inspect_part and lint_drawing.

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

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

It explicitly says the tool is deprecated and moved to draftwright, with version behavior, so an agent knows to use the replacement. It also gives clear mode-selection guidance: session mode is default, SVG mode is triggered by svg_path, and migration examples show annotate(result, name) instead of show().

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?

Despite readOnlyHint annotation, the description adds significant behavioral detail: exact feature matching (unexpected or ambiguous groups fail), unsupported expectation keys rejected, no built-in fixture expectations, and heuristic warnings for shallow cuts/constant sections. This goes far beyond the annotation and clarifies failure modes.

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 well-structured: it front-loads the main output, then explains optional parameter behavior, exact matching semantics, return modes, and constraints. Each sentence contributes value, though it could be slightly tightened.

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

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

Given the tool's complexity and output schema, the description covers return modes, error conditions, and heuristic warnings comprehensively. However, it omits context on object_name and sectioning parameters, and doesn't discuss relationship to other inspection tools. Still, the core behavior is fully specified.

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

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

Schema coverage is 0%, so description must compensate. It thoroughly explains the 'expected' parameter with supported keys and matching behavior, but says nothing about object_name, section_axis, or section_slices, leaving those under-characterized. Partial compensation only.

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

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

The description states a specific verb+resource: 'Return one compact generation-checkpoint inventory' and enumerates exact contents (bbox, solid/topology counts, holes, bosses, patterns, cross-section area profile). This clearly distinguishes it from sibling find_* tools which are single-feature, while inspect_part provides a consolidated inventory.

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

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

The description provides clear conditional context (with/without expectations) but does not explicitly state when to use this tool versus alternatives like find_holes or analyze_printability. It implies a checkpoint/inventory use case but lacks direct comparison or exclusion guidance.

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

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

Annotations only indicate the operation is neither read-only nor destructive, so the description carries the burden. It goes beyond that by disclosing that files are written, listing exact destination paths per target, and showing that 'force: overwrite existing installation' controls destructive behavior. It also flags a deprecated skill variant. This is rich, honest behavioral context.

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

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

The opening sentence states the core action, then the description breaks into tight bullet lists for skill and target with one-line definitions. The force parameter is handled in a single clear line. No filler or repetition — every sentence earns its place.

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

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

For a tool with three parameters, multiple target paths, deprecated variants, and an overwrite flag, the description covers the action, all parameter semantics, file destinations, and deprecation note. Since an output schema exists, return values need not be described. Minor details like failure behavior without force are not essential for correct invocation.

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

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

Schema description coverage is 0%, so the description must fully compensate. It does: each parameter is documented with its default, allowed values, and effect — skill meanings, target agent paths, and force overwrite behavior. All three parameters are meaningfully explained beyond the bare schema definitions.

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 ('Copy') and resource ('b123d workflow skill'), and elaborates on the concrete effect ('Writes the appropriate config file ... so the step-by-step workflow is available in future sessions'). It enumerates the skill and target options, which makes it unmistakably distinct from any sibling tool like workflow_hints.

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

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

The description provides clear context on when to use the tool — installing a workflow skill for a specific agent — and details valid values for skill and target. It does not explicitly compare against sibling tools or state when not to use it, though the deprecated 'drawing' note hints at an alternative. This is clear context without exclusions, so a 4 is appropriate.

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

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

Annotations declare readOnlyHint=true, and the description does not contradict this. It adds meaningful behavioral context by stating outputs are geometric candidates rather than design intent, and by describing the broader checks performed by the downstream edit_feature 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?

Three sentences, each earning its place: the main action, the semantic caveat, and the downstream usage. The description is front-loaded with the primary purpose and contains no filler.

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

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

The description covers purpose, output semantics, and downstream usage, while the output schema handles return shape. The main gap is the undocumented object_name parameter, but since it is optional with a default, the overall definition is still largely complete.

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

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

The only parameter, object_name, has 0% schema description coverage and is not mentioned in the tool description. The parameter name gives a weak hint, but the description does not compensate for the schema gap or explain what object_name should contain.

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

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

The description states a specific verb ('Suggest'), a precise resource ('planar mounting faces from recognised hole openings'), and clarifies that outputs are geometric candidates, not design intent. This clearly differentiates the tool from design_audit and edit_feature.

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

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

The description explicitly explains the downstream workflow: pass chosen hole handles as protected_refs to edit_feature(), and notes that edit also checks other holes and the outer envelope. It does not explicitly state when not to use this tool or name alternative tools, but the usage context is clear.

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

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

Annotations already indicate readOnlyHint=true, so safety is covered. The description adds valuable context on return structure for different error types and the case when no error occurred.

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 concise, with three sentences that efficiently convey purpose, behavior, and usage advice. No unnecessary words.

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

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

For a zero-parameter tool with an output schema, the description fully explains what it returns and when to use it. No 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?

No parameters exist, so the baseline is 4. The description does not need to add meaning beyond the schema.

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

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

The description clearly states the tool returns details of the last failed execute() call, including specific error information. It distinguishes itself from siblings like execute by focusing solely on error retrieval.

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

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

The description explicitly advises to call it immediately after an execute() error and contrasts it with re-reading code. It indicates when to use but does not explicitly state when not to use, though the 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?

Annotations declare readOnlyHint=true, and the description does not contradict this; it consistently describes read-only analysis. The description adds valuable context about internal delegation, the exact violation types checked, and the return format. It also discloses that calling the deprecated version 'explains the replacement,' a behavioral nuance beyond the annotation.

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

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

The description is long but well-structured: deprecation notice, purpose, mode breakdown, parameter details, and a usage tip. It is front-loaded with the most critical info. A few sentences are dense, but each serves a purpose; minor redundancy exists in repeating mode conditions.

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

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

For a tool with two modes, three parameters, and a structured output, the description covers everything an agent needs: operation, parameter semantics, when to run, and deprecation status. The return format is specified as {violations: [...]}. No critical 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 description coverage is 0%, so the description carries the full burden for parameters. It thoroughly explains svg_path (SVG mode), drawing_scale (with a concrete 5:1 example and division logic), and view_shape_names (with example list). Defaults are stated. This far exceeds the bare schema definitions.

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

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

The description states a clear verb and resource: 'Run structural drawing-quality checks and return JSON {violations: [...]}.' It enumerates specific checks (axis swap, leader-through-label, etc.), which distinguishes it from sibling drawing tools like inspect_drawing or render_drawing. The deprecation notice further clarifies its current role.

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 guidance is provided: 'Run this after major drawing additions; running it BEFORE rendering catches the bug at the source.' It also distinguishes session mode vs. SVG mode based on svg_path, and explains when drawing_scale and view_shape_names should be used. Alternatives are implied via the deprecation notice pointing to draftwright.

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?

Beyond the readOnlyHint annotation, the description discloses that handles are secrets and never returned, which is important security behavior, and explains the stdio vs HTTP session count difference. It adds useful context without contradicting the annotation.

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

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

Two concise sentences cover the main function, security caveat, and deployment context without redundancy. Every word adds value.

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

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

Given the simple scope (no params, read-only, has output schema), the description fully covers purpose, security, and operational nuance. It is complete for an operator/diagnostic tool.

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

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

The tool takes 0 parameters, so there is nothing for the description to explain. The schema coverage is trivially 100%, and the baseline for 0 params is 4.

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

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

The description uses a specific verb ('Report') and resource ('CAD sessions') and clearly states the three pieces of information returned: count, limit, and idle times. The phrase 'Operator/diagnostic tool' plus the HTTP/stdio distinction differentiates it from siblings like health_check and session_state.

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 notes this is for HTTP deployments and that over stdio there is always exactly one session, providing clear context for when to use it. However, it doesn't explicitly name alternative tools, so it falls short of full when/not-to-use 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?

Even though readOnlyHint=true already marks this as read-only, the description adds significant behavioral context beyond annotations: it is bounded out-of-process, mesh-checks, and returns a clean budget error for huge parts instead of hanging. It also discloses the output structure (per-defect metadata, diagnosis block, repair hints) and the empty-list meaning. No contradiction with annotations.

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

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

The purpose is front-loaded and every sentence adds a distinct piece of information: when to use, the defect taxonomy, budget behavior, and parameter semantics. However, the long single block of defect types is dense and could be broken into scannable sections; the length is justified but the structure is not ideal.

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 diagnostic with an output schema present, the description is complete: it covers invocation condition, output granularity, coordinate types, pass/fail interpretation, budget-limit behavior, and parameter semantics. Because an output schema exists, the description does not need to restate return values. Nothing essential is missing for an agent to select and invoke 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%, so the description carries the full burden for parameters. It fully compensates by explaining the only parameter: 'object_name: named object from show() (default: current shape)'. This clarifies both where the value comes from and its default, which is more than the schema's bare default of '' provides.

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

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

The description opens with a specific verb and resource: 'Report WHERE a solid fails the validity gate, with 3D coordinates'. It explicitly contrasts with validate()/export(), which tell WHAT is wrong but not where, so an agent can distinguish it from sibling tools. This is a clear, non-tautological purpose 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?

The description gives an explicit trigger: 'call this when validate() FAILs to get a per-defect list'. It names the alternatives (validate()/export()) and explains what those alternatives lack. It also clarifies the pass condition ('An empty list means the part passes the structural checks'), which helps the agent interpret the result and decide next steps.

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

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

The description discloses behavioral traits beyond the readOnlyHint annotation: it details the output structure, mentions that identical faces are collapsed and non-analytic sliver faces are folded into one summary line, and explains that mass and inertia are only computed when density or material is provided. No contradictions with annotations.

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

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

The description is well-structured, starting with the main output summary, then usage guidance, then parameter details. It is slightly lengthy but every sentence adds value. Could be trimmed slightly but remains effective.

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

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

Given the tool's complexity (many output fields), the description covers all return values, edge cases (face collapsing), and conditional behaviors (mass/inertia only with density/material). An output schema exists and likely duplicates some details, but the description is still comprehensive.

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 description provides full meaning for all three parameters (object_name, density, material) beyond the enum-free schema. It explains defaults and lists material presets. With 0% schema description coverage, the description compensates completely.

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

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

The description clearly states the tool's purpose: to measure a shape and return a complete geometric summary including volume, surface area, topology, bounding box, center of mass, inertia tensor, and face-type inventory. It distinguishes itself from the sibling tool render_view by noting that numbers are unambiguous for geometry verification.

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

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

The description explicitly advises preferring measure over render_view for verifying geometry and suggests using topology to check boolean operation success. It also explains when to provide density or material to get mass and inertia. However, it does not explicitly exclude other sibling tools like clearance or cross_sections.

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

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

Annotations only provide readOnlyHint=true, but the description adds rich behavioral detail: it slices on three axes, reports blind vs through holes separately, does not classify countersinks or thread forms, and notes that it reports what cross-sections show. This goes well beyond the annotation and sets accurate expectations.

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 moderately long but front-loads the core purpose and output structure before diving into usage and caveats. Every sentence adds value, though the parameter defaults could be more compactly integrated. Structure is logical and 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?

Given the tool has 7 parameters with no schema descriptions but an output schema, the description covers most critical aspects: what it does, when to use it, behavioral quirks, and meaning of several parameters. It doesn't explain all params but the defaults and output schema fill some gaps. Overall sufficient for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains min_diameter/max_diameter (M2-M8 clearance, counterbores, insert pockets), min_depth (filters chamfer rings and slivers), and object_name (from show()/import_cad_file). However, it omits explanations for weld, slices, and tolerance, leaving those parameters underspecified despite having defaults.

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

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

The description clearly states the tool finds fastener holes in a mesh by slicing on three axes, and explicitly contrasts it with find_holes() which requires real topology and fails on imported STL. This makes the tool's purpose unambiguous and distinguishes it from a sibling.

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

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

The description explicitly says when to use this tool: when you have an imported mesh (STL) and need mounting features, while find_holes() is unsuitable. It also provides guidance on interpreting depth/through to differentiate insert seats from screw holes, effectively giving 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?

Annotations provide readOnlyHint=true, and the description adds rich behavioral context: it details the exact JSON returned, explains enclosed_passages semantics (odd nesting depth), notes open grooves read 0, and specifies applicability to STL shells and solids. This goes beyond the annotation and clarifies what the tool does without contradicting it.

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 paragraph but tightly packed with necessary information. Every sentence adds value, and the main purpose is front-loaded. It could be split into structured bullets for readability, but it is not verbose or 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?

The tool has an output schema and the description explains the return format and semantics (enclosed_passages, loop structure). Parameters are fully described, and annotations cover read-only safety. There are no obvious gaps that would prevent an agent from calling this 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%, so the description must carry the parameter explanation. It does so thoroughly: axis (plane normal), position (absolute world coordinate), tolerance (tessellation tolerance), weld (point-merge distance), and object_name (named object, default current shape). This fully compensates for the lack of 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?

The description clearly states the verb ('Loops'), the resource (a mesh cross-section plane), and the specific scope (largest first). It also names the output format and distinguishes itself from siblings like cross_sections and mesh_holes by focusing on a single plane and providing loop details. This gives an agent enough to select it appropriately.

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

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

The description explains what the tool does and its constraints (works on STL shells/solids, defaults for object_name) but does not explicitly contrast with alternatives like cross_sections or mesh_holes. The usage context is implicit rather than explicit, so an agent might not know when to prefer this over a sibling without deeper analysis.

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

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

Annotations declare readOnlyHint=true, so the description doesn't need to justify safety. It adds value by disclosing that the tool saves files (overview and crops) as part of its operation, and it explicitly enumerates what it does not do (no view labelling, no CAD feature recognition, no dimension inference). This goes beyond the annotation and gives the agent an accurate mental model of its capabilities and boundaries.

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 well organised: purpose first, then capability, then limitations, then usage, then parameter details. Every sentence adds value; there is no fluff. It is longer than a one-liner, but the complexity of the tool justifies it. The negative-capability list is particularly useful and is not redundant.

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

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

An output schema exists, so return format is defined elsewhere. The description covers usage, parameter semantics, limitations, and the intended workflow. It doesn't mention error cases or what happens if the input is not a valid drawing, but for an inspection-prep tool this is acceptable. The description is sufficient for an agent to call it correctly in a typical workflow.

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

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

Schema description coverage is 0%, so the description carries the full burden. It explains each parameter: image_path with accepted formats and read-root constraint, output_dir with write-root constraint, max_regions with range 1..30, and padding with pixel range 0..500. This is exactly the kind of semantic enrichment that makes the tool callable without opening the schema.

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

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

The description states a specific verb ('prepare') and resource ('raster engineering drawing'), then details the exact behavior: detecting spatial regions, saving an overview and crops, and returning bounding boxes and paths. It also explicitly lists what the tool does NOT do (label views, recognise CAD features, interpret lines, etc.), which strongly distinguishes it from siblings like crop_drawing, render_drawing, and recognise_features.

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 usage guidance: 'Use it once near the start instead of repeatedly writing shell/PIL crop scripts; inspect the returned overview and only the relevant crops.' It also tells the agent to treat printed dimensions as authoritative, which is a clear directive on when to rely on the tool and when to defer to original data. This is more than enough to guide correct usage.

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

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

The readOnlyHint annotation already covers the safe read nature; the description adds valuable behavior beyond that: it discloses that handles fail if source geometry is replaced, explains the difference between coordinate frames ('caller' vs. 'part'), and notes that counts remain exact when max_features is set. This goes beyond the annotation without contradicting it.

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 dense paragraph but is efficiently packed with necessary information. The main purpose is stated first, followed by mode distinctions and usage details. It avoids fluff, though it could be broken into bullet points for readability. Still, every sentence adds value and the structure is logical.

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

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

Given the presence of an output schema (which is not shown but noted), the description need not detail return structures. It covers the key behaviors: default family behavior, handle usage in execute(), failure conditions, coordinate frame semantics, and max_features limits. The only minor gap is a lack of explicit mention of what happens when object_name is provided, but overall it is complete enough for an agent to call 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?

With schema description coverage at 0%, the description carries the full burden for parameter meaning. It explains families (empty vs. comma-separated), coordinate_frame (caller vs. part), include_faces (adds caller-face indices and geometry descriptors), and max_features (limits expanded records to 1..100). It does not explicitly describe object_name, but that parameter is likely self-explanatory given the tool name. Overall, it compensates well for the missing 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?

The description clearly states a specific action ('run the shared quiddity inventory once') and a specific output ('exact, run-local edit evidence'), and explains two distinct modes (empty families vs. specified families). It distinguishes itself from sibling tools like find_holes or find_bosses by describing a general inventory + feature-recognition operation with @feature handles, which is a unique capability. No tautology or ambiguity.

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

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

The description provides usage context (e.g., how to select families, coordinate frames, and handle use inside execute()), but it does not explicitly state when to prefer this tool over alternatives such as find_holes or find_bosses. It implies a broader role ('shared quiddity inventory') but lacks explicit exclusions or comparisons to siblings, leaving some choice 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?

The readOnlyHint annotation declares the operation is safe, and the description adds useful behavioral context beyond that: the PNG is returned inline so the LLM can inspect it, save_to allows optional file output, and calling a deprecated tool explains the replacement rather than silently doing something else.

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

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

The description is compact and well-organized: a clear deprecation warning up front, then the core purpose and comparison, then a terse Args block. Every sentence adds information, and the formatting makes the key decisions easy to parse.

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

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

Despite having no output schema, the description conveys the return behavior (inline PNG vs saved file) and the fail-soft deprecated behavior. It also provides enough context about the alternative tools and parameter semantics for an agent to invoke it correctly.

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

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

Schema description coverage is 0%, so the description carries the full burden—and it succeeds. It explains svg_path as a path on disk, width as output pixel width with a default and aspect-ratio behavior, and save_to as an optional write path with inline-only behavior when empty. Every parameter is meaningfully documented.

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

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

The description clearly identifies the action ('Rasterise an existing SVG file to PNG') and the precise resource (an SVG file on disk). It also differentiates itself from render_view by stating that render_view handles build123d shapes from the live session while this tool accepts externally written SVG files.

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

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

It explicitly names the replacement (draftwright), states the deprecation timeline, and says calling it explains the replacement. It also names the complementary sibling (render_view) and the exact condition for choosing between them: use this for an external SVG file, render_view for live session shapes.

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

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

Beyond the readOnlyHint annotation, the description discloses meaningful behavior: 3D/2D auto-detection via VTK vs 2D pipeline, timeout retry that downgrades to a coarse preview, azimuth/elevation applying after the preset, and PNG-only label/highlight behavior. These add real value that annotations do not convey.

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 efficient: the purpose is front-loaded and every clause adds operative detail about a parameter or behavior. It is a long single paragraph rather than structured bullets, but there is minimal waste given the high parameter count it must document.

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 enums, no output schema, and zero schema coverage, the description documents nearly every parameter with accepted values and discloses key behaviors (retry, auto-detection, PNG-only labels). The only gaps are clip_at semantics and explicit return-value description, which 'save_to writes the result' partially covers.

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?

With 0% schema coverage, the description carries the full burden and compensates strongly: it documents allowed values for format (png, svg, dxf, or both), direction (top, bottom, front, rear, side, left, right, or iso), quality (preview/standard/high with retry), mode (auto/2d/3d), clip_plane (x/y/z), and object selection. However, clip_at is never mentioned, leaving one parameter 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 ('Render model'), and clarifies the purpose is to 'confirm appearance, not geometry', which distinguishes it from measurement or analysis tools. However, it does not explicitly differentiate from sibling render_drawing, so differentiation is implied rather than named.

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

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

The phrase 'Renders confirm appearance, not geometry' implies the intended use case (visual appearance verification rather than dimensional checking), and the auto-detect behavior hints at when it applies. But there is no explicit when-to-use/when-not-to-use guidance or naming of alternatives like export or render_drawing.

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

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

Annotations declare readOnlyHint=true, and the description confirms the tool is read-only and does not mutate geometry. The description adds that the tool emits a plan, not direct edits, providing helpful behavioral context beyond annotations.

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

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

The description is concise, with two well-structured sentences. The first sentence clearly states the tool's purpose and distinguishes it from a sibling. No wasted words.

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

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

Given the existence of an output schema (not shown but indicated), the description does not need to explain return values. It covers input semantics and usage context well. Minor gap: it could mention the structure of the output plan, but the output schema likely covers that.

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

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

Despite zero schema description coverage, the description fully explains each parameter: error_text as full validate()/export()/last_error() text, goal as the intended edit, and context from locate_gate_defects()/compare(). This compensates completely for the lack of 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?

The description clearly states the tool returns structured repair recipes for agents to implement, and explicitly distinguishes from sibling repair_hints by noting repair_advice provides a sequenced plan versus short tips.

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

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

The description explains when to use this tool (when a sequenced plan is needed) and contrasts with repair_hints. It also specifies what inputs to provide (error_text, goal, context) from other tools. However, it does not explicitly state when not to use it.

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

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

Annotations already declare readOnlyHint=true, confirming safe read-only behavior. The description goes beyond by detailing the types of errors covered (wrong Location syntax, missing .part, etc.) and recommended sources, adding meaningful behavioral context without contradicting annotations.

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

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

The description is two concise sentences with no redundant information. The first sentence front-loads the purpose and scope, while the second provides usage guidance. Every sentence is necessary and earns its place.

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

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

Given the tool's simplicity (one parameter, read-only, with an output schema), the description sufficiently covers how and when to use it. It mentions return type implicitly ('return targeted fix suggestions'), and the output schema handles return value details.

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

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

With 0% schema description coverage, the description compensates by identifying the sole parameter (error_text) as an error string and specifying its origin. It adds value beyond the schema's title, though it could include more format or length constraints.

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

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

The description clearly states the tool's purpose: to return targeted fix suggestions for common build123d mistakes given an error message. It specifies the verb 'return' and the resource 'fix suggestions', and lists specific error categories, distinguishing it from siblings like repair_advice or workflow_hints.

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

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

The description explicitly tells the user to pass the full error string from specific sources (execute(), last_error(), validate(), or export()), providing clear context for when to use the tool. However, it does not mention when not to use it or specify alternatives among sibling tools.

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

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

Annotations already indicate destructive (destructiveHint=true) and idempotent (idempotentHint=true). The description adds that snapshots are also cleared, which is behavioral context beyond the annotations. However, it does not describe side effects like permission requirements or whether any data is recoverable.

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

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

The description is a single, concise sentence that front-loads the main action. Every word is informative, with no redundancy 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 parameterless tool with an output schema (as indicated by context signals), the description fully explains the tool's effect: clearing the session and all snapshots. No additional information is needed for an agent to correctly invoke it.

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

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

There are no parameters, and schema description coverage is 100% (trivially). Per guidelines, baseline is 4 for zero parameters, and the description adds no parameter info because none exist.

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

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

The description clearly states the tool's purpose: clearing the session and all snapshots, using the specific verb 'Clear' and resource 'current session back to empty state'. It distinguishes itself from siblings like 'restore_snapshot' or 'session_state' by specifying a full reset.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or caveats. It simply states what it does, leaving the agent to infer 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?

Beyond the annotations, the description discloses the side effect of storing descriptors in session.geometry_refs when a label is provided. It also exposes important geometric edge cases, such as the true centre versus parametric midpoint and the behavior of curved faces, which an agent could not infer from annotations alone.

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 every sentence adds useful behavioral or output information, especially around center computation and curved-face handling. Its length is justified by the tool's complexity, though a more structured layout (e.g., bullets for output fields) would improve skimmability.

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

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

The description explains what the tool does, how to use the selector, what the label parameter does, the full return structure, and the subtle geometry semantics. It is thorough enough for an agent to call the tool correctly even without parameter descriptions in the schema.

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

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

With 0% schema description coverage, the description compensates by explaining selector syntax with a concrete example and detailing label's storage side effect. Object_name is less explicit, but the phrase 'named object' and the @cad[object#label] format give enough context for an agent to understand its role.

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

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

The description names a specific verb, 'Evaluate a selector expression against a named object', and a concrete resource type, making the tool's function unmistakable. The emphasis on selector expressions and geometry descriptors clearly sets it apart from sibling geometry tools like measure or inspect_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?

The description gives a clear context of use through its example and selector explanation, so an agent can infer when this tool is appropriate. However, it never explicitly states when to use this tool instead of sibling tools like script, execute, or measure, nor does it mention 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?

Annotations indicate idempotentHint=true, which the description supports by implying the operation is reversible and idempotent. Description adds nuance about what is not restored (Python namespace) and error behavior, exceeding annotation detail.

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

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

Three sentences, front-loaded with purpose, followed by behavioral nuance and error condition. No superfluous words.

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

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

For a simple tool with one parameter and output schema, the description covers main behavior, constraints, and error. Could add a note on idempotency but annotations cover it.

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

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

Schema coverage is 0%, so description must compensate. The description only indirectly mentions the 'name' parameter by stating an error if snapshot name does not exist. It does not explain what valid names are, where snapshots come from, or format requirements.

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?

Description clearly states 'Restore geometric state from a previously saved snapshot' with specific details about what is restored (current_shape and show() registry). This is a specific verb and resource, differentiating from sibling tools.

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

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

Description provides context on when to use: to revert geometric state while preserving variable namespace. It also mentions error on non-existent snapshot. However, it does not explicitly compare to alternatives like diff_snapshot.

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

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

Annotations only set readOnlyHint=false and destructiveHint=false, so the description carries the burden of explaining write behavior. It does so well: writes a sidecar, explains why it is necessary (build123d renders text as glyph paths, making labels irrecoverable), and notes the sidecar is automatically read by inspect_drawing. It stops short of stating overwrite behavior or error cases, but the core behavioral context is strong.

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

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

The description is longer than minimal but every sentence earns its place: deprecation status, why the sidecar is needed, when to call, the workflow, and parameter detail. It is front-loaded with the deprecation warning and structured with a numbered workflow and args section, making it easy for an agent 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 single-parameter tool with an output schema, this description is complete. It covers deprecation, the exact calling sequence relative to export, the sidecar file naming, and integration with inspect_drawing. An agent has everything it needs to decide whether to use the tool and how to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate entirely for the single parameter. It does, fully: 'svg_path: path to the SVG file (sidecar written as <svg_path>.dims.json).' This adds the sidecar naming convention and makes the parameter semantics unambiguous. No other parameters exist to document.

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: 'Write a .dims.json sidecar file alongside an SVG with label metadata.' This clearly distinguishes it from sibling tools like export (which writes the SVG), inspect_drawing (which reads the sidecar), and lint_drawing. The deprecation note also clarifies its legacy status without muddling 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?

Explicitly says when to call it: 'after completing a drawing (annotate all dims/leaders with annotate()) and before or after exporting the SVG.' Provides a numbered workflow with exact call order and names the consumer (inspect_drawing). Also gives an exclusion: deprecated and moved to draftwright, so agents know not to rely on it going forward.

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

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

Annotations provide idempotentHint=true and destructiveHint=false. Description adds context about what is saved (geometry only) and what is not (variables), but does not clarify behavior on duplicate names or error conditions.

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?

Description is concise and front-loaded, but could be slightly more compact without losing clarity.

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

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

Given the tool's simplicity, the description covers purpose, usage guidance, and behavioral caveats. Lacks details on overwrite behavior, but overall adequate.

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

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

Only one parameter (name) with 0% schema coverage. Description mentions 'named checkpoint' but provides no details on name format, uniqueness, or constraints.

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

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

Description clearly states it saves a named checkpoint of geometric state, distinguishing it from restore_snapshot and diff_snapshot. It specifies that only geometry is saved, not Python variables.

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 (before risky experiments) and what it does not save (Python variable namespace). Alternates are implied by sibling tools (restore_snapshot).

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

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

The description adds key behavioral details beyond the readOnlyHint annotation: it prepends an import, optionally writes to a file, and returns different objects based on the parameter. The file write is a side effect, but it's clearly disclosed and doesn't contradict the annotation (which likely refers to internal state).

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

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

The description is three short sentences with no wasted words. It front-loads the core purpose, then adds key details, making it easy 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?

The description covers the main behavior, parameter effect, and return types. It could mention the case of no executed code blocks, but the tool is simple enough that this is a minor omission.

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

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

The schema has 0% description coverage, but the description fully explains the parameter 'save_to'—its effect on behavior and return value—adding semantic meaning that the schema lacks.

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

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

The description clearly states the tool returns a single Python script from executed code blocks, with a specific verb and resource. It differentiates from siblings like 'execute' or 'export' by focusing on assembling code, not running or saving files generically.

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 mentions the tool is 'useful for exporting a reproducible script after an interactive session,' providing clear guidance on when to use. While it doesn't mention when not to use or alternatives, the context is sufficient for an agent to decide.

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

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

Annotations already indicate readOnlyHint=true. Description adds that it returns a structured JSON snapshot with detailed breakdown of session state, which is fully transparent. No contradictions.

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

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

Two well-structured sentences that front-load the purpose and provide additional context. Every sentence is informative with no redundancy.

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

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

Given no parameters, high schema coverage, and presence of output schema, the description fully covers when to use, what it returns, and its purpose. Complete for the tool's complexity.

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

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

No parameters in schema, and description confirms no parameters needed. Baseline 4 as per guidelines.

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?

Description clearly states 'Return a structured JSON snapshot of the current session' with specific contents (shape metrics, named objects, snapshot names, variables summary). It also distinguishes itself from sibling tool list_objects by saying it replaces it.

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

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

Explicitly states when to use: 'Use this to orient after a reset, restore, or multi-step build to confirm what geometry and variables are active.' Also mentions it replaces list_objects, giving an alternative.

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

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

The annotations only declare readOnlyHint=true, so the description carries the behavioral disclosure burden. It adds substantial detail: the tool measures the named shape's bounding box, returns exact orthographic positions, approximates the iso position at 75% of the 3-D diagonal, and reports warnings/suggestions. It also discloses the deprecated runtime behavior ('Calling it explains the replacement'), which is useful for an agent deciding whether to invoke it.

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

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

The description is long but well-structured with a deprecation banner, an ASCII layout diagram, output-shape explanation, parameter bullets, and an accuracy caveat. It front-loads the most important decision signal (deprecation) and each section earns its place, though it is denser than strictly necessary for a deprecated tool.

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

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

Given 10 parameters, no schema-level parameter descriptions, and an output schema, the description nonetheless explains the return JSON structure, all parameter defaults, the layout algorithm, limitations, and follow-up verification. The only minor gap is that the replacement tool ('draftwright') is not itself a sibling in the current list, but the deprecation context is still sufficient.

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

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

Schema description coverage is 0%, and the description compensates thoroughly by explaining every parameter: object_name, page_w/page_h, scale, views, title_block_w/h, margin, extents, and centroid. It adds meaning beyond the schema by giving defaults, valid view subsets, and the extents fallback use case.

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

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

The description states a clear verb and resource: 'Auto-calculate safe VIEW_X / VIEW_Y positions for a multi-view engineering drawing.' It also leads with deprecation and the replacement path ('moved to draftwright'), which prevents an agent from mistaking it for a current layout tool. This is distinct from sibling rendering/measurement tools because it is specifically about calculating page positions and layout data.

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 deprecation notice ('DEPRECATED (#465) — moved to draftwright; off by default in 0.4.0, removed in 0.5.0') is an explicit when-not-to-use signal with a named alternative. It also provides a concrete conditional for the extents parameter ('use when the part isn't loaded, e.g. import failed') and advises verifying the approximate iso placement with render_view().

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

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

Annotations already declare readOnlyHint=true, so the description doesn't need to restate that. It adds meaningful behavioral context beyond the annotation: what the gate checks (BRepCheck, watertight, manifold, non-zero volume), what a FAIL means, and common causes. This goes beyond a mere read-only flag and helps the agent interpret results correctly.

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 fairly long but every sentence serves a purpose: purpose, return format, gate criteria, failure meaning, usage timing, and parameter. It is front-loaded with the core purpose and structured logically. It could be slightly trimmed (e.g., the list of failure causes could be shorter), but it remains efficient and readable.

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

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

Given the tool's complexity, the description is complete: it explains the function, the returned JSON fields (passes_gate, n_solids, volume, is_manifold, brep_valid, reasons), the gate criteria, when to use it, and the parameter. An output schema exists but the description already lists the fields, so nothing essential is missing for correct invocation.

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

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

Schema coverage is 0% and there is one parameter, object_name. The description explicitly explains it: 'object_name: named object from show() (default: current shape).' This fully compensates for the lack of schema description, giving the agent the source and default of the parameter. No other parameter exists, so nothing is left 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 states a clear verb (check) and a specific resource (whether a shape would pass a CAD validity gate), and explicitly ties it to exporting. It differentiates itself from siblings like export() by framing itself as the pre-export gate, and the phrase 'Run this immediately before export()' reinforces its distinct role.

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 usage instruction: 'Run this immediately before export() on any part you intend to submit or hand off.' This tells the agent exactly when to invoke it. It also explains the consequence of a FAIL (export would be rejected), which helps the agent decide whether to call this tool before other actions.

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

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

Annotations already mark it as read-only. The description adds value by specifying what versions are returned (server, dependencies, companion packages). No negative behaviors need disclosure.

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

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

Two sentences, front-loaded with what the tool returns, followed by usage. Every word earns its place; no redundancy.

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

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

Given zero parameters, readOnlyHint annotation, and an output schema, the description fully covers what the tool does and when to use it.

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

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

No parameters, so no additional parameter info needed. Baseline 4 applies as per rubric for 0 parameters.

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

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

The description clearly states it returns installed versions of the server and its key dependencies, listing specific packages. It distinguishes from sibling tools by focusing on version information.

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 provides use cases: confirm which server build is running, check for features/fixes, or detect a stale install. This gives clear guidance on when to invoke the tool.

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

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

Even though readOnlyHint is already set, the description adds substantial behavioral detail: it is computed analytically, performs no projection, is deprecated/off/removed in specific versions, and returns a JSON mapping with a concrete sign-flip example. This goes well beyond the annotation.

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

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

The description is dense but well-organized: deprecation status is front-loaded, followed by purpose, usage timing, example output, and parameter explanations. Each section earns its place and nothing feels redundant.

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

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

For a read-only analytical tool, the description is complete: it covers when to use it, what it returns, how the return is structured, the meaning of each parameter, and the deprecation behavior. The output schema also exists, so return values are fully covered.

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

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

Schema description coverage is 0%, and the description compensates fully for all three parameters: viewport_origin is the camera position and same arg as project_to_viewport, viewport_up is the up vector defaulting to (0,1,0), and look_at is the target point defaulting to origin. This adds real meaning absent from the schema.

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

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

The description states a specific verb and resource: it returns the world→page axis mapping for a project_to_viewport call, computed analytically with no projection performed. This clearly separates it from rendering tools and explains its role in catching axis swaps.

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

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

It explicitly says to use this BEFORE rendering a projected view, and explains that it catches bottom-view/side-view axis swaps. It also gives a clear when-not via the deprecation notice and names the replacement (draftwright), plus notes that calling it explains the replacement.

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

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

Annotations already indicate readOnlyHint=true; description reaffirms it returns guidance, consistent and sufficient for this simple case.

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

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

Two concise sentences with front-loaded purpose and usage instructions, 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?

Tool has no parameters, annotations cover safety, output schema exists, and description covers purpose and usage completely.

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?

No parameters, so schema coverage is 100%. Description does not need to add parameter 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 clearly states the tool returns guidance on using other tools, which is a specific verb and resource. It distinguishes itself from sibling tools that perform other actions.

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 advises calling at start of session or when unsure which tool to use, providing clear context and implying alternatives.

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