Skip to main content
Glama

section_view

Cut a solid with a datum or world plane to measure its cross-section area, wire count, and bounding box, optionally emitting the section outline as a new object.

Instructions

Cut a solid with a plane and return the cross-section it exposes. This is the best way to "see inside" a part blind: it measures the cut area and its extent, and can optionally emit the section outline as a new object for rendering/export. Units: mm (lengths), mm^2 (areas).

handle: the solid to slice (a AnkusDrive handle). plane: "XY", "XZ", or "YZ" (world datum planes) OR a datum-plane handle. World normals follow FreeCAD: XY -> +Z, XZ -> -Y, YZ -> +X. A datum handle uses its local +Z as the cutting normal. offset: shift of the cutting plane along its normal, in mm (default 0 = the plane through the world origin / datum origin). E.g. plane="XY", offset=10 cuts at z=10. emit_profile: when True, add a Part::Feature holding the section wires to the document, register it, and return its handle (raises if the plane misses the shape). Default False = measure only, no new geometry. name: object name for the emitted profile (only used when emit_profile=True).

Does not modify the input geometry. Returns a dict: plane: str (echoed), offset_mm: float (echoed), normal: [x, y, z] unit cutting-plane normal, section_area_mm2: float — total area of the closed cross-section wires, wire_count: int — number of section wires found (0 means the plane misses the shape), closed_wire_count: int — how many of those wires are closed, bbox: {min:[x,y,z], max:[x,y,z], size:[dx,dy,dz]} of the section, or None when the plane misses the shape, handle: str — handle of the emitted profile (ONLY when emit_profile=True), name: str — its FreeCAD object name (ONLY when emit_profile=True).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoSection
planeNoXY
handleYes
offsetNo
emit_profileNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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 well: it states the input geometry is not modified, that emit_profile adds a registered Part::Feature to the document, that the call raises when the plane misses the shape, and that wire_count=0 signals a miss. It also declares units (mm, mm^2) and describes the return dict field-by-field.

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

Conciseness4/5

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

The action and units are front-loaded, then parameters, then return shape — a sensible order with labelled blocks. It is long, but with no output schema and no annotations almost every line earns its place; only the exhaustive return-field listing borders on over-specification.

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

Completeness5/5

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

For a five-parameter geometry tool with zero annotation coverage, no schema descriptions, and no output schema, the description supplies everything an agent needs: purpose, parameter semantics, side effects, error condition, units, and a complete return contract.

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

Parameters5/5

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 fully and it does: every one of the five parameters is explained, including accepted plane values, the FreeCAD world normals for each plane, the semantics of a datum handle's local +Z, the meaning of offset relative to the origin, and that name is only used when emit_profile=True.

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

Purpose4/5

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

The description opens with a concrete verb+resource: 'Cut a solid with a plane and return the cross-section it exposes,' which precisely names the operation and output. It is clearly distinct from measurement siblings like bounding_box or mass_properties. However, it never differentiates itself from the sibling add_section_view (a drawing-oriented section tool), leaving an agent to guess which section tool applies.

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

Usage Guidelines4/5

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

It states a clear use context ('the best way to "see inside" a part blind') and distinguishes the two modes — measure-only (emit_profile=False) vs. emit geometry for rendering/export (emit_profile=True). No explicit exclusions or named alternatives are given, so it stops short of the top tier.

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

Deploy Server

Other Tools