Skip to main content
Glama
Sign In
CAD-CAE-Agent SolidWorks MCP Server

CAD-CAE-Agent SolidWorks MCP Server

by caoguanqiu1-alt
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

auto_center_marks

Automatically insert centre marks on circular features in a SOLIDWORKS drawing view. Specify view name and feature types (holes, slots, fillets) to mark; returns before/after counts.

Instructions

Auto-insert centre marks on circular features in a drawing view.

Runs SolidWorks' automatic centre-mark insertion for the named view. The API does not report how many marks it added, so the response gives the view's centre-mark count before and after and the delta. A run that added nothing is still a success — the view may have no un-marked holes.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "input_data": "<input_data>"
    },
    "name": "auto_center_marks"
  }
}

Input Schema

NameRequiredDescriptionDefault
input_dataYesThe view and which feature types to mark.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden, and it does real work: it discloses that the API reports no count, that the response returns before/after centre-mark counts and the delta, and that a zero-delta run is still a success rather than an error. It stops short of noting that this mutates drawing data (relevant given the undo sibling) or any permission/document-state requirement.

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?

Front-loaded with the action in the first sentence, then uses the remaining lines only for non-obvious behavior (count reporting, zero-delta success). No sentence is filler and the important caveat is stated rather than buried.

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?

An output schema exists, so return-value documentation is technically redundant, but the explicit before/after/delta explanation is a useful disambiguation of a non-obvious result shape. Combined with clear mutation intent, the definition is nearly complete; only document-state or permission prerequisites are unstated.

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 100%, so the nested view_name, mark_holes, mark_slots and mark_fillets fields are already documented, including defaults. The description adds no syntax, format, or default information beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource: 'Auto-insert centre marks on circular features in a drawing view' and reinforces it with the implementation note about SolidWorks' automatic insertion for the named view. This is clearly distinguishable from siblings like auto_dimension_view, add_annotation, or auto_dimension_view without opening any schema.

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 implied by the operation itself (call it when a drawing view needs centre marks), but the description never states when to prefer this over manual annotation tools such as add_annotation, nor any prerequisite like an active drawing document being open. No explicit alternatives or exclusions are given.

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