Skip to main content
Glama
SolidWorks MCP PRO

SolidWorks MCP PRO

by U-C4N

close_part

Destructive

Closes the active part in SOLIDWORKS, optionally saving changes, to end the current part session through the native engine.

Instructions

Close part through the independent native SOLIDWORKS engine. Public geometry units are mm, degrees and kg. Inspect verified measurements and error evidence.

Input Schema

NameRequiredDescriptionDefault
saveNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.0

TDQS

C2.3/5.0
Behavior2/5

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

Annotations already flag destructiveHint=true and non-idempotent, so the agent knows this is a lossy mutation. The description adds nothing about what is destroyed, that unsaved edits are discarded, or whether the document can be reopened. Instead it talks about units and measurements, which carry no behavioral weight for a close operation.

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

Conciseness2/5

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

Three sentences, two of which are boilerplate about units and inspection that do not apply to closing a part. The relevant information (one verb) is a fraction of the text, and the padding obscures rather than front-loads the purpose.

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

Completeness2/5

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

For a destructive, non-idempotent document operation with an undocumented boolean parameter and no output schema, the description should explain the save flag's effect on unsaved changes. It omits the single thing an agent needs to call this safely, and instead supplies irrelevant unit information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is one parameter (save, default false) with 0% schema description coverage, and the description never mentions it. The description must compensate for this gap since the schema offers no explanation of what save=true does, but it does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Close part" names a specific verb and resource, so the core action is identifiable. However, the following sentences about units (mm/degrees/kg) and inspecting "verified measurements and error evidence" are unrelated to closing a document and actively muddy what the tool does. There is no differentiation from adjacent document-lifecycle siblings such as save_part or open_part.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description never says when to close a part, whether save_part should be called first, or what happens to unsaved changes. No alternative or prerequisite is mentioned despite multiple document-lifecycle siblings existing.

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