Kiln

Overview Schema Source Related Servers Discussions Admin

get_model_print_history

Read-only

Retrieves every print attempt for a 3D model, including outcomes, settings, and quality grades. Filter success-rate metrics by material to see how a design performs in a specific filament.

Instructions

Get all print attempts for a model.

        Returns the complete history of print outcomes, settings, and
        quality grades.  The success-rate metrics cover every material
        by default; pass ``material`` to scope them to one filament
        ("how does this do in PETG?").

        PASS ``model_path`` WHENEVER YOU HAVE THE FILE.  History is a
        question about the SHAPE, and ``model_path`` lets Kiln identify
        it directly.  A file hash alone identifies BYTES: re-export an
        unchanged part from CAD and the hash changes, so a hash-only
        lookup reports a part with real history as never printed.

        ``identified_by`` in the response says which it used —
        ``"shape"`` is the precise answer, ``"file"`` means the history
        may be incomplete.

        Args:
            file_hash: SHA-256 hash of the model file, when known.
            material: Optional material filter for the success-rate
                metrics.  Empty = all materials.
            model_path: Path to the model file — the best input.  Kiln
                fingerprints it and identifies the design itself.
            geometric_signature: v1 shape signature, if you already have
                one from ``fingerprint_model``.
            geometric_signature_v2: v2 shape signature, likewise.

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

Input Schema

Name	Required	Description
`material`	No	Optional material filter for the success-rate metrics. Empty = all materials. Default: "".
`file_hash`	No	SHA-256 hash of the model file, when known. Default: "".
`model_path`	No	Path to the model file — the best input. Kiln fingerprints it and identifies the design itself. Default: "".
`geometric_signature`	No	v1 shape signature, if you already have one from ``fingerprint_model``. Default: "".
`geometric_signature_v2`	No	v2 shape signature, likewise. Default: "".

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv1.5.1Nov 5, 2026

changedInput schema / properties / file_hash / description

Previous value: -"Default: \"\"."New value: +"SHA-256 hash of the model file, when known. Default: \"\"."

changedInput schema / properties / geometric_signature / description

Previous value: -"Default: \"\"."New value: +"v1 shape signature, if you already have one from ``fingerprint_model``. Default: \"\"."

changedInput schema / properties / geometric_signature_v2 / description

Previous value: -"Default: \"\"."New value: +"v2 shape signature, likewise. Default: \"\"."

changedInput schema / properties / material / description

Previous value: -"Default: \"\"."New value: +"Optional material filter for the success-rate metrics.  Empty = all materials. Default: \"\"."

changedInput schema / properties / model_path / description

Previous value: -"Default: \"\"."New value: +"Path to the model file — the best input.  Kiln fingerprints it and identifies the design itself. Default: \"\"."

Changed10 schema fields changedv1.5.0Oct 23, 2026
- removedInput schema / properties / file_hash / default
```
Removed value: -""
```
- addedInput schema / properties / file_hash / description
```
Added value: +"Default: \"\"."
```
- removedInput schema / properties / geometric_signature / default
```
Removed value: -""
```
- addedInput schema / properties / geometric_signature / description
```
Added value: +"Default: \"\"."
```
- removedInput schema / properties / geometric_signature_v2 / default
```
Removed value: -""
```
- addedInput schema / properties / geometric_signature_v2 / description
```
Added value: +"Default: \"\"."
```
- removedInput schema / properties / material / default
```
Removed value: -""
```
- addedInput schema / properties / material / description
```
Added value: +"Default: \"\"."
```
- removedInput schema / properties / model_path / default
```
Removed value: -""
```
- addedInput schema / properties / model_path / description
```
Added value: +"Default: \"\"."
```

Changed5 schema fields changedv1.3.1Aug 19, 2026

addedInput schema / properties / file_hash / default
```
Added value: +""
```

addedInput schema / properties / geometric_signature

Added value: +{
+  "default": "",
+  "title": "Geometric Signature",
+  "type": "string"
+}

addedInput schema / properties / geometric_signature_v2

Added value: +{
+  "default": "",
+  "title": "Geometric Signature V2",
+  "type": "string"
+}

addedInput schema / properties / model_path

Added value: +{
+  "default": "",
+  "title": "Model Path",
+  "type": "string"
+}

removedInput schema / required
```
Removed value: -[
-  "file_hash"
-]
```

Changed1 schema field changedv1.3.0Jul 30, 2026
- addedInput schema / properties / material
```
Added value: +{
+  "default": "",
+  "title": "Material",
+  "type": "string"
+}
```
First observedv0.1.0Jul 4, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the readOnly/non-destructive annotations, the description discloses the response contract ('identified_by' returns "shape" or "file") and the consequence that a file-scoped lookup may report a part with real history as never printed. That failure mode is exactly the kind of behavioral context annotations cannot carry.

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?

Purpose is front-loaded, then the identity/fingerprint rationale, then the response caveat, then Args — a sensible order with minimal filler. The explicit Args block largely duplicates a schema that already has 100% description coverage, which is the main redundancy.

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 key response field and its interpretation. All five optional inputs are accounted for and the preferred-path behavior is spelled out, leaving nothing an agent needs in order to call this 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 100%, so baseline is 3, but the description adds genuine meaning: it ranks model_path as the preferred input, explains why a hash identifies bytes rather than shape, and describes where the geometric signature parameters come from (fingerprint_model). Some of the Args text merely restates the schema descriptions.

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?

Opening sentence gives a specific verb and resource ('Get all print attempts for a model') and the body clarifies the returned content (outcomes, settings, quality grades). It does not, however, distinguish this from adjacent history-style siblings such as print_history, failure_history, or get_part_passport, so an agent has to infer which history tool applies.

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?

Strong explicit guidance on input selection: 'PASS model_path WHENEVER YOU HAVE THE FILE' with a concrete rationale, plus a worked example for the material filter ('how does this do in PETG?'). It stops short of naming an alternative tool or stating when not to use this one, leaving sibling routing implicit.

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

Deploy Server