Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

get_proven_recipe

Read-only

Retrieve a proven recipe for a specific decoration and product combination, giving you tested print settings instead of guesswork.

Instructions

Get the proven recipe for a decoration + product combination (Pro).

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": {
      "decoration_type": "<decoration_type>",
      "product_type": "<product_type>"
    },
    "name": "get_proven_recipe"
  }
}

Input Schema

NameRequiredDescriptionDefault
materialNoThe material you'll print with (``PLA``, ``PETG``).
printer_nameNoThe printer you'll print on; its model and nozzle are read from what Kiln holds for it. Omit for the one printer Kiln knows of.
product_typeYes``ashtray``, ``frisbee``, ``wall_plaque``, etc.
filament_lineNoThe filament's line when you know it (``PLA Basic``, ``PLA Matte``); never guessed.
decoration_typeYes``logo_deboss``, ``photo_emboss``, ``text_deboss``, or ``qr_code``.
nozzle_diameter_mmNoYour nozzle size, if not on record.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.1

TDQS

B3.3/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 the safety profile is covered by structured data. The description contributes the '(Pro)' tier requirement, which is genuinely new behavioral information. It stops short of describing the miss case (no recipe recorded for the combination) or whether defaults are substituted.

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?

A single short sentence with the resource front-loaded and no wasted wording. It is arguably too terse for the amount of undefined terminology ('proven recipe'), but nothing is padded or redundant.

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

Completeness2/5

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

With six parameters and no output schema, the description must explain what a 'proven recipe' actually contains (slicer settings? decoration parameters?) and what a miss looks like. Neither is addressed, and the only differentiation from the list/record siblings is the tool name itself. This leaves an agent unable to anticipate the response shape for a non-trivial lookup.

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%, with each of the six parameters documented in the schema (materials, printer_name omission semantics, decoration_type values, etc.). The description only restates that decoration and product types are the lookup key, adding no format or precedence guidance beyond the schema, 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?

States a specific verb ('Get') and resource ('the proven recipe') scoped to a decoration + product combination, so the agent knows exactly what it returns. It does not explicitly distinguish itself from the close siblings list_proven_recipes (enumeration) and record_proven_recipe (write), leaving the agent to infer the split from the names alone.

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: look up a known-good recipe before configuring a decoration on a given product. The '(Pro)' marker hints at an entitlement gate, which is useful context. However, there is no explicit when-to-use versus list_proven_recipes, and no statement of what to do when no proven recipe exists.

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