Drives Anycubic Slicer Next (and its installed Anycubic printer presets) without the GUI: lists machine/process/filament presets, resolves and inspects preset settings, reports model info, slices STL/3MF/OBJ/STEP files into G-code with print time, filament usage, layer counts and warnings, summarizes existing G-code, renders top-down PNG previews of toolpaths, and saves user presets back into the slicer.
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., "@anycubic-slicer-mcp Slice examples/calibration_cube.stl for my Kobra S1 at 15% infill"
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.
An MCP server that lets AI agents (Claude Code, Claude Desktop, Cursor, …) use Anycubic Slicer Next without its GUI: list presets, slice models, read print time and filament estimates, and look at a rendered preview of the toolpaths.
Unofficial community project. Not affiliated with or endorsed by Anycubic.
You: Slice examples/calibration_cube.stl for my Kobra S1 with 15% infill.
Agent: slice_model → 20m 53s, 3.56 g PLA, 100 layers, first layer 24s
preview_gcode(layer=1) → [PNG of the first layer, colored by feature]examples/calibration_cube.stl is a plain 20 mm cube (regenerate it with python examples/make_cube.py).
Windows (the slicer's headless CLI and preset folders are used as installed by Anycubic)
Anycubic Slicer Next installed and opened at least once
Python 3.10+
Tested with Anycubic Slicer Next 2.0.0.3 on Kobra S1, S1 Max, Kobra 3 / 3 Max, Kobra 4, Kobra X, Kobra 2 Neo / 2 Pro and Kobra 1 presets. Presets are read from the slicer itself, so other Anycubic printers should work too.
Related MCP server: cura-mcp
git clone https://github.com/EmreTekir/anycubic-slicer-mcp
cd anycubic-slicer-mcp
py -3 -m venv .venv
.venv\Scripts\python.exe -m pip install .Register it with Claude Code (for all your projects):
claude mcp add --scope user anycubic-slicer -- "$PWD\.venv\Scripts\anycubic-slicer-mcp.exe"Or in any MCP client config:
{
"mcpServers": {
"anycubic-slicer": {
"command": "C:\\path\\to\\anycubic-slicer-mcp\\.venv\\Scripts\\anycubic-slicer-mcp.exe"
}
}
}With uv you can skip the clone:
uvx --from git+https://github.com/EmreTekir/anycubic-slicer-mcp anycubic-slicer-mcp
Variable | Default |
|
|
|
|
| unset; |
| unset; |
Tool | What it does |
| Install path, version, active preset folder, printer/process/filament selected in the GUI |
| Machine / process / filament presets, filtered to those compatible with a printer |
| Fully resolved preset (inheritance merged); |
| Size, bounding box, volume, facet count, manifold check |
| STL/3MF/OBJ/STEP → |
| The same estimates read from an existing |
| Top-down PNG: all layers shaded by height, or one layer colored by feature |
| Open a file in the slicer GUI (only when you ask for it) |
| Save a user preset that appears in the GUI |
Settings are changed with overrides, e.g.
{"sparse_infill_density": "20%", "enable_support": true, "brim_type": "outer_only", "nozzle_temperature": 215}.
Each key is routed to the process, filament or machine config that owns it. Unknown keys are rejected,
and the result lists warnings for values the slicer clamped or ignored (for example a bed temperature
key that doesn't match the selected plate type).
Notes:
Filament names can be given naturally: with a printer selected, "Anycubic PLA" means
Anycubic PLA @<that printer>.
scale and rotate_z work on STL and OBJ files (the model is transformed before slicing).
arrange=false keeps the coordinates stored in the file, so a model at the origin may land off the bed.
Results are written next to the first model unless output_dir is given; existing files with the
same name are replaced.
Presets live as JSON under %APPDATA%\AnycubicSlicerNext\system\Anycubic\… and user\<folder>\….
Each may inherits a parent; the server merges the chain into the flat config the CLI expects.
The active user folder and the GUI's selection come from AnycubicSlicerNext.conf.
The CLI checks compatible_printers against the printer's system parent, so flattened user printers
get that parent written back. Using a process or filament made for another printer works, and is
reported as a warning.
Anycubic filaments carry per-nozzle variants (nozzle_temperature_HS, _BRASS) that win over the
plain key; setting the plain key updates them too.
The slicer's own first-layer estimate is far too low, so first_layer_time is measured from the
M73 progress marks when the G-code has them (first_layer_time_source says which was used).
The slicer's own --scale above 1 and --rotate crash it, so models are transformed in Python.
Tools run in worker threads: a long slice does not block other requests.
The server runs locally over stdio with your user's permissions. It is built so a confused or manipulated agent (for example one following instructions hidden in a downloaded file) cannot turn it into more than a slicer:
post_process (programs the slicer runs after slicing) can never be set through the tools.
3MF files are scanned before they are sliced, inspected or opened, and refused if any settings entry
carries a post-processing script or cannot be checked reliably.
Raw G-code templates (machine_start_gcode, filament_end_gcode, …) are read-only unless you set
ANYCUBIC_MCP_ALLOW_GCODE_TEMPLATES=1.
Setting values may not contain line breaks or control characters, so a value that a G-code template expands (a filament type, a note) cannot smuggle in extra G-code lines.
Network paths (\\server\share\…, mapped network drives) are refused before anything touches the
filesystem, because merely opening one makes Windows send your credentials to that server.
File tools only accept existing files with model or .gcode extensions. slice_model writes only
.gcode / .gcode.3mf files; save_user_preset writes only into the slicer's user preset folder and
cannot change a preset's name, parent or compatibility fields.
Image size, timeout, copies, scale and plate number are bounded.
What it does not protect against:
Your own presets: a user preset that already contains a post_process script (set up in the GUI) is
used as-is, exactly as the GUI would use it.
A 3MF sliced with use_project_settings brings its own start/end G-code, as it would in the GUI.
Temperatures and speeds are ordinary settings and are passed through. Check what the agent sliced before you print it.
.venv\Scripts\python.exe -m pip install -e .[test]
.venv\Scripts\python.exe -m pytestThe tests need no slicer install. Changes that touch slicing should also be checked against a real
slicer with examples/calibration_cube.stl.
MIT
Print-time / filament / layer estimates and key settings read from an existing .gcode file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Read from' implies a non-destructive operation, but it doesn't confirm read-only status, describe behavior on non-gcode or missing files, or note any performance cost. Minimal viable disclosure for a no-annotation tool.
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 that identifies the source file first and the returned data second. Efficient, with no filler, though 'key settings' is left vague.
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 simple single-parameter read tool with no output schema, the description usefully enumerates the returned data categories. The remaining gap is the path semantics, which neither the schema nor the description covers.
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 single required parameter 'path' has 0% schema description coverage and the description never mentions it. An agent must infer that 'path' means a filesystem path to a .gcode file, with no guidance on format, relative vs absolute, or error conditions.
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 (read) and resource (an existing .gcode file) and enumerates what it returns: print-time, filament, layer estimates and key settings. It is distinguishable from slice_model (which creates gcode) because it targets an already-existing file, though it doesn't explicitly contrast with preview_gcode.
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 word 'existing' implies it should be used on files that have already been sliced, which separates it from slice_model. However, it never explicitly says when to prefer it over preview_gcode or model_info, nor what preconditions (a valid .gcode path) must hold.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fully resolved (inheritance-merged) preset values. Name may be a unique substring; printer narrows ambiguous process/filament names. Use search to filter keys by substring (e.g. 'infill', 'support', 'temp', 'speed') or keys for exact ones; with neither, long G-code template values are truncated.
| Name | Required | Description | Default |
|---|---|---|---|
| keys | No | ||
| kind | Yes | ||
| name | Yes | ||
| search | No | ||
| printer | No |
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 non-obvious behavior: values are inheritance-merged, name matching is substring-based with printer as a tiebreaker, and long G-code template values are truncated when neither search nor keys is given. It omits the read-only/side-effect profile and any indication of result size or format, but the truncation caveat is genuinely valuable.
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?
Three dense sentences with the return-value semantics front-loaded, followed by matching rules and the filtering options. No filler, though the semicolon-chained second and third clauses read as slightly telegraphic.
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?
No output schema and no annotations mean the description should cover more: it never describes the shape of the returned preset data (key/value map? nested?) nor the allowed values for the required kind. It is adequate for filtering but incomplete for a 5-parameter tool returning arbitrary preset contents.
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 name (substring match), printer (ambiguous process/filament resolution), search (key substring), and keys (exact keys). However, the required parameter kind is never mentioned and has no enum, leaving an agent to guess its valid values.
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 states precisely what is returned: "Fully resolved (inheritance-merged) preset values", which distinguishes it from list_presets (which only enumerates names). The verb is implicit (inherited from the tool name) rather than stated, but the resource and the resolution semantics are unambiguous.
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?
It gives concrete guidance on choosing between search (substring over keys) and keys (exact match), and on using printer to disambiguate, but it never says when to use this tool instead of list_presets or save_user_preset. Usage for the filtering parameters is clear; usage relative to siblings is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List selectable presets. kind: machine | process | filament. For process/filament pass printer to keep only compatible ones (user presets listed first). search is a case-insensitive substring filter (e.g. 'S1', 'PLA', '0.16mm').
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| search | No | ||
| printer | No | ||
| include_incompatible | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral load; it does disclose two non-obvious traits — user presets are returned first, and compatibility filtering is applied when printer is supplied. It does not say whether include_incompatible overrides that filtering, nor describe the shape of returned presets.
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 is front-loaded in the first sentence and the remaining two sentences each address specific parameters with concrete examples. Dense but essentially waste-free.
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 four-parameter list tool with no annotations and no output schema, the description omits include_incompatible entirely and gives no hint about what a returned preset contains. Adequate for calling the tool, incomplete for predicting its results.
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; it gives meaning to kind (valid values), search (case-insensitive substring with examples), and printer (compatibility filter). include_incompatible is never mentioned, and the rule that printer only applies to process/filament leaves its exact effect ambiguous.
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 ('List selectable presets') and enumerates the three valid kinds (machine | process | filament), which the schema does not do. It is implicitly distinguishable from the singular sibling get_preset, but never explicitly says so.
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?
'For process/filament pass printer to keep only compatible ones' is a real conditional usage rule for a parameter, but there is no guidance on when to choose this tool over get_preset or about the interaction with include_incompatible.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Size (mm), bounding box, facet count, volume (mm3) and manifold check for a model file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | 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 not say whether the tool is read-only, whether it parses the file (and thus how expensive it is on large meshes), or what happens on a malformed/unsupported file. The manifold check hints at validation behavior, but the failure mode is undisclosed.
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?
One short sentence-fragment listing the returned metrics, with the primary measure (size) front-loaded and no filler. It is efficient, though the fragment style leaves no room for the context the tool actually needs.
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?
There is no output schema and no annotations, so the description is the only documentation for a one-parameter tool, yet it omits path format, supported file types, and error behavior. For a simple inspection tool the metric list covers the return shape but not enough to invoke it confidently.
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 required 'path' parameter, and the description only indirectly implies it refers to a model file. It does not state accepted formats (STL/OBJ/3MF), whether relative or absolute paths work, or where paths are resolved from.
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 enumerates exactly what the tool reports for a model file: size in mm, bounding box, facet count, volume in mm3, and a manifold check. That is distinctive against siblings like slice_model or gcode_summary, which operate on different resources. It lacks an explicit verb ('returns'/'computes') but the resource and output set make the purpose unambiguous.
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 versus slice_model or preview_gcode, and no prerequisites such as needing an already-loaded or existing file. An agent must infer that this is a pre-slicing inspection step from the metric list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a model/3MF/G-code in the Anycubic Slicer Next GUI. Only call this when the user asks to see it.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose the key behavioral trait that this launches an external GUI application rather than returning data. It says nothing about what happens if the slicer is not running, whether the file must exist, or whether the call blocks until the GUI opens, leaving side-effect and failure semantics unstated.
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 short sentences with no filler; the action and resource are front-loaded and the usage constraint follows immediately. Every clause earns its place.
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 no explanation, and the call itself is simple with one required parameter. Still missing for a GUI-launching side-effecting tool are preconditions (slicer installed/running, file existence) and any note on blocking behavior, which an agent needs to call it safely.
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% for the single `path` parameter, so the description should compensate. It partially does by implying the path points to a model, 3MF, or G-code file, effectively constraining accepted formats, but it does not state whether the path must be absolute, a local filesystem path, or required to already exist.
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 states a specific verb ("Open") and resource set ("model/3MF/G-code") plus the target application (Anycubic Slicer Next GUI), which is distinctive. It does not name a sibling to contrast with, but the GUI-opening action is clearly separable from slice_model, preview_gcode, and model_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?
"Only call this when the user asks to see it" gives an explicit positive trigger and an implicit exclusion, which is real guidance rather than none. It stops short of naming an alternative (e.g., preview_gcode for in-chat viewing), so an agent must infer which sibling to pick for other viewing intents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top-down PNG render of a .gcode. layer=None: all layers shaded by height (footprint/placement check). layer=N (1-based): that layer colored by feature: outer wall orange, inner wall yellow, sparse infill dark red, solid infill magenta, top surface red, bottom surface blue, bridge light blue, overhang wall dark blue, support green, brim/skirt cyan, gap fill white. size: image edge in pixels (200-2000).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| size | No | ||
| layer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It discloses the output format and the valid size range, but says nothing about read-only safety, error behavior for bad paths, render cost, or whether the image is returned inline.
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?
Dense and front-loaded: the render target comes first, then parameter meaning, then the color legend. It's a bit run-on and the missing line breaks make the layer/color enumeration harder to scan, but no sentence is filler.
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 3-param read tool with no output schema, the description covers output format, both modes, the color legend, and the size constraint. An agent could invoke it correctly from this plus the schema.
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 largely does: size is defined as image edge in pixels with a 200-2000 bound, and layer is defined as 1-based with None meaning all layers shaded by height. Only 'path' is left implicit (a .gcode file), which is a minor gap rather than a real ambiguity.
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?
Opens with a specific verb+resource+format: 'Top-down PNG render of a .gcode'. An agent can distinguish this from gcode_summary or model_info, though the description never explicitly contrasts it with those siblings.
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?
It clearly explains the two operating modes (layer=None for footprint/placement check vs layer=N for per-feature inspection), which tells the agent which mode to pick. It stops short of naming alternatives or when not to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create/overwrite a user preset that shows up in the GUI (restart the slicer to see it). inherits: parent preset name; settings: only the keys that differ from the parent.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| name | Yes | ||
| inherits | Yes | ||
| settings | Yes |
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 valuable traits: overwrite semantics, GUI visibility requiring a slicer restart, and inheritance with a diff-only settings payload. It omits what happens on name collisions, validation failures, or what the call returns.
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 short sentences with zero filler, and the primary action is front-loaded before the parameter notes. The telegraphic 'inherits: ...; settings: ...' phrasing is compact but slightly clipped.
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 4-required-param mutation tool with nested objects, no annotations and no output schema, the description covers the tricky semantics (overwrite, inheritance, diffs) but leaves the meaning and valid values of 'kind' entirely to the agent's guesswork.
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; it does define 'inherits' (parent preset name) and 'settings' (only keys differing from the parent), which are the two non-obvious parameters. 'kind' and 'name' — 'kind' especially, a free-form string with no enum — are left unexplained.
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?
A specific verb ('Create/overwrite') plus resource ('a user preset') and an effect ('shows up in the GUI'). It does not distinguish itself from siblings like list_presets or get_preset, but the action itself is unambiguous.
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?
It conveys the post-condition (restart the slicer to see it) but gives no guidance on when to use this versus get_preset, list_presets, or open_in_slicer, and no prerequisites (e.g. whether the parent must already exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Slice STL/3MF/OBJ/STEP files to G-code plus a .gcode.3mf project (openable in the GUI / sendable to the printer).
printer/process/filaments: preset names or unique substrings; omitted -> GUI selection for that printer. overrides: setting key -> value, routed automatically to process/filament/machine (per-nozzle variants like nozzle_temperature_HS/_BRASS follow the plain key). output_dir defaults to the first model's folder; existing files with the same name are replaced. plate: 0 = all plates. arrange/orient: auto-place and auto-orient (arrange=false keeps the file's coordinates). scale / rotate_z (degrees): STL and OBJ only. copies: total instances of each model. use_project_settings: slice a 3MF with the settings stored inside it (no presets/overrides). Returns gcode paths with print time, filament grams/meters, layer count, key settings and warnings.
| Name | Required | Description | Default |
|---|---|---|---|
| plate | No | ||
| scale | No | ||
| copies | No | ||
| models | Yes | ||
| orient | No | ||
| arrange | No | ||
| printer | No | ||
| process | No | ||
| rotate_z | No | ||
| filaments | No | ||
| overrides | No | ||
| timeout_s | No | ||
| output_dir | No | ||
| output_name | No | ||
| use_project_settings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since there are no annotations, the description must carry the full weight of behavioral disclosure. It specifies critical traits like file replacement logic, output contents (time, grams, layer count), and default directory behavior.
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 description is extremely dense and functions more like a technical API reference manual dumped into a description field than a concise summary. While it is functional, it sacrifices conciseness for exhaustive detail.
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 zero schema description coverage, the description has to be comprehensive. It is highly complete, defining not only inputs and outputs but also default behaviors and constraints across the entire tool's function.
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?
Given the 0% schema description coverage, the description performs exceptionally well. It explains complex mapping logic (e.g., routing overrides, scaling limitations for certain files) that is impossible to convey through simple type definitions.
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 purpose is immediately clear: slicing specific 3D model formats (STL, 3MF, OBJ, STEP) into G-code and project files. It is slightly docked because the description spends the majority of its length detailing parameters rather than strictly defining the 'what' vs. the 'how'.
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?
This description excels at usage guidance. It provides complex conditional logic on parameters—for example, how to select a printer, naming conventions for process/filaments, and the specific functionality of using internal project settings vs. presets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Slicer install, version, active user preset folder and the GUI's current printer/process/filament.
| 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 disclosure burden, and it says nothing about read-only behavior, permission needs, failure modes when no slicer install is found, or how quickly results go stale. The passive field list implies a read but does not confirm it or describe limits.
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 compact fragment with no filler, and the most useful items (install, version) lead. It is under-structured rather than padded, but nothing in it 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 and no annotations, the description is the only source of return-value information, and it does list the returned fields, which is the right instinct. It still omits the shape/format of those values and any error conditions, so an agent cannot fully predict the response.
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 no parameter semantics to explain and the baseline of 4 applies. The description correctly implies a no-argument query.
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 enumerates what the tool surfaces (install, version, active preset folder, current printer/process/filament), which is specific to the slicer domain and distinguishes it from siblings like get_preset or list_presets. However, it is a bare noun phrase with no verb, so it never actually says it 'reports' or 'returns' status, leaving the agent to infer the action from the tool name.
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 indication of when to call this versus get_preset, list_presets, or model_info, nor any prerequisite such as whether the slicer must be running. The agent must infer that this is the general 'what's the current state' call from the field list alone.
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.0gcode_summaryget_presetlist_presetsmodel_infoopen_in_slicerpreview_gcodesave_user_presetslice_modelslicer_statusScored across 9 tools
Most tools have clearly distinct purposes: slicing, summarizing G-code, previewing, opening the GUI, inspecting models, and managing presets. The only potential overlap is between get_preset and list_presets, but their descriptions make the list-vs-resolve distinction clear.
All names use consistent snake_case, which is readable and predictable. However, the set mixes verb_noun names (get_preset, slice_model, preview_gcode) with noun-style names (gcode_summary, slicer_status, model_info), a minor deviation rather than a serious inconsistency.
Nine tools is well-scoped for an Anycubic slicer integration. Each tool covers a distinct workflow step, from model inspection through slicing, G-code review, and preset management, with no obvious padding.
The surface covers the core slicer lifecycle: inspect models, list/get/save presets, slice, summarize and preview G-code, open the GUI, and check slicer status. Minor gaps remain, such as deleting or renaming user presets, but agents can work around these for the main workflows.
Parametric 3D CAD for AI agents: build print-ready parts, check them, export STL, 3MF or STEP.
3D print farm management for AI. Monitor, queue, and control prints on your SimplyPrint account.
Real 3D-print slicing, quoting, DFM, orientation & material/settings advisors. Free personal tier.
214 tools for AI agents over one MCP endpoint: image, video, audio, 3D, data, storage, mail, GPUs.
