Skip to main content
Glama
nesso-labs

spaceclaim

by nesso-labs

select_faces

Read-only

Find faces in a body by normal, radius, surface type, area, or extreme position instead of guessing IDs.

Instructions

Find faces by geometry instead of guessing ids (top face, all Ø8 holes ...).

Input Schema

NameRequiredDescriptionDefault
bodyYesBody id or unique name.
normalNoPlanar faces whose outward normal points this way ("Z", "-X" or [x, y, z]), within normal_tolerance degrees.
radiusNoCylinder/cone/sphere radius.
extremeNoOf the matches, keep those whose centre is furthest along this direction, e.g. max_z = the top face(s).
max_areaNo
min_areaNo
surface_typeNoKeep only this surface type.
normal_toleranceNo
radius_toleranceNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and closed-world scope, so safety is covered. The description adds that selection is geometry-driven rather than id-driven, but says nothing about whether multiple filters are combined as AND, what happens with zero matches, or how results feed downstream operations.

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?

A single front-loaded sentence with no waste, and the geometry-over-ids differentiator leads. It is arguably too terse for a 9-parameter filter tool, but nothing is padded.

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

Completeness3/5

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a 9-parameter boolean-style filter with only 56% schema coverage, the description omits how filters compose and what tolerance parameters mean, leaving meaningful gaps.

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

Parameters3/5

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

Schema coverage is 56%, and the description's examples implicitly map to parameters ("top face" → extreme=max_z, "Ø8 holes" → radius + surface_type). That adds some intuition, but min_area/max_area, normal_tolerance and radius_tolerance get no explanation in either place, and the filter-combination semantics are unstated.

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?

States a specific verb and resource ("Find faces") and contrasts the approach with id guessing, with two concrete examples ("top face, all Ø8 holes"). It is clearly distinguishable from select_edges by resource, though it doesn't name that sibling.

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

Usage Guidelines3/5

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

The phrase "instead of guessing ids" implies when to prefer this tool over id-based selection, which is useful. But there is no explicit when-to-use/when-not guidance and no mention of select_edges or follow-up tools like pull_faces.

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