Skip to main content
Glama
dsh18235538266-crypto

onshape-mcp-codex

create_sketch

Creates an Onshape sketch by defining geometry with coordinates or constraints, supporting lines, circles, arcs, and rectangles.

Instructions

Create ONE sketch feature atomically. Two surfaces in one tool:

Coordinate-first (legacy, for simple sketches): pass entity dicts without id and no constraints. The builder hand-computes positions from your coordinates. Fast for 1–3 primitives where you already know where everything goes.

Constraint-first (for drawing transcription): give each entity a user-level id, list real-world constraints between them, and let Onshape's solver resolve positions. This is how the UI works and how engineering drawings are specified.

Sketch location: pass either plane (Front/Top/Right) or faceId (from list_entities or the feature_id of a create_offset_plane). faceId wins when both are given.

Coordinate-first entity types

rectangle: {type, corner1:[x,y], corner2:[x,y], variableWidth?, variableHeight?} rounded_rectangle: {type, corner1:[x,y], corner2:[x,y], cornerRadius} circle: {type, center:[x,y], radius, variableRadius?, variableCenter?:[xv,yv]} line: {type, start:[x,y], end:[x,y]} arc: {type, center:[x,y], radius, startAngle?, endAngle?, variableRadius?, variableCenter?:[xv,yv]}

Constraint-first entity types (require id)

line: {type:'line', id, start:[x,y]?, end:[x,y]?, construction?} circle: {type:'circle', id, center:[x,y], radius, construction?} arc: {type:'arc', id, center:[x,y], radius, start_angle?, end_angle?, short_arc?, construction?} — short_arc defaults true: if CCW sweep > 180° the builder silently swaps endpoints so the arc goes the short way (matches Onshape UI's three-point-arc default). Set false for the explicit long-way case. point: {type:'point', id, at:[x,y]?, construction?}

Circle / arc SEEDS (center + radius) are required even when a DIAMETER or RADIUS constraint will drive the final value — Onshape's solver needs a starting guess. Line start/end are optional; seed to [0,0] when omitted and let COINCIDENT / TANGENT constraints pull endpoints into position.

Constraints (constraint-first surface only)

Each item: {type, entities?:[id,...] | entity?:id, value?, direction?}. Entity refs are ids, optionally with a sub-point suffix: line.start, line.end, circle.center, arc.center Supported types: Entity-ref only: HORIZONTAL, VERTICAL (LINES ONLY — not points), COINCIDENT, TANGENT, CONCENTRIC, PARALLEL, PERPENDICULAR, EQUAL, MIDPOINT Dimensioned: DIAMETER, RADIUS, DISTANCE (add direction: HORIZONTAL|VERTICAL|MINIMUM), ANGLE (value in degrees by default — string "90 deg" / "1.57 rad" for explicit units) Binary pair: OFFSET (offset entity + master — pair it with a DISTANCE constraint on the same two for the offset length) Aliases: HORIZONTAL_DISTANCE → DISTANCE(direction=HORIZONTAL), VERTICAL_DISTANCE → DISTANCE(direction=VERTICAL), LENGTH → DISTANCE(direction=MINIMUM) (for line-length or slot end-to-end dimensions). POINT_ON is NOT a separate type — use COINCIDENT with a point sub-ref.

Pinning to the sketch origin

There is no magic origin keyword. To anchor geometry to the sketch plane origin (prevents drift on parametric resize), add a point entity at [0,0] and COINCIDENT to it: entities: [{id:'origin', type:'point', at:[0,0]}, ...] constraints: [{type:'COINCIDENT', entities:['hub.center', 'origin']}, ...] This gives you a sketch-local anchor the solver treats as fixed.

Bare numbers are mm; pass strings like "10 mm" / "0.5 in" for explicit units.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoSketch nameSketch
planeNoStandard datum plane. Defaults to Front if neither plane nor faceId is given.
faceIdNoDeterministic ID of an existing face (from `list_entities`). Mutually exclusive with `plane`; wins if both given.
entitiesYesMixed list of sketch primitives. Presence of `id` on an entity switches to the constraint-first surface (single-entity circles / arcs / lines + solver-driven positions). See tool description for per-type fields.
elementIdYesPart Studio element ID
documentIdYesDocument ID
constraintsNoConstraint-first sketch solver directives. Each item: {type, entities?:[id,...] | entity?:id, value?, direction?}. See tool description for supported types + entity-ref syntax.
workspaceIdYesWorkspace ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries full behavioral burden and succeeds: it discloses atomicity, faceId precedence, silent short_arc endpoint swapping, required circle/arc seeds, unit handling, constraint aliases, the absence of a magic origin keyword, and the origin-pinning pattern. These are exactly the non-obvious behaviors an agent needs.

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 long, but its length is earned by the tool's complexity. It is well-structured with headers, bullets, and examples, and front-loads the most important decision first: which sketch-creation surface to use. Every section addresses a real invocation concern.

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 highly complex tool with 8 parameters, no output schema, and no annotations, the description covers all invocation-relevant details: entity shapes, constraint formats, units, gotchas, origin anchoring, and mode selection. The only minor omission is an explicit statement of the return value, but this does not undermine completeness for correct invocation.

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?

Although the schema already has 100% parameter-coverage, the description vastly expands meaning: per-type entity field schemas, sub-point entity refs, constraint type semantics, dimension value units, direction enums, and alias mappings. The schema only names parameters; the description explains how to use them correctly.

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 specific verb and resource: 'Create ONE sketch feature atomically.' It clearly distinguishes this general sketch-creation tool from the single-primitive sibling tools (create_sketch_rectangle, create_sketch_line, etc.) by covering all entities in one feature, and from edit_sketch by being a create operation.

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 clear usage context for both modes: coordinate-first is 'for simple sketches' and constraint-first is 'for drawing transcription.' It also specifies plane vs faceId selection and precedence. However, it does not explicitly call out when to use the single-primitive sibling tools instead, so it stops short of full alternative routing.

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