Kiln

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

No annotations are provided, so the description must fully disclose behavior. It mentions exclusive lock, prevention of simultaneous control, and timeout, but lacks details on lock failure behavior, idempotency, automatic release, or side effects. This is insufficient for a tool with no annotation safety net.

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 statement, an explanatory sentence, and a parameter list. It is concise with no redundant information. Could be slightly more compact, but overall 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?

The tool has 3 parameters, no output schema, and no annotations. The description covers purpose and parameter semantics but omits return value, error handling, and blocking vs non-blocking behavior. For a relatively simple tool, the description is adequate but not fully complete to guide an agent without additional 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 0% with no parameter descriptions in the schema. The description includes an explicit 'Args' section explaining each parameter's semantic role (printer_name: Printer to lock, holder: Identifier of the lock holder, timeout_seconds: Maximum time to wait). This adds significant meaning beyond the schema's types and defaults.

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

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

The description clearly states it acquires an exclusive lock on a printer for safe concurrent access. The verb 'acquire' and resource 'lock on printer' are specific. It distinguishes itself from sibling 'release_printer_lock' by focusing on acquisition.

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 context by stating it prevents multiple agents from controlling the same printer simultaneously, implying when to use. However, it does not explicitly state when not to use or mention alternatives like 'release_printer_lock'. Guidelines are implied but not explicit.

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

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

The description discloses the write operation to '~/.kiln/license' and the return of tier info, which are key behaviors. With no annotations provided, this adequately covers transparency, though it could mention if any authentication is needed.

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, front-loading the purpose in the first sentence, and every sentence adds value. 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 simplicity of the tool (one parameter, no output schema), the description is adequate. It covers the action, side effects, and return value. Minor room for improvement: mentioning any prerequisites 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?

The only parameter 'key' is described with format examples ('kiln_pro_...' or 'kiln_biz_...'), adding significant meaning beyond the schema's simple string type.

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

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

The description clearly states 'Activate a Kiln Pro or Business license key,' specifying the verb and resource. It distinguishes itself from the sibling tool 'license_status' by mentioning it.

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

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

Explicitly advises to 'Use license_status to check the current tier first,' providing clear context for when to use this tool versus an alternative.

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

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

No annotations are provided, so the description carries full burden. It explains the tool's function and parameter details but does not disclose side effects, auth needs, or return behavior. The description is adequate but lacks full 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 clear parameter documentation in a bullet-like format. It is slightly verbose but each sentence adds value. No redundancy, and the most critical information is front-loaded.

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

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

The description thoroughly covers parameter semantics but omits the return value or effect on the assembly state. With no output schema and 7 parameters, the missing return behavior is a notable gap.

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

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

The description provides rich, detailed explanations for every parameter, including defaults, special cases (e.g., negative clearance for interference fit), and constraints (e.g., magnet polarity only meaningful for magnetic joints). This adds significant value beyond the schema's bare titles and defaults.

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

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

The description clearly states the tool adds a mating interface between two parts in an assembly, specifying joint type and clearance. It distinguishes itself from sibling tools like 'add_assembly_part' by focusing on interfaces between parts.

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

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

The description implies usage for validation and clearance checking but does not explicitly state when to use this tool vs. alternatives like 'compose_assembly_parts' or 'validate_assembly'. No prerequisites or exclusions are mentioned.

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

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

No annotations are provided, so the description carries the full burden. It describes the behavior: parsing JSON, appending the part, and returning the updated state. It mentions that the assembly is 'existing' and that the result is 'updated assembly state', implying immutability. While it could add more about error handling or permissions, it adequately discloses the core behavior.

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

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

The description is well-structured with a docstring format: purpose, process, then parameter list. It is slightly long but each sentence adds value. The front-loaded purpose is clear. It could be more concise by grouping defaults, but it is not overly verbose.

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

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

With 8 parameters, 3 required, and no output schema, the description covers all parameters and the return value (updated assembly state). It explains the process and default values. It lacks details on constraints (e.g., part_id uniqueness) or error scenarios, but for a moderately complex tool, 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?

Schema description coverage is 0%, so the description must add meaning. It fully describes each parameter: assembly_json (state from previous tool), part_id (unique identifier), file_path (mesh file path), position offsets, material (filament material), role (structural role). This provides essential context beyond the schema's property names and types.

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

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

The description clearly states 'Add a part to an existing assembly' with a specific verb and resource. It explains the process of parsing JSON, appending, and returning updated state. It distinguishes from sibling tools like create_assembly (creates new) and add_assembly_interface (adds interface).

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

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

The description implies that the assembly must already exist by specifying that assembly_json comes from create_assembly or previous tool calls. However, it does not explicitly state when to use this tool vs alternatives like add_assembly_interface or when not to use it. Guidance is implied but not explicit.

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

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

With no annotations, the description carries the full burden. It describes the action but does not discuss side effects, required permissions, or what happens on conflict (e.g., duplicate name). The message field indicates when the rule fires, but other behavioral aspects 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 concise and well-structured: a one-sentence summary followed by a bullet-like list of arguments. Every line adds value, with no redundant or vague statements.

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 11 parameters and no schema descriptions, the description explains each parameter adequately. However, it does not indicate which parameters are required (the schema lists 4 required), nor does it mention defaults like priority=medium. The output schema is present but not referenced. A small gap in 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?

The input schema has 0% description coverage, so the description must fully compensate. It does so by listing all 11 parameters with clear meanings, enumerating valid values for trigger, action, and priority, and providing examples (modify_params). This adds critical 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 'Add a custom interception rule to an active session,' specifying the verb (add), resource (interception rule), and context (active session). This distinguishes it from related tools like remove_interception_rule or list_interception_sessions.

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

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

The description does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. It implies usage through its purpose but lacks direct guidance on deciding when adding a rule is appropriate.

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

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

With no annotations, the description carries the full burden. It discloses the core behavior (edge detection and beveling), the return value ('Dict with sharp edge count, triangles added, and output path'), and a significant side effect: the inline 3D stage opening on success and automatic decimation of oversized meshes. It does not mention file overwrite behavior or error conditions, but the provided context is substantial.

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 a one-sentence purpose, followed by compact parameter documentation and a return-type note. The 3D stage paragraph adds relevant behavioral context but is somewhat lengthy; still, every sentence earns its place and there is little waste.

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

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

For a 4-parameter mesh processing tool with no annotations and no output schema, the description is fairly complete: it explains inputs, output default, return value, and post-success behavior. It could be more complete with notes on file overwriting, input formats, and failure modes, but these are not critical gaps given the detail already present.

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

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

Schema description coverage is 0%, so the description must fully compensate. It does: every parameter is documented with meaningful semantics (file_path is the STL path, distance_mm is chamfer distance, angle_threshold_deg controls which edges are chamfered, output_path defaults to <name>_chamfered.stl). This adds real meaning beyond the bare schema.

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

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

The description opens with a specific verb and resource: 'Add chamfers (flat bevels) at sharp edges.' It clearly explains the operation (detecting sharp edges and beveling them with flat transition faces) and distinguishes itself from the sibling 'add_mesh_fillet' by explicitly contrasting chamfers with fillets.

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

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

The description implies usage context by stating that 'Chamfers are faster to print than fillets and reduce stress concentration,' which helps an agent choose chamfering over filleting. It does not name add_mesh_fillet explicitly or state when not to use this tool, but the comparison provides clear contextual guidance.

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

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

With no annotations provided, the description carries the full burden. It discloses several behaviors: edge detection and triangle insertion, purpose (reduce stress concentration, improve printability), and side effects on output. It also mentions the interactive 3D stage side effect, including decimation of oversized meshes, which is valuable. No contradictions with annotations since none exist.

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 summary, followed by usage guidance, parameter documentation, and a note about the 3D stage. It is detailed but each sentence adds value; no filler. The inline 3D stage note is extra but relevant and 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?

For a moderately complex tool with 4 parameters, no output schema, and no annotations, the description is complete: it explains the purpose, how it works, when to use, parameters, return value (dict with sharp edge count, triangles added, and output path), and the 3D stage side effect. This is sufficient for an 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 description coverage is 0%, but the description explicitly explains each parameter in a :param block: file_path (path to STL), radius_mm (fillet radius with default), angle_threshold_deg (edge sharpness threshold), and output_path (output location with default). This adds meaning beyond the bare schema properties, fully compensating for the lack of schema descriptions.

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

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

The description clearly states it adds fillets (rounded transitions) at sharp edges of a mesh, using specific verbs and resources. It distinguishes itself from sibling tools like 'add_mesh_chamfer' (which adds chamfers) and other mesh operations, making its purpose 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 provides explicit guidance on when to use this tool: 'Use after design_scorecard() flags sharp corners or predict_print_failures() detects stress risers.' This clearly suggests the context and triggers, and implicitly differentiates it from alternative operations like chamfering by focusing on fillets for stress reduction and printability.

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 no annotations, the description comprehensively discloses behavior: it validates the profile, saves only locally to a specific file path, notes the older filename that is still read, explicitly states nothing is uploaded or shared, describes the tightening-only constraint and the rejection of higher numbers, and notes that values are labelled owner-supplied in readouts. This exceeds expectations given no annotations were provided.

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 clear paragraphs that each add value: purpose, location/scope, constraint, strategic guidance, labeling, and argument details. It is front-loaded with the key purpose and uses markdown for file paths and code identifiers, making it scannable without unnecessary 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 moderate complexity (a validation/write operation with data structure specifics), no annotations, and no output schema, the description is remarkably complete. It covers validation, persistence, domain constraints, alternatives, and parameter structure fully, leaving no significant onboarding gap.

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

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

Even though schema description coverage is 0%, the description thoroughly explains both parameters. It defines printer_model as a 'Short identifier' and gives an example, and describes the profile dict with required keys (max_hotend_temp, max_bed_temp, max_feedrate, build_volume) and their types (e.g., 'a list of 3 positive numbers'), plus optional fields. This provides substantial meaning beyond the bare schema.

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

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

The description clearly states the tool's primary function: 'Add a local safety-profile override for a printer model.' It specifies the resource (printer model) and the action (add/override safety profile), and distinguishes it from related tools like select_printer_variant, lock_safety_profile, and list_safety_profiles by emphasizing it is for local, owner-supplied overrides that only tighten limits.

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

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

Explicitly provides when to use and when not to use: 'this is the right tool for a printer Kiln has never heard of, or for holding your own machine BELOW the curated limits' and 'It is the WRONG tool for "my hotend is upgraded". Use select_printer_variant for that'. This gives clear strategic guidance and names the alternative.

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

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

With no annotations provided, the description carries the full burden. It implies a write operation but does not disclose side effects, required permissions, behavior on duplicates, or return value. The description lacks behavioral context beyond the basic action.

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 sentence for purpose followed by a labeled list. It is front-loaded and avoids redundancy. Every line adds value, though structuring as a bullet list might improve readability.

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

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

Given the tool's simplicity (5 parameters, no output schema, no annotations), the description is adequate but not thorough. It covers the basic function and parameters but omits validation rules, constraints on material values, and output details. It meets minimum viability.

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

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

The description includes an Args section that explains each parameter with examples (e.g., material types) and a default value. The schema provides no descriptions (0% coverage), so the description adds significant meaning, though it could be more precise (e.g., color format).

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 'Add a new filament spool to inventory.' The verb 'Add' and resource 'spool' are specific. The tool is distinguishable from sibling tools like 'remove_spool' and 'list_spools' by its name and description context.

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

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

No guidance is provided on when to use this tool versus alternatives such as 'suggest_spool_swaps' or 'list_spools'. There is no mention of prerequisites, conditions, or typical scenarios.

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

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

With no annotations, the description carries full burden and excels: explains key field behaviors (tray_now='255' meaning none/external spool, A1/AMS Lite differences, bitmask fields), mentions Bambu Lab only restriction, and details return contents. 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?

Well-structured: starts with a one-line summary, then usage guidance, return field details, edge cases, and practical applications. 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?

Given no annotations and no output schema, the description fully compensates by explaining return fields, special values, printer-specific behavior, and use cases. Comprehensive for a parameterless tool.

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

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

The tool has zero parameters and schema coverage is 100% trivially. The description does not need to add parameter semantics but provides rich contextual guidance on how the tool is used without parameters, exceeding the 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?

Clearly states it provides a full AMS hardware dump including all trays, humidity, and RFID, specifically for Bambu Lab printers. Explicitly distinguishes itself from sibling tools 'get_active_material' and 'get_material' by naming when to use those instead.

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 (check filament levels before printing, verify material, select ams_mapping for start_print()) and when-not-to-use (for just active material or Kiln's tracker), including specific alternative tool names.

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

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

No annotations are provided, so the description carries the full burden. It states the tool returns technical recommendations and does not indicate destructive side effects. However, it does not explicitly confirm that the tool is read-only or mention any authentication or rate limitations. The description is adequate but lacks explicit safety assurances.

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: it opens with the main purpose, then differentiates from a sibling tool, provides examples, and ends with parameter explanations. It is front-loaded but somewhat lengthy. Every sentence adds value, though it could be slightly more 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 simplicity (2 parameters, no output schema, no enums) and the rich sibling context, the description is remarkably complete. It covers what the tool does, when to use it, how parameters work, and provides examples. There is no missing information necessary for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 0%, but the description adds significant meaning. It explains the 'requirements' parameter as 'natural language description of what the object needs to do — functional needs, environment, loads, etc.' and 'material' as optional override. This goes beyond the schema's basic type definitions.

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

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

The description clearly states the tool's purpose: 'Analyze a functional requirement and return technical recommendations.' It specifies it is an internal-lookup tool that resolves natural-language requirements into material recommendations, design patterns, dimensional constraints, print orientation rules, and expert guidance notes. It distinguishes itself from the user-facing flow tool design_session, making its role unique among 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 tells when to use this tool versus the alternative: 'For the user-facing flow... call design_session(...) first. That tool internally calls this one for technical lookups; agents calling analyze_design_requirements directly should treat it as a pre-design analysis pass, not the user-facing entry point.' It provides concrete examples of valid inputs, guiding correct usage.

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

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

No annotations are provided, so the description must fully convey behavioral traits. It states the tool returns feedback (a read operation), but does not explicitly confirm it is non-destructive, nor does it mention any side effects, authentication needs, or rate limits. The description is insufficient given the lack of annotations.

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

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

The description is front-loaded with a clear purpose statement and a return value description, followed by a structured parameter list. It is reasonably concise, though the parameter list is somewhat verbose. Overall, it is well-organized 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 tool with 8 parameters, no output schema, and many siblings, the description provides basic functionality and parameter info but lacks return value format details, error conditions, or usage context. It does not fully compensate for the missing output schema or annotations, leaving gaps for an agent.

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

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

Schema coverage is 0%, so the description must provide parameter meaning. It includes a docstring listing each parameter with a brief explanation (e.g., failure_mode: 'Optional failure mode if the model was printed and failed'). These add value beyond the schema's titles and types, though descriptions are minimal. The effort compensates for the lack of schema descriptions.

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

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

The description clearly states the tool analyzes a generated model to get feedback for improvement, specifying it returns constraints to add to the generation prompt. This verb+resource pairing is specific and distinguishes it from sibling analysis tools like analyze_print_failure or analyze_warping_risk.

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

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

The description implies the tool is used when you have a generated model to improve, but it lacks explicit guidance on when to use it versus alternatives (e.g., other analysis tools). No when-not-to-use or prerequisite information is provided.

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

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

With no annotations, the description carries full transparency burden and succeeds: it discloses CAD conversion, that metrics are measured on a Kiln mesh copy, that an 'exact' block comes from the CAD file's own surfaces, and that mesh and exact values may disagree. It also states return type and score range.

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?

Though fairly detailed, the description is front-loaded with the core purpose, then flows logically through metrics, usage timing, CAD-specific behavior, parameter docs, and returns. Every sentence contributes actionable information without padding.

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

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

Given no annotations, no output schema, and a single parameter, the description is unusually complete: it covers input formats, the full set of computed metrics, CAD conversion nuances, exact vs expected values, and an alternative tool. An agent has enough to select and invoke this tool correctly.

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

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

Schema description coverage is 0% and the schema only says 'file_path: string'. The description compensates fully by specifying supported input formats (.stl, .obj, .glb and .step/.stp) and noting automatic conversion of CAD files, meaningfully enriching the lone parameter.

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

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

The description opens with a specific verb-resource pair: 'Deep geometric and printability analysis of a 3D mesh' and enumerates exact metrics (volume, surface area, center of mass, overhang detection, connected components, degenerate triangles, printability score). It also distinguishes itself from sibling mesh_quality_scorecard by noting that tool gives a fuller intake report, making its scope clear.

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

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

Provides explicit usage context: 'Use this after generating a model to understand its geometry and identify printability issues before sending to the slicer.' It also gives an alternative ('mesh_quality_scorecard gives the same file a fuller intake report') and notes that STEP/STP files are converted automatically, informing when it can 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?

No annotations are provided, so the description carries full burden. It discloses that analysis identifies specific geometric features and mentions parameter precedence. However, it does not describe the return format, potential side effects, permissions, or error cases. The behavioral disclosure is adequate but not comprehensive.

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 and well-structured. It starts with a clear purpose sentence, then lists Args with bullet points. Every sentence adds value without redundancy. 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 low complexity (2 parameters, no output schema, no annotations), the description is nearly complete. It covers purpose, parameters, and usage. The only gap is not describing the return format, but without an output schema, this is acceptable. The description provides sufficient context for an AI agent to understand and 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 fully. It explains both parameters: model_path (path to STL/3MF file) and model_stats (pre-computed dict with example keys). It clarifies that either or both can be provided and that model_stats takes precedence. This adds significant meaning beyond the schema.

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

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

The description clearly states the tool detects geometric regions affecting slicing (overhangs, bridges, thin walls, top/bottom surfaces, fine details, curved surfaces). It distinguishes itself from sibling tools like 'analyze_mesh_geometry' and 'analyze_printability' by focusing on slicing-specific geometry analysis. The verb 'Detect' and resource 'geometric regions in a 3D model' are specific and precise.

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 adequate usage context: use when needing to identify geometric features that affect slicing, with each region getting optimized slicing parameters. However, it does not explicitly state when not to use this tool or mention alternatives among sibling tools. The guidance is clear but lacks exclusions.

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

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

With no annotations provided, the description carries the full burden — and delivers exceptionally. It discloses the non-obvious STEP/STP conversion behavior, warns that the count reflects 'KILN'S TESSELLATION' not the user's file, and codifies an 'AGENT CONTRACT' requiring attribution via the subject field. The explicit note that this 'is not a finding about the user's file' is precisely the kind of behavioral nuance that prevents agent misuse.

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

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

Front-loaded with a crisp purpose sentence, and each subsequent paragraph addresses a distinct concern (classification semantics, usage timing, CAD caveat, params, returns). The prose is somewhat verbose — the subject/message attribution warning is restated twice — but the repetition serves a genuine safety purpose for agent behavior.

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

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

For a single-parameter, read-only tool with no annotations and no output schema, the description covers every gap: input file types, return dict contents ('edge count breakdown, watertight status, subject, message, and (CAD only) converted_from'), and an important behavioral edge case (CAD conversion). Nothing needed for correct invocation or interpretation is missing.

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

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

The schema's bare 'File Path' title conveys almost nothing, so the description must compensate — and does. It documents accepted formats ('.stl, .obj, .glb') and the additional STEP/STP CAD path, transforming an opaque string param into a fully specified input contract. For a single-parameter tool, this is complete 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 opening sentence 'Count and classify non-manifold edges in a mesh' pairs a specific verb with a clear resource, and the three-way classification (boundary/T-junction/manifold edges) precisely specifies scope. It distinguishes itself from diagnostic siblings like repair_mesh by explicitly labeling itself 'the diagnostic version of the manifold check,' making its role 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 gives explicit usage timing: 'use it to understand exactly how many edges are problematic before deciding whether to repair.' It clearly positions itself within a workflow (diagnose before repair), but stops short of naming alternatives or stating explicit when-not-to-use conditions, relying on the reader to infer which sibling does the repairing.

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

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

With no annotations, the description covers behavioral aspects: it describes the analysis scope, tier-dependent behavior, and parameter effects on warping/thermal checks. It does not mention side effects or rate limits, but for a read-only analysis tool, this is adequate.

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 structured with a summary paragraph and Args section. It is somewhat verbose but front-loaded with the core purpose. Minor redundancy exists (e.g., repeating 'analysis' in both parts), but overall 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 the complexity (9 params, no output schema), the description explains the analysis performed and return values (score, grade, recommendations). It also covers tier differences. However, it lacks detail on the output structure (e.g., format of recommendations), which would be helpful.

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 provides critical meaning for all 9 parameters. It explains defaults, units, and semantic context (e.g., material ID for warping analysis). This fully compensates for the missing schema descriptions.

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

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

The description clearly states the tool analyzes a 3D model for FDM printing readiness, specifying analyses (overhang, thin wall, bridging) and output (score, grade, recommendations). This distinguishes it from sibling tools like troubleshoot_print_issue or check_printer_material_compatibility.

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

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

The description advises passing material and printer_id for better accuracy and explains free vs Pro tier behavior. However, it does not explicitly contrast with alternatives or specify when not to use this tool, leaving room for improvement.

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

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

No annotations are provided, so the description must fully disclose behavior. It explains that the tool examines job record, events, and printer state, and produces a diagnosis. However, it does not explicitly state whether it is read-only or if it modifies any state, so a 3 is appropriate.

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 (5 sentences) and well-structured, with a clear purpose statement, process explanation, args section, and output description. No unnecessary information.

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

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

Given the single parameter and lack of output schema, the description adequately covers input and process, and describes the output as a structured analysis. It could be more explicit about the output format, but it is largely complete.

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

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

The description adds meaningful context to the single parameter 'job_id' by specifying its source: 'from job_history or job_status'. This goes beyond the schema's minimal definition, though the schema coverage is listed as 0%, the description effectively covers it.

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: analyze a failed print job and suggest causes/fixes. It specifies the verb (analyze) and resource (failed print job). However, it does not differentiate from sibling tools like 'detect_print_failure' or 'analyze_print_failure_smart', so a 4 is appropriate.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention when not to use it. It lacks any conditional or contextual advice, earning a 2.

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

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

No annotations are provided, so the description carries the full burden. It mentions it uses heuristics and suggests recovery steps, but does not disclose side effects (e.g., whether it modifies state, logs data, or requires specific permissions). The behavioral impact is under-specified.

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 concise 6-line docstring that front-loads the purpose and uses, then lists args efficiently. No redundant or irrelevant 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?

The description explains the tool's inputs and high-level behavior but omits the output format (e.g., how recovery steps are structured). Given no output schema, this gap leaves the agent uncertain about the return value's structure. Still adequate for an analysis tool.

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

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

The input schema has 0% description coverage, but the description's Args section adds meaning for all 4 parameters: progress range (0.0-1.0), error_message, printer_name, job_id. This compensates significantly for the schema lack.

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 classifies a print failure and suggests recovery steps, using heuristics based on error messages, progress, and failure history. This distinguishes it from sibling tools like 'analyze_print_failure' (likely simpler) and 'detect_print_failure' (detection only).

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

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

The description implies use when a print failure occurs to get classification and recovery steps, but does not explicitly state when not to use or compare to alternatives. Sibling tools are not mentioned, and no exclusions or prerequisites are given.

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

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

No annotations are provided, so the description carries full burden. It explains it reads the file header (non-destructive) and lists the metadata extracted. However, it does not explicitly state that the operation is read-only or mention potential 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 concise, well-structured with a note, and front-loaded. Every sentence adds value without waste.

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

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

The description is quite complete for a simple tool: purpose, usage context, input format, and return structure. It could mention error cases or prerequisites, 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?

The schema has 0% coverage, but the description adds meaning by specifying the filename is as shown by 'printer_files()'. This helps the agent locate the correct file.

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 analyzes a G-code file and extracts metadata. It specifies the verb 'analyze' and resource 'G-code file', and distinguishes from siblings like 'printer_files' and 'list_plate_objects'.

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

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

The description explicitly says when to use: 'when filenames are meaningless' and recommends an alternative tool ('list_plate_objects') for multi-object files. This provides clear 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?

No annotations are provided. The description describes the analysis but does not explicitly state that it is read-only or non-destructive. For a tool with no annotations, the burden is on the description to disclose behavioral traits; it partially meets this by describing the checks but omits safety information.

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: two sentences plus an args line. It front-loads the action and contains 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?

Given the tool's simplicity (1 param, no output schema, no annotations), the description covers the purpose and checks but lacks specification of return value (e.g., score, boolean) and error cases. Moderate completeness for a simple tool.

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

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

The single parameter file_path is described as 'Path to the snapshot image file,' providing context beyond the schema's type string. With 0% schema description coverage, this compensation is 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 clearly states the tool analyzes a webcam snapshot for print monitoring quality, listing specific checks (brightness, variance, resolution, format) and the output determination (usability). It distinguishes itself from sibling tools like analyze_print_file by focusing on snapshots.

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

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

The description implies usage for webcam snapshots but does not explicitly state when to use this tool vs alternatives (e.g., analyze_print_failure). No exclusions or prerequisites are mentioned.

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

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

No annotations are provided, so the description bears full burden. It discloses that the tool 'parses parameters, modules, and library imports' to understand architecture, implying a read-only analysis. However, it does not explicitly state that it is non-destructive or mention any limitations or 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 concise and front-loaded with the core purpose. The inclusion of an 'Args' section with parameter description is useful, though slightly redundant with the schema. Every sentence contributes valuable information with minimal 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 that there is no output schema, the description should specify the return format or structure to inform the agent's next steps. It mentions understanding architecture but does not describe the output (e.g., list of modules, parameters, imports). This leaves the agent without sufficient guidance on how to use the result.

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

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

The input schema has 0% description coverage, but the description adds crucial meaning by stating 'OpenSCAD source code' for the 'scad_code' parameter. This clarifies what the string should contain beyond the bare type, though further detail like encoding or size limits is absent.

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 'Analyze the structure of OpenSCAD code' with a specific verb and resource. It details what is parsed (parameters, modules, library imports) to understand architecture, distinguishing it from sibling tools like 'compile_scad' or 'modify_scad_module'.

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

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

Explicitly advises 'Use this before modifying code to know what modules exist and what each one does,' providing clear when-to-use context. It implicitly positions itself as a prerequisite for modification tools, though it does not mention when not to use it or list 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?

No annotations provided, so description carries full burden. It explains return format (risks list with locations) but does not disclose whether tool modifies the file, requires permissions, or has side effects. Adequate but not comprehensive.

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 well-structured with bullet points for risk types and clear sections for returns and parameters. Slightly verbose but efficient overall.

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 complexity (multiple risk types, three parameters, no output schema), description covers key aspects: risks, coordinate return, param details. Could mention output schema or severity scale, but still 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 has 0% parameter descriptions, but description includes :param section explaining file_path, min_cross_section_mm2 (with default), and sharp_angle_threshold_deg (with default). This adds significant meaning beyond the schema.

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

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

Description clearly states it analyzes STL mesh for structural weak points, listing specific risk types (thin_neck, stress_concentration, etc.) and contrasting with printability analysis. This distinguishes it from siblings like analyze_printability.

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

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

Description implies use for structural analysis beyond printability but does not explicitly state when to use this tool versus alternatives like assess_load_bearing or analyze_warping_risk. No exclusions or when-not guidance.

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

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

No annotations are provided. The description describes the analysis and returns a risk assessment, but does not disclose behavioral traits such as read-only nature, required permissions, or computational intensity. It lacks full disclosure of side effects or safety information.

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 purpose, details on what it examines, output fields, parameters, and examples. It is concise enough while being thorough; each section adds value, though some wording could be tightened.

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

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

Given no output schema, the description provides comprehensive information about return fields (risk_level, score_deduction, etc.), parameters with defaults and examples, and the overall workflow. It covers all necessary context for an 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?

The description adds meaning beyond the schema by explaining file_path as 'Path to STL or OBJ file', material with examples and default, and printer_id with its purpose. This compensates for the schema's lack of descriptions, effectively covering all three 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 tool analyzes warping risk for a 3D model based on geometry and material. It distinguishes itself from sibling tools like 'analyze_printability' by focusing specifically on warping risk factors.

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

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

The description explains what the tool does and provides examples, but does not explicitly state when to use this tool over alternatives like 'analyze_printability' or 'analyze_model_geometry'. No when-not or alternative guidance is given.

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

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

No annotations are provided, so the description carries full burden. It states the function but does not disclose consequences (e.g., mutability, reversibility, or error handling). The tool modifies a print record, but safety or side effects are unaddressed.

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: a single sentence for the main action, followed by a brief parameter list. No redundant information; every sentence adds value.

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

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

For a simple tool with two required parameters, the description covers the core function and parameter meaning. However, it omits behavior for edge cases (e.g., appending vs. overwriting notes, handling nonexistent print IDs) and does not describe the return value.

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

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

The description includes an 'Args:' section that explains each parameter beyond the bare schema (e.g., 'job_id: The job ID of the print to annotate,' 'notes: The annotation text to attach'). Since the input schema lacks property descriptions, this adds meaningful context.

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 action ('add notes to a completed print record') and gives examples ('quality observations, issues'). The verb 'annotate' is specific, distinguishing it from recording other outcomes. However, it doesn't explicitly differentiate from siblings like 'record_print_outcome' which may also accept notes.

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

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

The description implies usage for completed prints but provides no guidance on when to use this tool versus alternatives (e.g., 'record_print_outcome' for structured data). No exclusions or prerequisites are mentioned.

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

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

With no annotations, the description carries full disclosure weight — and it delivers. It transparently discloses the inline 3D stage side effect, automatic decimation of oversize meshes, and host-dependent fallback behavior ('in hosts that render MCP Apps panels... attaches a browser stage link for hosts that don't'). It falls short of a 5 only because it omits error/failure behavior and what happens when the named decoration doesn't exist.

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

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

Front-loaded with a punchy one-liner, then the core value prop, then params, then rich behavioral notes — a logical downward-spiral of detail. The only waste is 'This is the magic tool —' which is marketing fluff that doesn't add functional info. The param docs use reST format with helpful types but add a bit of noise. Otherwise, every other 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?

Given the tool's complexity (5 params, side-effectful 3D stage, no output schema), the description covers all essential dimensions: purpose, params, return value ('Dict with decorated model path and settings used'), and side effects. The gap is that it doesn't discuss error conditions, performance expectations for large models, or whether the tool mutates the original file. It's thorough, but a few edge-case behaviors would make it 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?

Param semantics are excellent. The description's docstring block provides meaning for all 5 params, even though schema coverage is 0%. It explains name is a 'slug', model_path accepts 'STL or OBJ' formats, material is an 'Override (empty = use proven or detect from printer)', face has values 'auto, top, bottom, etc.', and printer_id is 'for material detection'. This exactly compensates for the empty schema descriptions.

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

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

The opening line 'Apply a saved decoration to a new model — proven settings, one call' is a specific verb+resource+scope statement. It's further clarified with 'Loads a previously saved decoration and applies it to the target model using the exact settings that worked before,' clearly distinguishing this from sibling decoration tools like decorate_surface by emphasizing the 'replay a proven recipe' angle.

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

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

The description implies when to use: when you have a saved, proven decoration to replay ('proven settings, one call', 'decorations that took many iterations to perfect can be replayed'). However, it never explicitly names an alternative (e.g., 'use decorate_surface for new decorations') or provides when-NOT-to-use guidance. The usage context is clear but implicit rather than explicit, and no exclusions are given.

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

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

With no annotations, the description carries the full burden. It discloses multiple behavioral details: auto-applies fixes, specific transformation types (thickened walls, fillets, base plate, gussets), returns before/after scores and skipped list, requires OpenSCAD, and opens an interactive 3D stage with automatic decimation. It doesn't explicitly state whether the original file is modified vs. creating a new one, but the output_path parameter implies output to a new file.

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-organized, starting with a one-sentence summary followed by bullet lists of fixes and parameters, then an additional note about the 3D stage. Every sentence contributes useful information, especially given the need to compensate for the schema's lack of descriptions. Slightly verbose but justified.

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

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

Given the tool's complexity (mesh analysis + automatic fixes), no annotations, no output schema, and minimal schema descriptions, the description covers the essential aspects: inputs, outputs, dependencies, skipped items, and interactive stage behavior. It lacks error handling details and exact return structure, but overall provides enough context for an agent to use the tool 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 description coverage is 0%, so the description must compensate. It does so thoroughly, documenting all five parameters with their meanings and defaults: file_path, output_path, fillet_radius_mm, wall_thicken_mm, and base_height_mm. This adds significant semantic value beyond the bare types and defaults in 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 a specific verb-resource combination: 'Analyze a mesh for structural risks, then auto-apply fixes.' It further distinguishes itself as 'the one-step design hardening tool' that runs the full analysis pipeline and applies every applicable fix, setting it apart from siblings that likely only analyze or recommend.

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

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

The description implies when to use this tool: when you want both analysis and automatic fixes in one step. It also notes what it does NOT do ('Reinforcements that can't be auto-applied (like reorient) are listed in skipped with guidance'), giving context for limitations. However, it does not explicitly name alternatives like analyze_structural_risks or recommend_design_reinforcements, so an agent might not know when to choose those 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?

With no annotations, the description must carry the full burden of behavioral disclosure. It describes the algorithm and output but does not state side effects (e.g., file modifications, permissions required). The tool appears to be a read-only arrangement, but this is not explicitly confirmed.

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 summary, algorithm explanation, and parameter list. It is informative but slightly verbose; however, the detail is justified given the lack of schema descriptions.

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

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

The description covers all parameters, algorithm, and output keys. It lacks explanations of error handling (e.g., missing files) and prerequisites, but overall it provides sufficient context for a tool with no output schema and no annotations.

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

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

Schema description coverage is 0%, so the description must compensate. It provides detailed parameter descriptions in a docstring format, including defaults, examples, and expected formats (e.g., JSON arrays for file_paths, dict for copies). This adds significant value 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: 'Pack multiple STL files onto a virtual build plate.' It specifies the verb 'pack' and the resource 'STL files onto a build plate,' distinguishing it from sibling tools like 'auto_arrange_parts_on_plate' by emphasizing configurable parameters.

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

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

The description explains the algorithm and what the tool reports but does not explicitly state when to use this tool versus alternatives like 'auto_arrange_parts_on_plate.' It lacks guidance on context or exclusions, leaving the agent to infer usage.

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

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

No annotations provided, so the description bears full burden. It describes the analysis outputs but does not disclose whether the tool is read-only, modifies the file, has side effects, or requires specific file validity. A read-only analysis tool should state 'does not modify the file' for full transparency.

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

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

The description is front-loaded with a clear summary and bulleted outputs, then a clarifying example. The example sentence is slightly verbose but adds value. Overall efficient for the detail provided.

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 explains the return dictionary keys and the reasoning approach. It covers what the tool does and the main input requirement. Missing error conditions or limitations, but for a single-parameter tool, 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?

The only parameter 'file_path' is described as 'Path to the STL file', adding format specificity beyond the schema's 'File Path'. However, it does not clarify if the path must be local or remote, or if file existence is checked. With 0% schema coverage, the description partially compensates.

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 analyzes load-bearing characteristics from mesh geometry. It lists specific outputs (primary_load_axis, load_surfaces, etc.) and contrasts with simple material lookup, distinguishing it from sibling tools like analyze_mesh_geometry.

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

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

The description implies use when geometric reasoning is needed (e.g., 'this bracket should be printed on its side'), but does not explicitly state when not to use or suggest alternative tools. The example helps contextualize, but lacks explicit exclusions.

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

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

With no annotations provided, the description must carry the full burden. It details the internal steps (design briefing, mesh validation, etc.) and indicates the output is a single report. It does not mention side effects like file modification, but given the audit nature, it is likely read-only. The description adds significant context beyond the schema.

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

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

The description is efficient: a clear overview, a usage sentence, and a structured parameter list. Every sentence adds value, and the structure is easy to parse.

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

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

Given 10 parameters and no output schema, the description explains inputs and the nature of the output (a report answering readiness). However, it lacks details on the report format (structured vs. text) and does not specify if the tool modifies any files. Still, it covers the essential functionality well.

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

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

The description's 'Args' section adds meaningful descriptions for all 10 parameters, including examples (e.g., 'petg', 'bambu_a1') and units (e.g., degrees for max_overhang_angle). The input schema only provides types and defaults, so the description enriches understanding substantially.

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: 'Run a ruthless audit of an original design before printing.' It lists the specific aspects combined into a report and answers a precise question. No other sibling tool has an identical purpose; this is a comprehensive audit distinct from more focused analysis 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 explicitly states when to use the tool: 'after generating or modeling a new part.' It also frames the question the tool answers. However, it does not mention when not to use it or provide alternatives, which would improve 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?

No annotations provided, so description bears full burden. It describes arrangement strategy, group handling, defaults, and return format. Does not mention side effects or authentication, but those are not needed for this calculation tool. Slight lack of detail on error cases but overall transparent.

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?

Well-structured with clear sections (overview, usage, example, args, returns). Slightly verbose with docstring-style formatting, but every part is informative. Could be shortened 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 5 parameters, no output schema, and sibling tools, the description covers input format, output format (dict with success, parts, group_count, message), and usage context. Complete enough for correct agent invocation.

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

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

Schema coverage is 0%, but description compensates fully with a detailed Args section explaining each parameter, including nested fields of part_specs, defaults, and purpose of printer_id. Adds significant 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?

Clearly states the tool calculates non-overlapping XY positions for parts on a print plate. The verb 'calculate' and resource 'positions' are specific. Although it doesn't explicitly distinguish from sibling 'arrange_parts_on_plate', the name and description imply automatic arrangement.

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 compose_multicolor_3mf with multiple separate objects. Also provides alternative: for maximum density, use kiln-pro. Explains group index behavior for multi-color units.

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

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

With no annotations provided, the description carries the full burden and excels: it details precision cutting of crossing faces, capping behavior, per-zone closed-solid output, generation of STL/3MF files, zero cloud dependencies, and the inline 3D stage including automatic decimation of oversized meshes and browser fallback. This is exemplary behavioral disclosure.

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

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

The description opens with a strong one-line summary followed by tightly organized behavioral details and a clearly labeled 'INLINE 3D STAGE' callout. It's longer than typical but every sentence contributes distinct information; slight wordiness in the inline-stage section keeps it from a 5.

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 there's no output schema and no annotations, the description goes far: it documents parameters, return structure, file formats, and interactive viewer behavior. It's complete for the tool's complexity, though the return dict's edge cases (e.g., what happens with fewer colors than requested) are left speculative.

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

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

Schema description coverage is 0%, so the description must compensate — and it does via reST-style parameter docs: binary STL for input_path, default 4 for num_colors, and hex list defaults for color_palette, plus returns documentation. Loses a point for not noting valid ranges, format validation, or error behavior, but it adequately makes up for the bare schema.

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

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

The description clearly states the tool 'Split[s] a 3D model into horizontal color zones by Z-height' — a specific verb+resource+scope. It's readily distinguishable from siblings like auto_color_by_region conceptually, but it doesn't explicitly reference or contrast with that sibling, so it doesn't fully earn a 5.

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

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

Usage context is implied through the description of Z-height banding and the 3MF output for AMS/MMU printers, suggesting when this tool is appropriate. However, there is no explicit 'use this instead of X' guidance, no exclusions, and no mention of when to choose a region-based or alternative coloring tool.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the behavior for each method, including edge cutting, capping, closed solids for z_height, surface painting for others, and slicer compatibility. It also discloses side effects like the inline 3D stage, automatic decimation, and dependency-free geometry. This goes beyond typical transparency.

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

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

The description is long but each section adds value: method explanations, technical outcomes, slicer guidance, and the stage note. It is well-structured with bullet-like formatting, though slightly verbose. Every sentence earns its place, and it is front-loaded with core functionality before diving into details.

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

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

Given the tool's complexity (multiple assignment methods, variable output formats, and an interactive stage side effect), the description is remarkably complete. It covers prerequisites (input_path), return values (zone STL paths, colors, face counts, AMS mapping, weights, 3MF), and post-behavior (opens 3D stage). Since there is no output schema, the description bears full responsibility, and it fulfills it thoroughly.

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 fully explains each parameter. It defines input_path as a binary STL path, num_colors with default 4, method with allowed values and defaults, and color_palette with default hex list. It also describes the return dict structure, adding meaning beyond the schema's sparse property 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 tool's purpose: 'Split a 3D model into color zones by geometric region.' It specifies a precise verb (split), a resource (3D model), and the method (by region), and distinguishes itself from sibling tools like auto_color_by_height by covering multiple assignment methods (z_height, normal, random).

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 detailed context on when to use the tool, explaining the different methods and their outcomes (closed solids vs. watertight object). It does not explicitly name alternatives or exclusion cases, but it clearly implies when it is appropriate, and the distinction from auto_color_by_height is evident from the title and description.

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 key behaviors (evaluation, scoring, optional write) but lacks details on side effects (e.g., does writing a new STL overwrite the original? Permissions needed?). Without annotations, more explicit behavioral context would improve transparency.

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

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

The description is well-structured with a clear first sentence followed by bullet-like parameter explanations. It is concise, with no redundant or irrelevant information. Every sentence serves a 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?

The description covers the main functionality and parameters, but lacks detail on return values (no output schema) and scoring criteria. For a tool with moderate complexity and no annotations, more completeness on output behavior 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 0%, so the description must explain parameters. It does so for all five: file_path, candidates, nozzle_diameter, apply, output_path, including defaults and conditional use. This adds significant meaning beyond the bare schema.

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

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

The description clearly states the tool's purpose ('Find the optimal print orientation for a 3D model') and details how it works (evaluates rotations, scores based on adhesion, supports, etc.). It distinguishes itself from siblings like 'optimize_print_orientation' by specifying the evaluation criteria and optional file writing.

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

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

The description implies usage (when needing optimal orientation) but does not explicitly state when not to use or mention alternatives. Given sibling tools like 'optimize_print_orientation' and 'analyze_model_geometry', more explicit guidance would help.

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

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

With no annotations, the description carries full burden. It clearly explains the polling behavior, terminal state condition, timeout, and blocking nature. It does not disclose what happens on timeout (e.g., exception or status), but overall provides good transparency.

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

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

The description is a single paragraph with a structured Args section. It is relatively concise but could be slightly more compact. It front-loads the purpose and then details parameters, which is good.

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

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

The tool is simple but the description lacks detail on the return value (final status) - e.g., format or possible values. It does not explain error handling or timeout behavior. Given no output schema, this is a gap.

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

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

Schema description coverage is 0%, so the description must compensate. It lists all 4 parameters with explanations: job_id is required, provider defaults to 'meshy', timeout defaults to 600 seconds, poll_interval defaults to 10 seconds. This adds significant meaning beyond the bare schema.

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

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

The description clearly states the tool's purpose: to wait for a generation job to complete and return the final status. It uses specific verbs like 'Wait', 'polls', and 'block', and distinguishes from sibling tools like 'generation_status' by emphasizing synchronous blocking behavior.

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

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

The description provides clear context: 'Useful for agents that want to block until a model is ready.' It implies when to use this tool (synchronous waiting) but does not explicitly state when not to use it or mention alternatives like polling via 'generation_status'.

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

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

With no annotations provided, the description fully bears the burden of behavioral disclosure. It details the polling behavior, terminal states, timeout, and return structure (outcome, final state, elapsed time, completion history, optional design_goal block). It also notes best-effort for brief_id. This is comprehensive.

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 purpose statement, behavior paragraph, and parameter docstring. It is relatively concise given the amount of information, though slightly longer than minimal. Every sentence adds value, but could be tightened slightly.

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 of a polling tool with optional parameters and no output schema, the description covers the return value format thoroughly. It addresses the main use case, optional features, and edge cases like timeout. It is complete for an agent to understand and 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?

Schema description coverage is 0%, so the description must compensate. It explains each parameter's purpose and effect: job_id (track specific job vs. monitor printer), timeout (max wait), poll_interval (status check frequency), and brief_id (adds design_goal if resolves). This adds significant meaning beyond the schema's type and default values.

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

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

The description clearly states the tool's purpose: 'Wait for the current print to finish and return the final status.' It uses specific verbs ('await', 'polls') and resource ('print completion'), and distinguishes from sibling tools by focusing on blocking wait versus fire-and-forget, which differentiates it from monitoring or cancellation 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 provides clear context for when to use the tool (fire-and-forget, avoid manual polling) and explains the optional job_id and brief_id parameters. However, it does not explicitly state when NOT to use it or compare with alternatives like monitor_print, so it lacks explicit exclusion guidance.

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

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

Describes that a copy of SQLite database is created and sensitive fields are redacted by default. No annotations provided, so description carries full burden. It adds basic behavioral details but omits potential side effects like database locking or performance impact.

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

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

Description is concise and front-loaded with purpose. The Args section adds clarity but is slightly formal. No wasted sentences; every sentence contributes information.

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

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

For a tool with 2 parameters, no output schema, and no annotations, the description covers purpose, default behavior, and both parameters adequately. It lacks error scenarios or prerequisites but is sufficient for basic usage.

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

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

Schema coverage is 0%, so description compensates well. It explains output_path default pattern and redact default and meaning. This adds significant value beyond the schema's bare types and defaults.

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

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

Description clearly states 'Back up the Kiln database with optional credential redaction,' using specific verb and resource. Among sibling tools, none are database backup, so it is well-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?

No guidance on when to use this tool vs alternatives or when not to use it. With hundreds of sibling tools, lack of usage context makes it hard for an agent to select this tool appropriately.

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

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

With no annotations provided, the description carries the full burden. It correctly indicates a non-destructive read operation, but does not disclose any side effects, permissions, or behavioral details beyond the basic function.

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 highly concise with two short sentences and a brief args section. Every word adds value, with no redundancy or unnecessary detail.

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 status check with one optional parameter and no output schema, the description is adequate. It explains what the tool does and the single parameter. However, it could mention the return format or status indicators.

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

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

The description adds meaningful context to the single parameter 'printer_name' beyond the schema (which only provides type and default). It clarifies the purpose and default behavior, compensating for the 0% schema description 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 uses a specific verb 'Check' and clearly states the resource 'bed leveling status' and what it determines ('whether leveling is needed'). It effectively distinguishes from sibling 'trigger_bed_level' which performs a different action.

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

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

The description implies usage for checking leveling status but provides no explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or 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?

With no annotations, the description carries the burden and does a good job: it discloses the OpenSCAD dependency, output file behavior (defaults to temp), return values, and the inline 3D stage side effect with decimation behavior. It could add more about failure modes or file overwrite semantics, but it provides substantial transparency.

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

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

The description is front-loaded with the main purpose, then uses headings and bullet points to organize operation types, use cases, params, return, and the 3D stage note. Every sentence adds value and the structure makes it easy to scan.

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

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

For a complex mesh operation tool, the description covers the operation types, external dependency (OpenSCAD), parameter semantics, return format, and the unique inline stage behavior. No output schema exists, but the return dict is described. This is comprehensive for the tool's complexity.

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

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

Despite the schema having zero parameter descriptions, the docstring fully explains each parameter: operation's allowed values, file_paths requiring a minimum of 2, and output_path defaulting to temp. It also explains the semantic effect of each operation choice.

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

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

The description starts with 'Perform a CSG boolean operation on two or more STL meshes', which clearly identifies the specific verb and resource. It enumerates the three operation types (union, difference, intersection) and provides concrete use cases, distinguishing it from sibling tools like merge_stl.

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

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

It gives explicit use cases (e.g., subtract cylinder from block, combine parts) that clarify when to use this tool. However, it does not mention alternative tools or when not to use it, so it stops short of a full exclusion discussion.

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

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

With no annotations, the description must disclose all behavioral traits. It states the basic behavior and return similarity to search_models, but omits details about side effects, authentication needs, rate limits, or pagination limits beyond per_page max.

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, covering the tool's purpose, parameters, and a note on related tools in a compact block. The structure (paragraph with inline arguments) is efficient, though not highly formatted.

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 parameters, no output schema, and no annotations, the description covers the essential input semantics and references list_categories. It lacks return format details beyond a vague reference to search_models, which limits completeness for an agent needing to process 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 0%, so the description carries the burden. It explains browse_type (three options), page, per_page (default and max), and category with an example slug. It adds value beyond the schema but does not fully define all parameter nuances (e.g., behavior of default values).

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

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

The description clearly states the action (browse) and the resource (Thingiverse models) with specific sorting criteria (popularity, recency, category). It differentiates from 'list_categories' by mentioning that tool for category slugs. However, it does not explicitly distinguish from sibling 'search_models' beyond noting similar return format.

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 (browsing by type/ category) and references 'list_categories' for valid slugs. It lacks explicit guidance on when not to use this tool (e.g., versus searching) or 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?

With no annotations, the description carries the full burden. It discloses that the tool appends manufacturing constraints, printer-fit limits, and material guidance, and that prompt length is optimized per provider. It does not mention return format or side effects, but for a stateless builder, it is fairly transparent about its behavior.

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

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

The description is well-organized, starting with the core purpose, then usage guidelines, then parameters. Every sentence adds value; there is no redundancy or fluff. It is appropriately sized for the tool's complexity.

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

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

The description covers purpose and parameters well but lacks explicit mention of return value (e.g., the built prompt string) and does not address error cases or prerequisites. For a tool that outputs a prompt, the omission of return format is a gap 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 0%, so the description must add meaning. It describes each parameter: requirements (natural language description), material (optional override with example), printer_model (optional with example), provider (optional, controls prompt length budget). These descriptions provide essential semantics beyond bare types.

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

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

The description states 'Build a design-aware generation prompt for original 3D creation' and positions it as 'the best pre-generation tool for original designs', clearly identifying the verb (build) and resource (generation prompt) with a specific scope (original designs), distinguishing it from siblings like build_parametric_prompt or improve_generation_prompt.

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 recommends use for original designs and explains provider-specific length optimization with examples (openscad, meshy, gemini), providing clear context. It does not directly state when not to use it or name alternatives, but the focus on original design implies exclusion of other 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?

No annotations provided; the description discloses it auto-generates and combines data to produce a JSON dict. It does not mention side effects, error handling, or permissions. The behavior is mostly implied but lacks deep transparency.

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

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

The description is well-structured with a summary, details, and an example. It is relatively concise but the code block adds length; however, it adds value for understanding the workflow.

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 and moderate complexity, the description explains input, output purpose, and usage in a workflow. It covers the essential context but omits error handling and edge cases.

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

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

With zero schema description coverage, the description adds meaning by explaining material_id as the target material and printer_id as an optional printer model. It provides examples and clarifies behavior when omitted, though it doesn't specify allowed values or constraints.

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

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

The description clearly states the tool auto-generates a slicer override dict for a specific material, combining material thermal data with printer-specific tuning. It distinguishes itself from siblings as the key tool for material switching.

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 an explicit example workflow and states it is the key tool for material switching, giving clear when-to-use guidance. However, it does not explicitly mention when not to use or contrast with alternatives like get_material_slicing_profile.

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

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

No annotations are provided, so the description carries the full burden. It explains the tool returns an enhanced prompt with OpenSCAD-specific instructions for structured code, named variables, comments, and material-aware limits. This adds behavioral context beyond the basic purpose, though it does not cover potential side effects or performance implications.

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

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

The description is compact, with the main purpose in the first sentence and a clear usage directive in the second paragraph. It avoids redundancy and is front-loaded, though the phrase 'enhanced prompt' appears twice.

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 lack of output schema, the description does not specify the return type (e.g., a string). It does cover the tool's function and parameters adequately for a simple generation tool, but omitting the output format leaves room for ambiguity. The contrast with one sibling helps, but more sibling differentiation could 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?

The schema has 0% coverage (no parameter descriptions), so the description must compensate. It briefly explains each parameter: 'requirements: Natural language description of the desired part,' 'material: Optional material override (e.g. petg),' and 'printer_model: Optional printer model ID (e.g. bambu_a1).' This adds meaning beyond the raw schema types but is not highly detailed.

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

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

The description clearly states that the tool 'Build a prompt optimized for parametric OpenSCAD code generation,' which is a specific verb+resource combination. It directly contrasts with the sibling tool build_generation_prompt, indicating distinct functionality for generating editable OpenSCAD code versus mesh files.

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

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

The description explicitly states when to use this tool: 'Use this instead of build_generation_prompt when you want the AI to generate editable OpenSCAD code rather than a mesh file.' This provides clear usage context and 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?

No annotations are provided, so the description carries full burden. It states the tool 'caches for faster access and version tracking' but does not disclose behavioral traits like whether it overwrites existing caches, requires authentication, has storage limits, or if version tracking is automatic. The description is too brief to provide meaningful transparency.

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

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

The description is very concise (two sentences plus parameter list) but lacks structure. It front-loads the purpose, which is good, but the parameter descriptions are in a list format inside a docstring, which is acceptable. However, it could be improved by including a brief example or clarifying the output. It earns its place but barely.

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 3 parameters, no annotations, and no output schema, the description is incomplete. It does not explain what happens after caching (e.g., return value, side effects like file storage location), whether the operation is reversible, or any errors that might occur. For a tool with moderate complexity, more detail is needed.

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

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

Schema description coverage is 0%, so the description must compensate. It lists all three parameters with basic explanations: 'Path to the design file to cache', 'Human-readable label for the cached design', 'Intended material for this design'. These add meaning beyond the schema's titles, but are still minimal. For example, 'label' and 'material' could benefit from constraints or examples. Baseline 3 is appropriate given the descriptions are present but not detailed.

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: caching a 3D design file for faster access and version tracking. It uses a specific verb ('Cache') and resource ('3D design file'), and the mention of 'faster access and version tracking' differentiates it from general caching utilities. However, it doesn't explicitly distinguish from similar tools like 'cache_design_with_source' or 'cache_model', but the context helps.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., cache_model or cache_design_with_source). It also lacks any 'when not to use' or prerequisites. The tool appears to be for storing a design for faster access, but no context is given about when caching is appropriate or when to use other caching 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?

With no annotations provided, the description must convey behavioral traits. It describes the action (storing and attaching), implying a write operation, but does not disclose details such as whether existing cache entries are overwritten, authentication requirements, side effects, or return values. The description provides basic transparency but leaves gaps.

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, beginning with a one-line summary followed by a short explanatory paragraph and a properly formatted argument list. Every sentence adds value, and there is no unnecessary content. It could be slightly more condensed but remains well-structured and front-loaded.

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

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

Given the 6-parameter complexity, no output schema, and no annotations, the description covers the core functionality but does not fully equip an agent. It lacks return value details, overwrite behavior, and retrieval instructions. While it explains what is stored, it omits the outcome of the operation and post-call state, limiting 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?

The input schema has 0% description coverage for parameters, so the description must compensate. It lists all 6 parameters with brief explanations (e.g., 'file_path: Path to the design file'), which adds meaning beyond the schema's titles. However, it lacks details like path format, file existence requirements, or constraints on provider values. The explanations are adequate but minimal.

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: 'Cache a design file alongside its parametric source code.' It specifies the verb 'Cache', the resource 'design file' and 'parametric source code', and explains that it stores the STL/3MF file and attaches the OpenSCAD source and prompt. This distinguishes it from sibling tools like 'cache_design' which likely cache only the file.

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 lacks any guidance on when to use this tool versus alternatives such as 'cache_design' or 'cache_model'. It does not mention prerequisites, conditions, or when to avoid using it. The only implicit differentiation is the inclusion of source code, but no explicit 'when-to-use' or 'when-not-to-use' instructions.

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 key behaviors: file copying to '~/.kiln/model_cache/', metadata storage in a database, and duplicate detection via SHA-256. This goes beyond the schema, especially since no annotations are provided. It clearly indicates a write operation and explains the caching mechanism.

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 concise summary followed by parameter details in an 'Args:' block. It is front-loaded with the purpose. A slight reduction in parameter detail (e.g., more compact format) could improve conciseness, but it is already 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 7 parameters, 2 required, no output schema, and zero schema description coverage, the description provides complete coverage: explains all parameters, gives examples, describes the caching process and duplicate detection. It is self-sufficient for an 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 description coverage is 0%, so the description carries the full burden. It provides detailed explanations for all 7 parameters, including examples for 'source' (enum-like list), 'tags' (comma-separated example), and 'dimensions' (JSON object with bounding box format). This adds significant meaning beyond the schema's type-only fields.

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 adds a 3D model to a local cache for reuse across jobs, with specific details about storage location and metadata. While the verb and resource are specific, it does not explicitly distinguish from sibling tools like 'cache_design' or 'get_cached_model', leaving some 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 explains what the tool does but provides no guidance on when to use it versus alternatives like 'cache_design' or 'delete_cached_model'. There is no mention of prerequisites, when not to use, or when to prefer another tool.

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

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

No annotations are provided, so the description carries the full burden. It discloses that commands are sent automatically and lists options, but does not describe potential side effects, error conditions, or the tool's return value. It mentions a key precondition (printer idle) but lacks depth on what changes occur on the printer.

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 paragraphs and bullet points, starting with the core purpose. Every sentence adds value without redundancy, making it efficient for an AI agent to parse.

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