Skip to main content
Glama
dsh18235538266-crypto

onshape-mcp-codex

list_entities

Enumerate every face, edge, and vertex in a Part Studio with stable IDs and readable descriptions so you can reference exact geometry in sketches, fillets, or mates.

Instructions

Enumerate every face, edge, and vertex of every body in a Part Studio with deterministic IDs you can drop into subsequent feature payloads. Each entity has a human-readable 'description' like 'plane / outward +Z / origin (0.0,0.0,15.0) mm' or 'cylinder / radius 5.00 mm / origin ... mm' so you can pick the right one by reading rather than geometric reasoning. Call this after ANY feature that creates or modifies bodies, before sketching on a face, filleting an edge, mating to a face, or otherwise referencing picked geometry. IDs (JHK, JNC, JHl, ...) are the 'deterministicIds' you put in a BTMIndividualQuery-138 query entry.

FILTERS (all optional; prune BEFORE serialization so responses stay small on complex parts): geometry_type (PLANE/CYLINDER/LINE/ARC/...), outward_axis (+X/-X/+Y/-Y/+Z/-Z), at_z_mm + at_z_tol_mm (faces pick by origin Z; edges pick by midpoint Z), radius_range_mm ([min,max] mm; cylinders/arcs/circles), length_range_mm ([min,max] mm; edges only). The response echoes filters and reports both original_counts and filtered_counts per body so you can see how much pruning happened.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
atZmmNoZ cut in mm. Keep only faces whose origin Z (planar) is within `atZtolMm` of this value, and edges whose midpoint Z is within tolerance.
kindsNoSubset to return; defaults to all three.
atZtolMmNoTolerance around atZmm in mm; default 0.5.
bodyIndexNo0-based body index to limit output. Omit for all bodies.
elementIdYesPart Studio element ID
documentIdYesDocument ID
outwardAxisNoFace filter: keep only faces whose body-outward normal is this world axis. Falls back to `normal_axis` for faces the FS probe couldn't evaluate.
workspaceIdYesWorkspace ID
geometryTypeNoCase-insensitive type filter. For faces: PLANE, CYLINDER, CONE, TORUS, SPHERE, B_SURFACE. For edges: LINE, CIRCLE, ARC, B_CURVE. Entities without the named type are pruned.
lengthRangeMmNoEdges only: [min_mm, max_mm] inclusive edge length.
radiusRangeMmNo[min_mm, max_mm] inclusive. Keeps only entities with a radius in range (cylinders/cones/tori for faces; circles/arcs for edges).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the burden of explaining behavior. It discloses deterministic IDs, human-readable entity descriptions, optional filters that prune before serialization, and that the response echoes filters plus original/filtered counts. It stops short of explicitly stating that the operation is read-only or non-mutating, but the overall behavior is well characterized.

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?

The description is dense but well organized: purpose, entity description format, usage timing, ID semantics, then a clearly labeled FILTERS section. Every sentence contributes either operational guidance or output clarification, and the front-loading of purpose and timing makes it easy for an agent to decide quickly.

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?

Given 11 parameters, no output schema, and no annotations, the description covers the essential context: what the tool returns, how to use the IDs, when to call it, how to filter, and what the response reports. It leaves little ambiguity for correct invocation or interpretation.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining filter intent ('prune BEFORE serialization so responses stay small on complex parts'), mapping filter names to entity types, and clarifying that the response reports original_counts and filtered_counts per body, which is not in the schema.

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 opens with a precise verb-resource pair: 'Enumerate every face, edge, and vertex of every body in a Part Studio' and immediately ties it to deterministic IDs usable in downstream features. It clearly distinguishes this from siblings like get_parts or get_body_details by focusing on geometric entity enumeration and query IDs.

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 gives explicit when-to-use guidance: 'Call this after ANY feature that creates or modifies bodies, before sketching on a face, filleting an edge, mating to a face, or otherwise referencing picked geometry.' It does not name alternative tools or exclusion cases, but the temporal workflow context is strong and actionable.

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