Skip to main content
Glama
orcaslicer-mcp

orcaslicer-mcp

Save project (.3mf, can replace a file)

save_project
Destructive

Save the open OrcaSlicer project as a .3mf with its plates, object placement, and settings to preserve session work; specify a path for Save As or overwrite an existing file.

Instructions

Save the open project as a .3mf with its plates and settings (File > Save or Save As); save_gcode saves the sliced G-code instead.

It writes exactly what File > Save / Save Project As writes: plates, object placement, per-object and per-plate settings, height-range modifiers, slot presets and colours, and unsaved config overrides. No dialog opens; OrcaSlicer's own prompts are answered from the arguments. To create a new project file, call new_project and then save_project with a path.

Afterwards get_status reports the new path and dirty false, and the file joins File > Recent. Save early: everything set up through these tools lives only in the open session until it is saved, and is lost if OrcaSlicer closes. A save is refused while a slice runs (slicing). Replacing an existing file also needs Preferences > Remote API > 'Allow deleting and replacing project files' in OrcaSlicer (blocked_by_remote_api_policy otherwise). Needs fork v2.4.2-mcp.15 or later.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "save_project"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathNoWhere to save, a .3mf path on the OrcaSlicer host (Save As). None saves to the project's own path (Save); that fails with no_project_path when the project has never been saved.
overwriteNoReplace an existing file at `path`. Off by default: a collision is an error, never a silent clobber. Saving the project back onto its own path is a plain Save and needs no overwrite.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.21

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, it discloses what gets written, that no dialog opens, how prompts are answered, postconditions such as get_status and recent files, data-loss risk if unsaved, refusal during slicing, and the remote API policy required for replacement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded and mostly earns its length by covering prerequisites, failure modes, and side effects. There is some repetition around File > Save / Save Project As, but the structure remains clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a stateful project-save tool with no output schema, it is complete: it covers contents written, side effects, version requirements, failure modes, and how replacement is gated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by tying replacement of an existing file to the remote API policy and clarifying the new-project path workflow.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: save the open project as a .3mf with its plates and settings. It also explicitly distinguishes itself from save_gcode, which saves sliced G-code instead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear when-to-use guidance, including the File > Save / Save As equivalence and the alternative save_gcode. It also explains the new-project workflow: call new_project and then save_project with a path.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.