Skip to main content
Glama

get_auto_tuned_settings

Retrieve auto-tuned 3D print settings from a printer's historical successes and failures to cut failed prints and fix risks first. Requires Kiln Pro.

Instructions

Get auto-tuned print settings from historical success/failure analysis.

Kiln Pro would read this printer's recorded outcomes and return tuned settings, a success-likelihood read, and the risks to fix first. Requires Kiln Pro. Upgrade: https://kiln3d.com/pricing?src=agent&tool=get_auto_tuned_settings

Input Schema

NameRequiredDescriptionDefault
materialYes
printer_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.0

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations, the description carries the behavioral burden. It discloses that the tool reads recorded outcomes and returns tuned settings, a success-likelihood read, and risks to fix first, plus the Kiln Pro requirement. It does not explicitly confirm read-only safety, rate limits, or behavior when historical data is absent.

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 core purpose is front-loaded in the first sentence, followed by concise return-value and prerequisite context. The upgrade URL is somewhat promotional but still directly tied to the stated Kiln Pro requirement.

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?

The description covers purpose, return components, and the Kiln Pro prerequisite. However, with no annotations, no output schema, and 0% schema description coverage, it is incomplete: it omits material semantics, printer_id format, and guidance versus sibling settings tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description should compensate for the two required parameters. It vaguely references 'this printer' but never explains printer_id format or the required material parameter at all.

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?

The description states a specific verb and resource: get auto-tuned print settings from historical success/failure analysis. The purpose is clear, though it does not explicitly distinguish itself from nearby settings-related siblings such as get_optimal_settings or recommend_settings.

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 by the description: call it to get tuned settings for a printer based on recorded outcomes. It also states the Kiln Pro prerequisite, but it gives no explicit when-to-use guidance versus alternatives or when-not-to-use conditions.

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