Skip to main content
Glama

Section View

section_view

Slice a solid with a plane to reveal its internal cross-section, returning the cut area, wire counts, and bounding box. Optionally emit the section outline as a new object for rendering or export.

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.8/5.0
Behavior5/5

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

The description goes well beyond the annotations by stating 'Does not modify the input geometry,' describing side effects when emit_profile is True, warning that it raises if the plane misses the shape, and documenting edge-case return values such as wire_count=0 and bbox=None. This is substantial behavioral detail not present in the annotations or schema.

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

Conciseness5/5

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

Although long, the description is tightly structured: purpose first, then units, then detailed parameter semantics, then non-destructive behavior and a complete return dict. Every sentence adds operational value, and the parameter ordering mirrors the schema.

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?

With no output schema, the description fully documents the return structure, including conditional fields, units, and the miss case. It also covers parameter interactions, failure behavior, and document side effects, making the tool safe and callable without external documentation.

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 carries the full burden, and it delivers: every parameter is explained with units, defaults, valid values, and behavioral meaning. Offset includes a concrete example, plane explains FreeCAD normals, and emit_profile/name detail exactly when and how they take effect.

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

Purpose5/5

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

The description states a specific verb (cut), a resource (a solid), and the output (cross-section), then clarifies it measures the cut area/extent and can optionally emit the section outline. This clearly distinguishes section_view from drawing-oriented siblings like add_section_view by framing it as the way to 'see inside' a part and get measurable section data.

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?

The description explicitly positions this tool as 'the best way to see inside a part blind' and explains when emit_profile is useful for rendering/export. It provides clear context for choosing the tool, though it does not name alternative tools or state explicit when-not-to-use conditions.

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