How do I use 3D CAD BasePlate Generator MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@3D CAD BasePlate Generator MCP Generate a 3D printable bottle cap from this photo" 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.

3D CAD BasePlate Generator MCP

by Nirlepb

Overview Schema Related Servers Score Discussions

Python

Local

3D CAD BasePlate Generator MCP.

A NitroStack MCP server for the bottle-cap-cad workflow: turn a photo of a broken bottle cap, worn plug, or cavity into a printable replacement.

Vision/dimension extraction from the source photo happens client-side (in the MCP client, e.g. Claude) — none of these tools re-derive dimensions from pixels. generate_visual_mesh is the one exception, since Meshy infers geometry directly from the image itself.

Tools

Tool	Input	Backend	Network
`generate_precise_cap`	dimensions JSON (outer/inner diameter, height, thread pitch/starts/depth)	CadQuery (Python, local subprocess)	none
`fill`	hole/cavity geometry JSON — circle, rectangle, stadium (slot), polygon, or freeform/organic outline, uniform or tapered	CadQuery (Python, local subprocess)	none
`repair_mesh`	mesh URL or base64 (STL/OBJ/PLY/GLB/OFF)	PyMeshLab (Python, local subprocess)	none (fetches `url` if given)
`generate_visual_mesh`	raw image (base64)	Meshy image-to-3D API	HTTPS

A fill-geometry-guide MCP prompt is also registered, walking a caller through the fields fill expects.

Suggested pipeline: generate_visual_mesh (rough visual reference from a photo) → repair_mesh (make it manifold/watertight) → generate_precise_cap or fill for the actual dimensionally-accurate part → repair_mesh again if the CAD output needs cleanup after boolean operations.

Related MCP server: CAD-Query MCP Server

Setup

npm install
pip install -r requirements.txt --break-system-packages   # or your own venv
cp .env.example .env   # set MESHY_API_KEY
npm run build
npm start

For local iteration without a build step: npm run dev.

generate_precise_cap, fill, and repair_mesh shell out to a local Python interpreter (python-runtime.ts auto-detects python3/python/py, or respects a PYTHON_EXECUTABLE override in .env) — Python 3 with the packages in requirements.txt needs to be installed wherever this server runs. generate_visual_mesh only needs MESHY_API_KEY; it makes no Python calls.

Structure

3D-CAD-Modeling-using-MCP/
├── src/
│   ├── app.module.ts          # registers the four tool providers + prompt
│   ├── main.ts                 # bootstrap / entrypoint
│   ├── index.ts                # re-exports main.ts
│   ├── modules/bottle-cap-cad/
│   │   └── bottle-cap-cad.prompts.ts   # fill-geometry-guide prompt
│   └── tools/
│       ├── shapes.ts            # shared circle/rectangle/stadium/polygon/freeform zod schema
│       ├── cap.tools.ts         # generate_precise_cap
│       ├── fill.tools.ts        # fill
│       ├── repair.tools.ts      # repair_mesh
│       ├── mesh.tools.ts        # generate_visual_mesh (pure TS, calls Meshy)
│       ├── python-runtime.ts    # local python3/python/py auto-detection
│       └── cad-api-client.ts    # optional HTTP client for a remote CAD API
├── cad/
│   ├── precise_cap.py           # CadQuery threaded-cap builder
│   ├── fill.py                  # CadQuery plug builder
│   └── repair_mesh.py           # PyMeshLab repair pipeline
├── package.json
├── tsconfig.json
└── requirements.txt

Notes on the current code

Thread generation: precise_cap.py builds a solid, closed-top cap with a blind bore (not a through-hole) and sweeps one or more real helical thread ridges onto the skirt's inner wall along a cq.Wire.makeHelix() path. threadStarts (1–4), threadDepth, and topThickness are optional fields on generate_precise_cap; threadPitch falls back to an approximate PCO 1810-style pitch (3.18mm, single start) when omitted. This is a parametric approximation tuned for FDM printing, not a certified thread-spec generator.
fill shapes: shapes.ts supports five top/bottom shape types — circle, rectangle (with optional corner radius), stadium (true rounded slot with semicircular ends), polygon (straight-edged, arbitrary point count), and freeform (a smooth closed spline through 6–300 traced boundary points, for organic/irregular openings). capStyle: "flush" is only implemented for circle/rectangle/stadium/freeform tops — a polygon top with flush is downgraded to none by fill.tools.ts, with a warning returned to the caller rather than failing silently.
Low-confidence inputs: both generate_precise_cap and fill accept a confidence field (high/medium/low, from the caller's own vision-based dimension extraction). A low value still generates output, but the response includes a warning recommending the dimensions be confirmed before printing.
Remote CAD API: cad-api-client.ts supports routing generate_precise_cap / fill / repair_mesh over HTTP to a CAD_API_URL instead of spawning Python locally, for hosting environments without a Python runtime. This repo does not currently include the server-side counterpart (no api/ directory) — CAD_API_URL / CAD_API_KEY are recognized but there's nothing to point them at yet. Leave both unset for local development; the tools fall back to the local-subprocess path automatically.
Meshy polling: mesh.tools.ts polls Meshy's image-to-3d endpoint every 3s for up to 60 attempts rather than using a webhook callback. Meshy's free tier output is CC BY 4.0 licensed — check meshy.ai/pricing for current terms before relying on it beyond a demo.
app.module.ts registers a harmless placeholder for NitroStack's OAUTH_CONFIG DI token purely to silence a noisy (but non-fatal) startup log from OAuthModule — this server has no HTTP/OAuth surface and the placeholder has no effect on transport selection.

Team

Reshvanth Yeddla
Nirlep Boddapally
Tarun
Vijay Reddy

Available Tools

4 tools

fillA

Generate a solid plug that fills a measured hole/cavity — circular, rectangular, stadium (slot), arbitrary straight-edged polygon, or freeform organic/curved (amoeba-like) boundary, uniform or tapered. Takes structured JSON only (no image); deterministic CadQuery, no network call.

ParametersJSON Schema

Name	Required	Description	Default
`fitType`	No		press_fit
`capStyle`	No		flush
`topShape`	Yes
`holeDepth`	Yes	mm
`confidence`	No	caller-supplied confidence in the extracted geometry, from client-side vision analysis	medium
`bottomShape`	No	omit if the hole is uniform (not tapered)
`toleranceMargin`	No	mm, negative = undersized for friction fit (recommended default given measurement error)

TDQS

A4/5.0

Behavior4/5

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

The description discloses key behaviors: deterministic, no network call, shape constraints (e.g., do not repeat first point for freeform). It also explains differences between stadium and rectangle with cornerRadius, and between polygon and freeform. Missing details on error handling or output format.

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 covers a lot of information, which is concise. However, it could benefit from better structure (e.g., bullet points) to improve readability given the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (7 parameters, nested shapes) and no output schema, the description lacks information about return values or file format. The schema provides good internal descriptions, but the description could offer more guidance on integrating with sibling tools.

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 main description adds minimal parameter semantics beyond the already rich schema descriptions. The schema covers most parameters with detailed explanations (e.g., stadium vs rectangle, freeform usage). The description's contribution is marginal, so baseline 3 is appropriate.

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 generates a solid plug to fill holes/cavities, lists all supported shapes (circular, rectangular, stadium, polygon, freeform), and specifies it's deterministic CadQuery without network calls. This sufficiently distinguishes it from sibling tools like caps and meshes.

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 implies usage contexts by stating it takes structured JSON (no image) and is deterministic. However, it does not explicitly state when to use this tool over siblings or when not to use it, though the sibling tool names give some differentiation.

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

generate_precise_capA

Generate a threaded cap STL/STEP from measured opening dimensions: a solid closed top with a skirt carrying real helical internal threads (swept, not just a bore). Takes structured JSON only (no image) — vision/dimension extraction happens client-side before this is called. Deterministic CadQuery, no network call.

ParametersJSON Schema

Name	Required	Description	Default
`height`	Yes	mm, cap height
`confidence`	No	caller-supplied confidence in the extracted dimensions, from client-side vision analysis	medium
`threadDepth`	No	mm, radial depth the thread ridge protrudes inward from the skirt wall; omit for a 0.6mm default
`threadPitch`	No	mm, omit to fall back to a standard single-start pitch (~PCO 1810, 3.18mm)
`threadStarts`	No	number of parallel thread starts (2-3 is typical for quick-on caps); omit for a single-start thread
`topThickness`	No	mm, solid top wall thickness; omit to derive one from height (clamped to 1.2-3mm)
`innerDiameter`	Yes	mm, opening the cap must clear
`outerDiameter`	Yes	mm, cap outer diameter

TDQS

A4.4/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 burden. It states 'deterministic CadQuery, no network call,' which is helpful for safety and behavior. However, it does not disclose potential side effects (e.g., if any files are modified) or output format specifics.

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?

Three sentences, front-loaded with purpose, then constraints, then behavioral info. Every sentence adds value with no wasted words.

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 description covers the tool's purpose and constraints well, but does not specify how to choose output format (STL vs STEP) or if an additional parameter is needed. Given the lack of output schema, this is a minor 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?

Schema description coverage is 100%, so baseline is 3. The description adds meaning beyond schema by clarifying input format (JSON only, no image), and alludes to default values for parameters like threadDepth and threadStarts, enhancing understanding.

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 generates a threaded cap STL/STEP from measured opening dimensions, specifying the resource (threaded cap) and action (generate). It distinguishes from sibling tools (fill, generate_visual_mesh, repair_mesh) which have different purposes.

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 explicitly says it 'takes structured JSON only (no image)' and that vision/dimension extraction happens client-side before calling this tool, clarifying when to use it. It does not explicitly state when not to use it, but sibling context makes the distinction clear.

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

generate_visual_meshA

Generate a 3D mesh from a raw image via the Meshy image-to-3D API and return the resulting STL file directly. Use for visualization only — not dimensionally precise, so not suited to a cap/plug that needs to physically fit. Feed the output into repair_mesh before slicing.

ParametersJSON Schema

Name	Required	Description	Default
`imageBase64`	Yes	raw source image, base64-encoded

TDQS

A4.4/5.0

Behavior4/5

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

No annotations provided, description carries full burden. Discloses output is STL, non-precise, uses external API. Lacks details on permissions, rate limits, or side effects, but sufficient for core behavior.

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?

Three sentences: primary action, usage guidance, post-processing instruction. Each sentence is essential, no redundancy, front-loaded with 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?

For a simple one-parameter tool with no output schema, description covers purpose, output type, precision limitation, and next steps. Missing details on input constraints (e.g., image format) but otherwise complete.

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% for the single parameter (imageBase64). Description adds no extra meaning beyond 'raw image', so baseline 3 is appropriate.

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 explicitly states 'Generate a 3D mesh from a raw image' and specifies output as STL. It distinguishes from siblings by noting it is not suited for precision parts, contrasting with generate_precise_cap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear when-to-use ('for visualization only') and when-not-to-use ('not dimensionally precise, not suited to a cap/plug that needs to physically fit'). Also directs to feed into repair_mesh, guiding post-usage.

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

repair_meshA

Repair a 3D mesh (from Meshy image-to-3D or local CadQuery CAD) to make it manifold, watertight, and print-ready. Removes non-manifold edges/vertices, fills holes, unifies face normals, and optionally remeshes for clean topology. Accepts a URL (e.g. from generate_visual_mesh) or a raw base64-encoded mesh. Returns the repaired STL (or chosen format) as base64 plus a repair summary.

ParametersJSON Schema

Name	Required	Description	Default
`url`	No	publicly accessible URL of the mesh to repair (e.g. from generate_visual_mesh)
`stlBase64`	No	raw mesh file (STL/OBJ/PLY) encoded as base64, for locally-generated meshes
`inputFormat`	No	file format of the incoming mesh; used when writing the temp input file	stl
`repairLevel`	No	how extensively to repair the mesh; see field description for details	standard
`outputFormat`	No	format for the repaired output mesh	stl
`targetFaceCount`	No	target face count for remeshing pass (aggressive only); 0 = skip remesh
`holeSizeThreshold`	No	max hole perimeter in faces to auto-fill; ignored for repairLevel conservative

TDQS

A4.3/5.0

Behavior4/5

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

Details repair actions (removing non-manifold edges, filling holes, unifying normals, remeshing). No annotations exist, so description carries full burden; covers key behaviors but omits potential downsides like quality loss.

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?

Three sentences, front-loaded with main purpose and inputs. Every sentence adds value; no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all inputs (URL, base64, format), operations, outputs (STL/base64 + summary). No output schema, but description sufficiently explains return value. Complete for a repair tool with 7 params.

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 coverage is 100%, so baseline 3. Description adds minimal extra semantics beyond schema; e.g., repairLevel options deferred to field description. Adequate but not enhanced.

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?

Clearly states repairing 3D meshes to be manifold/watertight/print-ready, with specific operations listed. Distinguishes from sibling tools (generate, fill) by focusing on repair.

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?

Describes when to use (e.g., from generate_visual_mesh or local CadQuery). Does not explicitly exclude other tools or state when not to use, but context implies repair for flawed meshes.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv0.1.0Jul 28, 2026
- First observedfill
- First observedgenerate_precise_cap
- First observedgenerate_visual_mesh
- First observedrepair_mesh

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a distinct purpose: generating threaded caps, filling cavities, creating visual meshes from images (non-precise), and repairing meshes. No overlap in functionality.

Naming Consistency4/5

Tool names follow snake_case with a verb_noun pattern, except 'fill' which is a single verb but still clear. Overall consistent.

Tool Count5/5

4 tools is a well-scoped set for the domain of generating caps, plugs, visual meshes, and mesh repair. Not excessive or sparse.

Completeness2/5

Despite the server name 'BasePlate Generator', there is no tool to generate a baseplate itself. Tools focus on caps, plugs, and mesh operations, leaving a significant gap for the intended purpose.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

kernelcad A
com.kernelcad
Agent-first CAD: editable .kcad.ts source, deterministic review, OpenCASCADE kernel.
Design Tools Developer Tools
45218
FabTally 3D-Print Slicer, Quote & DFM A
com.fabtally
Real 3D-print slicing, quoting, DFM, orientation & material/settings advisors. Free personal tier.
Payments & Billing
141
Caliper A
fit.caliper
Geometry and CAD file metadata extraction for STL, OBJ, PLY, PCD, LAS/LAZ, glTF/GLB.
Design Tools Software Architecture
102
3DLogo.io AOAuth
io.github.cottom
3DLogo.io, a browser 3D logo maker: 3D logos, 3D coins, 3D models from photos or prompts, embeds.
Design Tools Image & Video Processing
291

Related MCP Servers

OpenSCAD MCP Server
Developer Tools Autonomous Agents App Automation
jhacksman
F
license
Not graded
quality
F
maintenance
Enables users to generate parametric 3D models from text descriptions or images using multi-view reconstruction and OpenSCAD, with support for AI image generation and remote processing.
Updated a year ago (2025-03-21 18:48 UTC)
187
-
CAD-Query MCP Server
Developer Tools Software Architecture
rishigundakaram
F
license
Not graded
quality
F
maintenance
Enables conversational 3D modeling by providing CAD-Query functionality to validate parametric 3D models against criteria and export to STL/STEP formats for 3D printing and CAD applications.
Updated a year ago (2025-06-29 20:47 UTC)
18
-
gridfinity-mcp
Design Tools
zanewebb
F
license
Not graded
quality
B
maintenance
Turns natural-language requests into printable Gridfinity STL/STEP files for bins, baseplates, and drawer spacers using CadQuery.
Updated 3 months ago (2026-06-21 05:31 UTC)
-
simple-3d-modeling-mcp
Design Tools Image & Video Processing
mazzanfar
A
license
A
quality
C
maintenance
Enables to create, iterate, and export 3D models through natural language conversations with an LLM by bundling OpenSCAD via WebAssembly for zero-setup 3D modeling.
Updated 2 months ago (2026-06-24 01:20 UTC)
10
22
3
GPL 2.0

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/Nirlepb/AI-CAD-Generator-MCP'

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