Provides slicing to the Elegoo Mars 5 Ultra's .goo format via list_printers and slice tools, enabling resin print preparation for Elegoo printers.
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., "@nakomis-dragonfruit-mcp hollow this STL with 2mm walls and slice it for the Elegoo Mars 5 Ultra"
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.
Unofficial. Not affiliated with or endorsed by the Open Resin Alliance or the DragonFruit project.
An MCP server that lets an AI assistant inspect,
hollow, check and slice resin prints using the engine of
DragonFruit, with no GUI.
It wraps dragonfruit-cli and a small Rust tool of its own.
If you find this useful, please consider buying me a coffee:
Related MCP server: PrusaMCP
Early days. The repository is scaffolded; the tools are being built. Planned tools:
mesh_info: triangles, size in mm, volume in ml
find_islands: where a model needs supports
list_printers and slice: slice to the printer's own format (.goo for the
Elegoo Mars 5 Ultra, .nanodlp for the Concepts3D Athena 8K, and anything else
you add as a plugin)
preview_layer and inspect_print: check the sliced output
hollow and drill_holes
Supports are out of scope: DragonFruit builds them by hand in its interface.
Path | Contents |
| The MCP server (Python, FastMCP) |
| pytest; integration tests run only when |
| Our Rust tool (hollowing, hole punching), linking DragonFruit's |
| DragonFruit, as a submodule pinned to upstream |
| Builds |
| Architecture diagram source ( |
| The logo; the other candidates live on the |
| Pre-commit hook: regenerates diagram SVGs and the README table of contents |
git clone --recurse-submodules git@github.com:nakomis/nakomis-dragonfruit-mcp.git
cd nakomis-dragonfruit-mcp
scripts/build.sh # needs cargo and Node; full log in /tmp/ndfm-build.log
uv run nakomis-dragonfruit-mcpAGPL-3.0-or-later, the same licence as DragonFruit, whose crates this project links.
docs/architecture/nakomis-dragonfruit-mcp.drawio is the source for the diagram above.
The SVG is auto-regenerated on commit by the pre-commit hook in .githooks/pre-commit.
To activate the hook after cloning:
git config core.hooksPath .githooksIf you find this useful, please consider buying me a coffee:
Report which dragonfruit-cli is in use and the print formats it can write.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| formats | Yes | Output extensions the engine can write |
| version | Yes | |
| cli_path | Yes | |
| warnings | No | |
| slice_defaults | Yes | Engine defaults; never relied on for a real printer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Report' implies a passive, non-mutating lookup, which is useful signal, and it hints at the returned content (available print formats). However it says nothing about permissions, cost, or side effects, leaving real gaps for a tool with no annotation coverage.
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?
A single front-loaded sentence with no filler or redundancy. Every clause adds information about what the tool reports.
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?
With an output schema present, the description need not explain return values, and with zero parameters there is no input surface to document. It is nearly complete, missing only guidance on when this diagnostic is relevant versus other info tools.
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?
The tool takes zero parameters, so there is nothing for the description to disambiguate. The 100% schema coverage and empty properties object make this a baseline case where no compensating text is needed.
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?
States a specific verb ('Report') and resource ('which dragonfruit-cli is in use and the print formats it can write'), so an agent knows exactly what it returns. It does not differentiate itself from siblings mesh_info or find_islands, but those cover unrelated domains so confusion is unlikely.
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?
There is no statement of when to call this tool, no prerequisites, and no reference to any alternative. The agent must infer usage entirely from the name and the one-line purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find islands: regions that appear in a layer with nothing solid beneath them.
These are where a resin print needs supports. The model is scanned as it sits
in the STL: layer 0 is its lowest point, as if lying on the plate, and no
supports are considered. Positions are in the STL's own X/Y/Z (mm). Layers are
sliced layer_height apart on a px_mm grid; a region counts as supported if
solid lies within support_buffer_mm of it in the layer below. Detections that
start within cluster_mm (XY distance from the cluster's first detection) and
ten layers of each other are merged into one entry; 0 disables that. Entries
whose first_area_mm2 is under min_area_mm2 are then dropped, and the
max_islands largest by that area are returned, with truncated set if there
were more.
| Name | Required | Description | Default |
|---|---|---|---|
| px_mm | No | ||
| stl_path | Yes | ||
| cluster_mm | No | ||
| max_islands | No | ||
| layer_height | No | ||
| min_area_mm2 | No | ||
| support_buffer_mm | No |
| Name | Required | Description |
|---|---|---|
| path | Yes | |
| px_mm | Yes | |
| layers | Yes | |
| islands | Yes | Largest first_area_mm2 first |
| bbox_max | Yes | |
| bbox_min | Yes | [x, y, z] mm of the model, to check positions against |
| warnings | No | |
| elapsed_s | Yes | |
| truncated | Yes | True when islands holds fewer than islands_total |
| islands_total | Yes | Islands found after clustering and filtering |
| plate_contacts | Yes | Layer-0 regions: on the plate, not islands |
| raw_detections | Yes | Off-plate islands the tracker reported, before clustering and filtering |
| total_area_mm2 | Yes | Unsupported footprint: first-layer areas of all islands_total islands (every merged detection), not just the ones listed |
| layer_height_mm | Yes | |
| support_buffer_mm | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so well: it explains that the model is scanned as it sits in the STL with layer 0 at the plate and no supports considered, that positions are in the STL's own mm frame, and that results may be merged, area-filtered and truncated. It omits operational traits like compute cost or whether the call is purely read-only, which keeps it from a 5.
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?
Purpose and caveats are front-loaded in the first two sentences, and every clause carries information. The final paragraph is a single very long sentence packing clustering, filtering and truncation together, which could have been broken up, but nothing is wasted.
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?
An output schema exists, so return values need not be detailed, yet the description still flags the important ones (area-based ordering, max_islands cap, truncated flag). Combined with full parameter explanation and the algorithmic model, an agent has everything needed to invoke it correctly.
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 coverage is 0%, so the description must compensate, and it explains essentially every parameter: px_mm (grid), layer_height (slice spacing), support_buffer_mm (support proximity test), cluster_mm (XY merge distance, with '0 disables'), min_area_mm2 (drop threshold) and max_islands (largest-N selection plus the truncated flag). This adds real meaning beyond the bare schema names.
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 gives a specific verb and resource ('Find islands') and immediately defines the term operationally: 'regions that appear in a layer with nothing solid beneath them.' It also grounds the output in a concrete use case (resin print supports), which clearly separates it from the informational siblings engine_info and mesh_info.
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?
Usage is implied rather than stated: 'These are where a resin print needs supports' hints at why you'd call it, but there is no explicit when-to-use/when-not, no prerequisite for preparing the STL, and no mention of alternatives. Adequate context, no routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report an STL's triangle count, bounding box, size (mm) and volume (mm3 and ml).
Warns about sizes that suggest the wrong units and volumes that suggest the mesh is not a closed solid. Volume is the CLI's signed-volume sum, which cannot tell a closed mesh from an open one that happens to integrate sensibly; it does not report watertightness itself. The absence of the fill-ratio warning therefore proves nothing about whether the mesh is closed.
| Name | Required | Description | Default |
|---|---|---|---|
| stl_path | Yes |
| Name | Required | Description |
|---|---|---|
| path | Yes | |
| source | Yes | What the CLI read: stl, voxl or directory |
| size_mm | Yes | |
| bbox_max | Yes | |
| bbox_min | Yes | mm, in the file's own coordinate frame |
| vertices | Yes | Unwelded: three per triangle |
| warnings | No | |
| triangles | Yes | |
| volume_ml | Yes | volume_mm3 / 1000: the resin a solid print needs |
| volume_mm3 | Yes | Signed-volume integral, absolute value |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does substantial work: it explains the warning conditions, states the volume is a signed-volume sum, and explicitly cautions that it does not report watertightness and that a missing fill-ratio warning proves nothing. What it omits is behavior on bad input (non-STL file, missing path) and permission/side-effect posture, though a reporting tool implies a safe read.
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 first sentence front-loads the four reported values, then the caveats follow. The three-sentence caveat block is a bit dense, but each sentence carries distinct, non-redundant information.
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?
An output schema exists, so return values need not have been explained, yet the description usefully clarifies their interpretation. For a single-parameter read tool with no annotations, it is nearly complete, lacking only input-failure behavior and an explicit usage routing against siblings.
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 0% for the single stl_path parameter, which is undocumented in the schema. The description implies the input is an STL file ('an STL's triangle count') but adds no path format, resolution, or error-handling semantics, so it only partially compensates.
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 names a specific verb and resource: reporting triangle count, bounding box, size, and volume for an STL. It is immediately distinguishable from siblings like engine_info or find_islands, but it never explicitly contrasts itself with them.
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?
Usage is only implied — an agent infers it inspects a mesh before other geometry operations. There is no explicit when-to-use statement, no prerequisites, and no pointer to the sibling tools that might be the better choice for related queries.
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.0engine_infofind_islandsmesh_infoScored across 3 tools
The three tools have clearly distinct purposes: engine_info reports CLI environment, mesh_info reports mesh statistics, and find_islands detects unsupported regions. No overlap in function.
All names use snake_case, but two follow a noun_info pattern (engine_info, mesh_info) while find_islands uses a verb_noun pattern. This is a minor inconsistency in verb style, though still readable.
Three tools is appropriate for a focused analysis server; each tool addresses a distinct need (environment, mesh properties, island detection) and there is no redundancy.
The server covers environment info, mesh inspection, and island detection, which are core for resin print support analysis. However, it lacks any tool to generate or export supports, which may be a gap for a full workflow, though possibly out of scope.
Real 3D-print slicing, quoting, DFM, orientation & material/settings advisors. Free personal tier.
3D print farm management for AI. Monitor, queue, and control prints on your SimplyPrint account.
Parametric 3D CAD for AI agents: build print-ready parts, check them, export STL, 3MF or STEP.
LLM chat, text tools, image generation, editing, batch image jobs, and asynchronous video generation
