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., "@send2orca-mcp send the design open in SolidCraft to OrcaSlicer as a 3MF"
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.
Send a SolidCraft design to OrcaSlicer in one command.
Model in SolidCraft, run send2orca, and the part is open in Orca, ready to slice.
$ send2orca
exported ~/.local/share/send2orca/out/Banana_box.step (323850 bytes) from live:7878
opened with /usr/bin/orca-slicerWorks with the design open in a running SolidCraft window, or with a saved design file.
Exports STEP (default), 3MF or STL; a multi-body design arrives in Orca as separate objects.
Finds your slicer by itself: orca-slicer / orcaslicer / orca-belt* forks on PATH, the OS install, an AppImage, or the Flatpak.
Ships an MCP tool (send2orca-mcp) so an AI agent that is already driving SolidCraft over MCP can say "send it to Orca".
Pure Python standard library. No dependencies.
Why a companion tool and not a plugin? SolidCraft has no in-app plugin API today. Send2Orca uses only the interfaces SolidCraft documents:
solidcraft-cli runfor files and the MCP bridge (solidcraft-cli mcp --connect) for a running window.
You need SolidCraft (for solidcraft-cli) and OrcaSlicer, plus Python 3.9 or newer.
pipx install git+https://github.com/tommasobbianchi/Send2Orca
# or: pip install git+https://github.com/tommasobbianchi/Send2OrcaCheck what it detects:
$ send2orca --doctor
send2orca: 0.1.1
solidcraft_cli: /usr/bin/solidcraft-cli
solidcraft_version: solidcraft-cli 0.14.0
live_windows: [7878]
orca: ['/usr/bin/orca-slicer']Related MCP server: orcaslicer-mcp
The design that is open right now. Start SolidCraft with its control channel once:
solidcraft --control 7878then, from any terminal on the same computer:
send2orca # STEP, opened in Orca
send2orca -f 3mf # another format
send2orca -b Body2 # only one body
send2orca --no-launch # export only
send2orca --list # which windows are runningA saved design, no window needed.
send2orca part.solidcraft
send2orca part.solidcraft -f stl -o /tmp/part.stlFiles are written to ~/.local/share/send2orca/out/ (Linux), named after the design.
option | meaning |
| export format (default |
| export only that body; repeat for several (live window only) |
| write here instead of the default folder |
| control port of the window (default: auto-detect) |
| slicer command; also |
| export only |
| machine-readable output |
| diagnostics |
Order of precedence: --orca, $SEND2ORCA_ORCA, "command" in the config file, then auto-detection.
Config file: ~/.config/send2orca/config.json (Linux/macOS), %APPDATA%\send2orca\config.json (Windows):
{ "command": "/home/me/bin/orca-belt-2026-08", "format": "step" }This is also how you point Send2Orca at a fork (for example a belt-printer build). If you start it from SSH on Linux, it borrows the desktop session's display variables so the window opens on the screen.
claude mcp add --scope user send2orca -- send2orca-mcpTools: send_to_orca (file?, format?, bodies?, port?, launch?) and send2orca_doctor.
Register it next to SolidCraft's own server (solidcraft-cli mcp --allow-path ~/designs).
A ready-to-copy Claude Code skill is in skills/send2orca.
Developed and tested on Linux with SolidCraft 0.14 (real solidcraft-cli, file export and the MCP export with body filter).
The test suite (pytest) runs against stand-ins for SolidCraft and Orca, and CI runs it on Linux and macOS.
Windows and macOS install locations for SolidCraft and the location of the control-channel token folder are
best-effort guesses. If detection fails, set SOLIDCRAFT_CLI and pass --port, and please open an issue.
STEP is the default because Orca imports it faithfully; Orca triangulates it on import. Use 3MF if you prefer.
The window path needs solidcraft --control PORT. Without it SolidCraft exposes no control channel and only saved files can be sent.
pip install -e '.[test]'
pytestMIT OR Apache-2.0, at your option (the same as SolidCraft). Not affiliated with SolidCraft or OrcaSlicer.
Report the SolidCraft CLI, running windows and OrcaSlicer that Send2Orca detects.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does not state that this is a read-only/safe operation, whether it probes the system or mutates anything, or how heavy the detection is (e.g., filesystem scans or launching the CLI). For a zero-annotation tool, this leaves meaningful gaps.
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 padding. The phrasing is slightly awkward ("Report the SolidCraft CLI, running windows and OrcaSlicer") 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?
With no output schema, the description should convey what a diagnostic report contains; it only lists the subjects inspected, not the shape or content of the result. For a zero-parameter diagnostic tool this is adequate but leaves the agent guessing about the return value.
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 and schema coverage is 100%, so there is nothing for the description to clarify. Baseline 4 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?
States a verb ("Report") and enumerates the subjects it inspects (SolidCraft CLI, running windows, OrcaSlicer), which hints at a diagnostic/environment-check tool. However, it never says what is actually reported (versions, paths, health status) and does not distinguish itself from the sibling send_to_orca, so the purpose remains only partially clear.
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?
No when-to-use guidance, no prerequisites, and no mention of the sibling send_to_orca as an alternative. An agent must infer that "doctor" means troubleshooting/diagnostics rather than the actual send operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the design open in SolidCraft (or a saved design file) and open it in OrcaSlicer. Multi-body designs arrive as separate objects.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | saved design path; omit to use the open SolidCraft window | |
| port | No | control port of the window (default: auto) | |
| bodies | No | live window only | |
| format | No | default step | |
| launch | No | false = export only (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose one non-obvious behavior ('Multi-body designs arrive as separate objects'). However, it omits side effects of launching an external application, failure/error behavior, and whether the open design is modified, leaving meaningful 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?
Two tight sentences with the primary action front-loaded and the notable multi-body behavior as a follow-up; no filler or 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?
For a 5-parameter tool with no annotations and no output schema, the description covers the core flow and one behavior but does not describe what the tool returns or how failures surface. It is minimally adequate but leaves the agent guessing about outcome and preconditions.
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%, so all five parameters (file, port, bodies, format, launch) are already documented in the schema. The description's 'or a saved design file' loosely echoes the file param but adds no syntax, defaults, or constraints beyond what the schema provides, so the baseline 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?
States a specific verb and resource pair ('Export the design... and open it in OrcaSlicer'), naming both the source app and destination, which is enough to distinguish it from a diagnostic sibling like send2orca_doctor. It does not, however, explicitly contrast itself with that sibling, so it falls short of a 5.
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 implies the workflow (export a design to OrcaSlicer) but never states when to use this tool versus the doctor tool, nor any prerequisites such as OrcaSlicer being installed or running. No exclusions or alternatives are given.
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.1send_to_orcasend2orca_doctorScored across 2 tools
send_to_orca performs the export/handoff action, while send2orca_doctor is a diagnostic that reports detection of environment components. Their purposes are distinct, though an agent might initially wonder if 'doctor' also triggers an export.
The two names use different conventions and structures: 'send_to_orca' is a verb-preposition-noun function name, while 'send2orca_doctor' is a product-style noun phrase that omits the underscore before the verb-like component. There is no predictable pattern across the set.
Two tools are borderline thin for a dedicated server, but the scope is narrowly focused on exporting from SolidCraft to OrcaSlicer. It is plausible that no more tools are needed, but it feels minimal.
The surface covers the core export action and a diagnostic check, but there is no tool to configure export options, list recent exports, or handle errors beyond the doctor report. For a simple bridge, coverage is adequate but not complete.
Parametric 3D CAD for AI agents: build print-ready parts, check them, export STL, 3MF or STEP.
Real 3D-print slicing, quoting, DFM, orientation & material/settings advisors. Free personal tier.
Manage SysML2 projects; check, evaluate, verify, query, document and diagram models.
DXF and PDF/X-4 for AI agents: structured facts, PNG renders, an interactive in-chat viewer.