Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

get_design_ancestry

Read-only

Trace a recipe's parent chain back to the root snapshot to understand design ancestry and version history before editing or printing.

Instructions

Walk the parent chain from a recipe back to the root.

Needs Kiln 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": {
      "recipe_path": "<recipe_path>"
    },
    "name": "get_design_ancestry"
  }
}

Input Schema

NameRequiredDescriptionDefault
max_depthNoMaximum ancestor hops (default 50). Default: 50.
recipe_pathYesPath to the starting ``.kiln_recipe.json`` file (or any versioned snapshot like ``.kiln_recipe.v3.json``).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.1
    • changedInput schema / properties / max_depth / description
      Previous value: -"Default: 50."New value: +"Maximum ancestor hops (default 50). Default: 50."
    • addedInput schema / properties / recipe_path / description
      Added value: +"Path to the starting ``.kiln_recipe.json`` file (or any versioned snapshot like ``.kiln_recipe.v3.json``)."
  2. Addedv1.5.0

TDQS

A3.5/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. The description adds one piece of non-obvious context—the Kiln Pro entitlement requirement—but says nothing about what the walk returns, whether the starting recipe is included, ordering, or what happens at the root.

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 with the traversal behavior front-loaded and the prerequisite stated second; nothing is wasted. The style is terse to the point that there is no room for any qualifying detail, but it is appropriately sized for a two-parameter read tool.

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 simple, non-destructive read with full schema coverage and no output schema, the description conveys enough to invoke it correctly: what is traversed, from what starting point, and the entitlement gate. Only edge-case behavior (root reached, depth cap hit, missing file) is unaddressed, which is a minor gap.

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 both recipe_path (including versioned snapshot forms) and max_depth (default 50) are fully documented in the schema. The description's "from a recipe" loosely corresponds to recipe_path but adds no detail on max_depth semantics or path resolution, 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?

"Walk the parent chain from a recipe back to the root" names a specific operation and a precise traversal scope, so an agent can tell this returns an ancestor chain rather than a version list. It does not name or contrast with near-siblings such as show_design_lineage, get_design_version, or diff_design_versions, so differentiation is left to inference.

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 eligibility prerequisite that tells the agent not to call this on lower tiers. However, there is no guidance on when to use ancestry traversal versus other lineage/version tools, nor any stated behavior for missing roots or depth exhaustion.

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