F
licenseNot graded
qualityD
maintenanceMCP server that exposes CAD geometry reasoning over STEP files to LLMs, allowing natural language queries about parts, assemblies, dimensions, holes, and mass properties.
-
bottle-cap-mcp
by Reshvanth-Y
Click on "Install 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., "@bottle-cap-mcpGenerate a precise cap: diameter 28mm, height 15mm, 2 thread starts."
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.
bottle-cap-mcp
NitroStack MCP server exposing three tools for the bottle-cap-cad workflow.
Vision/dimension extraction from the source photo happens client-side
(in Claude, the MCP client) — 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 |
| dimensions JSON | CadQuery (Python — local subprocess, or remote via | none / HTTPS |
| hole/cavity geometry JSON (circle/rectangle/polygon, uniform or tapered) | CadQuery (Python — local subprocess, or remote via | none / HTTPS |
| mesh URL or base64 | PyMeshLab (Python — local subprocess, or remote via | none / HTTPS |
| raw image (base64) | Meshy API | HTTPS |
Related MCP server: build123d-mcp
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 startFor local iteration without a build step: npm run dev.
Deploying to NitroCloud (or any Node-only host)
NitroCloud's managed hosting runs this server in a Node-only container —
there's no python3 there for getPythonCommand() to find, so
fill/generate_precise_cap/repair_mesh fail with "Could not find a
working Python interpreter" if deployed as-is.
The fix: run api/server.py (a small FastAPI wrapper around the same three
CAD scripts) somewhere that does have Python — your own machine, a VPS,
Render, Railway, Fly.io, etc. — and point the NitroCloud deployment at it.
1. Run the API somewhere with Python:
# locally, for testing (tunnel with ngrok/cloudflared if NitroCloud needs to reach it)
pip install -r requirements.txt --break-system-packages
export CAD_API_KEY=<pick-a-secret>
uvicorn api.server:app --host 0.0.0.0 --port 8787
# or as a container, anywhere that runs Docker:
docker build -f api/Dockerfile -t bottle-cap-cad-api .
docker run -d -p 8787:8787 -e CAD_API_KEY=<pick-a-secret> bottle-cap-cad-api
pymeshlab's mesh I/O plugins are Qt-based and needlibgl1/libglu1-mesapresent on the host even for fully headless use — the Dockerfile already includes them, but a bare VPS/Render/Railway box may need them installed separately (apt-get install libgl1 libglu1-mesa), or/repaircalls will fail withUnknown format for load: stl.
2. Point the NitroCloud deployment at it — set these in NitroCloud's
environment variables dashboard (not just your local .env, since that
doesn't travel with the deploy):
CAD_API_URL=https://<wherever-you-ran-the-api-above>
CAD_API_KEY=<same secret as above>That's it — fill.tools.ts/cap.tools.ts/repair.tools.ts check for
CAD_API_URL at call time and switch to HTTP automatically. Leave it unset
for local NitroStudio dev and they fall back to the original local-subprocess
behavior, unchanged.
Structure
bottle-cap-mcp/
├── src/
│ ├── app.module.ts # registers the tool providers
│ ├── main.ts # bootstrap / entrypoint
│ └── tools/
│ ├── shapes.ts # shared circle/rectangle/polygon 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 api/server.py (CAD_API_URL)
├── cad/
│ ├── precise_cap.py # CadQuery threaded-cap builder
│ ├── fill.py # CadQuery plug builder
│ └── repair_mesh.py # PyMeshLab repair pipeline
├── api/
│ ├── server.py # FastAPI wrapper exposing /fill /cap /repair over HTTP
│ └── Dockerfile # standalone image for hosting api/server.py
├── package.json
├── tsconfig.json
└── requirements.txtKnown gaps (carried over from the design discussion)
Real threads— resolved:precise_cap.pynow builds a solid, closed top and cuts a blind bore (not a through-hole), and unions one or more real helical thread ridges onto the skirt's inner wall via a triangular/trapezoidal profile swept along acq.Wire.makeHelix()path (seemake_thread_solid).threadStarts(1-4),threadDepth, andtopThicknessare new optional fields ongenerate_precise_cap—threadPitchstill 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; swap incq_warehouse's generators if you need an exact standard spec (e.g. a certified PCO 1881 mating thread).Polygon flush caps:
fill'scapStyle: "flush"is implemented for circle/rectangle top shapes only. A polygon top withflushis downgraded tononebyfill.tools.ts(with a warning returned to the caller) rather than silently failing.Loft corner fillets: for tapered holes, rectangle corner radii are applied at the wire level before lofting (an approximation), since filleting a lofted solid's edges directly is more involved than filleting a simple extrusion's vertical edges.
NitroCloud deployment target— resolved: NitroCloud's managed hosting is Node-only (no Python interpreter available for theexecFilecalls). CadQuery/PyMeshLab now run behind a separateapi/server.pymicroservice, called over HTTP whenCAD_API_URLis set — see "Deploying to NitroCloud" above. Local NitroStudio dev is unaffected (falls back to the original subprocess path whenCAD_API_URLis unset).main.tsbootstrap call:NitroFactory.createMcpServer(...).listen()follows NitroStack's documented NestJS-style pattern, but the exact factory method wasn't pinned down in the source discussion — confirm against your installed NitroStack version.Meshy polling:
mesh.tools.tspolls for task completion; swap for Meshy's webhook callback in production to avoid long-held connections.
Available Tools
4 toolsfillA
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
A3.6/5.0
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
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 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.
Usage Guidelines3/5
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_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.2/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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_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.5/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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_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.2/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
4 tool updates
v0.1.0- First observed
fill - First observed
generate_precise_cap - First observed
generate_visual_mesh - First observed
repair_mesh
TDQS
A4.1/5.0
Disambiguation5/5
Each tool has a unique purpose: precise cap generation, hole filling, visual mesh creation, and mesh repair. No overlap.
Naming Consistency4/5
Three tools use 'verb_noun' pattern (generate_precise_cap, generate_visual_mesh, repair_mesh) but 'fill' deviates by lacking a prefix.
Tool Count5/5
Four tools cover the core workflows without unnecessary bloat.
Completeness4/5
Covers generation, filling, visualization, and repair; missing explicit editing of existing caps.
Maintenance
ActivitySlowing
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for Qwen Image 3 AI image generation
MCP server for AI dialogue using various LLM models via AceDataCloud
Related MCP Servers
- AlicenseAqualityAmaintenanceMCP server for Python build123d to help AIs develop and reason about 3D models and CAD3875Apache 2.0
- FlicenseAqualityBmaintenanceCAD-engineering MCP tool server for parametric modeling, DFM validation, mechanical calculations, and more. Enables code-CAD builds (build123d/CadQuery), model inspection, meshing, and mechanical calculators via MCP stdio.11-
- FlicenseNot gradedqualityBmaintenanceA local MCP server for parametric, manufacturing-focused CAD workflows using Build123d as the modeling engine and FastMCP for the protocol.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/Reshvanth-Y/Team-Automata'
If you have feedback or need assistance with the MCP directory API, please join our Discord server