Skip to main content
Glama
Sign In
solidworks-mcp

solidworks-mcp

by rdolan5
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

solidworks_api_load

Destructive

Load a local vendor .tlb/.dll API library without registering it, enabling indexing and discovery of API paths for SOLIDWORKS automation.

Instructions

Index a local vendor .tlb/.dll API library without registering it; find paths with discover.

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": {
      "path": "<path>"
    },
    "name": "solidworks_api_load"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.4/5.0
Behavior4/5

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

The description discloses the key behavioral trait that registration is not performed, and that path discovery is delegated to discover. The annotations already cover destructive/read-only aspects, so the description does not need to repeat them. No contradiction with annotations.

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?

The description is one concise sentence with no filler or redundant wording. It packs the key information efficiently.

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?

For a simple single-parameter loading/indexing tool, the description provides enough context about the input and the workflow. Output/return values are not described, but an output schema is present, so this is not a significant gap.

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?

The lone required path parameter is implicitly clarified as pointing to a local .tlb/.dll API library, with discover suggested as a way to find valid paths. It could explicitly state whether the path is a file or directory, but the meaning is sufficiently inferable.

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 clearly states the tool indexes a local .tlb/.dll API library without registration, which is a specific verb and resource. It also distinguishes from sibling tools like solidworks_api_search and solidworks_discover by focusing on loading/indexing rather than searching or discovering.

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 practical guidance: use it for a local vendor library and avoid registration, and use discover to find paths. It could be more explicit about when to choose this tool over alternatives, but the context is clear enough.

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