Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

derive_assembly_plan

Read-only

Derives an assembly plan from positioned 3D part geometry, eliminating manual declarations and recording materials and optional pin joints for the assembly.

Instructions

Derive an assembly plan from part GEOMETRY — no hand declaration needed.

Needs Kiln Business.

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": "derive_assembly_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
kit_idNoWith ``design_id``, which recorded kit to plan. Empty uses the design's active kit; an id the design does not carry returns an error. Default: "".
materialNoDefault material stamped on each part. Default: "PLA".
design_idNoKit shortcut: a design split with tracking. Used only when ``part_paths`` is empty; the plan then comes from the kit's recorded graph instead of measuring geometry. Default: "".
part_namesNoDisplay names aligned with part_paths (default: file stems).
part_pathsNoOne mesh file per part, positioned as assembled (world coordinates).
pin_recipesNoOptional ``add_pin_joints`` results, each with a ``parts: [a, b]`` pair added, so the plan records the pins on those seams. Used on the geometry path only.
assembly_nameNoCover name for the derived assembly. Default: "derived-assembly".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.5.1
    • changedInput schema / properties / assembly_name / description
      Previous value: -"Default: \"derived-assembly\"."New value: +"Cover name for the derived assembly. Default: \"derived-assembly\"."
    • changedInput schema / properties / design_id / description
      Previous value: -"Default: \"\"."New value: +"Kit shortcut: a design split with tracking. Used only when ``part_paths`` is empty; the plan then comes from the kit's recorded graph instead of measuring geometry. Default: \"\"."
    • changedInput schema / properties / kit_id / description
      Previous value: -"Default: \"\"."New value: +"With ``design_id``, which recorded kit to plan. Empty uses the design's active kit; an id the design does not carry returns an error. Default: \"\"."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"PLA\"."New value: +"Default material stamped on each part. Default: \"PLA\"."
    • addedInput schema / properties / part_names / description
      Added value: +"Display names aligned with part_paths (default: file stems)."
    • addedInput schema / properties / part_paths / description
      Added value: +"One mesh file per part, positioned as assembled (world coordinates)."
    • addedInput schema / properties / pin_recipes / description
      Added value: +"Optional ``add_pin_joints`` results, each with a ``parts: [a, b]`` pair added, so the plan records the pins on those seams. Used on the geometry path only."
  2. Addedv1.5.0

TDQS

A3.6/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 is not required to repeat it. The description adds the Kiln Business entitlement requirement, which is real behavioral context an agent can't get elsewhere. It does not disclose the two internal modes (geometry measurement vs recorded kit graph) or failure behavior, both of which live only in the schema.

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?

Two short sentences, front-loaded with the core action, and nothing redundant. The second line is terse to the point of being cryptic about what "Kiln Business" means and what happens without it.

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?

Annotations cover the safety profile, no output schema exists to explain, and all 7 optional parameters are fully described in the schema including the geometry-vs-kit branching. The description supplies the non-schema prerequisites an agent needs, which is the right division of labor for a read-only planning tool.

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 every one of the 7 optional parameters is already documented with defaults and conditional semantics. The description's "from part GEOMETRY" loosely maps to part_paths but adds no format, coordinate, or precedence detail beyond what the schema states. Baseline 3 applies.

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?

States a specific verb+resource ("derive an assembly plan") and the source of truth ("from part GEOMETRY"), which distinguishes it from sibling tools like create_assembly or plan_assembly_split that presumably build plans differently. It stops short of naming any sibling explicitly, so differentiation still requires reading the schema.

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?

"no hand declaration needed" implies the use case: prefer this over manually declaring an assembly when mesh geometry exists. "Needs Kiln Business" is a genuine prerequisite. However, no alternative is named and no exclusion (e.g. use the kit path when no meshes exist) is given in the description itself.

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