Skip to main content
Glama
Sign In
orcaslicer-mcp

orcaslicer-mcp

by MaxEllis
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get printer status

get_printer_status
Read-only

Reads the connected 3D printer’s current state, temperatures, job progress, and reported problems so you can check what it is doing without sending commands.

Instructions

Read what the 3D printer is doing now (state, temperatures, job progress, problems); wait_for_printer waits for a point in a print.

It reports state (idle, heating, printing, paused, finished, cancelled, error, shutdown, offline), nozzle and bed temperatures with their targets, the current job (file, progress, layer, time elapsed and left, and what the time left is based on), and any problems the printer reports, each in the printer's own words with a plain-English hint for common ones. Relay headline as-is. Never invent a cause the printer did not report.

Finds the printer from OrcaSlicer's active printer profile (or ORCA_PRINTER_URL), so it needs no extra setup once the printer is connected in OrcaSlicer. Klipper (Moonraker) printers report the most; OctoPrint reports basic status. Read-only: it never sends commands to the printer.

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_printer_status"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.17

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, yet the description still adds substance: 'Read-only: it never sends commands to the printer', per-backend reporting fidelity (Klipper/Moonraker reports the most, OctoPrint basic status), and an output-processing rule ('Relay `headline` as-is. Never invent a cause the printer did not report'). The offline/error states listed as possible return values tell the agent what a degraded read looks like.

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 the sibling contrast before any detail, and every sentence contributes either routing or grounding information. The middle paragraph enumerating return fields is dense but slightly over-specified given the guidance says return values needn't be spelled out without an output schema.

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 carries the return-value burden itself and does so — state enum, temperature targets, job fields, and error reporting are all covered. It also answers the practical setup question ('finds the printer from OrcaSlicer's active printer profile (or ORCA_PRINTER_URL)') so the agent doesn't treat the tool as needing configuration.

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 there is no schema surface to compensate for; the description correctly stays silent on arguments rather than inventing them. The implicit parameter is environmental (the active OrcaSlicer profile), which is only loosely documented.

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?

Leads with a specific verb and resource: 'Read what the 3D printer is doing now', then enumerates the concrete payload (state, temperatures, job progress, problems). It also explicitly distinguishes itself from the named sibling wait_for_printer by contrast, so an agent can route without opening either schema.

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?

Names wait_for_printer and the condition that selects it ('waits for a point in a print'), which is a real alternative test. It does not address overlap with the sibling get_job_status even though this tool also returns 'the current job (file, progress, layer...)', leaving one ambiguous boundary unaddressed.

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