Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

recommend_adhesion_settings

Read-only

Recommends brim or raft settings from a 3D model’s bed contact area, material warp tendency, and printer type, returning slicer overrides for slicing or printing.

Instructions

Recommend brim/raft settings for a 3D model based on geometry + material.

        Analyzes the model's bed contact area, material warp tendency, and
        printer type to produce a concrete brim width and optional raft
        recommendation.  Returns ``slicer_overrides`` ready to pass to
        ``slice_model`` or ``slice_and_print``.

        Args:
            model_path: Path to an STL or OBJ mesh file.
            material: Filament material (e.g. ``"PLA"``, ``"ABS"``,
                ``"PETG"``).  Affects warp risk calculation.
            printer_id: Optional printer model ID (e.g. ``"bambu_a1"``).
                Used to detect bed-slinger printers that need wider brims.

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

Input Schema

NameRequiredDescriptionDefault
materialNoFilament material (e.g. ``"PLA"``, ``"ABS"``, ``"PETG"``). Affects warp risk calculation. Default: "PLA".
model_pathYesPath to an STL or OBJ mesh file.
printer_idNoOptional printer model ID (e.g. ``"bambu_a1"``). Used to detect bed-slinger printers that need wider brims.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.5.1
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"PLA\"."New value: +"Filament material (e.g. ``\"PLA\"``, ``\"ABS\"``, ``\"PETG\"``).  Affects warp risk calculation. Default: \"PLA\"."
    • addedInput schema / properties / model_path / description
      Added value: +"Path to an STL or OBJ mesh file."
    • addedInput schema / properties / printer_id / description
      Added value: +"Optional printer model ID (e.g. ``\"bambu_a1\"``). Used to detect bed-slinger printers that need wider brims."
  2. Changed3 schema fields changedv1.5.0
    • removedInput schema / properties / material / default
      Removed value: -"PLA"
    • addedInput schema / properties / material / description
      Added value: +"Default: \"PLA\"."
    • removedInput schema / properties / printer_id / default
      Removed value: -null
  3. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and closed-world, so the safety profile is covered; the description usefully adds that this is a pure analysis producing a concrete brim width and optional raft, and that the output is slicer_overrides consumable by slicing tools. It does not say whether mesh parsing can fail or how expensive the analysis is, but beyond the annotations it contributes real behavioral context.

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 first two sentences are well front-loaded and earn their place, but the Args block duplicates the input schema verbatim and inflates the description with information the agent already receives structurally. Trimming the parameter restatement would make it tighter.

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 three-parameter read-only analysis tool with no output schema and full schema coverage, the definition covers what is computed and what the return value is for (slicer_overrides for slice_model/slice_and_print). Remaining gaps are minor, such as the shape of the overrides or behavior when the mesh has no bed contact.

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 coverage is 100%, so the schema already documents all three parameters, and the description's Args block largely restates the same text (material affecting warp risk, printer_id detecting bed-slingers). It adds no new semantics such as accepted material spellings, fallback behavior when printer_id is omitted, or path resolution rules, so the baseline 3 applies.

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 (recommend brim/raft adhesion settings) and scopes it to a model's geometry plus material, which clearly separates it from broad siblings like recommend_settings or infer_print_settings. It also names the concrete factors analyzed (bed contact area, warp tendency, printer type), so an agent can tell exactly what knowledge the tool produces.

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 implied rather than stated: the description says the returned slicer_overrides are "ready to pass to slice_model or slice_and_print," which hints at the downstream workflow but never says when to call this versus alternatives such as analyze_warping_risk, recommend_settings, get_optimal_settings, or print preflight tools. No exclusions or prerequisites are given.

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