Skip to main content
Glama
Sign In
orcaslicer-mcp

orcaslicer-mcp

by MaxEllis
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Set filament slot mapping

set_filament_slot_mapping

Assign each plate filament to a specific CANVAS tray for the next Send, replacing the current mapping without starting a print. Use valid tray IDs so OrcaSlicer's Send dialog is pre-filled correctly.

Instructions

Choose which CANVAS tray each filament prints from on the next Send (Elegoo Centauri Carbon 2 only); it starts nothing.

Returns the same reply as get_filament_slot_mapping, so check valid and problems. Needs fork v2.4.2-mcp.14 or later. It reads the printer when no slot list is cached, so it can take up to about 18 seconds, and OrcaSlicer's API serves one request at a time meanwhile, so other tools wait.

The list REPLACES the whole mapping set through the API: a filament left out gets no tray from the API, and an empty list clears the API choices so Send falls back to the saved choices and automatic matching. Include every filament you want pinned.

This starts nothing. OrcaSlicer's own Send dialog opens pre-filled with this mapping and the user still clicks Send. Each tray can serve only one filament (422 duplicate_tray), the tray must be ready (422 tray_not_ready), and the indexes must exist (422 unknown_filament_index, which also covers a project filament that is not on the plate; unknown_tray, slots_unavailable when the printer could not be read; the reply then says why). Malformed lists get 400: each filament at most once, and integers for filament, canvas_id and tray_id. Use get_printer_slots first to pick trays whose material and colour fit.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "mapping": "<mapping>"
    },
    "name": "set_filament_slot_mapping"
  }
}

Input Schema

NameRequiredDescriptionDefault
mappingYesOne entry per filament of the plate the next Send uses (the indexes get_filament_slot_mapping lists): {filament: 0-based filament index, canvas_id, tray_id} from get_printer_slots.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.19

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations, it discloses the write-the-whole-set semantics (omitted filaments lose their tray, empty list clears API choices), a latency bound of ~18 seconds, and an API serialization constraint that makes other tools wait. It adds a version floor and a detailed 422/400 error taxonomy with the meaning of each code.

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 key constraint is front-loaded in the first sentence, but "it starts nothing" is stated twice and the Send-dialog sentence largely restates it, and the long parenthetical error-code run-ons are dense. Still, nearly every clause carries actionable information.

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 single-parameter mutation with no output schema, the definition covers prerequisites, side effects, latency, version requirement, failure modes, and how to read the response. Nothing an agent needs in order to call it safely is missing.

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

Parameters5/5

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

Schema coverage is 100%, so baseline would be 3, but the description adds real meaning: the array is a full replacement set, not a patch, and an empty array has a defined fallback meaning. It also explains the per-entry constraints (each tray serves one filament, indexes must exist) that the schema does not encode.

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?

"Choose which CANVAS tray each filament prints from on the next Send" gives a specific verb, resource, and scope, and immediately bounds it to Elegoo Centauri Carbon 2 only while declaring "it starts nothing." It also names get_filament_slot_mapping as the read counterpart, so the agent can separate it from the sibling without opening schemas.

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 states an explicit ordering prerequisite ("Use get_printer_slots first to pick trays whose material and colour fit") and clarifies that the mapping is only pre-filled while the user still clicks Send, so an agent knows calling this completes nothing. It also tells the agent to consult the returned reply via get_filament_slot_mapping's semantics.

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

Deploy Server

Other Tools