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?

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?

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?

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 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?

Annotations already declare readOnlyHint=true. The description adds that it is diagnostic and lists the specific details reported. No contradictions and provides useful 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 to three sentences, front-loaded with the main action and details. Every sentence provides essential information without redundancy. Highly concise.

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 a single optional parameter and an output schema. The description lists reported items but does not explain the input parameter. Given the low complexity, the gap in parameter guidance makes it incomplete.

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 optional parameter 'object_name' with default empty string. Schema coverage is 0%, but description does not explain what the parameter represents or how to use it. The description mentions 'extending a boss' but does not connect to the parameter, leaving 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 finds candidate bored bosses and reports specific evidence (bore opening location, axis, diameter/depth, cap faces, etc.), distinguishing it from sibling tools like 'find_bosses' which likely find generic 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?

Explicitly states when to use: 'before extending a square/rounded-square boss with a central bore.' Also clarifies it is 'read-only and diagnostic, not proof.' No explicit alternatives mentioned, but 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?

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?

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?

Annotations indicate readOnlyHint=true, confirming a safe read operation. The description goes beyond by detailing what is returned (bounding boxes, annotation metadata, lint) and explaining behavior in both modes, including SVG mode's independence from the session. 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 fairly long but well-structured with headings and bullet-like sections. It is front-loaded with the core purpose. Every sentence adds value, though the examples could be slightly condensed. Overall, it is appropriately detailed without being overly verbose.

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

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

Given the tool's dual-mode complexity and the presence of an output schema, the description is complete. It covers both modes, explains what is returned, and provides necessary context for using annotate() with different libraries. No 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 bears full responsibility. It explains both parameters: 'objects' (comma-separated names, default all) and 'svg_path' (switches to SVG mode). It also provides usage examples, adding significant value beyond the schema's basic type 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 clearly defines the tool as providing a structured bbox and annotation report for 2D drawings. It explicitly distinguishes two modes (session and SVG) and explains what each does, making it easy to understand the tool's purpose and differentiate from sibling tools like 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?

The description gives clear guidance on when to use each mode, including examples and prerequisites for session mode (using annotate() correctly). It also explains default behavior (all objects). While it does not explicitly state when not to use this tool, the context provided is sufficient for correct selection.

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

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

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 indicate the tool is not read-only and not destructive. The description adds context that it writes config files, overwrites if force=True, and lists the effects for each skill-target combination. 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 well-structured with a clear general statement, followed by bullet-like lists for skill and target parameters. Every sentence adds value, 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?

The description covers all necessary aspects: what the tool does, parameter details with examples, and behavioral context (defaults, overwrite). With an output schema present, return values need not be explained.

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, but the description fully explains each parameter: skill options with their meanings, target options with file paths, and force behavior. This compensates completely 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 the tool copies a workflow skill into the current project and writes config files, with specific skill types and targets listed. This distinguishes it from sibling tools like workflow_hints, validate, or analyze 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?

The description explains when to use the tool (to install specific workflow skills for different agent targets) and provides defaults, but does not explicitly state when not to use it or mention alternative 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 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; the description confirms it runs checks and returns violations without side effects. It adds significant behavioral detail: two modes, specific checks performed, and how drawing_scale affects false positives. This adds value beyond the annotations.

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

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

The description is somewhat long but well-structured with sections and bullet-like lists. Key information is front-loaded (purpose and return format). Each sentence adds value, though some details could be more concise. Overall 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 an output schema (violations) and three parameters, the description covers all important aspects: modes, parameter semantics, violation structure, and usage timing. It is self-contained and sufficient for an agent to understand 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%, so the description must explain all three parameters. It does so thoroughly: svg_path triggers SVG mode, drawing_scale adjusts label-vs-measured checks with default 1.0, view_shape_names detects view overlaps. Each parameter's purpose, usage, and defaults are clearly described.

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

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

The description clearly states the tool runs structural drawing-quality checks, returns JSON with violations, and lists specific categories (label divergence, overlaps, etc.). It distinguishes session mode (annotations) from SVG mode (SVG file scanning), making the purpose concrete and differentiating it from sibling tools like inspect_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?

The description advises 'Run this after major drawing additions; running it BEFORE rendering catches the bug at the source.' It also explains when to use each mode (session vs. SVG). However, it does not explicitly state when not to use the tool or name alternatives, 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?

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?

Beyond the readOnlyHint annotation, it discloses the tool's full behavior: it returns per-defect coordinates, includes repair hints and a diagnosis block, returns an empty list when the part passes, and is bounded out-of-process with a budget error for huge parts. This goes far beyond the annotation's minimal read-only flag.

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 information-rich, front-loaded with purpose, but it is a single long paragraph rather than structured bullets. Every sentence contributes, but readability would benefit from partitioning; still, it earns a high score for substance.

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

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

Given the tool's complexity, the output schema, and the read-only annotation, the description fully covers purpose, usage, behavior, parameters, and edge cases (budget errors), leaving no significant gap. It even explains return semantics despite the output 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?

The only parameter, object_name, is explained in the description as 'named object from show() (default: current shape),' adding semantic context beyond the schema's bare string type and default. This compensates 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 opens with 'Report WHERE a solid fails the validity gate, with 3D coordinates' — a specific verb and resource, and explicitly contrasts with validate()/export() which tell WHAT but not WHERE, distinguishing it from sibling tools. It also enumerates concrete defect types, making the purpose unmistakable.

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

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

It explicitly says 'call this when validate() FAILs to get a per-defect list,' giving a clear trigger condition, and contrasts with validate()/export() as alternatives. It also warns about budget errors for huge parts, which further guides when 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?

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 already indicate readOnlyHint=true. The description adds that the PNG is returned inline and that width uses a default of 1200 with height determined by aspect ratio, using the resvg-py library. It does not detail potential issues like file not found or large file limits, but the key behaviors are covered.

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 efficient, consisting of a concise opening sentence, a contrast with a sibling, a note on return method, and a clear Args section. Every sentence adds value 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?

For a simple conversion tool with no output schema, the description covers the essentials: purpose, input parameters, comparison to a sibling, and return behavior. It could mention error handling or format details, but it is largely 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?

The schema has no parameter descriptions (0% coverage). The description compensates fully by explaining each parameter: svg_path is a file path, width is pixel width with aspect ratio scaling, save_to optionally writes the PNG to disk. This adds clear meaning beyond the raw 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 it rasterizes an SVG file to PNG, and distinguishes from the sibling tool render_view by noting that render_drawing accepts an external SVG file, while render_view uses build123d shapes from the live 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?

The description explains when to use this tool (when you have an SVG file written outside the sandbox) and contrasts it with render_view. However, it does not provide explicit guidance on when NOT to use it or mention other alternatives 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?

The description discloses auto-detection logic, fallback behavior, format specifics, object coloring, clip plane operation, and highlight limitations (PNG-only), adding significant context beyond the readOnlyHint 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-organized, starting with purpose then detailing parameters, though slightly verbose for some users.

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 13 parameters and no output schema, the description covers all parameter behaviors, auto-detection, fallback, and limitations, providing complete guidance for effective use.

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 thoroughly explains all 13 parameters including format values, object syntax, clip plane axis, and highlights structure, effectively compensating for the schema gap.

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

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

The description starts with 'Render model' and details auto-detection of 3D vs 2D, formats, and parameters, clearly distinguishing from siblings like 'render_drawing' by its 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 advises using measure() for geometry verification and explains when to force mode if auto-detection is wrong, but lacks explicit comparison with 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 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?

Annotations already indicate idempotentHint=true and readOnlyHint=false, but the description adds useful behavioral context: it stores results in session.geometry_refs if a label is provided and describes the return format. This goes beyond the annotations without contradicting them.

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 pack substantial information: purpose, example usage, return format, and side-effect of labeling. While concise and front-loaded, the structure could be more bulleted or segmented for easier parsing.

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

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

Given the presence of an output schema (not shown but noted), the description covers the essential purpose, parameter usage, and return structure. It omits details about error cases or default behavior when label is omitted, but overall suffices for typical use.

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 carries the full burden. It explains the selector parameter with an example ('.faces().filter_by(Axis.Z).last()'), clarifies that object_name is a named object, and describes the label's storage effect. This significantly 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 tool evaluates a selector expression against a named object and returns a geometry descriptor. It provides a specific verb ('evaluate') and resource, distinguishing it from sibling tools like 'measure' or 'inspect_drawing' that perform different analyses.

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 does not explicitly state when to use this tool versus alternatives like 'measure' or 'clearance'. It provides no context about prerequisites, when not to use it, or how it compares to other geometry query tools, leaving the agent to infer usage solely from the purpose.

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 indicate readOnlyHint=false and destructiveHint=false. The description adds that the tool writes a sidecar file (non-destructive write) and explains the file naming convention (<svg_path>.dims.json). It also describes how the sidecar is used by inspect_drawing. This provides good behavioral context beyond the annotations.

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

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

The description is approximately 150 words, well-structured with sections for purpose, why needed, workflow, and args. It is front-loaded with the core purpose and every sentence adds value. No unnecessary repetition or fluff.

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, no nested objects, output schema exists), the description is complete. It explains the sidecar file, workflow steps, and the relationship with inspect_drawing. An agent has enough information to invoke the tool correctly in the intended context.

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

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

The description includes an 'Args' section that adds value to the schema: it explains that svg_path is the path to the SVG file and that the sidecar is written as <svg_path>.dims.json. This clarifies the parameter's purpose and the naming convention, improving on the schema's minimal definition.

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 writes a .dims.json sidecar file alongside an SVG with label metadata. It explains why this is necessary (build123d renders Text as filled glyph paths, making label strings irrecoverable) and distinguishes from sibling tools like inspect_drawing which reads the sidecar.

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 a clear workflow: build drawing, export SVG, save annotations, inspect later. It specifies when to call (after completing a drawing and before/after exporting) and prerequisites (annotate() for all dims/leaders). However, it does not explicitly state when not to use or mention alternatives, though the workflow implicitly guides 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?

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?

Annotations already declare readOnlyHint=true, so the description does not need to restate that. It adds valuable behavioral context: returns positions, free space, warnings, and a suggestion. Importantly, it notes accuracy limitations ('Iso position is approximate') and advises verification with render_view(). This goes 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 front-loaded with the purpose and a visual layout diagram, then the return structure, then parameter details. It is relatively long due to complexity but every part adds value. Could be slightly more concise, but the structure aids readability.

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

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

Given the tool's complexity (10 parameters, no required, output schema exists), the description covers all aspects: purpose, layout pattern, output format, detailed parameter explanations, and accuracy caveats. It is thorough and leaves little ambiguity for an AI agent to correctly invoke and interpret results.

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 all 10 parameters in context. It describes object_name, page_w/h, scale, views, title_block_w/h, margin, extents, centroid, and their purposes, including use cases like extents for unloaded parts. This provides clear semantic meaning beyond the schema's name and type.

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 'Auto-calculate safe VIEW_X / VIEW_Y positions for a multi-view engineering drawing', specifying a specific action (calculate) and resource (positions). It further details the output and layout pattern, distinguishing it from all sibling tools that focus on other aspects like alignment, clearance, or rendering.

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 usage when needing to place views on a drawing and mentions a conditional use case for extents when part is not loaded. However, it lacks explicit guidance on when to use this tool versus alternatives, or when not to use it. No direct exclusions or comparisons to sibling tools 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?

The description adds significant behavioral details beyond the readOnlyHint annotation: it explains the gate conditions (watertight, manifold, non-zero volume), common failure causes, and the consequences of a FAIL. It also lists the exact JSON fields returned, which is not in the annotations.

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

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

The description is front-loaded with the purpose and return type, followed by gate details and usage instructions. It is concise (6 sentences) without superfluous text, though some sentences are lengthy.

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 tool's purpose, when to use it, return values, and parameter. With the output schema present, the return structure is well-documented. However, it does not explain all possible failure reasons exhaustively, but provides common ones.

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 documents the sole parameter 'object_name' meaningfully: it is a named object from show() with default being the current shape. This fully compensates for the lack of schema documentation.

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

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

The description clearly states the tool's purpose: to check if a shape passes a CAD validity gate before export. It specifies the return type (PASS/FAIL verdict plus JSON) and distinguishes it from the sibling 'export' tool by stating it should be run immediately before export.

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

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

The description explicitly says to run this tool immediately before export() on any part intended for submission. This provides clear context for when to use it, though it does not contrast with alternative tools like 'locate_gate_defects' which might serve a similar purpose.

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?

Annotations already declare readOnlyHint=true, and the description adds valuable behavioral context: 'computed analytically (no projection performed)' and shows an example output with sign flips. This goes beyond annotations to explain the computation nature.

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: first sentence states purpose, second gives usage context, third shows example output, then Args. It is front-loaded and concise, though the example output could be slightly trimmed 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 that there is no output schema shown, the description fully compensates with a clear example JSON output. It covers all 3 parameters (1 required), provides defaults, and links to a sibling. The tool is simple, and the description leaves no 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?

Schema description coverage is 0%, but the description includes an 'Args:' section with brief descriptions for all three parameters. It links viewport_origin to the sibling project_to_viewport and specifies defaults for viewport_up and look_at, adding 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 the world-to-page axis mapping, computed analytically. It explicitly says 'Use this BEFORE rendering a projected view' and describes catching axis swaps, which distinguishes it from sibling tools like render_view or align_check.

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

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

The description provides clear context: 'Use this BEFORE rendering a projected view' and explains the benefit of catching axis swaps early. It does not explicitly mention when not to use it or list alternatives, but the context is strong enough for an agent to understand its purpose relative to siblings.

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.