Skip to main content
Glama

record_print_outcome

Destructive

Record print outcomes, settings, and failures to build validated cross-printer learning data, helping agents choose suitable printers and materials for future jobs.

Instructions

Record the outcome of a print for cross-printer learning.

The learning database helps agents make better decisions about which
printer to use for a given job and material.  Outcomes are agent-curated
quality data — separate from the auto-populated print history.

**Safety**: Settings are validated against hard safety limits.  Outcomes
with temperatures exceeding safe maximums are rejected to prevent
poisoning the learning database with dangerous data.

**Decoration feedback**: When ``decoration_slug`` is provided, the
corresponding decoration's proven-settings counter is auto-updated
(``success_count`` or ``failure_count``) so the library's tracked
reliability reflects real field outcomes without manual curation.

**Auto-classification** (opt-in): When ``auto_classify=True`` and the
outcome is ``"failed"`` with no explicit ``failure_mode``, the failure
classifier runs (:func:`kiln.failure_recovery.classify_failure`) and
its result is mapped into the canonical DB vocabulary.  The
classification is always echoed back in the ``auto_classification``
key of the response; it is only STORED as ``failure_mode`` when the
classifier's confidence meets or exceeds
``_AUTO_CLASSIFY_MIN_CONFIDENCE`` (0.75).  Lower-confidence guesses
are surfaced to the caller without poisoning the learning database.

Args:
    job_id: The job ID from the print queue.
    outcome: One of ``"success"``, ``"failed"``, ``"partial"``, or
        ``"cancelled"``.
    quality_grade: Optional — ``"excellent"``, ``"good"``, ``"acceptable"``, ``"poor"``.
    failure_mode: Optional — one of ``spaghetti``, ``layer_shift``,
        ``warping``, ``adhesion``, ``stringing``, ``under_extrusion``,
        ``over_extrusion``, ``clog``, ``thermal_runaway``, ``power_loss``,
        ``filament_runout``, ``mechanical``, ``other``.
    settings: Optional dict of print settings used (temp_tool, temp_bed, speed, etc.).
    environment: Optional dict of environment conditions (ambient_temp, humidity).
    notes: Optional — a note on how the print came out, in the words
        of whoever wrote it ("the back-left corner lifted at layer
        40").  Up to 2000 characters; kept with the print on this
        computer and, for a print of a kept design, on the person's
        Kiln account, where the version history shows it with who said
        it.  A person's note is never overwritten
        by an agent's; an agent's is replaced by a later agent's only
        when the ending is at least as surely known.
    note_by: Who wrote ``notes``: ``"person"`` (their own words, which
        you relay as written) or ``"agent"`` (what you saw, as the one
        that watched the print).  When omitted: ``"person"`` for an
        ending the person reported, ``"agent"`` for one you observed
        or saw; a hook's auto-recorded string carries no label.
    clear_note: Delete the note on this print, when the person asks.
        Send the print's ``job_id`` and the ``outcome`` it is recorded
        with (the call is refused if that is not its ending, so the
        wrong print is never changed); nothing else is recorded and the
        ending stays as it was.  The delete reaches the person's Kiln
        account too.
    printer_name: Printer used.  Auto-resolved from job if omitted.
    file_name: File printed.  Auto-resolved from job if omitted.
    file_hash: Optional hash of the file for cross-printer comparison.
    material_type: Material used (e.g. ``"PLA"``, ``"PETG"``).  Omit and
        Kiln backfills it from what the job declared (print history, then
        the queue job) or — for an outcome watched live — from the
        filament the printer currently holds.  Stays unset when no honest
        source knows it; per-material learning skips unset rows rather
        than learning from a guess.
    decoration_slug: Optional decoration slug that was applied to this
        print.  When set, the matching decoration's success/failure
        counters are auto-updated.
    decoration_settings: Optional dict of decoration settings used
        (``depth_mm``, ``mode``, ``image_style``).  Falls back to the
        decoration's current defaults when omitted.
    auto_classify: When True and this outcome is a failure with no
        explicit ``failure_mode``, run the failure classifier; a
        confident guess is stored as ``failure_mode``, a weak one is
        only echoed back in ``auto_classification``.  Default False —
        callers opt in.
    auto_recorded: When True, tags the outcome as auto-fired by
        the terminal-state hook (see
        :mod:`kiln.auto_record_hook`).  Agents can later refine
        the outcome by calling record_print_outcome again with the
        same ``job_id`` — the most recent call wins at the
        ``proven_settings`` level.  Default False.
    determined_by: Who settled this outcome — ``"observed"`` (a
        live process watched the print end), ``"inferred"``
        (reconstructed from printer state after the fact), ``"seen"``
        (a camera frame judged at the ending), or
        ``"user_reported"`` (the human said so).  A weaker source
        never contradicts a decided row.  Defaults to
        ``"observed"`` for auto-recorded outcomes and
        ``"user_reported"`` otherwise — a manual record normally
        relays what the user reported about the part in hand.
        Recording an outcome for a print that started while Kiln
        wasn't watching RESOLVES its pending row in place rather
        than duplicating it.
    print_error: Optional raw firmware error code the print tripped
        (Bambu HMS, e.g. ``50348044``).  Stored as EVIDENCE and kept
        deliberately separate from ``failure_mode``, which is a
        VERDICT: a print the user CANCELLED carries whatever code the
        abort tripped and no failure_mode at all, because a deliberate
        stop is not a machine failure but the firmware's complaint
        still happened and is worth keeping.  A single machine cannot
        characterise a fault from codes like these — what predicts one
        sticking is a question for many printers — so the code is
        captured now against the day there are enough of them to ask.
        ``0`` and unset both store NULL; a backend with no such code
        simply omits it.
    version_id: Optional — the design version that was printed.  A
        print started from a kept design already carries it (the
        start stamps it); pass it here when recording a print Kiln
        did not start, so the ending lands on that version's history.
        Never overwrites a version the start recorded.
    design_id: Optional — the design the version belongs to.
    branch_id: Optional — the branch the version sits on.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "job_id": "<job_id>",
      "outcome": "<outcome>"
    },
    "name": "record_print_outcome"
  }
}

Input Schema

NameRequiredDescriptionDefault
notesNoOptional — a note on how the print came out, in the words of whoever wrote it ("the back-left corner lifted at layer 40"). Up to 2000 characters; kept with the print on this computer and, for a print of a kept design, on the person's Kiln account, where the version history shows it with who said it. A person's note is never overwritten by an agent's; an agent's is replaced by a later agent's only when the ending is at least as surely known.
job_idYesThe job ID from the print queue.
note_byNoWho wrote ``notes``: ``"person"`` (their own words, which you relay as written) or ``"agent"`` (what you saw, as the one that watched the print). When omitted: ``"person"`` for an ending the person reported, ``"agent"`` for one you observed or saw; a hook's auto-recorded string carries no label.
outcomeYesOne of ``"success"``, ``"failed"``, ``"partial"``, or ``"cancelled"``.
settingsNoOptional dict of print settings used (temp_tool, temp_bed, speed, etc.).
branch_idNoOptional — the branch the version sits on.
design_idNoOptional — the design the version belongs to.
file_hashNoOptional hash of the file for cross-printer comparison.
file_nameNoFile printed. Auto-resolved from job if omitted.
clear_noteNoDelete the note on this print, when the person asks. Send the print's ``job_id`` and the ``outcome`` it is recorded with (the call is refused if that is not its ending, so the wrong print is never changed); nothing else is recorded and the ending stays as it was. The delete reaches the person's Kiln account too. Default: false.
version_idNoOptional — the design version that was printed. A print started from a kept design already carries it (the start stamps it); pass it here when recording a print Kiln did not start, so the ending lands on that version's history. Never overwrites a version the start recorded.
environmentNoOptional dict of environment conditions (ambient_temp, humidity).
print_errorNoOptional raw firmware error code the print tripped (Bambu HMS, e.g. ``50348044``). Stored as EVIDENCE and kept deliberately separate from ``failure_mode``, which is a VERDICT: a print the user CANCELLED carries whatever code the abort tripped and no failure_mode at all, because a deliberate stop is not a machine failure but the firmware's complaint still happened and is worth keeping. A single machine cannot characterise a fault from codes like these — what predicts one sticking is a question for many printers — so the code is captured now against the day there are enough of them to ask. ``0`` and unset both store NULL; a backend with no such code simply omits it.
failure_modeNoOptional — one of ``spaghetti``, ``layer_shift``, ``warping``, ``adhesion``, ``stringing``, ``under_extrusion``, ``over_extrusion``, ``clog``, ``thermal_runaway``, ``power_loss``, ``filament_runout``, ``mechanical``, ``other``.
printer_nameNoPrinter used. Auto-resolved from job if omitted.
auto_classifyNoWhen True and this outcome is a failure with no explicit ``failure_mode``, run the failure classifier; a confident guess is stored as ``failure_mode``, a weak one is only echoed back in ``auto_classification``. Default False — callers opt in. Default: false.
auto_recordedNoWhen True, tags the outcome as auto-fired by the terminal-state hook (see :mod:`kiln.auto_record_hook`). Agents can later refine the outcome by calling record_print_outcome again with the same ``job_id`` — the most recent call wins at the ``proven_settings`` level. Default False. Default: false.
determined_byNoWho settled this outcome — ``"observed"`` (a live process watched the print end), ``"inferred"`` (reconstructed from printer state after the fact), ``"seen"`` (a camera frame judged at the ending), or ``"user_reported"`` (the human said so). A weaker source never contradicts a decided row. Defaults to ``"observed"`` for auto-recorded outcomes and ``"user_reported"`` otherwise — a manual record normally relays what the user reported about the part in hand. Recording an outcome for a print that started while Kiln wasn't watching RESOLVES its pending row in place rather than duplicating it.
material_typeNoMaterial used (e.g. ``"PLA"``, ``"PETG"``). Omit and Kiln backfills it from what the job declared (print history, then the queue job) or — for an outcome watched live — from the filament the printer currently holds. Stays unset when no honest source knows it; per-material learning skips unset rows rather than learning from a guess.
quality_gradeNoOptional — ``"excellent"``, ``"good"``, ``"acceptable"``, ``"poor"``.
decoration_slugNoOptional decoration slug that was applied to this print. When set, the matching decoration's success/failure counters are auto-updated.
decoration_settingsNoOptional dict of decoration settings used (``depth_mm``, ``mode``, ``image_style``). Falls back to the decoration's current defaults when omitted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed22 schema fields changedv1.5.1
    • changedInput schema / properties / auto_classify / description
      Previous value: -"Default: false."New value: +"When True and this outcome is a failure with no explicit ``failure_mode``, run the failure classifier; a confident guess is stored as ``failure_mode``, a weak one is only echoed back in ``auto_classification``.  Default False — callers opt in. Default: false."
    • changedInput schema / properties / auto_recorded / description
      Previous value: -"Default: false."New value: +"When True, tags the outcome as auto-fired by the terminal-state hook (see :mod:`kiln.auto_record_hook`).  Agents can later refine the outcome by calling record_print_outcome again with the same ``job_id`` — the most recent call wins at the ``proven_settings`` level.  Default False. Default: false."
    • addedInput schema / properties / branch_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "Optional — the branch the version sits on.",
      +  "title": "Branch Id"
      +}
    • addedInput schema / properties / clear_note
      Added value: +{
      +  "description": "Delete the note on this print, when the person asks. Send the print's ``job_id`` and the ``outcome`` it is recorded with (the call is refused if that is not its ending, so the wrong print is never changed); nothing else is recorded and the ending stays as it was.  The delete reaches the person's Kiln account too. Default: false.",
      +  "title": "Clear Note",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / decoration_settings / description
      Added value: +"Optional dict of decoration settings used (``depth_mm``, ``mode``, ``image_style``).  Falls back to the decoration's current defaults when omitted."
    • addedInput schema / properties / decoration_slug / description
      Added value: +"Optional decoration slug that was applied to this print.  When set, the matching decoration's success/failure counters are auto-updated."
    • addedInput schema / properties / design_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "Optional — the design the version belongs to.",
      +  "title": "Design Id"
      +}
    • addedInput schema / properties / determined_by / description
      Added value: +"Who settled this outcome — ``\"observed\"`` (a live process watched the print end), ``\"inferred\"`` (reconstructed from printer state after the fact), ``\"seen\"`` (a camera frame judged at the ending), or ``\"user_reported\"`` (the human said so).  A weaker source never contradicts a decided row.  Defaults to ``\"observed\"`` for auto-recorded outcomes and ``\"user_reported\"`` otherwise — a manual record normally relays what the user reported about the part in hand. Recording an outcome for a print that started while Kiln wasn't watching RESOLVES its pending row in place rather than duplicating it."
    • addedInput schema / properties / environment / description
      Added value: +"Optional dict of environment conditions (ambient_temp, humidity)."
    • addedInput schema / properties / failure_mode / description
      Added value: +"Optional — one of ``spaghetti``, ``layer_shift``, ``warping``, ``adhesion``, ``stringing``, ``under_extrusion``, ``over_extrusion``, ``clog``, ``thermal_runaway``, ``power_loss``, ``filament_runout``, ``mechanical``, ``other``."
    • addedInput schema / properties / file_hash / description
      Added value: +"Optional hash of the file for cross-printer comparison."
    • addedInput schema / properties / file_name / description
      Added value: +"File printed.  Auto-resolved from job if omitted."
    • addedInput schema / properties / job_id / description
      Added value: +"The job ID from the print queue."
    • addedInput schema / properties / material_type / description
      Added value: +"Material used (e.g. ``\"PLA\"``, ``\"PETG\"``).  Omit and Kiln backfills it from what the job declared (print history, then the queue job) or — for an outcome watched live — from the filament the printer currently holds.  Stays unset when no honest source knows it; per-material learning skips unset rows rather than learning from a guess."
    • addedInput schema / properties / note_by
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "Who wrote ``notes``: ``\"person\"`` (their own words, which you relay as written) or ``\"agent\"`` (what you saw, as the one that watched the print).  When omitted: ``\"person\"`` for an ending the person reported, ``\"agent\"`` for one you observed or saw; a hook's auto-recorded string carries no label.",
      +  "title": "Note By"
      +}
    • addedInput schema / properties / notes / description
      Added value: +"Optional — a note on how the print came out, in the words of whoever wrote it (\"the back-left corner lifted at layer 40\").  Up to 2000 characters; kept with the print on this computer and, for a print of a kept design, on the person's Kiln account, where the version history shows it with who said it.  A person's note is never overwritten by an agent's; an agent's is replaced by a later agent's only when the ending is at least as surely known."
    • addedInput schema / properties / outcome / description
      Added value: +"One of ``\"success\"``, ``\"failed\"``, ``\"partial\"``, or ``\"cancelled\"``."
    • addedInput schema / properties / print_error / description
      Added value: +"Optional raw firmware error code the print tripped (Bambu HMS, e.g. ``50348044``).  Stored as EVIDENCE and kept deliberately separate from ``failure_mode``, which is a VERDICT: a print the user CANCELLED carries whatever code the abort tripped and no failure_mode at all, because a deliberate stop is not a machine failure but the firmware's complaint still happened and is worth keeping.  A single machine cannot characterise a fault from codes like these — what predicts one sticking is a question for many printers — so the code is captured now against the day there are enough of them to ask. ``0`` and unset both store NULL; a backend with no such code simply omits it."
    • addedInput schema / properties / printer_name / description
      Added value: +"Printer used.  Auto-resolved from job if omitted."
    • addedInput schema / properties / quality_grade / description
      Added value: +"Optional — ``\"excellent\"``, ``\"good\"``, ``\"acceptable\"``, ``\"poor\"``."
    • addedInput schema / properties / settings / description
      Added value: +"Optional dict of print settings used (temp_tool, temp_bed, speed, etc.)."
    • addedInput schema / properties / version_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "Optional — the design version that was printed.  A print started from a kept design already carries it (the start stamps it); pass it here when recording a print Kiln did not start, so the ending lands on that version's history. Never overwrites a version the start recorded.",
      +  "title": "Version Id"
      +}
  2. Changed17 schema fields changedv1.5.0
    • removedInput schema / properties / auto_classify / default
      Removed value: -false
    • addedInput schema / properties / auto_classify / description
      Added value: +"Default: false."
    • removedInput schema / properties / auto_recorded / default
      Removed value: -false
    • addedInput schema / properties / auto_recorded / description
      Added value: +"Default: false."
    • removedInput schema / properties / decoration_settings / default
      Removed value: -null
    • removedInput schema / properties / decoration_slug / default
      Removed value: -null
    • removedInput schema / properties / determined_by / default
      Removed value: -null
    • removedInput schema / properties / environment / default
      Removed value: -null
    • removedInput schema / properties / failure_mode / default
      Removed value: -null
    • 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
    • removedInput schema / properties / notes / default
      Removed value: -null
    • removedInput schema / properties / print_error / default
      Removed value: -null
    • removedInput schema / properties / printer_name / default
      Removed value: -null
    • removedInput schema / properties / quality_grade / default
      Removed value: -null
    • removedInput schema / properties / settings / default
      Removed value: -null
  3. Changed1 schema field changedv1.3.1
    • addedInput schema / properties / print_error
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Print Error"
      +}
  4. Changed1 schema field changedv1.3.0
    • addedInput schema / properties / determined_by
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Determined By"
      +}
  5. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only tell us this mutates and is destructive; the description goes far beyond that, disclosing safety rejection of unsafe temperature data, auto-classification confidence threshold (0.75), note-overwrite precedence rules, the clear_note delete path reaching the user's cloud account, determined_by precedence, and version_id being non-overwriting. These are the exact consequences an agent needs before invoking a destructive write.

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 purpose and safety notes are correctly front-loaded, but the document is bloated: the multi-paragraph preamble repeats decoration and auto-classification behavior that the Args block then repeats again, and each parameter duplicates the schema text. Some asides ('captured now against the day there are enough of them to ask') are colorful but not load-bearing for a caller.

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 22-parameter destructive tool with no output schema, the description covers the safety envelope, side effects on decoration counters, the auto_classification response key, note lifecycle, and re-call refinement semantics — everything needed to invoke it without surprises. Handling of auto-resolution and pending-row resolution is also spelled out.

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 Args block is essentially a verbatim restatement of the property descriptions, so the prose adds little the schema does not already carry. The richer semantics (note_by defaults, determined_by precedence, material backfill sources) are valuable but are reproduced identically in the schema, making this additive only at the narrative level.

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 opening line names a specific verb and resource ('Record the outcome of a print') and immediately states the downstream purpose ('for cross-printer learning'). The second paragraph distinguishes it from the closest sibling concept, the auto-populated print history, so an agent knows this is the curated manual path.

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's role — agent-curated quality data feeding learning — and explains opt-in behaviors (auto_classify defaults False, auto_recorded true only for the terminal hook), which tells the agent when each mode applies. It does not explicitly compare against adjacent tools like record_decoration_success, annotate_print, or record_proven_recipe, so there is no full when-not guidance.

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