Skip to main content
Glama
MatteoBaisini

solidworks-mcp

sketch_rectangle

Draws a rectangle in an open SolidWorks sketch by specifying center coordinates and width/height in millimeters.

Instructions

Draws a rectangle in the open sketch, given centre and size (mm).

Input Schema

NameRequiredDescriptionDefault
width_mmYesRectangle width in mm
height_mmYesRectangle height in mm
center_x_mmNo
center_y_mmNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already disclose readOnlyHint=false, destructiveHint=false, openWorldHint=false, and idempotentHint=false, so the safety profile is covered. The description adds the useful operational constraint that drawing happens inside the currently open sketch, but it says nothing about where the geometry lands on the sketch plane, what happens if the region already has geometry, or the units assumption for the center coordinates when only width/height are documented.

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?

A single sentence with zero filler, front-loaded with the action and resource. Nothing in it is redundant with the schema or annotations.

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 the tool has only four flat numeric parameters. What is missing is behavioral detail the description should carry: it doesn't state that a sketch must already be open in a specific way, what happens on failure, or how the two undocumented center coordinates are interpreted.

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 description coverage is only 50%: width_mm and height_mm are documented in the schema, while center_x_mm and center_y_mm have neither a description nor an obvious meaning beyond their defaults of 0. The description's '(given centre and size (mm))' confirms the unit system for all four arguments and legitimizes the two undocumented center parameters, but it does not explain the coordinate origin or how the centre relates to the sketch plane.

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?

The description states a specific verb and resource ('Draws a rectangle') and names the scope ('in the open sketch') and units (mm). It contrasts implicitly with siblings like sketch_circle or sketch_line by naming the geometry, though it never explicitly differentiates itself from those tools.

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 'in the open sketch' implies the prerequisite that a sketch must be active, but there is no explicit when-to-use guidance, no mention of what to do if no sketch is open, and no reference to the sibling sketch tools (sketch_circle, sketch_line, etc.) that an agent might confuse it with.

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