solidworks-mcp-pro

by ANYLXB

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools target clearly distinct actions: health check, document info, creation of specific shapes, export, and review. The main overlap is between the specific creation tools and sw_create_from_spec_json, which can create the same supported types and may cause an agent to pick the wrong pathway.
Naming Consistency4/5
The sw_ prefix and verb_noun structure are used consistently, creating a readable pattern like sw_create_box, sw_export_active, and sw_review_active. Minor deviations exist with sw_health and sw_active_document_info, which omit a verb, but the overall convention is still predictable.
Tool Count5/5
Ten tools is well-scoped for a SolidWorks automation server covering health, modeling, export, and review. Each tool serves a distinct role in the workflow without unnecessary redundancy or bloat.
Completeness4/5
The tool surface covers the core workflow: health check, inspect active document, create common part types, export to standard formats, and review the result. Missing capabilities like opening/closing documents, editing existing models, or assembly support are notable but likely outside the intended focused scope.
Average 3.1/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the high-level action. It does not mention whether the tool creates a new part, saves a file, requires an active document, overwrites existing files, or returns a path or confirmation.
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 description is a single, direct sentence with no filler or redundant wording. It is concise and front-loaded, but it sacrifices useful contextual detail that an agent would need.
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 tool with four parameters, no annotations, and no parameter descriptions, the one-sentence description is incomplete. The output schema exists, so return values need not be described, but prerequisites, side effects, and parameter semantics are all missing.
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?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It does not mention shell_diameter_mm, shell_height_mm, material, or save_as_name, and adds no meaning beyond what the raw parameter names already convey.
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 description uses a clear verb and resource: 'Create a simplified vertical heat exchanger shell concept model.' This is more specific than sibling creation tools like sw_create_box or sw_create_cylinder, though the phrase 'concept model' is somewhat vague and could benefit from stating the intended use.
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?
There is no guidance on when to use this tool versus alternatives such as sw_create_cylinder or sw_create_tube_sheet. The tool name implies a vertical heat exchanger shell, but the description does not provide selection criteria, exclusions, or dependencies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must carry behavioral disclosure, but it only states that a parametric flange is created. It does not explain what document or context is affected, whether existing files are overwritten, whether the part is saved, how SolidWorks state changes, or any failure modes.
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 a single front-loaded sentence with no filler or repetition. Every word adds meaning, and it is immediately clear what the tool creates.
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 tool with nine parameters, six required, no annotations, and no schema descriptions, a one-line description is not enough. It lacks parameter relationships (e.g., bolt circle must fit within outer diameter), unit conventions, material behavior, and what happens after creation. The output schema exists but does not compensate for missing input semantics.
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?
Schema description coverage is 0%, so the description must compensate for all nine parameters. It only hints at center hole and bolt holes, leaving material, thickness, bolt count, chamfer, bolt circle diameter, and save_as_name semantically unexplained. Units are only implied by parameter names, not described.
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 description uses a specific verb ('Create') and resource ('parametric flange') and names two defining features ('center hole and bolt holes'), which clearly separates it from generic siblings like sw_create_box or sw_create_cylinder. It does not explicitly compare itself to sw_create_tube_sheet, but the flange-specific wording is enough to identify its purpose.
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?
No guidance is given about when to choose this tool over the many creation siblings (sw_create_box, sw_create_cylinder, sw_create_tube_sheet, etc.). The description only states what it does, leaving the agent to infer selection criteria from the name and brief description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It only reveals that the result is simplified and geometric; it does not state side effects such as creating a SolidWorks part, using save_as_name, requiring an active document, or behavior on invalid dimensions.
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 description is a single, grammatically clean sentence with no filler, front-loading the core action and object. It is appropriately short for stating purpose, though the brevity contributes to missing semantics elsewhere.
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?
With 8 parameters, 5 required, and no annotations, the description is insufficient. It does not explain constraints between outer_diameter, tube_hole_count, tube_pitch, and edge_margin, nor the role of material and save_as_name. The output schema covers return values, but preconditions and valid parameter relationships are undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema property descriptions cover 0% of the parameters, and the description names none of them explicitly. Terms like tube_pitch_mm, edge_margin_mm, material, and save_as_name are left entirely to inference from parameter names.
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 uses a specific verb ('Create') and names a concrete resource ('simplified tube sheet') with distinguishing geometry ('grid of tube holes inside a circular plate'). It is clearly distinct from sibling tools like sw_create_cylinder or sw_create_flange.
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?
No guidance is given about when to use this tool versus the sibling CAD-creation tools. There is no mention of prerequisites, exclusions, or alternatives; the only implied context is the tool name and the word 'Create'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It does reveal that the tool creates and saves a part, but it omits units, overwrite behavior, what 'output root' means, and any side effects or prerequisites.
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?
A single sentence that front-loads the core action and the save behavior with no filler or redundant wording.
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?
The output schema exists, so return-value documentation is not necessary, but the description is still too skeletal for a tool with multiple creation siblings, no annotations, and a 0% schema-description coverage. It lacks prerequisites, units, file-handling details, and routing guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it mentions none of the three parameters or their roles. The schema names provide some meaning, but the description itself adds no parameter-level guidance.
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 uses a specific verb-resource pair ('Create a cylinder Part') and names a distinct geometry, which differentiates it from sibling tools like sw_create_box, sw_create_flange, and sw_create_tube_sheet. It also adds the saving behavior, making the intended outcome unambiguous.
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?
There is no guidance about when to select this tool versus alternatives. With several creation siblings, the description does not state any conditions, exclusions, or references to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It only states that a model is created and lists supported types; it does not mention effects on the active document, validation behavior, failure modes, or whether the JSON spec fully replaces the direct-creation tools. This is minimal behavioral coverage.
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 description is compact and front-loaded with the core action before the supported-types list. It wastes no words, though it could use the available space for more useful guidance without becoming verbose.
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?
The existence of an output schema helps but does not compensate for the missing input-spec details for five distinct model types. The tool is more complex than a single-sentence description suggests, and an agent would likely need to fall back to trial or external knowledge.
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?
Schema description coverage is 0%, so the description must explain the single spec_json parameter. It adds that the value is a structured JSON spec and enumerates supported types, but it gives no JSON schema, examples, or required fields, leaving an agent unable to construct a valid spec for any supported type.
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 description states a clear action ('Create a model') and resource ('from a structured JSON spec'), and the supported-types list identifies the model kinds it handles. It does not explicitly contrast itself with the dedicated sw_create_* siblings, so it stops short of a full 5.
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?
The phrase 'from a structured JSON spec' implies the intended use case, and the supported types list tells the agent which model kinds are valid. However, there is no explicit guidance on when to choose this tool over sw_create_box, sw_create_cylinder, or the other dedicated creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 the save action ('save it under the output root') but omits potential behavioral details: whether the part is opened in the active document, whether it modifies current geometry, what units are expected, or what happens to existing files with the same name. No annotation contradiction exists since there are no annotations.
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 description is a single sentence that is short and efficient, no redundant words. It front-loads the core purpose ('Create a rectangular box Part') before stating the save behavior. The 0% schema coverage requires a bit more parameter detail, but the description itself is concise and well-structured.
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?
Given the tool has 4 parameters and no annotations, the description is thin. It doesn't explain what 'output root' means, how dimensions are interpreted, whether save_as_name is required or optional, or what the output schema contains (though output schema exists and might describe return values). Sibling tools suggest a family of parametric geometry creators, and this description does not situate the tool within that family.
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 0%, so the description must compensate. It explains the purpose of the tool (dimensions of a box) but doesn't elaborate on any parameter meaning beyond names like length_mm, width_mm, height_mm, and save_as_name. The description adds context that the dimensions define a rectangular box, which is the core semantics, but does not clarify units, valid ranges, or naming rules. Baseline 3 for useful but not compensatory.
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 description states a specific verb ('Create') and resource ('a rectangular box Part'), and mentions saving under the output root. It distinguishes from siblings like sw_create_cylinder by the box geometry, though it doesn't name alternative tools. The purpose is clear but the primary use of the output root is slightly unclear since save_as_name can be provided.
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?
The description provides a clear context: create a rectangular box Part and save it. It does not explicitly state when to use this tool vs alternatives like sw_create_cylinder or sw_create_flange, but the box-specific wording implies when it's appropriate. No exclusions or alternative routing are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that a summary is returned; it does not indicate whether the operation is read-only, what happens when no document is active, or what 'basic review summary' actually includes.
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 a single concise sentence with no filler or repetition. It leads with the action and names the target resource immediately, making it easy to scan.
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 zero-parameter tool with no annotations, the description is too sparse to fully support correct invocation. It leaves unclear what a review summary consists of, how it differs from sibling tools, and how the tool behaves if no document is active. The output schema helps with return structure, but the semantic gaps remain.
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 tool has zero parameters, so there are no parameter semantics for the description to clarify. The empty input schema is already complete, and the description does not need to add anything about arguments.
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 description states a clear verb and resource: it returns a basic review summary for the active SolidWorks document. However, it does not define what a 'review summary' contains or distinguish it from sibling tools like sw_active_document_info or sw_health, so it stops short of full differentiation.
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?
There is no guidance on when to use this tool versus alternatives such as sw_health or sw_active_document_info. It also does not mention preconditions like needing an active document open, leaving the agent to infer usage context from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Return information' implies a read-only operation, but it does not disclose failure behavior when no active document exists, whether it can throw an error, or what exact information is included. The lack of detail leaves important behavioral questions unanswered.
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 a single, front-loaded sentence that states the action and target with no wasted words. It is concise while still being informative enough for a simple zero-parameter tool.
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?
Given the low complexity, zero parameters, and presence of an output schema, the description is mostly complete for an information-retrieval tool. It does not explain what happens when no active document is open, but the output schema likely covers return values, and this gap is minor for a simple getter.
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 tool has zero parameters and schema coverage is 100%, so the description has no parameter meaning to add. The baseline for zero-parameter tools is 4, and the description does not need to compensate for any missing parameter documentation.
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 description clearly states a verb ('Return') and a resource ('information about the active SolidWorks document'). It is distinct from sibling tools like sw_export_active and sw_review_active, though the term 'information' remains somewhat generic without specifying which properties are returned.
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 provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites such as requiring an open document. Usage must be inferred from the tool name and generic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral transparency. It discloses the action and formats but omits important behavioral details such as output file behavior, overwrite policies, path defaults, or format-specific side effects.
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 a single, front-loaded sentence with no wasted words. It immediately states the verb and resource, then adds the essential format list, making it easy to scan and process.
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 two-parameter tool with an output schema, the description sufficiently covers the core invocation context: active document and accepted formats. It leaves save_as_name semantics and side-effect details undocumented, which is a minor gap given the tool's low complexity.
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?
The description adds meaning to the required 'format' parameter by listing valid format values, which is valuable given the schema has an unconstrained string with no enum. However, it does not explain the 'save_as_name' parameter or its null default, so parameter coverage is only partial.
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 uses a specific verb ('Export'), identifies the resource ('active SolidWorks document'), and enumerates the supported target formats. This clearly distinguishes the tool from sibling create, review, and info tools.
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?
The description clearly states the tool is for exporting the currently active SolidWorks document, which provides an unambiguous usage context. It does not explicitly name alternatives or when-not-to-use cases, but no sibling tool overlaps with this export responsibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the main behavior (reachability check) but does not mention side effects, such as whether connecting may start the server or how reachability is determined. This is minimal but not misleading; gaps remain around semantics and potential side effects.
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?
A single, clear, front-loaded sentence with no redundant words. Every word contributes to understanding the tool's purpose.
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?
The tool is simple: no parameters, and an output schema is present, so return values are documented elsewhere. The description sufficiently identifies the tool's function. A minor omission is lack of guidance on when to run the health check relative to other SolidWorks tools, but this is partially covered by usage guidelines.
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 tool has zero parameters, and the description adds useful context by identifying the target ('local SolidWorks COM server'). With no parameters to explain, baseline is high and the description is sufficient.
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?
Description uses a specific verb ('Check') and a concrete resource ('the local SolidWorks COM server is reachable'). It clearly identifies this as a health/connectivity check and distinguishes it from the create/export/review sibling tools.
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?
The description implies the tool is used to verify SolidWorks COM server availability before performing other operations, but it does not explicitly state when to use it vs. alternatives, nor does it mention workflow placement or exclusions. The usage context is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![solidworks-mcp-pro MCP server](https://glama.ai/mcp/servers/ANYLXB/solidworks-mcp-pro/badges/card.svg)](https://glama.ai/mcp/servers/ANYLXB/solidworks-mcp-pro)

Score Badge

Copy to your README.md:

[![solidworks-mcp-pro MCP server](https://glama.ai/mcp/servers/ANYLXB/solidworks-mcp-pro/badges/score.svg)](https://glama.ai/mcp/servers/ANYLXB/solidworks-mcp-pro)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ANYLXB/solidworks-mcp-pro'

If you have feedback or need assistance with the MCP directory API, please join our Discord server