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

With no annotations, the description carries the full behavioral burden and does so richly: it discloses caching, 'never unioned', UNRESOLVED distances inside tessellation error bounds, exit_code 0/1/2, full-turn certificates, and SCAD expression evaluation in model scope. This goes well beyond the raw 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 text is dense and information-rich with no fluff, but it is structured as a single run-on paragraph mixing mode definitions, inline type hints, and examples. Bullet points or mode-separated blocks would make parsing significantly easier.

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 core invocation paths, all mode semantics, expression evaluation, and edge-case behavior like UNRESOLVED and exit codes, while an output schema handles return-shape details. Still, several input parameters are left unexplained, so the agent may need to guess at their meaning.

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 successfully explains mode values, the parts record structure, check_file contents, quality options, and volume behavior. However, many schema properties such as pairs, against, steps, tolerance_mm, response_format, and include_paths remain undocumented, leaving partial compensation.

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

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

The description states a specific purpose: checking relations between named parts in an assembly, and enumerates six distinct modes (interference, clearance, contact, alignment, motion, rules). It clearly distinguishes this from simple syntax validation, though it never explicitly contrasts with sibling tools like check_openscad.

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

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

The description gives clear internal usage context: choose a mode such as 'interference' or 'clearance', supply parts or a check_file, and interpret exit codes. However, it does not explicitly say when to prefer this tool over siblings like check_openscad, scad_eval, or measure, so cross-tool selection guidance is only implied.

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 is the only source. It discloses the return type and the effect of include_paths, but does not explain what happens if OpenSCAD is not installed or any potential errors. The read-only nature is implied but not explicitly stated.

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

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

The description is compact and front-loaded with its purpose. The Args/Returns format is structured and free of redundant information. Every sentence contributes.

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

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

For a simple tool with one optional parameter and an output schema, the description covers purpose, parameter semantics, and return type. Missing details about error behavior when OpenSCAD is absent, which would be relevant for a verification tool, but overall it is sufficient for basic invocation.

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

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

Schema coverage is 0%, so the description must compensate. It explains 'include_paths' as 'Include searched paths in response', adding meaningful semantic meaning beyond the boolean schema. This fully clarifies the parameter's effect.

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 'Verify OpenSCAD installation and return version info' with a specific verb and resource. This clearly distinguishes it from sibling tools focused on model/render operations.

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

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

No explicit guidance is given about when to use this tool or alternatives. It does not mention prerequisites, typical use cases, or when to avoid using it. The usage is only implied by the verb 'verify'.

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 explicitly discloses the edge-case behavior: 'Does nothing (and still reports success) when the cache is disabled or the directory does not exist.' It also explains the return value (Dict with success status, cleared_files count, and freed_bytes). It does not mention permission requirements or potential side effects, but for a cache-clearing operation, this is sufficient. The description goes beyond a simple 'clears cache' and gives non-obvious 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: a one-line summary followed by a detailed explanation, and clearly labeled Args and Returns sections. It is concise with no fluff. The main purpose is front-loaded, and the edge-case note is placed early. 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?

Given that there are no parameters and an output schema is present (as indicated by 'Has output schema: true'), the description is complete. It explains the exact behavior, including the no-op edge case, and states what the return value contains. There is nothing an agent needs to know to call it correctly that is missing. The description does not need to repeat return format details since an output schema exists.

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 is empty (0 parameters), so schema description coverage is 100% vacuously. The description mentions an 'Args: ctx: MCP context for logging', which is likely an internal argument, not a user-facing parameter. With no user parameters to explain, the description adds no additional parameter semantics but is not deficient. The baseline for 0 parameters is 4, and the description does not contradict or omit anything relevant.

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

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

The description clearly states a specific action: 'Delete all cached render files and report freed space.' It specifies the resource (cached render files) and the exact scope ('every cached image and its dependency manifest'). It is distinct from all sibling tools, which handle checking, exporting, rendering, etc., with no ambiguity.

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

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

The description does not explicitly compare against alternative tools or state when to prefer this one. However, the purpose is so specific and self-contained that usage is implied by the name and description. It does not provide when-not-to-use guidance beyond noting behavior when cache is disabled, which is more behavioral than usage guidance. No explicit alternatives are named.

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

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

With no annotations, the description carries the full burden and delivers rich behavioral detail. It discloses the return dict structure, temporary output_path behavior, parts bundling into 3MF or STLs, manifest return, and mesh_health semantics including the meaning of manifold true/false/null and the typical cause of non-manifold results. It even advises overlap adjustments, which agents can act on.

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 appropriately so for an 8-parameter tool with no schema descriptions. It front-loads the core purpose and parts behavior, then adds mesh_health guidance, then systematically documents parameters. No sentence is filler, though the first paragraph could be tightened by moving parts details into the Args section.

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, 0% schema coverage, and an output schema already present, the description is largely complete: it covers return values, error hints, format choices, and typical failure causes. The omission of the 'quality' parameter is the most notable gap, and it also does not mention prerequisites like OpenSCAD installation, though sibling check_openscad may cover that.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it explains scad_content/scad_file mutual exclusivity, output_format values with default, output_path fallback, variables via -D, include_paths via OPENSCADPATH, and parts structure in the intro. The main gap is the 'quality' parameter, which is never described, and 'parts' is not restated in the Args block, leaving that schema field partially uncovered.

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: 'Export OpenSCAD code or file to a mesh, 2D, or CSG format.' It clearly names the output families and even details the parts-bundling behavior, which makes the tool's function unmistakable. This distinguishes it from siblings like render, measure, and validate, which focus on other stages of the pipeline.

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 strong context about what the tool does and how it behaves, such as mutual exclusivity of scad_content and scad_file, and the parts export mode. However, it never explicitly contrasts this tool with sibling tools or says when to use export_model over alternatives like render or model. Usage is implied by the verb 'export' rather than stated as 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 the read-only nature, that OpenSCAD is not required, that standard paths and OPENSCADPATH are searched, and that it lists subdirectories with file counts, README presence, and main entry files. This covers key behavioral traits without contradicting anything.

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 and front-loaded with a one-sentence summary. It uses paragraphs effectively and every sentence adds value. The Returns section is somewhat redundant given the output schema, but it does not bloat excessively.

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?

This is a simple, read-only tool with a rich output schema. The description provides enough context about what paths are searched, what data is returned, and the read-only nature. It lacks edge-case details like error handling, but for this complexity level it is adequately 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 input schema has zero parameters, so the baseline is 4. The description adds that the only argument, ctx, is used for MCP logging, which is meaningful but minimal. No further parameter semantics are needed.

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

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

The description opens with 'Discover installed OpenSCAD libraries on the system,' using a specific verb and resource. It clearly distinguishes this from sibling tools like check_openscad, rendering, and model management tools. The scope is further clarified by mentioning standard library paths and OPENSCADPATH.

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 the tool: to discover libraries on the system, including via OPENSCADPATH. It explicitly notes it is read-only and does not require OpenSCAD to be installed, which signals a low-risk discovery operation. However, it does not explicitly name alternatives or exclusions, so it falls short of full guidance.

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

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

With no annotations, the description carries the full burden. It discloses retrieval details (size, mtime, references, dependency graph) and constraints (allowed_paths). However, it does not explicitly state that this is a read-only operation or describe any side effects or rate limits. It is transparent about information returned but not fully explicit about behavior beyond queries.

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

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

The description is a single paragraph but packed with essential details in two sentences. It front-loads mode-specific behavior and constraints. While long, it is efficient and avoids redundancy, though a more structured layout (e.g., bullets) could improve scanability.

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 (two modes, multiple parameters), the description covers key aspects: what is returned, depth, direction, and path constraints. Since an output schema exists, it doesn't need to detail return format. However, it lacks information on edge cases (e.g., empty projects, invalid symbol) and performance implications, leaving minor gaps.

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

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

Schema description coverage is 0%, so the description is the sole source of parameter meaning. It thoroughly explains 'mode' with its two values, defines 'symbol' as the constant to trace, clarifies 'direction' as downstream/upstream, and explains 'project_dir' with the allowed_paths constraint. This adds substantial value beyond the raw schema.

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

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

The description clearly states the tool's function: listing .scad files and tracing constant dependency graphs. It specifies the two modes (files, trace) and distinguishes the resource and actions. However, it is dense and might be better split, but it is unambiguous and distinct from siblings like get_libraries or check.

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

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

The description explains what the tool does and the modes, implying when to use it (for file listing or dependency tracing). It mentions the allowed_paths constraint but does not explicitly state when not to use it or compare with alternatives. It lacks a clear 'use this when' vs. sibling differentiation.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses units, coordinate frames, override semantics ('mass_g overrides purchased parts'), and output caveats ('facts only', 'no winner'). This gives an agent an accurate model of behavior beyond the bare tool name.

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

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

The description is dense and every clause adds information, with the core purpose front-loaded before the mode catalogue. It is concise for the amount of behavior covered, though a single wall of text with no line breaks or bullets makes it harder to scan than it could be.

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 21-parameter tool with no annotations and no schema descriptions, this is a strong effort: it covers units, modes, source mesh, and response formats. It is not fully complete because the model-source parameters (scad_file, scad_content, variables, include_paths) are never explained, which an agent would need to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate; it explains the meaning of most parameters (parts, mode, section_axis/offset, about_axis, points, rays, polyline, quality, response_format). However, several schema parameters are left unexplained, including scad_file, scad_content, variables, include_paths, and orientation, so the compensation is not complete.

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

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

The opening line 'Exact numbers from a model's geometry (mm)' states the tool's function with a specific resource and unit, and the mode list (model, parts, section, mass, probe, etc.) defines its scope precisely. This clearly separates measurement from visual or export tools like render or export_model.

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?

'Prefer this over judging a picture' explicitly tells an agent when to choose this tool, and the mode descriptions give direct selection criteria (e.g., use 'mass' for grams, 'section' for cut contours). It does not name sibling alternatives or state exclusions, but the contextual guidance is strong.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does this well by revealing the etag/content-hash workflow, automatic '.scad' suffixing, template branching, and workspace path restrictions. It does not detail overwrite or delete side effects, but the key behavioral traits are disclosed.

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 four dense sentences with no filler. The action list is front-loaded, and every subsequent clause adds a distinct behavioral fact: file suffix, etag, template mode, and workspace restrictions.

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 multi-action CRUD tool with no annotations, this is quite complete: it covers parameter semantics, the etag workflow, speculative template usage, and security constraints. It leaves per-action parameter requirements slightly implicit (e.g., which parameters delete or list need), but the output schema and clear prose keep the gap minor.

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

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

Schema description coverage is 0%, so the description must explain all parameters in prose. It does: action is enumerated, name includes the '.scad' suffix rule, content is the source for create/update, template defines catalog-part creation and precedence over content, and workspace covers defaults and allowed_paths. Every parameter is given meaningful semantics.

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

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

The description opens with a specific verb and resource: 'Manage .scad files in a workspace,' then enumerates the full action set: create, get, update, list, delete. This clearly differentiates it from sibling tools like render, measure, and export_model, which do entirely different things.

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 concrete usage context: it explains the template alternative for catalog parts, the default workspace behavior, and the allowed_paths restriction. It does not explicitly name sibling alternatives or state when not to use this tool, but the context is clear enough for correct selection in most cases.

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

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

With no annotations, the description carries the full burden; it discloses confidence labels, filtering semantics, top-3 result behavior, and cross-tool guidance for writing part models. It does not state read-only or discuss auth/rate limits, but as a reference tool the disclosed behavior is sufficient.

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 content is dense and informative but presented as one run-on paragraph without bullet structure; topics are packed into parentheses and examples are tacked on at the end. It is not poorly worded, but it could be much clearer with front-loaded formatting.

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 lookup tool with an output schema, the description covers a large number of topics, gives parameter examples, and provides cross-tool instructions. The main gap is the undocumented 'detailed' parameter and lack of explicit exclusion guidance, but overall the agent has enough to operate.

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 for topic, diameter_mm, shaft_mm, and bore_mm through examples, and for query by saying it filters entries. However, at 0% schema coverage, it still fails to explain the 'detailed' parameter and leaves query syntax largely implicit.

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

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

The description identifies the tool as a source of engineering reference data for 3D-printed parts, lists its topic coverage, and explains the query/topic behavior. It lacks an explicit verb like 'query' or 'lookup' and does not contrast with siblings, but the purpose is clear from the content and examples.

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 concrete usage cues, e.g. topic='fits' with diameter_mm names a hole and shaft_mm/bore_mm determines a fit class. It does not explicitly name alternatives or mention when not to use the tool, but the examples and topic list give clear conditions for use.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It openly conveys that output includes a text digest and metadata, that OpenSCAD draws a blank scene and exits 0 on failed asserts/unknown modules, that auto-fit views have no absolute scale, and that image_size impacts token usage. These are meaningful behavioral traits beyond simple function, though it does not explicitly state read-only status or rate limits, so a 4 fits.

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?

Every sentence in the description contributes substantive information—there is no fluff. However, it is one long dense paragraph with no bullet points, headers, or separation of modes, which makes it harder to parse. For a tool with 22 parameters, structured formatting would help, so it earns a 3.

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 (22 parameters, no output schema, no annotations), the description covers a large amount of core behavior: output structure, error caveats, all main modes, and many parameters. But it leaves out several parameters and does not explain the full relationship between inputs (e.g., scad_file vs scad_content, variables) or any return format details beyond the textual metadata. It is sufficient for basic use but not exhaustive.

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 add meaning to many parameters: views defaults and choices, section expression syntax, parts structure, compare mechanism via variables_after/scad_content_after, grounded scale, annotate contents, look_at forms, callouts, quality values, and image_size token estimate. However, it omits several parameters such as camera_up, include_paths, color_scheme, and camera_target, leaving them to inference, so a 4 is appropriate.

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

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

The description states the tool produces images of a model with a text digest and metadata, and enumerates the main modes (views, section, parts, compare). It is specific about the resource and output format, but it does not explicitly mention how it differs from siblings like export_model or model, so it loses a point for lacking sibling differentiation.

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

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

The description gives within-tool guidance on when to use different modes and parameters (e.g., grounded=true for orthographic views, compare for before/after), but it never addresses when to choose render versus an alternative sibling tool. There is no mention of alternatives or exclusions, so cross-tool usage guidance is absent.

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 numeric precision (6 significant digits), scope behavior, and the boundary 'No geometry is evaluated.' It does not explicitly state whether the tool is side-effect-free or mention error handling, but it covers key execution behaviors.

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

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

Four sentences with no filler. The core purpose leads, followed by scope context, a precision note, and a boundary statement. Every sentence earns its place.

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

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

For a tool with five parameters and no annotations, the description does not fully document the roles of variables and include_paths, nor does it mention error behavior or security implications. The output schema covers return types, but the input-side gaps make it only adequately complete.

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

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

Schema coverage is 0%, so the description should compensate for all parameters. It explains the role of scad_content/scad_file and implies expressions, but says nothing about variables (how they map into expressions) or include_paths (what they resolve). This leaves two of five parameters semantically underdocumented.

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 'Evaluate OpenSCAD expressions and return typed values' – a specific verb and resource with a clear list of result types. It also explicitly states 'No geometry is evaluated,' which differentiates it from sibling tools like render and measure.

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 explains when to pass scad_content/scad_file versus running standalone, which is useful context. However, it does not name alternative tools or explicitly state when not to use this tool, leaving the agent to infer exclusion from sibling 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?

The description discloses important behavioral details beyond the schema: 'valid' is false whenever an ERROR was reported regardless of OpenSCAD exit code; syntax mode returns errors/warnings/echo_output/hints/unresolved_includes with locations; geometry mode reports specific mesh findings with numbers; predicates mode re-runs per sweep value and reports first failure and crossing; includes mode includes a BOSL2 lint with autofix behavior. This is substantial behavioral context, though it does not cover all edge cases (e.g., exact output shape, error handling for invalid mode values).

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

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

The description is dense and structured as a mode-by-mode list, which is appropriate for a multi-mode tool. It front-loads the core behavior ('valid' is false on ERROR) and then each mode gets a compact explanation. It is longer than a typical description, but the complexity of the tool justifies the length; every sentence adds information.

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

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

The description covers the main modes, their outputs, and key parameters, and an output schema exists to define return values. It does not explicitly state prerequisites (e.g., whether scad_file or scad_content is required), nor does it detail all parameter interactions (e.g., how variables interact with predicates). However, for a tool with 10 optional parameters and an output schema, the description 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?

Schema description coverage is 0%, so the description carries the full burden of explaining parameters. It explains mode values, sweep, predicates, autofix, profile, orientation, and measure(mode=printability) facts. It does not explicitly explain scad_file, scad_content, variables, or include_paths, but the mode descriptions imply their roles (e.g., includes mode resolves include/use/import/surface references). Given 10 parameters and 0% schema coverage, the description compensates well but not completely.

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

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

The description opens with a clear verb-resource pair ('Check a model') and then enumerates five distinct modes (syntax, geometry, predicates, includes, printability), each with a specific purpose. This distinguishes validate from siblings like check_openscad, scad_eval, export_model, and measure by showing it is a multi-mode model checker.

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 each mode does and when it would be relevant (e.g., 'syntax' for fast parse/geometry-free checks, 'geometry' for mesh export findings, 'printability' for DFM rules). It does not explicitly name sibling tools as alternatives or state when not to use validate, but the mode breakdown gives clear context for selecting the right mode.

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