Skip to main content
Glama
SolidWorks-MCP

SolidWorks-MCP

check_printability

Analyze a part for 3D printing issues: detect overhangs, islands, unsupported edges, and thin walls, then report face areas, bed contact, print height, and problem locations.

Instructions

Check the current part for 3D printing, built along up ('+z', '-y', ...).

Overhangs: downward faces leaning more than overhang_deg from vertical (90 = a flat ceiling) need support; the faces on the bed do not count. Gives the overhanging area per face (list_faces index) with its worst lean and centre, the bed contact area and the print height. Islands: each place where the print starts in the air, its height above the bed, centre and faces; a downward edge between faces too steep to overhang still needs support there. Unsupported edges: stretches of such an edge with air below, also where the rest of it rests on material (the ends of a chamfered pad's edge beside a tube), with length, height, centre and faces. With min_wall_mm (e.g. two nozzle widths) also the walls thinner than that, measured straight through the material from points spread over every face, with where each is thinnest; that stops after a minute on a detailed part, and rays then says how much it measured. A spot right beside an edge where faces meet at a sharp angle reads as thin as the wedge of material there is: that is the edge, not a wall.

Input Schema

NameRequiredDescriptionDefault
upNo+z
min_wall_mmNo
overhang_degNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.9.0

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full load and does so unusually well: it discloses a hard time limit ('stops after a minute on a detailed part'), an otherwise undocumented 'rays' counter, and an accuracy caveat that sharp-angle edges read as thin walls. It stops short of confirming that the tool is purely read-only and requires an active document.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and the body walks through outputs in a sensible order (overhangs, islands, unsupported edges, thin walls). However, sentences are run-on and grammatically tangled -- the min_wall_mm/rays sentence requires re-reading -- and there is no structural break-up for a description of this length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no annotations, so the description must convey the result shape, and it does: overhanging area per face with lean and centre, bed contact area, print height, islands, unsupported edge stretches and thin walls. Only minor gaps remain, such as the case where no active part exists and the precise shape of the returned structure.

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 0%, so the description must define the three parameters and it does: `up` gets example values ('+z', '-y'), overhang_deg gets a concrete interpretation ('90 = a flat ceiling'), and min_wall_mm gets a practical scale ('two nozzle widths'). Defaults are only in the schema, and the accepted string grammar for `up` is not fully specified.

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 opening line states a specific verb and resource: 'Check the current part for 3D printing', and scoping to 'the current part' tells an agent which part is inspected. No sibling is named or excluded, so differentiation from tools like compare_with_mesh or measure_distance is left implicit rather than stated.

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?

Usage is only implied: an agent must infer that this is the pre-fabrication sanity check. There is one genuinely useful usage hint -- supplying min_wall_mm '(e.g. two nozzle widths)' -- plus the cost warning that the wall check 'stops after a minute'. No 'do not use this when...' exclusions are given, and no prerequisites (an open/active part) are stated.

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