Skip to main content
Glama
andrewbartels1

SolidworksMCP-python

verify_model

Validates the active part or assembly against expected dimensions, mass, volume, feature counts, and interference, then reports pass/fail checks.

Instructions

Check the active part or assembly against what you meant to build.

Call this as the last step of a build (and whenever a step looks suspicious). A modelling tool returning success does not prove the geometry is right; this reads the model back and compares it with your expectations. Give only the expectations you know; each becomes one check. With no expectations it just reports what it measured.

Units: mm, mm³ and kg. bounding_box_mm is the overall size [x, y, z] in model axes (a sketch on the Front Plane extrudes along z). Widen relative_tolerance when your hand calculation ignores fillets or chamfers, and length_tolerance_mm when measured.bounding_box_method is assembly_box (SolidWorks' assembly box can be slightly larger than the parts). Mass depends on the assigned material; without one SolidWorks uses a default density.

Each check reports expected, actual, tolerance and passed: true, false, or null when the value could not be measured (never counted as a pass). verdict is pass, fail, inconclusive (nothing failed, something unmeasured) or report_only. status stays success when the model does not match: the tool worked, the model is what failed.

Input Schema

NameRequiredDescriptionDefault
input_dataNoExpectations and tolerances. Defaults to None (report only).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.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 behavioral burden and does so thoroughly: it explains that a modelling success does not prove geometry is right, that checks report expected/actual/tolerance/passed, that null means unmeasured, and that status remains success even when the model fails. It also discloses unit, tolerance, material, and assembly-box caveats.

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?

Despite its length, the description is front-loaded and information-dense. The opening states purpose and usage immediately, then moves through expectations, units, tolerances, and result semantics without apparent filler.

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?

The tool is complex, with many optional expectations and an output schema, and the description supplies the contextual details an agent needs: which expectations to provide, tolerance behavior, unit conventions, material caveats, and verdict/status semantics. Nothing critical appears to be missing for correct invocation.

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 schema already documents each expectation field. The description adds useful semantics beyond the schema: units (mm, mm³, kg), how each supplied expectation becomes one check, and when to widen relative_tolerance or length_tolerance_mm.

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: 'Check the active part or assembly against what you meant to build.' It also explains the core mechanism — reading the model back and comparing it with expectations — which clearly distinguishes verification from creation or measurement tools.

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?

It gives clear timing guidance: call this as the last step of a build and whenever a step looks suspicious. It also explains the no-expectations behavior, but it does not name alternative sibling tools or explicit when-not-to-use conditions.

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