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., "@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.
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.
Tool | Input | Backend | Network |
| dimensions JSON (outer/inner diameter, height, thread pitch/starts/depth) | CadQuery (Python, local subprocess) | none |
| hole/cavity geometry JSON — circle, rectangle, stadium (slot), polygon, or freeform/organic outline, uniform or tapered | CadQuery (Python, local subprocess) | none |
| mesh URL or base64 (STL/OBJ/PLY/GLB/OFF) | PyMeshLab (Python, local subprocess) | none (fetches |
| 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
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 startFor 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.
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.txtThread 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.
Reshvanth Yeddla
Nirlep Boddapally
Tarun
Vijay Reddy
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.
| 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It mentions deterministic CadQuery and no network call, which are helpful. However, it does not disclose error handling, performance characteristics, or any side effects. More detail would improve transparency for a complex tool.
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, information-dense sentence that efficiently captures the tool's purpose, input constraints, and key features. It is front-loaded and free of fluff, though splitting into two sentences could improve readability.
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?
Given the tool's complexity (7 params, many shape options) and no output schema, the description covers input format, shape types, deterministic behavior, and no network use. It lacks explicit output description (e.g., format or file type) and has no annotations. Fairly complete but could add more 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?
With 57% schema description coverage, the description adds value by summarizing shape types and mentioning tapered (hinting bottomShape is optional). It clarifies input format (JSON only). But many detailed constraints are left to the schema; description does not fully compensate for gaps.
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 solid plug to fill holes/cavities, lists all supported shapes (circular, rectangular, stadium, polygon, freeform), and mentions uniform or tapered options. This distinguishes it from sibling tools like caps or meshes.
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 does not explicitly state when to use this tool versus alternatives. However, sibling tool names (caps, meshes, repairs) are distinct, and the description implies JSON-only input. No explicit when-not or alternative recommendations, but the shape-specific schema descriptions provide guidance within the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses deterministic CadQuery and no network call, giving insight into reliability and offline behavior. Does not mention side effects or resource usage, but for a generation tool these are secondary.
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?
Three sentences packed with essential information: what it generates, input constraints, and behavioral traits. No wasted words, front-loaded with the main purpose.
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?
Given 8 parameters with 100% schema coverage, no output schema, and no annotations, the description covers the tool's purpose, input constraints, and behavior. Could mention return format or size limits, but overall adequate.
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% (all parameters have descriptions in schema). The description does not add per-parameter meaning beyond the high-level summary, so 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?
Description clearly states it generates a threaded cap STL/STEP from measured dimensions, specifying the output format (STL/STEP) and key features (solid closed top, skirt, helical internal threads). It distinguishes itself from sibling tools like fill, generate_visual_mesh, and repair_mesh by being for cap generation from dimensions.
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?
Explicitly mentions it takes structured JSON only and that vision/dimension extraction happens client-side before calling this tool, clarifying when to use it. No explicit alternatives or when-not-to-use guidance, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| imageBase64 | Yes | raw source image, base64-encoded |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that output is not dimensionally precise and is for visualization only. Missing details on error handling or if image is invalid, but sufficient for the tool's simplicity.
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?
Three concise sentences with no fluff: purpose, usage caveat, and next step. Front-loaded and efficient.
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?
Given the tool has only one parameter and no output schema or annotations, the description covers everything needed: what it does, when to use, limitations, and what to do with the output. Complete for the 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 100% with adequate parameter description. The tool description adds no new information about the parameter beyond what the schema provides, so baseline score of 3 applies.
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 3D mesh from a raw image via the Meshy API and returns an STL file. It distinguishes from siblings by specifying it's for visualization only and not dimensionally precise.
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?
Explicitly states when to use (visualization only) and when not to use (cap/plug requiring fit). Provides a follow-up step to feed output into repair_mesh.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behaviors: removal of non-manifold edges, hole filling, normal unification, optional remeshing, and returning base64 + summary. It lacks details on side effects or limitations like potential detail loss.
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 two sentences, front-loaded with purpose, then input/output. Every sentence adds value; no redundancy.
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?
Given 7 parameters and no output schema, the description covers core functionality and input/output well. It could elaborate on repair levels and the repair summary, but overall is sufficiently complete for a complex tool.
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?
All 7 parameters have schema descriptions (100% coverage). The tool description adds context on input sources and output format but does not significantly enhance parameter meaning beyond schema defaults.
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 repairs a 3D mesh to be manifold, watertight, and print-ready, listing specific actions. It distinguishes from siblings like generate_visual_mesh by mentioning it accepts output from that tool.
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 specifies input sources (URL from generate_visual_mesh or base64) and output (repaired STL plus summary). It implies when to use (need repair) but does not explicitly exclude scenarios or provide alternatives.
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.
v0.1.0fillgenerate_precise_capgenerate_visual_meshrepair_meshScored across 4 tools
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.
Tool names follow snake_case with a verb_noun pattern, except 'fill' which is a single verb but still clear. Overall consistent.
4 tools is a well-scoped set for the domain of generating caps, plugs, visual meshes, and mesh repair. Not excessive or sparse.
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.
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.
Geometry and CAD file metadata extraction for STL, OBJ, PLY, PCD, LAS/LAZ, glTF/GLB.
