OCCTMCP

The Swift implementation calls OCCT directly in-process (no subprocess, no JSONL marshalling) and exposes 77 typed MCP tools that cover authoring, scene reads, mutation, introspection, construction, analysis, I/O, mesh, drawing, selection / remap, mesh-zone analysis, mesh inspection, alignment, and dimension overlays.

LLM picks a typed tool (boolean_op, transform_body, render_preview, …) → OCCTMCP runs the OCCT operation directly via OCCTSwift / Tools / AIS / Mesh → Writes BREP/STEP/PNG + manifest.json + annotations.json → OCCTSwiftViewport (optional) auto-reloads the 3D model

For novel geometry the typed tools don't cover, the LLM falls back toexecute_script: arbitrary Swift code with the full OCCTSwift API, compiled and run in-process.

77 tools, organized below. Callget_api_reference({ category: "mcp_tools" })to dump every tool's JSON Schema in one shot, useful for LLM auto-discovery. Most flows can answer "what's the volume?", "make it red", "boolean-subtract these", "render a preview", "add a dimension between these two faces", "export to STEP", and "draw this" without ever touchingexecute_script.

Signed, spatially-resolved comparison of a reconstruction against its source mesh. Wheremeasure_deviation's scalars can hide asystematicshape error (a wrong cross-section that averages out), these exposewhereandwhich waythe candidate departs. Pure-Swift rendering — no Python/matplotlib.

Which way is out?measure_deviation,deviation_histogramandsigned_deviation_heatmapshare one signed-distance engine, so they share asignModeknob. The sign of a deviation depends on which reference triangle a sample is judged against, and against anopen, thin-walledreference (a raw scan / STL skin) the nearest one is often the wrong one: a candidate flank sitting 4.5 mm inside a 2 mm wall is only 2.5 mm from the wall'sinnersurface, so that surface wins on proximity and — facing the cavity — reports+2.5 proud for a part that is 4.5 shy. Wrong side, wrong magnitude, nothing tying to flag it.signMode: "robust"(the default since v1.17.0) rejects reference triangles whose outward normal opposes the sample's own before the nearest survivor wins, recovering both figures; samples with no compatible surface in reach are reportedambiguousand withheld from the signed statistics rather than guessed.signMode: "nearest"restores the pre-v1.17 raw nearest-triangle sign, which is correct against a watertight / single-surface reference. AnambiguousFractionnear 1.0 means the reference's winding is likely inverted relative to the sampled body; where nothing has a trustworthy sign the signed figures come backnullrather than a zero that would read as "perfectly centred".

The two families of number answerdifferent questions, andsignModemoves only the second:

Against a watertight reference these are the same surface and the families agree. Against an open thin-walled one they diverge on purpose:max: 2.5next tosignedMin: -4.5says the nearest reference geometry is an inner wall 2.5 away while the skin that flank belongs to is 4.5 above it. Both true. A gap between them is itself the tell that the reference is thin-walled.

The mesh-inspection surface for raw scans / STL skins: split a body's mesh into surface zones (plane / cylinder / sphere / cone, via OCCTSwiftMesh's dihedral region-growing + primitive-fit merge), then measure how far each zone's own cross-section stays constant along an axis (a loftable-extent map). Both are pure mesh-domain composition — the aggregation/verdict logic here is independent of OCCTReconstruct's own engine, per the mandatory-analytic-verification policy.

The mesh-domain check-list / measurement surface (Phase 2 of the mesh-analysis expansion): integrity diagnosis, wall thickness, reflective-symmetry detection, and two-body alignment, all working directly on a body's tessellated surface rather than BREP topology, so they don't degrade on facet shells (a raw STL import) the waycheck_thicknessdoes.

This repo ships two implementations side-by-side:

Both speak stdio MCP and read/write the same manifest format.

git clone https://github.com/SecondMouseAU/OCCTMCP.git cd OCCTMCP swift build -c release

{ "mcpServers": { "occtmcp": { "command": "/path/to/OCCTMCP/.build/release/occtmcp-server" } } }

git clone https://github.com/SecondMouseAU/OCCTMCP.git cd OCCTMCP npm install npm run build

Releases are tagged on GitHub. Themainbranch is what SPI tracks.

A lightweight MCP (Model Context Protocol) server for Blender. It offers a natural language interface with Blender’s Python API, improving access to documentation, and allowing users to explore and understand complex setups.

The Lottie Creator MCP brings your AI assistant directly into your animation workflow — giving it full access to LottieFiles Creator so it can build and edit Lottie animations on your behalf through natural language.

AI Video, Image & Audio Generation with over 150 models

Rive MCP let AI handle repetitive tasks, like creating complex View Models, State Machines with hundreds of states/layers, Layouts, Shapes, and more.

Create, edit, and export SVGator animations (SVG, Lottie, GIF, video) from your AI assistant, and keep an editable project you can open in the editor anytime.

You're agent can Chain 60+ AI image and video models on one workflow canvas

Real interaction references and motion recipes for AI coding agents.

Search 1,145 real website designs by style, font, colour, section and measured design tokens.

Render, verify, describe, and safely edit Mermaid diagrams through MCP.