Kiln

Overview Schema Source Related Servers Discussions Admin

design_improvement_plan

Read-only

Generate a full structural improvement plan for an STL part: ranked risks, specific reinforcement fixes, load analysis, print orientation, and a 0–100 score to compare versions.

Instructions

Generate a complete structural improvement plan for a design.

        The **full design reasoning pipeline** — combines risk analysis,
        reinforcement recommendations, and load analysis into one actionable
        report.  Its ``summary`` names the risks found, the worst first, and
        the first thing to do; the overall structural score (0-100, A-F
        grade) stays in the report for comparing versions of the part.

        This is the tool that makes Kiln a **design advisor**, not just a
        geometry validator. It answers: "This bracket needs a gusset at the
        load point" — not just "the part has thin walls."

        The plan includes:
        1. **Risks**: all structural weak points with locations and severity
        2. **Reinforcements**: specific fixes and what each does for the part
        3. **Load analysis**: how the part handles forces, best print orientation
        4. **Summary**: the risks named, and a score for comparing versions

        :param file_path: Path to the STL file.
        :param min_cross_section_mm2: Minimum safe cross-section area.
            Leave unset for Kiln's own threshold.
        :param sharp_angle_threshold_deg: How far the surface must turn inward
            across an edge, in degrees, for an inside corner to count as
            sharp.  Leave unset for Kiln's own threshold, the same for
            every caller.
        :returns: Complete improvement plan as dict.

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": {
      "file_path": "<file_path>"
    },
    "name": "design_improvement_plan"
  }
}

Input Schema

Name	Required	Description
`file_path`	Yes	Path to the STL file.
`min_cross_section_mm2`	No	Minimum safe cross-section area. Leave unset for Kiln's own threshold.
`sharp_angle_threshold_deg`	No	How far the surface must turn inward across an edge, in degrees, for an inside corner to count as sharp. Leave unset for Kiln's own threshold, the same for every caller.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv1.5.1Nov 5, 2026

addedInput schema / properties / file_path / description
```
Added value: +"Path to the STL file."
```

addedInput schema / properties / min_cross_section_mm2 / anyOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / min_cross_section_mm2 / description

Previous value: -"Default: 4.0."New value: +"Minimum safe cross-section area. Leave unset for Kiln's own threshold."

removedInput schema / properties / min_cross_section_mm2 / type
```
Removed value: -"number"
```

addedInput schema / properties / sharp_angle_threshold_deg / anyOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / sharp_angle_threshold_deg / description

Previous value: -"Default: 60.0."New value: +"How far the surface must turn inward across an edge, in degrees, for an inside corner to count as sharp.  Leave unset for Kiln's own threshold, the same for every caller."

removedInput schema / properties / sharp_angle_threshold_deg / type
```
Removed value: -"number"
```

Changed4 schema fields changedv1.5.0Oct 23, 2026
- removedInput schema / properties / min_cross_section_mm2 / default
```
Removed value: -4
```
- addedInput schema / properties / min_cross_section_mm2 / description
```
Added value: +"Default: 4.0."
```
- removedInput schema / properties / sharp_angle_threshold_deg / default
```
Removed value: -60
```
- addedInput schema / properties / sharp_angle_threshold_deg / description
```
Added value: +"Default: 60.0."
```
First observedv0.1.0Jul 4, 2026

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 openWorldHint=false, so the safety profile is covered. The description goes beyond that by disclosing the exact report contents (risks with locations/severity, reinforcements, load analysis with best print orientation, summary with a 0-100 score and A-F grade) and by explaining that the score is meant for comparing design versions. It does not mention runtime cost or preconditions, which keeps it from a 5.

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 core purpose is front-loaded in the first sentence, but the text is padded with marketing framing ('This is the tool that makes Kiln a design advisor, not just a geometry validator' and the bracket/gusset example) and repeats the summary/score concept twice across the opening paragraphs and the numbered list. The numbered breakdown is scannable, but a third of the description could be cut without losing 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?

There is no output schema, so the description must carry the return-value burden, and it does so thoroughly by itemizing the four report sections and explaining the score's semantics. For a read-only three-parameter analysis tool this is nearly complete; only minor gaps remain (file format constraints, expected latency, and how the score relates to the sibling validators).

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 all three parameters are already documented, and the description's :param: text largely restates the schema verbatim ('Path to the STL file', 'Leave unset for Kiln's own threshold'). It adds a little color on sharp_angle_threshold_deg ('the same for every caller') but no new syntax or behavioral detail, 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 ('Generate a complete structural improvement plan for a design') and then enumerates the four components the plan contains, which implicitly distinguishes it from siblings like analyze_structural_risks and recommend_design_reinforcements that each cover only one slice. The line about combining risk analysis, reinforcement recommendations, and load analysis into one report makes the composite nature unmistakable.

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 only implied: an agent can infer this is the 'full pipeline' tool to reach for when it wants everything at once rather than a single analysis. There is no explicit statement like 'use analyze_structural_risks if you only want risks' and no prerequisites or exclusions (e.g., mesh must be validated first, cost of the call).

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

Deploy Server