Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

find_design_templates

Read-only

Search print-verified parametric part templates for a functional part like a bracket, bin, or adapter, then fill in the user's dimensions to generate a printable STL.

Instructions

Find a ready-made parametric part for what the user is making.

        CALL THIS FIRST whenever a user asks for a FUNCTIONAL PART to
        their own dimensions — a bracket that holds a shelf, a bin
        that fits a drawer, a clip for an 8 mm cable, a case for a
        board, an adapter between two hose sizes.  Kiln ships a
        library of print-verified parametric parts; offering one is
        faster and more reliable than writing OpenSCAD from scratch,
        it is FREE, and it needs no AI provider or API key.  Do not
        wait to be asked whether a template exists — search, and if
        something fits, offer it.

        Ranked best match first, across both libraries:

        * ``generatable: true`` — a PARAMETRIC PART.  The result
          carries its parameters, so you can fill in the user's
          dimensions and call ``generate_from_template(template_id, {...})``
          to render a printable STL.
        * ``generatable: false`` — a DESIGN PATTERN (snap fit, living
          hinge, press fit).  Guidance for OpenSCAD you write
          yourself; ``generate_from_template`` does not accept it.

        No match is a normal answer, not a failure — fall back to
        writing OpenSCAD and compiling with ``compile_scad``.

        Args:
            use_case: What the user is making, in their words —
                e.g. "shelf bracket", "storage bin", "cable clip",
                "enclosure", "gear train", "hose adapter".

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": {
      "use_case": "<use_case>"
    },
    "name": "find_design_templates"
  }
}

Input Schema

NameRequiredDescriptionDefault
use_caseYesWhat the user is making, in their words — e.g. "shelf bracket", "storage bin", "cable clip", "enclosure", "gear train", "hose adapter".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.1
    • addedInput schema / properties / use_case / description
      Added value: +"What the user is making, in their words — e.g. \"shelf bracket\", \"storage bin\", \"cable clip\", \"enclosure\", \"gear train\", \"hose adapter\"."
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover read-only/non-destructive/non-open-world, so credit goes to what the description adds: results are ranked best-match-first across two libraries, the generatable flag determines whether generate_from_template will accept the result, and the search is free with no API key. It does not disclose result count/limit or pagination, which is a minor gap for a search tool.

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?

The prime directive is front-loaded in capitals and the result-type breakdown is cleanly bulleted. It runs long, and the trailing Args section duplicates the schema text, which is the only real waste in an otherwise well-structured description.

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?

For a single-parameter search tool with no output schema, the description supplies everything an agent needs: when to call it, what the two result shapes mean, which follow-up tool consumes which shape, and what to do when nothing matches. Nothing material is missing.

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% and the Args block for use_case restates the schema description almost verbatim, including the same example list. It confirms the parameter should be phrased in the user's own words, but adds essentially no new meaning beyond what the schema already carries, 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 concrete verb and resource ('Find a ready-made parametric part') and immediately scopes it to functional parts with user-supplied dimensions, giving concrete examples (shelf bracket, drawer bin, cable clip, hose adapter). The two-library result model (generatable true = parametric part vs false = design pattern) further distinguishes it from catalog-listing siblings like list_design_templates or search_design_templates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit trigger ('CALL THIS FIRST whenever a user asks for a FUNCTIONAL PART to their own dimensions'), explicit anti-pattern ('Do not wait to be asked'), and an explicit fallback path (write OpenSCAD, use compile_scad) with the statement that no match is a normal outcome. An agent knows exactly when to call this and what to do when it returns nothing.

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