@slicerx/mcp

A Model Context Protocol server that gives AI tools (Claude, ChatGPT, Cursor and any other MCP client) what PrintPilot, the assistant built into SlicerX, can do: slice and estimate, plan and check settings, orient, arrange and slice a project, queue jobs, control printers, and read the knowledge base and the integrator guides. Everything that changes a printer, a saved profile or spends money goes through the same permission policy and approvals PrintPilot uses in the app.

It runs over stdio for desktop clients and over streamable HTTP for clients that connect to a URL.

#Tools

Reading is always allowed. The permission class of the other tools decides what the user's policy does with them.

The PrintPilot skill and tool names come from its registry, so new skills appear here as they ship. The skill catalog is readable at slicerx://pilot/skills.

Resources:

• slicerx://docs/{id}: the install, embedding and theming guides, this README, and the printer and service guides (printers/bambu-lan, printers/moonraker, printers/creality, printers/snapmaker, printers/prusalink, printers/octoprint, printers/duet, printers/elegoo, printers/spoolman, printers/home-assistant), and the settings guide and reference (settings/guide, settings/reference/index and one file per group).
• slicerx://settings/reference (the index), slicerx://settings/reference/{key} (one setting), slicerx://settings/schema (JSON) and slicerx://settings/catalog (edit rules and bounds).
• slicerx://knowledge/{kind}/{id}: every knowledge entry as YAML with sources.
• slicerx://pilot/skills: the PrintPilot skill catalog.

#Permissions

The policy file gives each class of action one of three modes:

Write it as JSON at ~/.config/slicerx/mcp-policy.json, or pass --policy <file>:

{
  "classes": { "slice": "allow", "queue": "ask", "start": "ask", "profile": "ask", "buy": "off" },
  "printers": { "bay-2": { "queue": "allow", "start": "allow" } }
}

• allow runs the call and logs it. ask asks the user first. off refuses.
• start cannot be allow for every printer at once; a class-wide allow is treated as ask. Allow it per printer under printers, for a machine you trust to run unattended.
• A per-printer entry can loosen ask to allow, but it cannot turn on a class that is off.
• Unknown or malformed entries fall back to the defaults. The server reads the file at startup, and no tool can change it, so a model cannot loosen its own permissions.

#How Ask first works

1. The tool builds an approval plan: a one-line question, details, and the exact host calls it needs, such as "upload this file with this SHA-256 to bay-2, then start it".
2. If the client supports MCP elicitation, the server asks the user directly, and the call runs only if they approve.
3. Otherwise the tool returns status: "approval_required" with a request_id, the question and the details. The client shows it to the user, and only on a yes calls slicerx_approve with approve: true. Requests expire after five minutes and work once.
4. On approval the server issues a signed token bound to those exact calls. The printer connector verifies the token before it sends anything, so a token for one printer, file or command fails for any other, and a second use fails.

Without elicitation, approval depends on your client asking you before it calls slicerx_approve. Most clients ask before every tool call by default; do not add slicerx_approve to a client's auto-approve list.

#Action log

Every call is appended to <out-dir>/actions.jsonl (or --log <file>): time, tool, permission class, decision (read, allowed, approved, denied, off, pending, expired, failed), who decided (policy, user or client), the request id, the printer, a SHA-256 of the input, and the result summary. Tokens, file contents and credentials are never written. slicerx_action_log returns the recent entries.

#Engines

• sx: the SlicerX core through its CLI, as a separate process. The server finds sx through --sx-bin, SLICERX_SX_BIN or PATH. Build it with cargo build -p sx-cli --release (the binary is target/release/sx).
• stub: a rough estimate from mesh volume and surface area (STL only). Results say so, its G-code holds only comments, and printers refuse it.

The mesh tools use sx-geom, found through --sx-geom-bin, SLICERX_SX_GEOM_BIN, the folder of sx, or PATH. Build it with cargo build -p sx-geom --release. Without it the slicerx_geom_* tools are not offered.

--engine auto (the default) uses sx when it is found and the stub otherwise. Project plates are sliced as one combined model; the core centers it on the bed.

#Printers

• --printers demo (default): five simulated printers. Nothing reaches real hardware, and approvals work exactly as they do for real printers.
• --printers link --link-code <code>: real printers through sx-link, the SlicerX bridge on this machine. Start sx-link, add your printers to it, and pass the pairing code it prints. Setup for each printer is in the guides at slicerx://docs/printers/.... Approvals for printer actions are registered with and granted by sx-link's own broker, because sx-link verifies every token before it sends anything to a printer; project and profile approvals stay with the server's broker. Tested against sx-link and the mock printers; not yet on physical printers.
• --printers off: no printer tools.

#Install

With npm (once @slicerx/mcp is published), no clone needed:

npx -y @slicerx/mcp@0.1.0 --allow-dir ~/prints

From a clone:

pnpm install
pnpm --filter @slicerx/mcp build        # writes packages/mcp/dist/cli.js and packages/mcp/data/
cargo build -p sx-cli --release         # optional: the real slicer instead of the stub

The commands below use /path/to/slicerx; replace it with your clone.

#Claude Desktop

Settings, Developer, Edit Config, then add the server to claude_desktop_config.json:

{
  "mcpServers": {
    "slicerx": {
      "command": "node",
      "args": [
        "/path/to/slicerx/packages/mcp/dist/cli.js",
        "--allow-dir", "/Users/you/prints",
        "--sx-bin", "/path/to/slicerx/target/release/sx"
      ]
    }
  }
}

Restart Claude Desktop. Clients that support elicitation show Ask first actions as an approval prompt; others get an approval request in the conversation.

#Claude Code

claude mcp add slicerx -- node /path/to/slicerx/packages/mcp/dist/cli.js --allow-dir ~/prints

Over HTTP instead, with the server already running (see below):

claude mcp add --transport http slicerx http://127.0.0.1:3977/mcp --header "Authorization: Bearer $SLICERX_MCP_TOKEN"

#Claude Code plugin

The SlicerX plugin for Claude Code bundles this server with skills and slash commands; see packages/claude-plugin.

#Cursor

~/.cursor/mcp.json (all projects) or .cursor/mcp.json (one project) takes the same mcpServers block as Claude Desktop.

#Other clients

Any client that launches a stdio server can run node /path/to/slicerx/packages/mcp/dist/cli.js. Clients that connect to a URL use streamable HTTP:

export SLICERX_MCP_TOKEN="$(openssl rand -hex 24)"
node packages/mcp/dist/cli.js --http --port 3977 --allow-dir ~/prints

The endpoint is http://127.0.0.1:3977/mcp, stateless, POST only. In HTTP mode approvals always use slicerx_approve, since a stateless server cannot hold an elicitation open. ChatGPT and other hosted assistants connect only to remote HTTPS servers, so they cannot reach a loopback address; you need a reverse proxy or tunnel you control, with --token set and --allowed-host <public name>. Keep printer classes on Ask first or Off for any server reachable from outside your machine.

#Options

#Adding tools

An edition or another host can start the server in-process and add its own tools, written as PrintPilot tools, without the base package importing them. They go through the same permission policy and approvals:

import { createContext, createSlicerxServer } from '@slicerx/mcp'
const ctx = await createContext({ extraTools: [cloudSlice, cloudJobs] })
await createSlicerxServer(ctx).connect(transport)

#Security

• Model paths must be inside --allow-dir when it is set. HTTP mode reads no local path until you add one.
• HTTP mode binds to 127.0.0.1, checks the Host and Origin headers against loopback names (against DNS rebinding), and refuses to bind elsewhere without a bearer token. Each request gets a new server instance.
• The server never reads credentials. Printer credentials stay in the operating system keychain behind sx-link.
• Knowledge text, model metadata, profile names and printer replies are data. Tool output marks printer and file text as untrusted, and none of it can approve an action.

#Licensing

MPL-2.0, like the rest of the SlicerX base kit. The package bundles no OrcaSlicer code or data. MCP clients talk to the server over stdio or HTTP, so connecting a client places no license terms on it.

#Development

pnpm --filter @slicerx/mcp test        # tools, permissions and approvals, resources, HTTP, both engines
pnpm --filter @slicerx/mcp typecheck
pnpm --filter @slicerx/mcp dev -- --engine stub   # run from source
npx @modelcontextprotocol/inspector node packages/mcp/dist/cli.js

Tests that need the real core run when target/release/sx exists and are skipped otherwise.

Dependencies:

• @modelcontextprotocol/sdk 1.31.0: the MCP server, stdio and streamable HTTP transports (MIT).
• zod 4.6.5: tool input schemas (MIT).
• yaml 2.9.1: reads the knowledge base (ISC).
• Development only: esbuild 0.28.2 bundles the workspace packages into dist/cli.js, tsx 4.23.15 runs from source, vitest 5.0.2 runs the tests, and @types/node 24.19.0.

#Status

Working: stdio and HTTP transports, the permission policy with elicitation and approval requests, the action log, file slicing with the sx engine or the stub, the MCP project with PrintPilot's skills, the simulated printers, and every resource listed above. Theming tools build and check themes; applying one happens in your page with applyTheme() or <ThemeProvider>. Printer actions on real printers go through sx-link's broker (tested with the mock printers). Planned: publishing @slicerx/mcp to npm, and testing on physical printers.