Skip to main content
Glama
Sign In
orcaslicer-mcp

orcaslicer-mcp

by MaxEllis
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

List plates

list_plates
Read-only

Lists a project's plates, their objects, lock state, build volume, and current plate, exposing the 0-based indexes needed by other plate tools and showing whether plates can be added or deleted.

Instructions

List the project's plates with their objects and which one is current; the plate tools take the 0-based index shown here.

For each plate: its 0-based index, name, whether it is current (the one slice, get_gcode, render_plate and get_job_status act on), lock state, build volume and the objects it holds. Also says how many plates the build allows (max) and whether one can be added or deleted right now. Read-only.

Plate numbers shown in the OrcaSlicer window are 1-based; every tool here takes the 0-based index from this list. Needs fork v2.4.2-mcp.13 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": "list_plates"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.17

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, and the description reinforces it while adding real context beyond the annotations: the enumerated return fields, the max-plate count, whether a plate can be added or deleted right now, and a version prerequisite ('Needs fork v2.4.2-mcp.13 or later'). The version gate is useful operational information the annotations cannot carry.

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 core purpose and return contents, then the index convention, then the version requirement. Slight redundancy: the 0-based index is described twice across paragraphs, and the parenthetical tool list adds bulk, but nothing is wasted outright.

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?

There is no output schema, so the description carries the full burden of describing the return value, and it does: per-plate index, name, current flag, lock state, build volume and contained objects, plus the max count and add/delete eligibility. Combined with the version prerequisite, nothing an agent needs to call this correctly is missing.

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?

The tool takes zero parameters, so the baseline is 4. The description compensates for the only semantic question a caller has — that plate indices in arguments are 0-based and differ from the UI's 1-based numbering.

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 ('List the project's plates with their objects and which one is current') and immediately ties it to consumers: 'the plate tools take the 0-based index shown here.' An agent knows exactly what it gets back and why it matters, distinct from describe_plate or list_objects.

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?

Gives concrete usage guidance: every plate-facing tool takes the 0-based index returned by this call, and explains the 1-based/0-based mismatch with the OrcaSlicer UI. It doesn't explicitly say 'call this first before add_plate/delete_plate,' but the index framing makes the workflow clear.

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