Skip to main content
Glama

await_print_completion

Waits for a 3D print to reach completed, failed, cancelled, or timeout status, so agents can fire-and-forget a print and collect the result later without managing polling.

Instructions

Wait for the current print to finish and return the final status.

Polls the printer (or a specific queued job) until it reaches a
terminal state: completed, failed, cancelled, or the timeout is
exceeded.  This lets agents fire-and-forget a print and pick up the
result later without managing their own polling loop.

A host that runs tools in the background (the MCP tasks extension) gets
a task back instead of a blocked call: keep working,
and the host says when the wait returns.  There one call can wait as
long as the plan needs, up to the whole print.  Closing that app ends
the wait, never the print.

Args:
    job_id: Optional job ID from ``submit_job()``.  When provided,
        tracks that specific job through the queue/scheduler.  When
        omitted, monitors the printer directly for idle/error state.
    timeout: Maximum seconds to wait (default 7200 = 2 hours).
    poll_interval: Seconds between status checks (default 15).
    brief_id: Optional saved-goal id from ``design_session``.  When
        the brief resolves, the terminal-outcome response gains a
        ``design_goal`` block with the design's duty / environment /
        safety notes — so the agent surfacing the print result can
        answer "did this match the goal?" without a separate
        lookup.  Best-effort: missing kiln-pro silently skips.

Returns a dict with ``outcome`` (completed / failed / cancelled /
timeout), final printer state, elapsed time, completion percentage
history, and (when ``brief_id`` resolves) a ``design_goal`` block.

A print carrying a hardware plan (pauses written in for nuts, magnets or
bearings) also returns early with ``outcome: "hardware_stop"`` and a
``hardware`` block: when a stop is a few minutes away, when the printer
has stopped for the parts, and when it went past a stop without
stopping.  Tell the person what the block says, then wait again.  A
finished print's ``hardware`` block names what goes in after the print.

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

Input Schema

NameRequiredDescriptionDefault
job_idNoOptional job ID from ``submit_job()``. When provided, tracks that specific job through the queue/scheduler. When omitted, monitors the printer directly for idle/error state.
timeoutNoMaximum seconds to wait (default 7200 = 2 hours). Default: 7200.
brief_idNoOptional saved-goal id from ``design_session``. When the brief resolves, the terminal-outcome response gains a ``design_goal`` block with the design's duty / environment / safety notes — so the agent surfacing the print result can answer "did this match the goal?" without a separate lookup. Best-effort: missing kiln-pro silently skips. Default: "".
poll_intervalNoSeconds between status checks (default 15). Default: 15.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.5.1
    • changedInput schema / properties / brief_id / description
      Previous value: -"Default: \"\"."New value: +"Optional saved-goal id from ``design_session``.  When the brief resolves, the terminal-outcome response gains a ``design_goal`` block with the design's duty / environment / safety notes — so the agent surfacing the print result can answer \"did this match the goal?\" without a separate lookup.  Best-effort: missing kiln-pro silently skips. Default: \"\"."
    • addedInput schema / properties / job_id / description
      Added value: +"Optional job ID from ``submit_job()``.  When provided, tracks that specific job through the queue/scheduler.  When omitted, monitors the printer directly for idle/error state."
    • changedInput schema / properties / poll_interval / description
      Previous value: -"Default: 15."New value: +"Seconds between status checks (default 15). Default: 15."
    • changedInput schema / properties / timeout / description
      Previous value: -"Default: 7200."New value: +"Maximum seconds to wait (default 7200 = 2 hours). Default: 7200."
  2. Changed7 schema fields changedv1.5.0
    • removedInput schema / properties / brief_id / default
      Removed value: -""
    • addedInput schema / properties / brief_id / description
      Added value: +"Default: \"\"."
    • removedInput schema / properties / job_id / default
      Removed value: -null
    • removedInput schema / properties / poll_interval / default
      Removed value: -15
    • addedInput schema / properties / poll_interval / description
      Added value: +"Default: 15."
    • removedInput schema / properties / timeout / default
      Removed value: -7200
    • addedInput schema / properties / timeout / description
      Added value: +"Default: 7200."
  3. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations, the description explains terminal outcomes, timeout behavior, polling intervals, background-task semantics in hosts supporting MCP tasks, and that closing the app ends only the wait and never the print. It also discloses the special hardware_stop early-return case and what the hardware block tells the agent.

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?

The description is long but well structured, front-loading the purpose and then covering behavior, arguments, returns, and hardware-stop handling. Some of the argument text duplicates the schema, but the content is generally useful for this complex polling tool.

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 compensates by explaining the returned outcome values, final printer state, elapsed time, completion percentage history, optional design_goal block, and hardware block behavior. It is complete enough for an agent to understand both the normal and hardware-stop return paths.

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 description coverage is 100%, and the description largely repeats the schema's parameter explanations for job_id, timeout, poll_interval, and brief_id. It adds surrounding context about job tracking and design-goal resolution, but no new syntax or format details beyond what the schema already provides.

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?

The description states a specific verb and resource: wait for the current print to finish and return its final status. It also distinguishes the tool from a generic status check by explaining that it polls until a terminal state and lets an agent avoid managing its own polling loop.

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 gives clear usage context: use it after fire-and-forget submissions, optionally with a job_id or without one to monitor the printer directly. It does not explicitly name sibling alternatives such as monitor_print or job_status, so it lacks direct when-not guidance, but the intended usage is otherwise 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