Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

export_adaptive_slicer_config

Read-only

Export an adaptive slicing plan as slicer-compatible configuration for PrusaSlicer, OrcaSlicer, Cura, or generic formats, enabling variable layer heights to be applied in the target slicer.

Instructions

Export an adaptive slicing plan as slicer-compatible configuration.

Converts a plan to the target slicer's format — PrusaSlicer and
OrcaSlicer use variable layer height data, Cura uses adaptive
layers plugin format.

Args:
    plan_data: Plan dict from ``generate_adaptive_slicing_plan``.
    slicer: Target slicer — "prusaslicer", "orcaslicer", "cura",
        or "generic".

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": {
      "plan_data": "<plan_data>"
    },
    "name": "export_adaptive_slicer_config"
  }
}

Input Schema

NameRequiredDescriptionDefault
slicerNoTarget slicer — "prusaslicer", "orcaslicer", "cura", or "generic". Default: "prusaslicer".
plan_dataYesPlan dict from ``generate_adaptive_slicing_plan``.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.1
    • addedInput schema / properties / plan_data / description
      Added value: +"Plan dict from ``generate_adaptive_slicing_plan``."
    • changedInput schema / properties / slicer / description
      Previous value: -"Default: \"prusaslicer\"."New value: +"Target slicer — \"prusaslicer\", \"orcaslicer\", \"cura\", or \"generic\". Default: \"prusaslicer\"."
  2. Changed2 schema fields changedv1.5.0
    • removedInput schema / properties / slicer / default
      Removed value: -"prusaslicer"
    • addedInput schema / properties / slicer / description
      Added value: +"Default: \"prusaslicer\"."
  3. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered and the description only needs to add context. It adds the per-slicer format mapping, but leaves ambiguous what 'export' returns (a file path, a config string, or a dict) and does not clarify the tension between 'Export' and a non-destructive read.

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 key statement is front-loaded in the first sentence and the format distinctions follow immediately; the Args block repeats schema descriptions but is short and conventional. Minor redundancy with the schema keeps it from a 5.

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 two-parameter tool with a nested free-form plan_data object and no output schema, the description should say what the returned configuration looks like and whether anything is written to disk. The format mapping is helpful, but the return-value gap leaves an agent guessing after the call.

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 the schema alone would warrant a 3. The description goes beyond the enum list by explaining the consequence of each choice ('PrusaSlicer and OrcaSlicer use variable layer height data, Cura uses adaptive layers plugin format'), which helps the agent pick a value meaningfully.

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 opens with a specific verb and resource ('Export an adaptive slicing plan as slicer-compatible configuration') and then explains the transformation per target slicer, so the agent knows exactly what it produces versus other slicing tools like generate_adaptive_slicing_plan or quick_adaptive_plan.

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?

Usage is only implied: naming plan_data as 'Plan dict from ``generate_adaptive_slicing_plan``' signals the correct upstream call sequence. There is no explicit when-to-use/when-not guidance and no mention of when to prefer alternatives such as get_adaptive_plan_summary or reslice_with_overrides.

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