Skip to main content
Glama
MaxEllis

orcaslicer-mcp

Recall past prints of this model

recall_prints
Read-only

How did past prints of THIS model actually turn out? Matches the current plate by geometry (or by model_name if given / the slicer is offline), returning each past print's result (success/cancelled/error), your recorded verdict (e.g.

Instructions

How did past prints of THIS model actually turn out? Matches the current plate by geometry (or by model_name if given / the slicer is offline), returning each past print's result (success/cancelled/error), your recorded verdict (e.g. 'warped'), and the settings it was sliced with. Call this BEFORE slicing and tell the user anything relevant (a past warp, a failed layer height). Each row also carries failure_reason (the printer's own words, when known) and the slicer's estimates (est_time_s, est_filament_g). duration_s is Moonraker's whole job time, including heating up and any pauses, so beside the estimates it overstates an overrun; list_print_history compares the print time (without heating or pauses) with the estimate. filament_g comes from the G-code file's own estimate, because printers don't report grams. Call list_print_history first to pull in recent results. Read-only. Returns available=false and nothing else when no outcome store exists yet. If neither geometry nor name matches, it returns the most recent prints of ANY model with matched_by='recent'; never attribute those to the current model.

Input Schema

NameRequiredDescriptionDefault
limitNo
model_nameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.10

TDQS

A4.7/5.0
Behavior5/5

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

Annotations cover readOnlyHint, but the description adds substantial context beyond that: it explains the geometry vs. model_name vs. offline matching logic, the available=false empty-store case, the matched_by='recent' fallback, and clarifies duration_s vs. est_time_s and where filament_g comes from. This is rich behavioral disclosure.

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

Conciseness3/5

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

Front-loaded with the core purpose, but the body rambles across many clauses about duration_s, est_time_s, filament_g, and list_print_history. Several sentences are dense and run together, diluting the key routing instructions.

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 2-param read-only tool with no output schema, the description covers matching behavior, fallback semantics, return fields, edge cases (no store), and cross-tool workflow. An agent has everything needed to call it correctly.

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 0%, so the description must compensate. It explains the model_name-fallback ('or by model_name if given / the slicer is offline') but says nothing about limit's meaning or default behavior, leaving one of two parameters partly undocumented.

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?

Opens with a direct framing question and states the specific function: matching the current plate by geometry or model_name and returning past print results. The distinction from list_print_history is made explicit (recall vs. pull recent results).

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?

Explicitly says 'Call this BEFORE slicing' and 'Call list_print_history first to pull in recent results,' naming the alternative and the ordering. The matched_by='recent' fallback and the instruction never to attribute those rows to the current model is a clear when-not-to-conclude rule.

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