Skip to main content
Glama

suggest_printer_for_job

Read-only

Suggests which 3D printer to use for a job by ranking printers on past success rates, optional file hash or material filters, and current availability.

Instructions

Suggest the best printer for a job based on historical outcomes.

        Rankings are based on success rates from previously recorded outcomes,
        optionally filtered by file hash or material type.  Cross-references
        the printer registry for current availability.

        **Note**: Suggestions are advisory.  They do NOT override safety limits
        or preflight checks.  Always run preflight validation before starting
        a print regardless of learning data.

        Each suggestion also says ``has_room``: whether that printer's plate,
        as Kiln's record has it, can take a print right now (a clear plate;
        a part still on it, or no record, is ``false``), with the plate
        block beside it.  Advisory, like the rest: the slice and start doors
        judge the real part against the real plate.  The plate reading is a
        fleet feature (Kiln Business), the same on every install; below
        its tier ``has_room`` is ``null`` and ``plate_note`` says so, once.
        When the plates could not be read (offline, signed out, no
        answer), ``has_room`` is ``null`` and ``plate_note`` says why.

        Args:
            file_hash: Optional hash of the file to match previous prints.
            material_type: Optional material type to filter by (e.g. ``"PLA"``).
            file_name: Optional file name (informational, not used for matching).
        

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

Input Schema

NameRequiredDescriptionDefault
file_hashNoOptional hash of the file to match previous prints.
file_nameNoOptional file name (informational, not used for matching).
material_typeNoOptional material type to filter by (e.g. ``"PLA"``).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.5.1
    • addedInput schema / properties / file_hash / description
      Added value: +"Optional hash of the file to match previous prints."
    • addedInput schema / properties / file_name / description
      Added value: +"Optional file name (informational, not used for matching)."
    • addedInput schema / properties / material_type / description
      Added value: +"Optional material type to filter by (e.g. ``\"PLA\"``)."
  2. Changed3 schema fields changedv1.5.0
    • removedInput schema / properties / file_hash / default
      Removed value: -null
    • removedInput schema / properties / file_name / default
      Removed value: -null
    • removedInput schema / properties / material_type / default
      Removed value: -null
  3. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true with no destruction or open-world access, and the description adds substantial context on top: rankings derive from recorded success rates, the printer registry is consulted for availability, and the advisory nature means it cannot bypass safety gates. It also documents tier-gating (fleet/Kiln Business), the null conditions for unreadable plates, and what plate_note reports, though it does not state the overall shape or ordering of the returned suggestions.

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?

The core purpose and the advisory caveat are front-loaded, which is good, but the has_room/plate_note paragraph is long and heavy with incidental detail (tier behavior, 'says so, once', offline/signed-out states) that competes with the primary guidance. It reads as accumulated documentation rather than a tight, prioritized definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 burden of explaining returns and does so for the notable fields (has_room, plate_note) while covering advisory limits and tier dependence. It falls short only in not describing the main suggestion payload itself — printer identity, ranking order, or how suggestions are ordered by success rate.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents all three optional parameters. The Args block restates the schema text almost verbatim — including the note that file_name is informational and not used for matching — adding essentially no meaning beyond what the structured field descriptions already supply.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb and resource — recommending a printer for a job — and names the evidence basis (historical outcomes). It is distinguishable from mutation-oriented siblings like route_print_job or start_print, though it never names a sibling to contrast 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?

It clearly frames the tool as advisory and explicitly directs the agent elsewhere for enforcement: 'They do NOT override safety limits or preflight checks. Always run preflight validation before starting a print.' That gives a real when-not condition and a companion action, but it does not distinguish this from other selection tools such as route_print_job or optimize_fleet_assignment.

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