Frameworks & Eval · Reviewed 2026-07-29
jupytercad-mcp
FADING · 66/100
A precise, honestly-scoped MCP server for JupyterCAD — every tool enumerated, nothing oversold — carried by one maintainer with twenty stars and no release since October 2025.
Visit jupytercad-mcp →This is a small piece of work that does the unglamorous things right. The package documents all eighteen of its tools by name and effect — add_box, add_cone, cut, fuse, chamfer, fillet, set_visible, set_color and the rest — so a developer knows the exact surface before installing anything. That is rarer than it should be among MCP servers, where 'controls X with natural language' frequently stands in for an actual tool list. Both stdio and streamable-http transports are documented with the precise command for each, the licence is a clean Apache-2.0, and a runnable end-to-end example against the OpenAI Agents SDK is provided along with optional MLflow tracing and an interactive REPL mode. Nothing here is overclaimed: the description is 'an MCP server for JupyterCAD that allows you to control it using natural language', and that is exactly what the tool list delivers. The bounded tool surface is also a genuine security property — this server can add a torus or apply a fillet, and it cannot execute arbitrary code, which is a materially different risk profile from its larger cousins in the same space. What we cannot support is a claim of durability. Twenty stars, four forks, a single maintainer, one open issue, and a most-recent release dated 7 October 2025 — roughly nine and a half months before this review — is a project that works but is not visibly moving. No tests, CI or reliability evidence appears on the captured surface, and the dependency on JupyterCAD narrows the addressable use to a specific CAD workflow inside JupyterLab. For a hobby or research pipeline where the author is reachable, that profile is fine. For anything load-bearing, adopt it the way you would adopt any single-maintainer dependency: read the source, and expect to maintain it yourself.
Why FADING
FADING (66) is a continuity signal, not a quality judgement on the code. The engineering that is visible is good: all eighteen tools are individually documented, both transports are specified with exact commands, the licence is clean Apache-2.0, and a runnable example is shipped. What pulls it below STEADY is durability evidence — 20 stars and 4 forks, a single maintainer, and no release since 7 October 2025 (~9.5 months at review), with no tests, CI or reliability signal on the captured surface. A tool with a bounded, well-specified surface that has stopped moving is exactly what this tier is meant to describe.
What it does well
- Documents all eighteen tools individually by name and effect — no hand-waving about capability
- Specifies both stdio and streamable-http transports with the exact command for each
- Clean Apache-2.0 licence, declared and verified on the PyPI project page
- Ships a runnable end-to-end example against the OpenAI Agents SDK, plus optional MLflow tracing
- Bounded tool surface with no code-execution path — a materially smaller blast radius than comparable 3D/CAD MCP servers
- Honest scoping: the description matches exactly what the tool list delivers, with no overclaim
What it fails at
- No release since 7 October 2025 — roughly 9.5 months stale at time of review
- Very low adoption: 20 stars, 4 forks, single maintainer
- No tests, CI status or reliability evidence on the captured surface
- Narrow applicability — requires JupyterCAD inside JupyterLab
- No documented versioning or maintenance commitment
- Example client is coupled to the OpenAI Agents SDK, with no vendor-neutral quick start shown
Red flags
- No release in ~9.5 months against a single-maintainer, 20-star project — continuity risk should be assumed rather than discounted for any load-bearing use.
Best for
- Researchers and hobbyists driving JupyterCAD conversationally from an LLM agent
- Teams that need a bounded, auditable CAD tool surface with no arbitrary code execution
- Educational settings demonstrating MCP against a real desktop application
- Developers comfortable reading and maintaining a small single-maintainer Apache-2.0 dependency
Not recommended for
- Production pipelines requiring an active maintenance and release cadence
- Teams without JupyterCAD/JupyterLab already in their workflow
- Anyone needing tests, CI evidence or a support path before adoption
- Users wanting broad 3D capability — the tool surface is deliberately primitive-and-boolean only
Compared to
-
ahujasid-blender-mcp
bounded-auditable-tool-surface
Both drive a desktop 3D/CAD application over MCP. Blender MCP is much broader — six documented AI clients, asset libraries, generative-mesh backends — but exposes arbitrary Python execution. jupytercad-mcp is narrower and quieter, with a fixed, fully-enumerated tool surface and no code-execution path. Choose Blender MCP for capability; choose this for a bounded, auditable blast radius.
Agent relevance
CLI MCP Behavioral-testable
Native MCP server launched via uvx, with stdio as the default transport and streamable-http documented as an alternative. Eighteen tools are individually enumerated, so an agent can reason about the exact action space before calling — and because there is no code-execution tool, the blast radius is fully bounded by that list. A working OpenAI Agents SDK client is included as a reference integration.
Agent-friendly score: 8/10
What we saw
1 screenshot captured by the Hlido engine during the reviewed run (run-c77bc46267ac1c2e-pypi-org). Our own captures — not vendor marketing material.
Evidence
scorecard.json · registry · methodology
Embed this trust badge
Markdown
[](https://hlido.eu/check/?agent=asmith26-jupytercad-mcp)HTML
<a href="https://hlido.eu/check/?agent=asmith26-jupytercad-mcp"><img src="https://hlido.eu/badge/asmith26-jupytercad-mcp.svg" alt="Hlido trust score"></a>