cross_section_view

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds real value by disclosing the return payload (contour_count, contour_points, cross_section_area_mm2) and the fact that offset_mm overrides offset_ratio. It says nothing about behavior at out-of-range planes, empty cuts, or whether the file must already be cached, 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 first two paragraphs are well front-loaded and tight. The trailing :param: block duplicates a schema that already has 100% description coverage, so several lines do not earn their place; only the :returns: line carries non-redundant information.

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

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

There is no output schema, so the :returns: line is essential and present, which is a genuine strength. However, 'Path to STL file' is ambiguous in a toolset full of cached-model tools (cache_model, search_cached_models, list_cached_models) — the description does not say whether this is a local filesystem path or a cached model identifier, nor what happens if the plane misses the geometry.

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

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

Schema description coverage is 100%, and the :param: lines largely restate the schema text verbatim ('Axis perpendicular to the cut -- "x", "y", or "z"', 'Fractional position 0.0-1.0'). The one genuinely useful clarification is that offset_mm overrides offset_ratio, but the schema already states this too. Baseline 3 applies since nothing meaningful is added beyond the structured 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 uses a specific verb and resource ('Compute a 2D cross-section of a mesh at a cutting plane') and immediately states the mechanism ('slices the mesh perpendicular to the chosen axis') plus the outputs ('contour polygons and cross-sectional area'), which clearly separates it from siblings like analyze_mesh_geometry or inspect_mesh_view. It never names a sibling explicitly to route the agent, so it falls short of 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?

It gives a concrete usage context: 'Useful for inspecting internal geometry (e.g., wall thickness, hole placement).' That is a clear when-to-use signal. There is no explicit exclusion or named alternative (e.g., versus detect_mesh_pockets for pocket detection), so it does not reach 5.

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