kernelcad

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

The description declares 'Side-effect-free' and explains the return value ('Returns modified source plus diagnostics'), which matches the annotation destructiveHint=false. 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 clear sentences and a code snippet; every part is essential and front-loaded with the purpose. 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 tool with 7 parameters and no output schema, the description adequately covers usage, side effects, and return value. It could mention constraints like unique name within part, but overall 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?

With 86% schema coverage, the description adds value by showing the exact code template for using parameters like part_binding, name, type, origin, and optional axis/normal, going beyond 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 states the specific action 'add a mate connector to a part' and provides a code template, clearly distinguishing it from other sibling tools like add_feature or add_constraint.

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 initial sentence explicitly says 'Use this when you need to add a mate connector to a part.' It provides clear context, though it does not mention when not to use it or name 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?

Explicitly states 'Side-effect-free' and describes the input/output pattern, which adds value beyond annotations. Annotations already indicate non-destructive and non-read-only, but the description clarifies the safe, pure function behavior.

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

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

Exceptionally concise with two sentences that front-load the purpose and provide essential guidance. Every sentence adds 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?

Covers the basic flow (input list, constraint, output list) but lacks details on return format and constraint validation, which are important given no output schema and nested objects.

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 compensates by explaining the role of 'constraint' and 'constraints' in appending. However, it does not detail the structure of the constraint object, leaving some 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?

Clearly states the verb 'add' and resource 'sketch constraint to a list', distinguishing it from general add tools. However, it does not explicitly differentiate from sibling add tools like add_connector or add_mate, which also add constraints.

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 a clear condition ('when you need to add a sketch constraint to a list') but lacks explicit when-not-to-use guidance or alternatives, such as when to use add_connector instead.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, and the description confirms 'Side-effect-free.' It explains behavior for each kind, including defaults and that each kind fails closed on missing required params. 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 somewhat lengthy due to the complexity of two authoring paths, but it is well-structured with bullet points and front-loaded with the main purpose. Minor redundancy could be trimmed.

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 complexity (10 parameters, nested objects, two distinct paths), the description covers purpose, usage, parameter details, return value, side-effects, and downstream consumption. No output schema, but the description explains the return. Complete 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?

Schema description coverage is 100%, but the description adds significant meaning: it explains the purpose of each kind, the structure of hermite endpoints, default degree, and how parameters relate to the two paths. This goes beyond the 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 'Use this when you need to author a 3D Curve3D' and explains two distinct authoring paths (nurbs and hermite). It distinguishes from sibling tools like add_variable_sweep and add_surface by specifying that the returned Curve3D is consumed by them.

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 states when to use the tool ('Use this when you need to author a 3D Curve3D') and mentions how the result is consumed by other tools. It does not explicitly list when not to use it, but the context is clear. Slight lack of direct comparison to siblings like project_curve.

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 'Side-effect-free' and 'Returns the modified code as text plus diagnostics', providing behavioral context beyond annotations (which already show readOnlyHint=false and destructiveHint=false). 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 moderately sized with two main sentences, front-loading the purpose. The third sentence about faceLabels is useful but slightly lengthy. Overall efficient with 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 tool has 2 parameters, no output schema, and basic annotations, the description is fairly complete: it explains the action, behavior, return value, and includes a tip. Sufficient for its simplicity.

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

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

Schema coverage is 100%, but the description adds value by specifying feature_code as 'single-statement source line', giving an example, and mentioning faceLabels usage. This clarifies parameter semantics 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 verb 'insert' and the resource 'feature line into a script', specifying insertion before the last return statement. It is clear but does not explicitly differentiate from sibling tools like add_connector or add_constraint.

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

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

The description says 'Use this when you need to insert a new feature line into a script', providing a clear when-to-use. However, it lacks explicit when-not-to-use or alternatives, despite having 37 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 indicate readOnlyHint=false and destructiveHint=false, but the description adds behavioral details: 'All durably edit source', 'each relation fails closed on its own missing required params', and the forwarding of parameters. This context aids the agent in understanding side effects.

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

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

The description is front-loaded with purpose and uses a bullet list for relation types, making it scannable. However, it could be more concise by condensing the inline parameter structure definitions.

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 complexity (22 parameters, 3 relation types) and no output schema, the description covers the main behaviors and required parameters per relation. It lacks information about return values or confirmation, but remains fairly complete.

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

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

Schema coverage is 100%, so baseline is 3. The description groups parameters by relation type, explains the default 'relation' parameter, and highlights that parameters are forwarded verbatim. This adds meaningful context beyond the 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 authors a 'mate-graph relationship' and lists three specific relation types ('mate', 'coupling', 'transmission') with their purposes. This distinguishes it from siblings like 'add_connector' or 'add_constraint'.

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

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

The description says 'Use this when you need to author a mate-graph relationship', but it does not explicitly guide when not to use it or provide alternatives among siblings. While the context implies it is for mechanical relationships, there is no clear exclusion or comparison.

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 behavioral traits beyond annotations: it notes that the tool is 'side-effect-free' and that the caller persists the returned source. It also explains the return value (modified source plus diagnostics). Annotations only provide non-read-only and non-destructive hints.

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

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

The description is concise at three sentences, front-loads the purpose, and each sentence provides essential information without 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 complexity (6 params, no output schema), the description covers the core functionality and return values. It could elaborate on the diagnostics format, but it is sufficiently complete for an AI agent to use the tool correctly.

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

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

With 100% schema coverage, the baseline is 3. The description adds value by explaining how parameters are used together in the code insertion pattern (e.g., 'const <binding> = <assembly>.part(partName, shapeExpression, opts?)'), and clarifies the optional parameters like 'binding_name'.

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: 'Use this when you need to add a part to an assembly.' It specifies the exact code insertion pattern and distinguishes from sibling 'add_' tools by targeting a different entity.

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 the tool ('when you need to add a part to an assembly') and specifies the insertion point ('before the final top-level return'). However, it does not explicitly exclude alternative tools or mention 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?

The description explicitly states behavioral traits: the call is injected at the END of the chain before any '.close()', it is side-effect-free, returns modified code and diagnostics, and each kind fails closed on missing required params. Annotations provide readOnlyHint=false and destructiveHint=false, which the description reinforces without contradiction, adding further context about the nature of the mutation.

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

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

The description is well-structured with a clear lead sentence followed by bullet points for each segment kind. Every sentence adds essential information; there is no fluff. The front-loaded purpose and organized details make it easy to scan and understand.

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 (14 parameters, nested objects, no output schema), the description covers all necessary contextual elements: the overall purpose, how segments are appended, return value ('modified code + diagnostics'), side-effect safety, and constraints for each kind. No missing aspects for an AI agent to use it correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds significant value beyond the schema by explaining the workflow, the position of injection, constraints like points[0] must match pen position, and semantics of optional parameters like tension and tangents. This enrichment justifies a score above baseline, though some details are already in 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 action ('append a curved segment to an existing PathBuilder chain') and the specific resource ('named chain_anchor variable'). It details three segment kinds, each with distinct usage, which implicitly distinguishes it from sibling tools like 'add_curve' that may have a different scope. The verb-resource combination is precise and 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 begins with 'Use this when you need to append a curved segment...', providing clear context for when to invoke the tool. However, it does not explicitly mention when not to use it or list alternative tools, so it misses the full 'when-not/alternatives' requirement for a 5. Nonetheless, the context is well-defined.

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 value beyond annotations by stating 'Side-effect-free' and explaining the geometric behavior (cumulative boolean union, additive vs subtractive features). This complements the annotation destructiveHint=false and readOnlyHint=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?

The description is a single paragraph that front-loads the purpose, but includes some technical detail (e.g., face refs, geometric note) that could be condensed. It is adequate but not optimally 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?

Given the tool's complexity (7 parameters, nested objects, no output schema), the description covers key aspects: usage, return value (modified code + diagnostics), side-effects, and pattern behavior. It lacks details on error cases or prerequisites, but overall is fairly complete.

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

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

Schema coverage is high (86%), so the schema already documents most parameters. The description adds high-level guidance ('Pass structured args (kind + the matching spec object)') and explains 'target' as the variable name, but does not substantially enhance individual parameter semantics 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's purpose: 'Use this when you need to repeat a feature in a pattern.' It specifies that it inserts a pattern call (Shape.patternLinear/.patternCircular/.patternGrid) into a script, which differentiates it from sibling tools like add_feature or flatten_pattern.

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 when to use the tool ('when you need to repeat a feature in a pattern') and how it modifies the script ('before the last top-level return'). However, it does not explicitly mention when not to use it or provide alternatives among 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 indicate readOnlyHint=false and destructiveHint=false, meaning the tool modifies state but is not destructive. The description adds important behavioral context: the tool returns modified code and diagnostics, the Surface produces no Shape until chained, and for the 'nurbs' kind, weights are ignored in the current slice-1 build. This goes beyond the annotations and provides useful operational knowledge.

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, using bullet-like formatting to separate the two paths. Every sentence contributes useful information (parameters, limitations, return behavior). It could be slightly more concise, but it is not wasteful. The front-loaded purpose sentence 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's complexity (12 parameters, two distinct modes, nested objects, no output schema), the description is remarkably complete. It explains the return value (modified code + diagnostics), the required follow-up step via add_feature, the limitation about weights, and defaults for optional parameters. No important aspect is left unaddressed.

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

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

The input schema has 100% description coverage, but the description still adds significant meaning: it explains the two construction paths (direct vs. skinning, boundary vs. nurbs), defaults for knots and continuity, and the requirement for 4 curve bindings in boundary mode. It clarifies that 'controls' supplies a grid for direct construction while 'section_sketch_ids' is for skinning. This is far beyond the schema descriptions alone.

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: 'author a NURBS Surface into the user's .kcad.ts'. It specifies two concrete paths (nurbs and boundary) and their input options, making the action very specific. The sibling list contains no other surface-creation tool, so differentiation is inherent.

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 (to author a NURBS surface) and briefly mentions that the resulting Surface requires further chaining with .thicken or .toShape via add_feature. However, it does not explicitly state when not to use it, nor does it compare with alternatives like direct code editing or other tools. The guidance is present but not comprehensive.

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 annotations: side-effect-free, returns modified code plus diagnostics, fails closed on missing params, default font, and emboss depth behavior. 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 concise with 3-4 sentences, front-loads the primary use case, and explains modes and key behaviors efficiently. No redundant 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?

Despite no output schema, the description covers purpose, both modes, parameter behavior, side effects, and fallback behavior. It is complete for a complex tool with 17 parameters.

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

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

Schema coverage is 100%, but the description adds meaningful context (e.g., chainability for sketch, depth direction for emboss, default values for anchor and font). This goes beyond the 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 is for authoring text into a kernelCAD script, with two distinct modes (sketch and emboss). It distinguishes from sibling tools that handle other design elements like curves, features, etc.

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 guidance on when to use each mode (sketch for chainable sketch.text, emboss for engraved/raised text on faces) with concrete examples. It does not explicitly exclude other usage, but the context is sufficient.

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 beyond annotations by detailing the side-effect-free insertion into source code, validation method (regex), and return value (modified code + diagnostics). It also mentions limitations (no orientation support), which adds transparency not covered by 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 (6 sentences), front-loaded with the primary use case, and every sentence adds value. No redundancy 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?

For a tool with no output schema, the description adequately covers the insertion action, validation, and return value (modified code + diagnostics). It could mention more about the return format or error cases, but given the complexity and sibling context, it is sufficiently complete.

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

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

With 100% schema coverage, the baseline is 3. The description adds significant context: it explains that spine_binding references existing Curve3D/Sketch/Vec3[], sections profile_binding references existing Sketch, and reinforces constraints on t values and section ordering. This exceeds the structural 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 explicitly states the tool's purpose: 'Use this when you need to author a variable-section sweep along a spine.' It clearly distinguishes from sibling tools like add_curve or add_path_segment by specifying the variable sweep operation and mentions the resulting Shape type.

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 when-to-use guidance ('author a variable-section sweep'), constraints (sections must be strictly increasing t, span [0,1]), and what not to expect ('Orientation is not exposed'). It also suggests chaining via add_feature, providing a usage pattern.

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?

Description goes beyond annotations by specifying 'durably insert' (mutation), 'modifies source', returns modified source plus diagnostics, and mentions verification by validation/review gates. No contradiction 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?

Three sentences, front-loaded with purpose, no redundancy. Every sentence adds necessary 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?

Provides all needed context: when to use, what it inserts, effect on validation, and return value (modified source + diagnostics). No output schema, but return is described.

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

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

Schema coverage is 100%, baseline 3. Description adds value by showing the call syntax `<assembly>.workspace(connectorRef, { reachable, toleranceMm? })`, clarifying parameter relationships beyond 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 declares a reachability target for a connector and inserts a workspace() call. It is specific but does not explicitly differentiate from sibling tools like add_constraint, though the unique purpose is evident.

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

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

Explicitly says 'Use this when you need to declare a reachability target for a connector.' Provides clear context but lacks explicit exclusions or 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?

The description discloses extensive behavior beyond annotations: no code mode, interference verification runs by default, collisions don't fail call, environment requirement, and mutually exclusive parameters. It adds significant value over annotations (readOnlyHint=false, destructiveHint=false). No contradiction.

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

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

The description is long but every sentence adds value. It is front-loaded with the main purpose. Could be slightly more concise, but not overly verbose given the complexity.

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

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

The tool is complex (8 params, no output schema). The description covers all aspects: usage, behavior (verification, collision handling), output format, environment requirements, and return fields. It is comprehensive without gaps.

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

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

Schema coverage is 100% with descriptions. The description adds extra context: e.g., for 'file' it emphasizes no inline mode, for 'focus'/'hide' it clarifies render-only and no effect on verification, and explains mutual exclusivity of 'frames_dir' and 'output_path'. This goes beyond schema basics.

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: 'render a script's animation timeline to a video'. It specifies the verb (capture/render), resource (animation timeline), and output formats (MP4 or PNG). This is distinct from sibling tools like evaluate_script or add_connector.

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 usage context: 'Use this when you need to render a script's animation timeline to a video.' It explains file-only mode, environment requirements, and default behavior. However, it does not explicitly state when NOT to use or compare to alternatives, though the context is sufficient.

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 are sparse (no readOnly, destructive, or openWorld hints), so the description carries the burden. It discloses the loop flow: reviewing each attempt, continuing past functional attempts with warnings, returning repair prompts, and optionally writing a build record. No contradictions with annotations, and no hidden side effects are omitted.

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 sentences (about 70 words), front-loading the purpose. It is efficient but could be slightly more structured (e.g., bullet points for key behaviors). Overall, it earns its length without significant 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?

With a high parameter count (16), nested objects, and no output schema, the description gives an overall process overview but does not specify return values or the structure of repair prompts. It covers the main loop behavior but lacks detail for a fully complete picture, especially given the complex input 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?

Schema description coverage is 94% (very high), so the schema already documents most parameters. The description adds high-level process context but does not detail individual parameter semantics beyond what the schema provides. The baseline score of 3 is appropriate.

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

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

The description clearly states the tool runs a CAD design loop over multiple attempts. It uses specific verbs and resources (review with review_cad, return repair prompts, write build record) and distinguishes itself from siblings like review_cad by focusing on the multi-attempt loop process.

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

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

The opening phrase 'Use this when you need to run a CAD design loop over multiple attempts' gives explicit usage context. However, it does not mention when not to use this tool or describe alternatives among the many sibling tools, though no other tool appears to provide similar looping behavior.

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 destructiveHint=false. Description adds explicit 'Read-only — never touches the active session.' and details output format (per-part deltas, interference, mate-graph, param changes). 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?

Description is a single paragraph but fairly long. However, every sentence adds value: usage guidance, output details, behavioral note. Front-loaded with purpose. Slightly verbose but not wasteful.

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

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

Given 4 params, no output schema, the description fully explains output format (JSON with per-part details, interference, mate-graph, param changes, special case for single-shape scripts), read-only behavior, and usage context. No significant gaps.

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

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

Schema description coverage is 100%. Description adds meaning beyond schema: explains parameter combinations (baseline vs revision), that exactly one baseline and one revision must be provided, and the logic of {baseFile}/{baseCode} vs {file}/{code}.

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

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

The description clearly states the verb 'diff', the resource 'CAD scripts', and the outcome 'structured geometric delta'. It distinguishes itself from siblings by focusing on version comparison, which is unique among the many 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?

Explicitly states when to use: 'Use after editing a script to verify exactly what changed physically before re-rendering.' Also implies when not to use (not for other purposes). Provides clear context and alternative 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 annotations (readOnlyHint, destructiveHint), the description details what dryRun skips (OCCT lowering, DFM gates, meshing), its 100x speed advantage, and the implication that full evaluate affects the active session. This adds significant 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 well-structured with a clear front-loaded purpose, followed by technical details. It is slightly long but every sentence contributes to understanding. A minor trim could improve conciseness.

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 output schema, the description adequately explains return values: pass/fail, feature count, diagnostics, and optional parts summary for assembly scenes. It also covers edge cases like dryRun, making it contextually complete.

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

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

With 100% schema description coverage, the description adds substantial meaning: explains the mutual exclusivity of file and code parameters, provides examples, and describes the dryRun behavior in detail, including what validation it performs and what it skips.

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 CAD script, reporting pass/fail, feature count, diagnostics, and optionally a parts summary. It uses specific verbs ('run', 'check', 'report') and distinguishes from siblings by focusing on script compilation and evaluation.

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 'Use this when you need to run a script and check it compiles' and explains the dryRun option for fast validation. It provides clear context for when to use dryRun vs full evaluate, but does not explicitly mention when to use 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 declare readOnlyHint=true; description adds details on return value structure (distance, inside, aabb, kind) and distance meaning in mm. No contradiction. 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?

Front-loaded with purpose, concise sentences, no fluff. Every sentence adds value. Well-structured.

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

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

Despite no output schema, description explains return structure. All parameters covered. Completes the picture for an agent to use effectively.

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 100%, but description adds critical context: script must bind SdfField via sdf.bind and pass name as fieldName. Also hints about file or code. Adds meaning beyond 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 verb 'sample' on the resource 'signed-distance field' and distinguishes from sibling 'sdf.materialize' by noting it is an expensive step. This provides specific purpose and differentiation.

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

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

Explicitly says when to use: 'to verify SDF composition before calling sdf.materialize'. Implies alternative is materialize. Could strengthen by stating when not to use, but provides clear context.

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

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

Beyond annotations (readOnlyHint=false, openWorldHint=true), the description reveals detailed behavior: file creation, watertight verification, error codes (export.mesh.not-watertight, export.part.not-found), multi-file output for URDF/SDF, and the effect of no_verify. This far exceeds what annotations alone provide.

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

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

The description is lengthy but well-structured with clear sections for each target and bullet-like details. It is front-loaded with the primary purpose. Some redundancy exists (format list repeated in schema and description), but overall each sentence provides unique, actionable information.

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

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

With 10 parameters, nested objects, and no output schema, the description fully covers all aspects: required vs optional params, error behavior, file output details, and verification mechanics. It even explains how to interpret failures and what files are written where. No gaps remain.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining parameter interdependencies (e.g., 'target' determines required params), listing per-format options for the 'options' parameter, and clarifying the roles of ambiguous parameters like 'part' and 'output_dir'. This justifies above baseline.

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

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

The description clearly states 'export geometry to a file' and distinguishes two specific targets ('model' and 'part') with detailed sub-descriptions. It uses specific verbs and resources, making the tool's unique purpose evident among 40+ 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?

The description opens with 'Use this when you need to export geometry to a file' and provides explicit guidance for choosing between the two targets ('target: model' vs 'target: part'). It also explains failure conditions and the optional verification. However, it does not explicitly mention when to avoid this tool or suggest alternatives among 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?

The description adds value beyond annotations by disclosing the side effect of writing the STEP file to the local cache and the network dependency for non-bundled ids. This complements the readOnlyHint=true (server-side read) and openWorldHint=true. 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 very concise (2 sentences, ~58 words) and front-loaded with the main purpose. Every sentence adds 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?

The description covers the primary use case and return format (cache path + fingerprint), but does not explain all parameters (family, category, standard) nor mention error conditions, prerequisites (like partsBaseUrl requirement), or detailed behavior for edge cases. Given no output schema, more detail would be beneficial.

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 only 17% (only 'partsBaseUrl' has a description). The description clarifies 'id' and 'query' as identification methods ('single-match query') but does not explain 'family', 'category', or 'standard', leaving their meaning ambiguous. The description partially compensates but leaves gaps.

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 action ('download a catalog part as a STEP file') and the resource, with a specific verb and context. It distinguishes from siblings like 'find_part' (which likely only searches) and others by specifying the output (STEP file, cache path, fingerprint).

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 good context for when to use ('when you need to download a catalog part as a STEP file') and explains the id vs query resolution and offline/online behavior. However, it does not explicitly exclude cases or compare to alternatives beyond implicit differentiation.

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 value beyond annotations by explaining the fuzzy query and faceted filter behavior, AND-combination of tokens and filters, and the distinction between bundled and remote results. Annotations already indicate readOnlyHint=true and openWorldHint=true, and the description aligns with these. 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 concise, consisting of three sentences. It front-loads the primary use case and provides essential behavioral details without unnecessary words. Every sentence contributes meaningful 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?

The tool has 8 parameters and no output schema. The description explains the core query mechanism and remote/bundled distinction, but lacks details on return format, pagination (limit parameter), meaning of the 'auto' source, or how to interpret results. Given the complexity, additional context would improve completeness.

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 low (13%, only partsBaseUrl has description). The description indirectly explains the query parameter (fuzzy query) and faceted filters (tag, family, category, standard, source) and their AND-combination, but does not detail each parameter individually. This provides some semantic value but not enough to fully compensate for the low 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 clearly states the tool's purpose: to find a part in the catalog using fuzzy query and faceted filters. It specifies the resource (part-catalog records) and the action (find), and distinguishes between bundled and remote results, which helps differentiate from siblings like fetch_part or add_part.

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

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

The description provides a clear use case ('Use this when you need to find a part in the catalog') and explains how tokens and filters work (AND-combine). It also gives guidance on enabling the remote tier via partsBaseUrl or environment variable. However, it does not explicitly state when not to use the tool or mention alternative tools, which would improve the score.

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 and destructiveHint=false, so the agent knows it's safe. The description adds value by detailing the output format ('Region with outer polyline, holes, bend lines, sketch plane') and the behavioral constraint ('at most 2 bends'), going 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 extremely concise with three sentences, each serving a distinct purpose: purpose, output, and usage. No extraneous information, and the structure is logical.

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

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

Given the moderate complexity (3 parameters, no output schema), the description covers the purpose, output structure, and a usage constraint. It could be more complete by explaining what happens if more than 2 bends or clarifying the 'file' vs 'code' formats, but overall is sufficient for an agent to use the tool.

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

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

Schema coverage is 0%, so the description must compensate. It explains that 'file' and 'code' are alternatives and 'featureId' is optional to pick a specific shape. This adds meaning beyond the schema but lacks details on file format or code syntax, so it is adequate but not comprehensive.

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: 'unfolded flat pattern of a bent sheet-metal part.' It specifies the verb ('unfolded') and resource ('bent sheet-metal part'), and distinguishes it from sibling tools which are all unrelated, ensuring no ambiguity.

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

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

The description explicitly states when to use this tool ('when you need the unfolded flat pattern') and provides a usage constraint ('Slice 1: at most 2 bends'). However, it does not mention when not to use it or suggest alternatives, which would improve the score.

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 and openWorldHint. The description adds critical auth behavior (slug as capability, OAuth needs), return structure (signed URL + timestamp), error handling (no_render with hint), and the capture mechanism, providing excellent 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, starting with the primary purpose, then usage context, auth details, return type, and error case. Every sentence adds 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?

Despite lacking an output schema, the description fully explains the return structure, error conditions, and dependencies (open viewer). It is complete 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?

Schema coverage is 100% with a clear description of 'slug'. The description adds semantic context: the slug's role as a capability and auth implications, enhancing the schema's meaning.

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 explicitly states 'Fetch the latest rendered PNG', specifying the verb and resource. It clearly distinguishes from sibling tools by explaining the capture process and its role after open_in_studio.

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

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

Provides clear guidance on when to use ('after you have edited a model and want to SEE the result', 'after open_in_studio') and what to do if no render exists. While it doesn't explicitly state when not to use it, the context is well-defined.

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 context beyond the annotations: it explains the two operational modes, the necessity of OAuth for private projects and listing, and the live-update behavior of the user's tab. 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 a single focused paragraph that efficiently covers both modes, OAuth requirements, and integration with other tools. It is well-structured and front-loaded, though slightly dense.

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 two distinct modes, a single optional parameter, no output schema, and basic annotations, the description thoroughly covers all necessary details: when to use each mode, auth requirements, and relation to edit and open_in_studio. It is fully adequate for an agent to use 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?

Although the input schema has 100% coverage for the single parameter, the description adds valuable semantic context: where the slug originates, that omitting it triggers listing, and the OAuth requirement. This enhances understanding beyond the schema's property description.

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

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

The description uses specific verbs 'fetch' and 'list' and clearly distinguishes between retrieving a single project by slug and listing all saved projects. It also ties the tool to subsequent actions like 'edit' and 'open_in_studio', differentiating it from siblings.

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

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

The description explicitly states when to use the tool ('when you need to reopen a saved project or browse what the user has saved') and provides clear conditions for each mode (with/without slug). It mentions OAuth requirements but does not compare directly 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 already declare readOnlyHint=true and destructiveHint=false. The description adds context about parameter forwarding, default feature_id, and that most subjects accept file or code, providing useful behavioral details 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 a clear opening and bullet list for subjects. While verbose with 18 items, it is organized and every sentence adds value, though some grouping could improve conciseness.

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 lack of output schema, the description provides enough detail for each subject (e.g., returns 'physical assembly inventory' for assembly) and explains parameter usage. It is mostly complete, though some subjects could use more explicit output format hints.

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

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

Schema coverage is 100%, but the description adds extensive context for each subject, explaining what each returns and which parameters are relevant. It clarifies that all params except 'of' are subject-specific, significantly aiding parameter understanding.

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 'Use this when you need to read facts about a model' and lists 18 specific subjects, making it distinct from sibling tools that add, modify, or export. Verb 'inspect' with resource 'model' is explicit.

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

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

The description opens with when to use the tool and provides a comprehensive list of subjects. However, it does not explicitly mention when not to use it or compare to alternative tools for similar tasks.

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 provide readOnlyHint and destructiveHint. The description adds minimal behavioral context beyond what is listed (e.g., it is a list operation). 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 sentences, front-loaded with purpose, 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 no parameters and no output schema, the description fully covers what the tool does and why 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?

There are 0 parameters, so no additional explanation needed. Schema coverage is 100%.

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 lists the kernelCAD script-runtime surface, including specific functions and methods. It distinguishes from sibling lookup tools by its specific focus.

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 states when to use the tool ('when you need to list the kernelCAD script-runtime surface') and provides context for discovery. It implies alternatives (other lookup tools) but does not explicitly exclude them.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds output structure details ({ uri, mimeType, text }) and notes equivalence to a resource, providing good 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?

Three concise sentences: purpose, usage guidelines, input/output. No wasted words, front-loaded with purpose.

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

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

For a simple read tool with no parameters and no output schema, the description covers purpose, usage context, and output format completely. The agent has all needed 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?

No parameters, so baseline 4. The description explicitly states 'INPUT: none.' Schema coverage is 100% trivially, no additional semantics needed.

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

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

The description clearly states it returns the SKILL.md body for authoring conventions, with a specific verb and resource. It distinguishes from sibling lookup tools like lookup_api by specifying the content (kernelcad-authoring SKILL.md).

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 generating CAD code if client does not list resources) and when not to (if client lists resources, use direct resource URI). Provides alternative method.

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?

Adds details beyond annotations: ranking by BM25 over title/tags/keywords/trigger, and behavior when no snippet scores above relevance floor. No contradiction with readOnlyHint and destructiveHint.

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?

Five sentences, front-loaded with purpose and usage. Efficient but could be more structured. 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?

Covers key aspects: purpose, when to use, retrieval details, empty result handling. Slight gap: output snippet structure not described, but plausible from 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?

Schema coverage is 100%, so baseline 3. Description explains that k controls max snippets and query is natural-language, but adds minimal new meaning (e.g., ranking method). Adequate but not exceptional.

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 explicitly states the tool searches the kernelCAD cookbook for canonical pattern snippets, using specific verbs ('search', 'returns') and resource ('cookbook'). It distinguishes from sibling tools like lookup_api by focusing on canonical patterns.

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 when-to-use scenarios (e.g., 'fillet-after-subtract') and when-not-to-use (empty result indicates proceed without cookbook help). No alternatives listed, but context is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it's a 'tiny one-shot call' and gives 'the canonical list up front', providing extra 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 three sentences long, front-loaded with the purpose, and contains no unnecessary words or repetition. It is concise and well-structured.

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

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

For a zero-parameter, no-output-schema tool with good annotations, the description is complete. It explains the tool's output (catalogue with hint templates) and its utility. Minor improvement could elaborate on return format, but current is 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 tool has no parameters, and schema description coverage is 100%. The description does not need to add parameter details since none exist. Baseline score of 4 is appropriate.

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

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

The description clearly states the tool provides the 'kernelCAD 26-code diagnostic catalogue with hint templates', using specific verbs and resource. It distinguishes itself from sibling lookup tools like lookup_api and lookup_cookbook by specifying the exact catalogue type.

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 'Use this when you need the kernelCAD 26-code diagnostic catalogue' and gives a concrete use case ('pre-populate retry strategies'). It could be improved by noting when not to use it or naming alternatives, 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?

Annotations indicate readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds behavioral context: it persists the model, returns a link, and allows live updating by passing slug. It does not contradict annotations and provides useful details beyond the structured fields.

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 comprehensive but a bit lengthy. However, every sentence serves a purpose: main usage, parameter details, and usage tips. The structure is logical and front-loaded with key information, making it easy for an agent to parse.

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

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

Given 4 optional parameters and no output schema, the description covers the essential usage scenarios: creating new projects, updating existing ones, and reusing code from evaluate_script. It could be more explicit about error cases (e.g., missing both code and slug when no prior evaluate_script), but overall it is complete 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 100% with descriptions for all 4 parameters. The description adds significant value: explains that 'code' is optional and can reuse last evaluated script, 'slug' updates an existing project live, and 'title' and 'parameters' are optional enhancements. This goes beyond what the schema alone provides.

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

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

The description clearly states the tool persists the current kernelCAD model and returns a one-click link to open it in Studio for viewing and sharing. It includes trigger phrases and distinguishes itself by being the only tool that opens models in the Studio web app, which sets it apart 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?

Explicit usage guidance is provided: use when user wants to SEE or share the model, after finishing a build, or after each meaningful revision. It explains when to omit slug for new projects and when to pass slug to update. While it does not explicitly state when not to use it, the context is clear enough.

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?

Description states it's side-effect-free and returns modified code plus diagnostics, aligning with annotations. Also discloses deferred feature (asEdge) and missing library, 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?

Single dense paragraph front-loads purpose. Could be more structured with bullet points, but all information is essential and efficiently conveyed.

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 purpose, usage, parameters, behavior, and limitations (deferred feature). No output schema but description explains return value adequately.

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

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

Schema coverage is 100%, but description adds significant value: explains curveExpression as JS expression with example, asEdge as deferred, and scaleMode options. No contradiction with 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?

Description explicitly states 'wrap a 2D curve onto a 3D face' with verb and resource. Differentiates from siblings by specifying it's for 2D to 3D projection and pairing with extrude/cut.

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?

Clearly indicates when to use ('Use this when...') and gives usage example (chained call). Does not explicitly state when not to use, but context is sufficient.

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 (readOnlyHint, destructiveHint), the description details mode-specific behaviors, parameter forwarding ('All params except mode are forwarded verbatim'), and the purpose of each mode.

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: one introductory sentence followed by a clear bullet list of modes. No extraneous content.

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

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

The description explains inputs and modes but does not fully describe return values for all modes, especially 'lineage' which only says 'walk the HistoryMap' without return 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?

While schema coverage is 100%, the description adds semantic grouping by mode, clarifying which parameters are relevant for each mode and adding examples like 'expect:unique'.

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 resolves or inspects topology against a script's lowered geometry, with three distinct modes. It uses specific verbs and resources, and the modes are differentiated.

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 starts with 'Use this when...' and explains each mode's use case, but does not explicitly state when not to use it or compare it to 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 destructiveHint=true. The description adds valuable behavioral details: returns modified code and diagnostics, and refuses to remove the line with the return statement. The claim 'Side-effect-free' is somewhat redundant with destructiveHint but not contradictory.

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

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

Four efficient sentences with no redundancy. The first sentence front-loads the purpose, followed by mechanism, constraint, and safety claim. Every sentence earns its place.

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

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

For a destructive tool with 2 parameters and no output schema, the description covers: when to use, how identification works, what is returned (modified code + diagnostics), a refusal constraint, and a side-effect-free claim. It is complete for an AI agent to invoke 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 100%. The description clarifies the 'match' parameter as a substring that uniquely identifies the line, adding meaning beyond the schema's type descriptions. It also gives usage context for both 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 the verb 'remove' and the resource 'feature line from a script', with specific detail on using a substring match and that it removes a single line. It distinguishes itself from sibling 'add' tools effectively.

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

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

The opening sentence explicitly tells when to use this tool. It also provides a specific constraint (refuses to remove return statement), which aids in appropriate use, but does not explicitly mention alternatives or when not to use.

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 this is a non-read-only, non-destructive operation. The description adds substantial behavioral context: it explains the mechanism truth probe, watermarking for broken mechanisms, strict mode behavior, latency impact of interference sweeps, and the fact that returned paths are local. This goes well 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 long but dense with useful information. It uses clear structuring with bullet points and separated sections. There is minor redundancy (e.g., emphasizing 'NO STUDIO / DEV-SERVER REQUIRED' twice), but overall it is efficient and front-loaded with the core purpose.

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

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

Despite having no output schema, the description fully explains the return structure (images array with name, path, description; fields like mechanism, render_source, diagnostics). It covers edge cases (broken mechanism, strict mode, local paths for remote clients) and provides complete context for a complex 13-parameter tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema: it explains mutual exclusivity of code/file and focus/hide, details the pose coordinate system (az=0,el=0 is front, +az CCW, +el lifts), and explains environment presets. This adds value over the schema.

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

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

The description clearly states the tool's purpose: to render a kernelCAD model script to deterministic PNG views for visual self-check. It uses specific verbs ('render', 'look at') and resources ('kernelCAD model', 'PNG views'), and distinguishes it from siblings like 'open_in_studio' and 'evaluate_script'.

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 states when to use the tool ('when you need to LOOK at a kernelCAD model'), clarifies that no studio or dev server is required, and mentions alternatives for remote clients ('open_in_studio'). It also provides guidance on skipping mechanism check for fast iteration. However, it does not explicitly state conditions when the tool should not be used.

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 outlines the deterministic CAD review loop in detail (evaluate script, validate assembly/mate graph, check connectors, sample limits, check interferences, report bounds, return fitness verdict). This aligns with annotations (readOnlyHint=true, destructiveHint=false) and adds behavioral context beyond them. 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 concise at about four sentences, front-loading the usage scenario. It lists the steps in the review loop efficiently, but could potentially be slightly more streamlined without losing key 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?

The description explains the overall process and mentions the output includes a fitness verdict with repair modes. However, without an output schema, the description would benefit from more detail on the exact structure or fields of the return value, leaving some uncertainty for the agent.

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

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

Schema coverage is 100% and each parameter already has a description. The tool description does not add additional parameter-specific information, so the baseline score of 3 is appropriate. The description focuses on the overall process rather than parameter semantics.

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

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

The description clearly states the tool's purpose: reviewing a mechanism for fitness and repair mode. It uses a specific verb ('review') and resource ('CAD model' / 'mechanism'), and distinguishes itself from sibling tools which are primarily for creation and modification.

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 'Use this when you need to review a mechanism for fitness and repair mode,' providing clear usage context. However, it does not mention when not to use this tool or suggest alternatives, though the sibling tools are different enough that confusion is unlikely.

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 read-only and non-destructive. Description adds: no OAuth required with slug, private projects require signed-in owner, short-lived signed URLs, and parameter effect on response size. 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?

Single paragraph that is informative and well-structured, front-loading purpose. Slightly lengthy but earns its sentences.

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

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

Covers all aspects: slug usage, OAuth scenarios, path behavior, response contents (screenshot, mask, part names, note, intent tags). No gaps for an agent to select and invoke 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 100%, but description adds operational context: slug's capability-based access, paths_only controls inline vs URL, freshness_sec age limit. This goes beyond schema definitions.

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

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

The description clearly states the verb 'Return' and the resource 'newest brush-painted review packet from a Studio session.' It distinguishes from siblings like 'review_cad' by focusing on painted feedback from a /p/<slug> link.

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?

Describes when to use: after sharing a link and painting marks, call with slug; or omit slug for own latest with OAuth. Does not explicitly state when not to use or alternatives, but 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?

Despite annotations (readOnlyHint=false, destructiveHint=false), the description adds valuable behavioral context: it is a pure function with no side effects, returns modified code plus diagnostics, and the caller must persist via file-write tools. This goes beyond the annotations and fully discloses behavior.

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

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

Two sentences with no fluff: first sentence states purpose, second explains output and persistence. Front-loaded and efficient.

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 editing tool with 3 parameters and no output schema, the description fully covers what it does, what it returns, and how to persist. Complete and self-contained.

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

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

Schema coverage is 100% with each parameter described. The description adds context beyond schema by explaining 'param_name is the first arg to param()' and associating with editing a param default value. This is helpful but not critical given complete 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 verb 'edit' and resource 'param() default value in a kernelCAD script', distinguishing it from sibling tools that add elements (e.g., add_connector, add_constraint). It is specific and 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 clearly says 'Use this when you need to edit a param() default value', setting clear usage context. However, it does not explicitly mention when not to use or provide alternatives, though the sibling list implies many other tools for different purposes.

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?

Describes the modification behavior ('Replace the final top-level return statement') and output ('Returns modified source plus diagnostics from re-evaluation'). Annotations (non-readOnly, non-destructive) are not contradicted, and the description adds useful 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?

Two sentences, front-loaded with purpose, no wasted words. Every sentence adds essential 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?

Covers purpose, mode selection, return value, and parameter hints. Lacks detail on diagnostic format but is sufficient given no 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?

Schema coverage is 80%, and the description adds meaning to `mode`, `poses`, `options`, and `assembly_binding`. It explains when to use each mode and the purpose of optional parameters 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 explicitly states the tool's purpose: 'Use this when you need to set how the script returns its assembly.' It specifies replacing the return statement with either `model()` or `solvedModel()`, distinguishing it 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?

Provides clear context for when to use the tool and when to choose `solvedModel` over `model` ('Use solvedModel for mate-authored mechanisms so FK and validation run.'). Does not explicitly mention when not to use it, but context is sufficient.

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 destructiveHint=false. Description adds return format and optional overrides, which aligns with read-only behavior. No contradictions, but little additional depth 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?

Three sentences, front-loaded with purpose, efficient wording. No extraneous 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?

Describes core functionality and return format. Lacks explanation for 'assembly' parameter, error handling, or prerequisites. Adequate but not fully comprehensive for a solver tool.

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

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

Schema coverage is 50% with 'assembly' parameter undescribed. Description explains 'poses' override semantics but omits explanation for 'assembly', leaving ambiguity. Insufficient compensation for 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?

Description states specific verb 'solve the mate graph' and resource 'get part poses'. Clear purpose but does not explicitly differentiate from sibling tools like solve_sketch, though context implies solving mates.

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?

Implies usage when needing to solve mate graph, but no direct when-not-to-use or alternative recommendations. Lacks explicit exclusion or comparison.

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 destructiveHint false. Description adds 'Side-effect-free' and explains input/output structure, including that entities are specific types and constraints use a vocabulary. This 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 sentences but the first sentence is repeated ('Solve a 2D sketch constraint set' twice). It is short but contains redundancy. Could be more concise 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 no output schema, description explains return value (solved entities + constraints) and mentions entity types. It covers the basic workflow but could mention error handling or edge cases. However, for a side-effect-free solver with simple inputs, it is reasonably complete.

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

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

Schema coverage is 100% with descriptions, so baseline is 3. Description adds that entities are POINT, LINE, and CIRCLE records and constraints use kernelCAD vocabulary, adding meaning beyond the generic 'array of objects' schema. This compensates for missing type 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?

Clearly states the tool solves 2D sketch constraint sets, specifying the action and resource. The repetition 'Solve a 2D sketch constraint set' reinforces purpose but is slightly redundant. Distinct from siblings like solve_mates or add_constraint.

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

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

Explicitly says 'Use this when you need to solve a 2D sketch constraint set,' providing clear context. Does not mention when not to use it or compare to alternatives, but the use case is well-defined.

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?

Discloses backend behavior, accuracy differences (opencv exact, LLM 5-10% off), confidence reporting, caller payment responsibility, and pairing with skill. Annotations only say not readOnly, but description adds extensive behavioral 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?

Front-loaded with usage guidance. Multiple sentences but each adds value (backends, accuracy, skill pairing). Could be slightly more concise but justified by complexity.

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

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

No output schema, but description explains output includes confidence and waypoints, and mentions conversion pipeline. Covers backends, accuracy, and caller obligations. Adequate for a complex tool with 5 params.

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 covers all parameters with descriptions. Description adds context on backend selection logic (corner-color stddev for auto) and how hint/region are used, enhancing understanding beyond 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 traces features from a reference photo into waypoints. It distinguishes from sibling tools by detailing backend dispatch and pairing with a specific skill.

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?

Opens with 'Use this when you need to trace features...' and explains backend selection criteria. Lacks explicit when-not-to-use cases but provides sufficient 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by detailing that params are check-specific and forwarded verbatim, and that each check 'fails closed on its own missing required params'. This goes 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 bullet points and front-loaded purpose. It is somewhat long due to the number of checks, but each check is concisely described. Could be slightly more terse but still efficient.

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 28 parameters and 8 distinct checks, the description covers all checks and their parameter dependencies. It lacks detail on return values (no output schema), but the behavior per check is adequately described. Overall very complete for the 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?

With 100% schema coverage, baseline is 3. The description adds significant value by grouping parameters per check, indicating which are required for each check, and explaining the forwarding behavior. This helps the agent understand parameter relationships 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 states the tool's purpose clearly: 'check a design against a rule set'. It lists 8 distinct check types with one-liner descriptions, directly differentiating from siblings like evaluate_script (explicitly mentioned as a prerequisite for 'assembly'). The verb 'verify' and resource 'design' are specific.

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 check-specific usage context (e.g., 'run evaluate_script first' for assembly), but does not explicitly state when NOT to use or compare to alternatives. The guidance is sufficient for the intended use cases.

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 destructiveHint=false, so the description adds value by explaining the tool walks the upstream chain in topological order and returns inline hints. This goes beyond 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?

The description is relatively concise, packing purpose, behavior, return format, and a note about an alternative into three sentences. It front-loads the usage context and maintains focus, though the parameter list at the end could be integrated more smoothly.

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 output schema, the description covers return format (diagnostics chain, topological order, inline hints) and guides toward lookup_diagnostics for full details. However, it omits edge cases like what happens if the feature has no failure, prerequisites (feature must exist?), or error conditions.

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%, requiring the description to compensate. However, the description merely restates parameter names in a list ('Pass { file?, code?, feature_id? }') without explaining their meaning or how they influence the output. This adds minimal semantic value.

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 specific language ('trace why a feature failed') and clearly identifies the resource (failure diagnostics chain). It distinguishes itself from sibling lookup_diagnostics by noting that this tool returns upstream chain diagnostics while the sibling provides the full catalogue.

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 you need to trace why a feature failed') and provides an alternative via sibling lookup_diagnostics. While it doesn't list explicit exclusions or prerequisites, the guidance is clear enough for an agent to decide between tools.

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