Kiln

Overview Schema Source Related Servers Discussions Admin

attach_part_feature

Attach a reusable PART feature to a host mesh and compose the result, then open an interactive 3D stage to orbit and inspect the placement.

Instructions

Attach a reusable PART feature onto a host mesh and compose the result. Opens Kiln's interactive inline 3D stage on the result (orbit/zoom panel in MCP Apps hosts; hosted sessions add a browser stage link).

Needs Kiln Pro.

INLINE 3D STAGE: on success this tool opens Kiln's interactive 3D stage — an inline viewer panel the user can orbit, zoom, and turn over — in hosts that render MCP Apps panels (Kiln's hosted connection attaches a browser stage link for hosts that don't). Oversized meshes are decimated automatically for the stage; the PNG preview is the floor, not the whole experience.

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": {
      "host_mesh_path": "<host_mesh_path>"
    },
    "name": "attach_part_feature"
  }
}

Input Schema

Name	Required	Description
`scale`	No	Uniform scale applied to the part at attach time (default ``1.0``). Default: 1.0.
`validate`	No	When true (the default), a composed mesh that is not watertight or is left as disconnected bodies (a flush placement that never fused to the host) is refused, and the refusal says how far to sink the placement. Pass false to keep the mesh as composed. Default: true.
`design_id`	No	Optional host design id for the ATTACHED provenance event; the host mesh path is recorded when omitted.
`feature_id`	No	Feature id — attaches its latest version.
`output_path`	No	Optional composed-STL output path. Default: "".
`target_spec`	No	Optional placement — ``translate`` (a 3-vector) and/or ``rotate`` (a 3-vector of degrees).
`host_mesh_path`	Yes	Readable STL/3MF/OBJ the part attaches onto.
`feature_release_id`	No	Signed-release id — pins and verifies the version the signature covers.
`feature_version_id`	No	Exact feature version id — pins that version; it must be a ``part``. Give exactly one of ``feature_id``, ``feature_version_id`` or ``feature_release_id``.

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv1.5.1Nov 5, 2026

addedInput schema / properties / design_id / description

Added value: +"Optional host design id for the ATTACHED provenance event; the host mesh path is recorded when omitted."

addedInput schema / properties / feature_id / description

Added value: +"Feature id — attaches its latest version."

addedInput schema / properties / feature_release_id / description

Added value: +"Signed-release id — pins and verifies the version the signature covers."

addedInput schema / properties / feature_version_id / description

Added value: +"Exact feature version id — pins that version; it must be a ``part``.  Give exactly one of ``feature_id``, ``feature_version_id`` or ``feature_release_id``."

addedInput schema / properties / host_mesh_path / description

Added value: +"Readable STL/3MF/OBJ the part attaches onto."

changedInput schema / properties / output_path / description

Previous value: -"Default: \"\"."New value: +"Optional composed-STL output path. Default: \"\"."

changedInput schema / properties / scale / description

Previous value: -"Default: 1.0."New value: +"Uniform scale applied to the part at attach time (default ``1.0``). Default: 1.0."

addedInput schema / properties / target_spec / description

Added value: +"Optional placement — ``translate`` (a 3-vector) and/or ``rotate`` (a 3-vector of degrees)."

changedInput schema / properties / validate / description

Previous value: -"Default: true."New value: +"When true (the default), a composed mesh that is not watertight or is left as disconnected bodies (a flush placement that never fused to the host) is refused, and the refusal says how far to sink the placement.  Pass false to keep the mesh as composed. Default: true."

Addedv1.5.0Oct 23, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations only declare the mutation/safety profile; the description adds genuinely new behavior — that the call opens an interactive 3D stage in MCP Apps hosts, that non-panel hosts get a browser stage link, and that oversized meshes are auto-decimated for the viewer. That side-effect disclosure (UI panel opening) is exactly the kind of 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentence is well front-loaded, but the dedicated 'INLINE 3D STAGE:' paragraph restates almost verbatim what the parenthetical in paragraph one already said (orbit/zoom panel, browser link for non-panel hosts). The repetition of the decimation and PNG-preview caveat costs space without new information.

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

Completeness4/5

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

For a 9-parameter mutation tool with a nested target_spec and no output schema, the description covers the tier requirement, the viewer side effect, and mesh-size handling. What an agent still cannot learn is what the composed result returns or where it lands when output_path is omitted, but the schema covers most of that.

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%, including the exactly-one-of constraint on feature_id/feature_version_id/feature_release_id and the validate semantics. The description adds nothing parameter-level beyond what the schema already states, so 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?

The first sentence gives a specific verb and resource ('Attach a reusable PART feature onto a host mesh and compose the result'), which is more precise than the bare name. It does not explicitly distinguish itself from related siblings such as add_assembly_part or compose_part_from_primitives, so the agent must infer the boundary.

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?

'Needs Kiln Pro' is a real prerequisite gate that tells the agent when the call will fail. However, there is no statement of when to prefer this tool over sibling composition tools, nor any exclusion for non-PART features beyond what the schema's feature_version_id note implies.

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

Deploy Server