Skip to main content
Glama
Sign In
orcaslicer-mcp

orcaslicer-mcp

by MaxEllis
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get filament slot mapping

get_filament_slot_mapping
Read-only

Shows which CANVAS tray each plate filament will print from on the next Send for Elegoo Centauri Carbon 2, flagging unmapped filaments or unready trays.

Instructions

Show which CANVAS tray each filament would print from on the next Send (Elegoo Centauri Carbon 2 only); read-only.

The filaments listed are the ones on the plate the next Send would use. 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 reply names the plate (0-based, the current plate) and supported (true, or false with a reason). Each filament has its 0-based index, type, name, colour, the tray it maps to (or null), the source of that choice (saved, matched, user, api or none) and any warnings. valid is true when that Send would go through; if not, problems says why (an unmapped filament, a tray that is not ready). Call it after slicing or changing filaments, before telling the user the plate is ready to send. Nothing is sent to the printer. A supported false reply carries a reason to relay, as get_printer_slots does.

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": "get_filament_slot_mapping"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.19

TDQS

A4.6/5.0
Behavior5/5

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

Beyond readOnlyHint, it discloses a hard latency bound (~18 seconds when no cache exists), a concurrency side effect (OrcaSlicer's API serializes requests, so other tools wait), a firmware/fork prerequisite, and that nothing is sent to the printer. Those are exactly the operational traits an agent needs to sequence and narrate the call.

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?

Front-loaded with the one-line purpose and read-only status, then prerequisites, latency, and reply shape in descending importance. It is dense but every clause carries information; minor cost from the awkward mid-sentence line break around the fork version and the long reply-taxonomy sentence.

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?

With no output schema, the description fully covers the return contract: plate index, supported flag with reason, per-filament index/type/name/colour/tray/source enum (saved, matched, user, api, none), warnings, plus valid and problems. Combined with the version gate and latency note, an agent can call it and interpret the result without further lookups.

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?

There are zero parameters, so there is no parameter meaning to add; the baseline for a no-param tool is 4. The description spends its words on return semantics rather than inventing parameter detail.

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?

States a specific verb and resource — show which CANVAS tray each filament would print from on the next Send — and scopes it to a named printer model with a fork version requirement. It is unmistakably distinct from set_filament_slot_mapping and from get_printer_slots (which it explicitly contrasts the failure payload against).

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

Usage Guidelines4/5

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

"Call it after slicing or changing filaments, before telling the user the plate is ready to send" gives concrete timing and a decision point, and the supported/printer restriction tells the agent when the tool is not applicable. It does not spell out an explicit when-not vs. get_printer_slots beyond the failure-reason comparison, so it falls short of a 5.

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