Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

run_benchmark

Destructive

Validates, slices, and uploads a benchmark model using the selected printer profile, then reports printer history stats; the print must be started manually.

Instructions

Prepare a benchmark print: validate → slice → upload → report stats.

Slices a model with the printer's profile and uploads it, then
reports printer stats from history. The print is NOT started
automatically — benchmarks should be manually observed.

Args:
    model_path: Path to benchmark model (STL).
    printer_name: Registered printer name.
    printer_id: Printer model ID for profile selection.
    profile_path: Explicit slicer profile path.
    skip_validation: Bypass the pre-print mesh validation step.
        Defaults to False — user-supplied benchmark meshes are
        pre-tested for printability.  Set to True for known-good
        fixed reference benchmark models.

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": {
      "model_path": "<model_path>"
    },
    "name": "run_benchmark"
  }
}

Input Schema

NameRequiredDescriptionDefault
model_pathYesPath to benchmark model (STL).
printer_idNoPrinter model ID for profile selection.
printer_nameNoRegistered printer name.
profile_pathNoExplicit slicer profile path.
skip_validationNoBypass the pre-print mesh validation step. Defaults to False — user-supplied benchmark meshes are pre-tested for printability. Set to True for known-good fixed reference benchmark models. Default: false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.5.1
    • addedInput schema / properties / model_path / description
      Added value: +"Path to benchmark model (STL)."
    • addedInput schema / properties / printer_id / description
      Added value: +"Printer model ID for profile selection."
    • addedInput schema / properties / printer_name / description
      Added value: +"Registered printer name."
    • addedInput schema / properties / profile_path / description
      Added value: +"Explicit slicer profile path."
    • changedInput schema / properties / skip_validation / description
      Previous value: -"Default: false."New value: +"Bypass the pre-print mesh validation step. Defaults to False — user-supplied benchmark meshes are pre-tested for printability.  Set to True for known-good fixed reference benchmark models. Default: false."
  2. Changed5 schema fields changedv1.5.0
    • removedInput schema / properties / printer_id / default
      Removed value: -null
    • removedInput schema / properties / printer_name / default
      Removed value: -null
    • removedInput schema / properties / profile_path / default
      Removed value: -null
    • removedInput schema / properties / skip_validation / default
      Removed value: -false
    • addedInput schema / properties / skip_validation / description
      Added value: +"Default: false."
  3. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

The description adds useful behavior beyond the annotations: the pipeline order, the upload step, that the print is not started, and that benchmarks should be manually observed. It does not explain what the destructive upload may overwrite, whether existing files are replaced, or what permissions or printer state are required.

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 purpose and process are front-loaded in a short arrow-style summary, followed by concise behavioral notes. The Args section is largely redundant because the same parameter descriptions already exist in the schema, but the overall structure remains clear and efficient.

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

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-step mutation tool with no output schema, the description explains the pipeline and the no-auto-start behavior well. It remains vague about the reported printer stats, upload destination or overwrite behavior, and failure handling, which leaves meaningful gaps for an agent invoking it.

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%, so all five parameters are already documented in the input schema. The description repeats those parameter meanings, including the skip_validation context, but does not add precedence rules for printer_name versus printer_id or other meaning beyond the schema.

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 description gives a specific pipeline: validate, slice, upload, and report stats for a benchmark print. It clearly states the print is not started automatically, which distinguishes it from ordinary print-starting tools, but it does not explicitly differentiate itself from similarly named benchmark or slicing siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies the tool is for benchmark prints and explains the skip_validation choice for known-good reference models. However, it does not say when to use this instead of slice_model, slice_and_print, print_bench, start_print, or other related siblings.

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