Skip to main content
Glama
NejcDvorsek

SolidWorks MCP

by NejcDvorsek

add_view

Creates model, projected, section, or detail views on a SolidWorks drawing sheet with specified placement, orientation, alignment, scale, and spacing for dimensioning.

Instructions

Add a view. kind:

  • 'model': orientation 'front', 'top', 'right', 'left', 'back', 'bottom', 'iso' or '*Name'; its geometry centred on at=[x, y] (sheet mm), or beside='' on side 'right'/'left'/'above'/'below';

  • 'projected': from parent, on side (first angle), aligned with it;

  • 'section': parent cut by the plane through model point through=[x, y, z] square to model axis normal ('x'/'y'/'z'); label 'A'; flip=True looks the other way;

  • 'detail': of parent, the circle round model point center=[x, y, z] with model radius radius_mm, at scale (default about 2.5x the parent's). Placed with room for dimensions, past views in the way (gap_mm to fix the gap). scale '1:2'. A section or detail view keeps its label's name; name becomes an alias for it.

Input Schema

NameRequiredDescriptionDefault
atNo
flipNo
kindNomodel
nameNo
partNo
sideNo
labelNo
scaleNo
besideNo
centerNo
gap_mmNo
normalNox
parentNo
throughNo
radius_mmNo
orientationNofront

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.16.3

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses useful behavior such as automatic placement with room for dimensions, collision avoidance via gap_mm, label naming for section/detail views, and alias handling; however, it does not state that it mutates the active drawing, what permissions/context are required, or what is returned.

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

Conciseness4/5

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

The bullet structure is front-loaded with the core action and kind-specific details. Given 16 parameters, the density is justified, though a few phrases (e.g., orientation '*Name') are cryptic rather than concise.

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?

Covers the complex geometry and naming behavior well, but for a 16-parameter mutation tool with no annotations and no output schema, it omits prerequisites such as an active drawing context and leaves the 'part' parameter undocumented.

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 0% across 16 parameters, so the description must compensate. It explains most parameters in context: kind, orientation, at, beside/side, parent, through/normal, label, flip, center, radius_mm, scale, gap_mm, and name-as-alias; only 'part' is left unexplained.

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?

States the specific verb+resource ("Add a view") and enumerates the four view kinds with their geometric behavior. It is clearly distinct from list_views/edit_view, though it does not explicitly name those siblings as alternatives.

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?

Explains when each kind is appropriate (model, projected, section, detail) and how placement works, but gives no broader when/when-not guidance, no prerequisite that a drawing/document must exist, and no explicit alternative for modifying an existing view.

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