Skip to main content
Glama
hellstein-dev

fusion-mcp

by hellstein-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

sketch_draw

Draw multiple sketch items with constraints and dimensions in one atomic call, automatically restoring the sketch if any step fails.

Instructions

Draw many sketch items, then constraints, then dimensions — one call, all or nothing (on any error the sketch is restored and details = {phase: geometry|constraints|dimensions, index, id}).

Coordinates: [x, y] sketch mm (numbers only — expressions like "w/2" are refused: draw approximately and fix exact sizes with dimensions), {"model": [x, y, z]} model mm (projected on the sketch plane; mind sketch_create's XZ pitfall), or a ref of an existing point / curve end. A point given by ref is shared (no coincident needed).

Local ids: give an item id (letters, digits, _; not origin) and later items, constraints and dimensions of THIS call can use id or id.<sub>; origin is the sketch origin point. Local ids live one call only: the result refs maps every local path to a real ref — use those refs in later calls.

Every item: {"kind", "id"?, "construction": false, ...}: | kind / mode | fields | sub-ids | | point | at | — | | line | start, end | start, end | | polyline | points (≥2), closed=false | e0..e{n-1} (edges), v0..v{n-1} | | rectangle two_point (default) | corner1, corner2 | bottom,right,top,left, bl,br,tr,tl | | rectangle center | center, corner | as two_point + center, diagonal | | rectangle three_point | p1, p2, p3 | e0..e3, v0..v3 | | circle center_radius (default) | center, radius | center | | circle two_point | p1, p2 (diameter ends) | center | | circle three_point | p1, p2, p3 | center | | arc three_point (default) | start, mid, end | start, end, center | | arc center_start_sweep | center, start, sweep (deg, + = CCW) | start, end, center | | arc tangent | from (curve end, e.g. "l1.end"), to | start, end, center | | ellipse | center, major_radius, minor_radius, angle=0 | center | | polygon | center, radius, sides 3..64, mode=inscribed|circumscribed, angle=0, constrain=true | e0.., v0.., center, circle | | spline | points (≥2 fit points), closed=false | start, end, fp0.. | | slot center_to_center (default) / overall | p1, p2, width | side0, side1, end0, end1, axis, c0, c1 | | text | text, height, corner, size=[w,h]?, font?, h_align=left, v_align=bottom | — |

constraints: [{"type": coincident (point, entity) | horizontal / vertical (line, or points [p1, p2]) | parallel / perpendicular / collinear (line1, line2) | tangent / equal / concentric (curve1, curve2) | midpoint (point, curve) | symmetry (entity1, entity2, line) | smooth (spline, curve) | fix (entity, fixed=true)}]. dimensions: [{"type": distance (line, or point1 + point2; orientation=aligned| horizontal|vertical) | offset (line, entity) | radial / diameter (curve) | angular (line1, line2) | ellipse_major / ellipse_minor (ellipse), "value": 25 (mm/deg) or "plate_w * 0.6", "parameter_name"?, "driven"=false, "text_at"?}]. A named dimension (parameter_name) can be used by later dimensions' expressions in the same call.

Returns {"sketch", "refs": {"r": {ref}, "r.bottom": {ref}, ...}, "constraints", "dimensions", "status" {fully_constrained, ...}, "profiles", "warnings"}.

Example — fully constrained 100 x 60 plate centred on the origin with a hole: sketch_draw(sketch=, items=[ {"kind": "rectangle", "mode": "center", "id": "r", "center": "origin", "corner": [50, 30]}, {"kind": "circle", "id": "h", "center": [30, 15], "radius": 4}], dimensions=[ {"type": "distance", "line": "r.bottom", "value": 100, "parameter_name": "plate_w"}, {"type": "distance", "line": "r.left", "value": "plate_w * 0.6"}, {"type": "diameter", "curve": "h", "value": 8}, {"type": "distance", "point1": "origin", "point2": "h.center", "orientation": "horizontal", "value": 30}, {"type": "distance", "point1": "origin", "point2": "h.center", "orientation": "vertical", "value": 15}]) -> status.fully_constrained = true; the plate profile has one inner loop.

Input Schema

NameRequiredDescriptionDefault
itemsYesGeometry, drawn in order
unitsNoUnit of numeric coordinates and sizesmm
sketchYesSketch ref (from sketch_create)
dimensionsNoApplied after constraints, in order
constraintsNoApplied after all items, in order
return_profilesNoAdd the current profiles to the result (false = faster)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/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 burden and does so: it discloses atomic rollback behavior on any error, the exact error payload shape ({phase, index, id}), expression refusal, point-sharing semantics for by-ref points, and the one-call lifetime of local ids. It also documents the return payload keys (refs, status, profiles, warnings).

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?

Front-loaded with purpose and atomicity, then organized into coordinates, local ids, the item table, constraints, dimensions, returns, and a worked example. Despite its length, every line carries load-bearing information for a highly polymorphic schema, and nothing is repeated verbatim from 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?

For a 6-parameter polymorphic tool with no annotations and no output schema, the description supplies everything needed: coordinate conventions, id/ref lifecycle across calls, the full kind catalogue, and an end-to-end example showing a fully constrained plate with a hole. Nothing essential for correct invocation is missing.

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 description coverage is 100%, so the baseline is 3; the description adds real value beyond the schema with a compact kind/mode/field/sub-id table, mode defaults, and the `origin`/`id.<sub>` ref grammar. It also clarifies dimension expression usage and parameter_name cross-referencing within a call, though unit behaviour of the `units` parameter is left to 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?

States a specific compound action: draw many sketch items, then constraints, then dimensions, in a single atomic call. The atomic scope ('all or nothing') and the pointer to sketch_create's XZ pitfall make the tool's identity distinct from geometry-editing siblings like sketch_constrain or sketch_offset.

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?

Clearly establishes when this tool is appropriate (batch drawing of a whole sketch in one atomic operation) and gives concrete operational rules: draw approximately because expressions in item coordinates are refused, then fix sizes via `dimensions`. It does not explicitly name when a sibling (e.g. sketch_constrain on an existing sketch) should be preferred instead.

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