Generates parametric OpenSCAD (.scad) source files and can automatically use the OpenSCAD CLI to render and compile them into watertight binary STL meshes.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gemini-cad-mcp Convert this photo of a battery cover with a quarter into a printable STL."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
gemini-cad-mcp)Model Context Protocol (MCP) server for Optical Photo-to-CAD, Parametric OpenSCAD synthesis, and 3D Printable STL generation.
This project was inspired by a community exchange in the Google Gemini Ultra Discord between Shane (@Gaming2Gamers) and Jack from Google (Gemini Support):
ShaneMKelley [G2G]: "I want to eventually be able to take a picture of a broken idk battery cover? and have Gemini be able to take the image and make a new one. [Ultra-Suggestion]"
JackFromGoogle: "Okay snapping a photo of a missing TV remote battery cover and having Gemini spit out a ready-to-print .STL file is a 10/10 [Ultra-Suggestion]—officially logging that one! 📝🔥 (Every missing remote backplate in the world is trembling right now 😂)
Until native photo-to-STL lands, a fun trick you can test right now is putting a ruler or a quarter next to the broken slot in the photo so Gemini can calculate the exact millimeter scale, and having it generate the OpenSCAD parametric code with the clip tolerances! 🛠️📐"
gemini-cad-mcp turns Jack's trick into an automated, production-grade MCP tool suite. Any multimodal AI (Gemini, Claude, Antigravity) equipped with this server can inspect a photo containing a reference coin or ruler, calculate sub-millimeter cavity dimensions, and instantly generate both:
Parametric OpenSCAD (.scad) code with tunable clearance and tolerance sliders.
Ready-to-print watertight binary STL (.stl) meshes compiled on the fly.
Related MCP server: 3D MCP Server
flowchart LR
Photo["📸 Photo with Coin/Ruler"] --> Calib["cad_reference_calibration<br/>(Calculates mm/px)"]
Calib --> Gen["cad_generate_battery_cover<br/>(or bracket, knob, spacer)"]
Gen --> SCAD["📄 Parametric .scad<br/>(Editable sliders)"]
Gen --> STL["🖨️ Binary .stl<br/>(Watertight solid)"]
STL --> Inspect["🔍 cad_inspect_stl<br/>(Manifold, grams, slicer advice)"]🪙 Optical Scale Calibration (cad_reference_calibration):
US Quarter ($24.26\text{ mm}$), Penny ($19.05\text{ mm}$), Nickel ($21.21\text{ mm}$), Dime ($17.91\text{ mm}$)
Euro 1€ / 2€, UK £1 coin
Standard ID-1 Credit Card ($85.60\text{ mm} \times 53.98\text{ mm}$)
Direct Metric/Imperial Ruler markings, or any custom millimeter reference
Automatically calculates FDM printing fit offsets (slide_fit = 0.25mm, snap_fit = 0.20mm, press_fit = 0.10mm).
🔋 Parametric Battery Cover Generator (cad_generate_battery_cover):
Solves the lost remote backplate problem.
Filleted outer shell, rear alignment retention prongs, front flexible cantilever snap-fit clip, and ergonomic thumb traction ribs.
🛠️ Universal Replacement Part Generators:
cad_generate_bracket: Structural L-brackets and flat plates with countersunk screw holes and $45^\circ$ reinforcing gussets.
cad_generate_knob: Potentiometer and appliance rotary knobs with D-shaft sockets, indicator pointer notches, and perimeter fluting.
cad_generate_spacer: Round and hexagonal bushings, standoffs, and washers with precision through-holes.
⚡ Dual-Engine Architecture (Zero External Dependencies):
Embedded Pure JS 3D CSG Engine: Generates valid, watertight, binary STL meshes directly out of the box with zero required software installations.
OpenSCAD CLI Auto-Bridge: If OpenSCAD is installed on the host system, the MCP will seamlessly use it for headless rendering and compilation.
🔍 Mesh Printability Inspector (cad_inspect_stl):
Watertight 2-manifold verification (checks for open boundary holes).
Calculates bounding box ($X \times Y \times Z$ in mm), exact surface area ($mm^2$), and volume ($cm^3$) via Gauss's divergence theorem.
Estimates filament consumption in grams (PLA, PETG, ABS) and provides slicer orientation recommendations.
Clone the repository:
git clone https://github.com/ssfdre38/gemini-cad-mcp.git
cd gemini-cad-mcp(No npm install needed! The server runs on pure Node.js stdlib with zero external npm dependencies).
In your MCP configuration file (mcp_config.json or Antigravity tool config):
{
"mcpServers": {
"gemini-cad": {
"command": "node",
"args": ["C:/Users/admin/source/gemini-cad-mcp/index.js"]
}
}
}In %APPDATA%\Claude\claude_desktop_config.json:
{
"mcpServers": {
"gemini-cad": {
"command": "node",
"args": ["C:/Users/admin/source/gemini-cad-mcp/index.js"]
}
}
}Start the HTTP & SSE server on port 18888:
npm run start:http
# or: node index.js --http
# or: node index.js --port 8080MCP SSE URL: http://127.0.0.1:18888/sse (or http://localhost:18888/sse)
Direct JSON-RPC Endpoint: http://127.0.0.1:18888/mcp
Health & Diagnostics: http://127.0.0.1:18888/health
Direct File Downloads: http://127.0.0.1:18888/download/<filename>
If the Gemini App requires a public HTTPS URL:
npx --yes localtunnel --port 18888
# Yields: https://<subdomain>.loca.lt/ssePass https://<subdomain>.loca.lt/sse into the Gemini App MCP connection field.
Run the master test suite:
npm test
# or: node test/run-tests.jsGenerate a sample TV remote battery cover in ./output:
node index.js --demoCheck host environment and OpenSCAD status:
node index.js --checkTool Name | Purpose | Key Inputs |
| Converts photo pixels to real mm using a reference object |
|
| Generates parametric remote cover ( |
|
| Generates structural L-bracket with gusset |
|
| Generates replacement knob with D-shaft socket |
|
| Generates standoff bushing or washer |
|
| Validates STL manifoldness, dimensions, and filament weight |
|
| Reports OpenSCAD CLI status and supported standards | None |
MIT © Daniel Elliott (@ssfdre38)
Checks host environment for optional OpenSCAD CLI installation, default fit tolerances, and supported optical reference objects.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. The verb 'Checks' implies a read-only diagnostic operation, and the description lists what is examined, but it does not state whether the tool modifies anything, what happens if OpenSCAD is missing, or what kind of result 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that leads with the action verb and resource, then lists three distinct checks. There is no wasted wording or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic tool, the description names the core checks, but with no output schema and no annotations, it leaves out what the tool returns and how an agent should act on the result. It also does not explain domain-specific terms like 'default fit tolerances' or 'supported optical reference objects'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, so there is no parameter information for the description to add. The baseline for a parameterless tool is 4, and the description appropriately focuses on behavior rather than input semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Checks' with a clear resource: the host environment, and enumerates three concrete subjects: OpenSCAD CLI installation, default fit tolerances, and supported optical reference objects. This clearly distinguishes it from the generation, inspection, and calibration siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a preflight/diagnostic usage context by saying it 'checks host environment', but it never explicitly states when to call this tool before the cad_generate_* or cad_inspect_stl tools, nor does it mention any exclusions. The usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a complete parametric 3D-printable battery cover (TV remote, controller, toy) with cantilever snap-fit clip, alignment retention prongs, and grip ribs. Emits both human-editable OpenSCAD (.scad) code and ready-to-print watertight binary STL (.stl).
| Name | Required | Description | Default |
|---|---|---|---|
| width | Yes | Nominal cavity width in millimeters (e.g. 33.2). | |
| length | Yes | Nominal cavity length in millimeters (e.g. 62.4). | |
| filename | No | Base filename without extension. | |
| gripRibs | No | Number of ergonomic thumb traction ridges (default: 5). | |
| tabWidth | No | Rear retention tab width in mm (default: 8.0 mm). | |
| clearance | No | Printing clearance tolerance offset in mm (default: 0.25 mm for slide-fit). | |
| clipWidth | No | Cantilever snap latch width in mm (default: 12.0 mm). | |
| outputDir | No | Directory path where .scad and .stl files will be saved. | |
| tabLength | No | Rear retention tab insertion depth in mm (default: 3.5 mm). | |
| thickness | No | Main plate wall thickness in mm (default: 1.6 mm - optimal for 0.4mm nozzle). | |
| clipLength | No | Cantilever flex arm length in mm (default: 8.0 mm). | |
| cornerRadius | No | Corner fillet radius in mm (default: 2.5 mm). | |
| hookOverhang | No | Catch tooth latch depth in mm (default: 1.2 mm). |
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 that the tool emits both .scad and .stl files and mentions the use of parametric modeling, implying customization. However, it does not disclose potential side effects like file creation or the need for permissions on output directories, nor does it state any limitations or edge cases (e.g., the tool might require certain minimum dimensions). With no annotations, this is a moderate gap, but the description adds useful context about outputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is dense but not overly long. It front-loads the core purpose and then lists features. It could be slightly more concise by removing redundant phrasing, but it is structured effectively for quick skimming. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generation tool with 13 parameters and no output schema, the description provides key context: the type of part, the features included, and the output formats. It does not explicitly explain return values (but since no output schema exists, it should), yet the mention of emitting files covers what the agent needs to know about side effects. It is complete enough for an agent to understand what the tool does, though it could benefit from noting that it returns a confirmation or file paths.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for all 13 parameters, each with a description and defaults where applicable. The description does not need to explain each parameter, but it adds value by stating that the design is parametric and lists key features (snap-fit, ribs) that map to parameters like clipWidth, hookOverhang, and gripRibs. However, it does not provide additional semantics beyond what the schema already gives, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a parametric 3D-printable battery cover, listing specific features (snap-fit clip, retention prongs, grip ribs) and output formats (.scad and .stl). It distinguishes from sibling CAD generation tools by specifying the exact part type (battery cover) and the included features. This is a specific verb+resource with clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for battery covers for TV remotes, controllers, toys) but does not explicitly state when not to use it or name alternatives. However, the sibling tools are named and the description's focus on battery covers gives clear context. It could be improved by explicitly saying 'use for battery covers, not for brackets or knobs' but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a parametric structural mounting bracket (L-bracket, flat plate) with mounting screw holes and reinforcing 45-degree gussets.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Bracket configuration. | |
| width | Yes | Bracket width in mm. | |
| filename | No | ||
| outputDir | No | ||
| thickness | No | Wall thickness in mm (default: 3.0 mm). | |
| leg1Length | Yes | Base leg length in mm. | |
| leg2Length | Yes | Vertical leg length in mm. | |
| holeDiameter | No | Mounting screw hole diameter in mm (default: 4.5 mm for M4 screw). | |
| reinforcingGusset | No | Whether to add 45-degree triangular stiffener gusset. |
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. It indicates generation but does not explain whether a file is written, how outputDir and filename are used, what the tool returns, or any side effects or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It communicates the core purpose and key configuration options efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter generation tool with no output schema and no annotations, the description is too sparse. It does not state what the tool produces or returns, how output files are handled, or how optional parameters like filename and outputDir behave, leaving an agent with incomplete operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 78%, so the schema already documents most parameters, including defaults and units. The tool description adds limited context by tying 'mounting screw holes' to holeDiameter and 'gussets' to reinforcingGusset, but it does not clarify the meaning of filename, outputDir, or the default for the type enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a parametric structural mounting bracket and names the supported configurations (L-bracket, flat plate) and key features (screw holes, 45-degree gussets). The verb-resource pairing is specific, and the bracket scope distinguishes it from sibling tools like cad_generate_battery_cover and cad_generate_knob.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'structural mounting bracket' implies the intended use case, and sibling tool names make it easy to route to this tool for bracket generation. However, there is no explicit guidance about when to choose this over other cad_generate_* tools or any when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a replacement rotary knob with D-shaft socket, perimeter fluting, and pointer indicator notch.
| Name | Required | Description | Default |
|---|---|---|---|
| height | Yes | Knob total height in mm. | |
| diameter | Yes | Knob outer diameter in mm. | |
| filename | No | ||
| outputDir | No | ||
| shaftType | No | Shaft profile (default: 'D_shaft'). | |
| dFlatDepth | No | Flat depth for D-shaft (default: 1.5 mm). | |
| knurlCount | No | Number of grip flutes around perimeter (default: 18). | |
| shaftDiameter | No | Potentiometer shaft diameter in mm (default: 6.0 mm). | |
| indicatorNotch | No | Whether to include indicator pointer notch. |
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. It only says 'generates' and lists features; it does not mention whether a file is created, what output format is produced, whether existing files are overwritten, or behavior around optional parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence communicates the tool's output and key geometric features without redundancy. No filler or repeated schema content appears.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nine parameters, no output schema, no annotations, and no usage context. The description is too brief to tell an agent what artifact is produced, how to interact with optional parameters, or when to choose this over sibling CAD generation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 78%, close to the high-coverage baseline, so the schema mostly carries parameters. The description adds some value by mapping its features (D-shaft, fluting, notch) to relevant parameters, but it does not explain the optional filename/outputDir parameters or clarify defaults beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Generates'), a specific resource ('replacement rotary knob'), and enumerates distinctive features (D-shaft socket, perimeter fluting, pointer indicator notch). This clearly separates it from sibling tools like cad_generate_bracket or cad_generate_spacer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 its siblings. There is no context such as 'use when a replacement knob is needed' or exclusions like 'for non-rotary parts use cad_generate_spacer'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a round or hexagonal standoff, spacer, or bushing with a central through-hole.
| Name | Required | Description | Default |
|---|---|---|---|
| shape | No | Cross-sectional shape (default: 'round'). | |
| height | Yes | Spacer height in mm. | |
| filename | No | ||
| outputDir | No | ||
| innerDiameter | Yes | Through-hole diameter in mm (e.g. 4.5 mm for M4). | |
| outerDiameter | Yes | Outer diameter (or across-flats for hex) in mm. |
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 what is generated but does not mention whether an STL file is produced, how outputDir/filename are used, units expected, or constraints like innerDiameter < outerDiameter. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. It adds no filler, though it could include behavioral context without much extra length. The structure is efficient but slightly under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a generation tool with 6 parameters, no output schema, and no annotations. The description explains what kind of part is generated but not how the output is delivered, what constraints exist, or what defaults apply. An agent would lack essential context to invoke it correctly, especially around file output and parameter validation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, so the schema already explains most parameters like innerDiameter and outerDiameter. The description adds minimal meaning beyond the schema, only confirming that these are through-hole dimensions for a spacer. Baseline 3 is appropriate because the schema handles the heavy lifting for the covered parameters, though filename and outputDir remain undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it generates round or hexagonal standoffs, spacers, or bushings with a central through-hole. This clearly distinguishes it from siblings like cad_generate_bracket or cad_generate_knob, which focus on other part types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives like cad_generate_bracket or cad_generate_knob. An agent must infer usage solely from the mention of standoffs/spacers, with no stated exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspects a 3D STL mesh file for watertight manifoldness, triangle count, bounding box dimensions, volume, and estimated filament consumption in grams (PLA, PETG, ABS).
| Name | Required | Description | Default |
|---|---|---|---|
| stlPath | Yes | Path to the .stl file. |
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 does disclose the full set of computed metrics, and the verb 'Inspects' implies a non-destructive read operation. However, it does not state what happens for non-watertight or malformed files (whether volume and filament estimates degrade or error) nor explicitly confirm the tool has no side effects on the file.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single ~25-word sentence that front-loads the verb and resource and packs the complete metric list with zero filler. Every element earns its place; nothing is redundant or missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must cover return values, and it does — all five computed metrics are enumerated, including material-specific filament consumption. The remaining gaps are unit specification for dimensions/volume and the result format of the watertightness check (boolean vs. issue list), which an agent would need for downstream interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — 'Path to the .stl file' fully documents the single parameter. The description adds only marginal context by clarifying it is a 3D mesh and listing what will be computed from that path, so the high-coverage baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description pairs a specific verb ('Inspects') with a specific resource ('3D STL mesh file') and enumerates the exact analysis outputs: watertight manifoldness, triangle count, bounding box dimensions, volume, and filament consumption for PLA/PETG/ABS. This unambiguously distinguishes it from its siblings, which are all generation, calibration, or system-check tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when/when-not guidance and names no alternative tools. Usage is only implied through the purpose statement — an agent can infer this tool is for validating/analyzing STL files before printing or generation — but the description never states that context or contrasts itself with the generate siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates real-world millimeters from photo pixel measurements using a reference object (US Quarter 24.26mm, Penny 19.05mm, Credit Card, or Ruler). Also calculates 3D printing fit clearances (slide-fit, snap-fit).
| Name | Required | Description | Default |
|---|---|---|---|
| pixelSpan | Yes | Pixel diameter or length of the reference object measured in the photo. | |
| customRefMm | No | Known reference dimension in mm if referenceType is 'custom_mm'. | |
| referenceType | Yes | Known reference object placed beside the part in the photo. | |
| measuredPixels | No | Optional list of features (e.g. cavity length, width, clip) to convert to millimeters. |
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. 'Calculates' correctly implies a read-only, computational operation and the fixed reference dimensions add useful context. However, it does not describe output shape/return values, how the fit-clearance mode is triggered, or behavior around optional inputs like customRefMm.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and front-loads the core conversion first. The second sentence adds the secondary capability without unnecessary detail. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should ideally explain what the tool returns; it only says it 'calculates' millimeters. The primary inputs are covered clearly, and the optional measuredPixels list is documented in the schema, but the fit-clearance feature is introduced without enough connection to the input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining that pixelSpan is measured from a photo and by supplying concrete reference constants (US Quarter 24.26mm, Penny 19.05mm), which clarify the enum values. It does not repeat schema text, though it could have mapped the fit-clearance mention to specific parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific verb, resource, and conversion type: 'Calculates real-world millimeters from photo pixel measurements using a reference object.' This clearly distinguishes it from the sibling CAD-generation and inspection tools, which do different work. The secondary fit-clearance capability is also stated explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context: use it when a photo contains a reference object and pixel measurements need to become millimeters, or when 3D printing clearances are needed. It does not explicitly list when not to use it, but the sibling tools are so different that ambiguity is unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0cad_check_systemcad_generate_battery_covercad_generate_bracketcad_generate_knobcad_generate_spacercad_inspect_stlcad_reference_calibrationScored across 7 tools
Each tool targets a distinct operation: calibration, inspection, system check, and four distinct parametric part generators. The generate tools are clearly separated by object type (battery cover, bracket, knob, spacer), leaving no ambiguity.
All tools share the consistent `cad_` prefix, and most follow a verb_noun pattern (inspect_stl, generate_battery_cover, check_system). However, `cad_reference_calibration` uses a noun_noun format instead of a verb-led name, creating a minor deviation.
Seven tools is within the ideal range for a focused CAD generation server. Each tool serves a specific function without redundancy, making the count feel well-scoped and purposeful.
The set covers the core lifecycle: calibrate from reference, generate replacement parts, and inspect the resulting STL. It lacks more generic shape generators or modification tools, but for a replacement-part-focused CAD server, the coverage is solid with only minor gaps.
Parametric 3D CAD for AI agents: build print-ready parts, check them, export STL, 3MF or STEP.
Agent-first CAD: editable .kcad.ts source, deterministic review, OpenCASCADE kernel.
Real 3D-print slicing, quoting, DFM, orientation & material/settings advisors. Free personal tier.
Turn any LLM multimodal; generate images, voices, videos, 3D models, music, and more.
