Skip to main content
Glama
danielproxd2

MCP_CAD

by danielproxd2

record_drawing_spec

Record a structured part specification from a drawing to compile feature plans for deterministic builds.

Instructions

Record a structured DrawingSpec (LEGACY/dormant spine — see docs/AUTOMATION_LANE.md).

Advisory only: does NOT mutate SolidWorks. Pins a structured part spec (the LLM's own reading, from any source) so compile_feature_plan_from_drawing_specrun_feature_plan can build it deterministically. Generating a part from a drawing is a legacy path, not the product focus (automation + reuse).

Args: source: Dict with pdf_path, page_number, crop_pdf_pts, render_path, note. interpretation: One-sentence part interpretation. archetype: One of axisymmetric_revolved, extruded_closed_profile, plate_hole_pattern, custom. dimensions: List of {name, value, units, status, source, tolerance, confidence, note}. status is grounded/derived/assumed/missing. features: List of {kind, label, tool, params, source_dimensions, confidence, note}. If tool is set, compile_feature_plan will use it directly; otherwise it emits archetype defaults. internal_features: List of {type, diameter_mm, radius_mm, depth_mm, axis, position_mm, status, note} — the dashed-line bores/grooves/threads to model. type is through_hole/blind_hole/counterbore/countersink/ groove/thread/radius_cut. radius_cut (a swept-arc / scooped cut) uses radius_mm instead of diameter_mm. verify_build_report reconciles each against the built tree to catch silently-dropped or wrong-sized features. views: Optional list of source-view notes/crops. assumptions: Assumptions explicitly chosen by the LLM/user. missing_dimensions: Required dimensions not visible in the source. confidence: Global confidence 0..10. notes: Free-form audit notes.

Returns the stored spec, warnings, expected_size_mm when inferable, and a short build recommendation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesNo
viewsNo
sourceYes
featuresNo
archetypeYes
confidenceNo
dimensionsNo
assumptionsNo
interpretationYes
internal_featuresNo
missing_dimensionsNo
Behavior4/5

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

The description clearly states the tool does not mutate SolidWorks and details the return value, including stored spec, warnings, expected size, and build recommendation. Without annotations, it provides good behavioral disclosure, though it could elaborate on overwrite behavior or error conditions.

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

Conciseness3/5

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

The description is lengthy (over 500 words) and includes some tangential details (e.g., references to AUTOMATION_LANE.md, legacy path explanation). It is structured with an Args section, but the first paragraph is cluttered and could be trimmed for better conciseness.

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 complex tool with 11 parameters and no output schema, the description covers the workflow, parameter details, and return values comprehensively. However, it lacks information on error handling or validation behavior, which slightly detracts from completeness.

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

Parameters5/5

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

With 0% schema description coverage, the description fully compensates by providing a detailed Args block for each of the 11 parameters, including allowed values for archetype and internal_features.type, and explaining the structure of nested fields like dimensions and features.

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 the tool records a structured DrawingSpec and explicitly notes it does NOT mutate SolidWorks, distinguishing it from mutation-focused siblings. However, the purpose is somewhat buried in a verbose opening about legacy/dormant spine and file references, which could be more direct.

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 mentions the tool is advisory-only and part of a legacy path, and it explicitly connects to compile_feature_plan_from_drawing_spec and run_feature_plan, giving some usage context. But it does not explicitly state when to use this tool over alternatives or provide clear exclusions, leaving some ambiguity for an AI agent.

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

Install Server

Other Tools

Latest Blog Posts

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/danielproxd2/solidworks-mcp'

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