Skip to main content
Glama

plan_multi_copy_split

Destructive

Plan how many copies of a part fit across registered printers based on current plate space; optionally submit the approved plan to queue jobs per printer.

Instructions

Plan many copies of one part across your printers, wherever there is safe room.

        Requires Kiln Business.  Kiln reads every registered printer's
        plate as it stands and works out how many copies each printer
        takes now -- an empty plate filled, an occupied one filled
        beside what is already there -- and how many follow as later
        plates once a plate is cleared.  A printer marked needs repair,
        a plate nobody has looked at, or a plate with no room takes
        none, and says why.  By default the faster printers take more,
        so the run ends as soon as it can; ``share="even"`` gives every
        printer the same share.  The plan says when the run ends both
        ways, and how many more plates finishing sooner leaves to clear.
        Below Kiln Business, copies print on one printer with
        ``multi_copy_print(fill=True)``, plate after plate.

        Two steps.  Call it with the part (STL, 3MF or OBJ) and how many
        copies: it answers ``plan_id``, the plan per printer, and
        ``picture``, a top-down map of every plate.  AGENT DISPLAY
        CONTRACT: show ``picture`` to the person before anything is
        queued, and say ``message``.  When they say go, call it again
        with the same ``file_path`` and ``copies``, ``plan_id`` and
        ``submit=True`` (and ``preview_token``): one job per printer is
        queued, printers run side by side, each waits for its plate to
        be clear, and later plates follow on the same printer.  Follow
        the run with ``split_plan_status(plan_id)``; stop it with
        ``cancel_split_plan(plan_id)``.

        Args:
            file_path: The part, as a mesh (STL, 3MF or OBJ).
            copies: How many copies in all.
            material: The filament (default ``"pla"``).
            plan_id: The plan to queue, from the first call.
            submit: Queue the plan named by ``plan_id``.
            preview_token: The person's yes for the part, when submitting.
            quality: "draft", "standard" or "fine".
            priority: "low", "normal" or "high".
            share: "soonest" (the default) or "even".
        

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": {
      "file_path": "<file_path>",
      "copies": "<copies>"
    },
    "name": "plan_multi_copy_split"
  }
}

Input Schema

NameRequiredDescriptionDefault
shareNo"soonest" (the default) or "even". Default: "soonest".
copiesYesHow many copies in all.
submitNoQueue the plan named by ``plan_id``. Default: false.
plan_idNoThe plan to queue, from the first call.
qualityNo"draft", "standard" or "fine".
materialNoThe filament (default ``"pla"``). Default: "pla".
priorityNo"low", "normal" or "high".
file_pathYesThe part, as a mesh (STL, 3MF or OBJ).
preview_tokenNoThe person's yes for the part, when submitting.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv1.5.1
    • addedInput schema / properties / copies / description
      Added value: +"How many copies in all."
    • addedInput schema / properties / file_path / description
      Added value: +"The part, as a mesh (STL, 3MF or OBJ)."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"pla\"."New value: +"The filament (default ``\"pla\"``). Default: \"pla\"."
    • addedInput schema / properties / plan_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "The plan to queue, from the first call.",
      +  "title": "Plan Id"
      +}
    • addedInput schema / properties / preview_token
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "The person's yes for the part, when submitting.",
      +  "title": "Preview Token"
      +}
    • addedInput schema / properties / priority
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "\"low\", \"normal\" or \"high\".",
      +  "title": "Priority"
      +}
    • addedInput schema / properties / quality
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "\"draft\", \"standard\" or \"fine\".",
      +  "title": "Quality"
      +}
    • addedInput schema / properties / share
      Added value: +{
      +  "description": "\"soonest\" (the default) or \"even\". Default: \"soonest\".",
      +  "title": "Share",
      +  "type": "string"
      +}
    • addedInput schema / properties / submit
      Added value: +{
      +  "description": "Queue the plan named by ``plan_id``. Default: false.",
      +  "title": "Submit",
      +  "type": "boolean"
      +}
  2. Changed2 schema fields changedv1.5.0
    • removedInput schema / properties / material / default
      Removed value: -"pla"
    • addedInput schema / properties / material / description
      Added value: +"Default: \"pla\"."
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=true) by explaining per-printer decisions: empty vs occupied plates, needs-repair and uninspected plates taking zero with a stated reason, share mode defaulting to soonest. It also discloses the side effect of submit=True (one job per printer queued, run side by side, each waiting for a clear plate) and the required human confirmation via picture and message.

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 and gating conditions are front-loaded, then the two-step protocol, then args; the ordering is easy to follow. The closing Args block largely duplicates a schema that is already fully described, which costs some efficiency.

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 carries return-shape duty and does it: plan_id, per-printer plan, and picture, plus how to track and cancel the run. For a nine-parameter, two-phase, business-gated tool, everything an agent needs to invoke it correctly is present.

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 baseline is 3; the description adds meaning by explaining how parameters combine across the two calls (same file_path and copies plus plan_id, submit, and preview_token on the second call) and by characterizing preview_token as the person's explicit yes. The Args list otherwise restates the schema field-for-field.

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?

States a specific verb and resource ("Plan many copies of one part across your printers") and constrains scope ("wherever there is safe room"). It is clearly separable from siblings like multi_copy_print (single printer, plate after plate), plan_assembly_split, and split_plan_status.

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

Usage Guidelines5/5

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

Explicitly names the precondition (Requires Kiln Business) and the fallback path when unmet (multi_copy_print(fill=True)). It also gives the two-step call protocol and points to split_plan_status and cancel_split_plan for follow-up, so when-to-use and alternatives are both covered.

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