Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

check_autonomy

Read-only

Determine whether an agent may execute a tool without human confirmation by evaluating its name, safety level, and optional operation context, so you know whether to proceed or ask for approval.

Instructions

Check whether the agent may execute a tool without human confirmation.

Pass the tool name, its safety level, and optional operation context
(material, time, temperatures) to get a decision.  Use this before
calling confirm-level tools to decide whether to proceed or ask.
:param tool_name: The tool the agent wants to call, by name.
:param safety_level: That tool's safety level: ``"safe"``, ``"guarded"``,
    ``"confirm"`` or ``"emergency"``.
:param material: Material the operation would print in, when it prints.
:param estimated_time_seconds: How long the operation would run, in
    seconds; ``0`` when unknown.
:param tool_temp: Hotend temperature the operation would set, in °C; ``0``
    when it sets none.
:param bed_temp: Bed temperature the operation would set, in °C; ``0``
    when it sets none.

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": {
      "tool_name": "<tool_name>",
      "safety_level": "<safety_level>"
    },
    "name": "check_autonomy"
  }
}

Input Schema

NameRequiredDescriptionDefault
bed_tempNoBed temperature the operation would set, in °C; ``0`` when it sets none. Default: 0.0.
materialNoMaterial the operation would print in, when it prints. Default: "".
tool_nameYesThe tool the agent wants to call, by name.
tool_tempNoHotend temperature the operation would set, in °C; ``0`` when it sets none. Default: 0.0.
safety_levelYesThat tool's safety level: ``"safe"``, ``"guarded"``, ``"confirm"`` or ``"emergency"``.
estimated_time_secondsNoHow long the operation would run, in seconds; ``0`` when unknown. Default: 0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.5.1
    • changedInput schema / properties / bed_temp / description
      Previous value: -"Default: 0.0."New value: +"Bed temperature the operation would set, in °C; ``0`` when it sets none. Default: 0.0."
    • changedInput schema / properties / estimated_time_seconds / description
      Previous value: -"Default: 0."New value: +"How long the operation would run, in seconds; ``0`` when unknown. Default: 0."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"\"."New value: +"Material the operation would print in, when it prints. Default: \"\"."
    • addedInput schema / properties / safety_level / description
      Added value: +"That tool's safety level: ``\"safe\"``, ``\"guarded\"``, ``\"confirm\"`` or ``\"emergency\"``."
    • addedInput schema / properties / tool_name / description
      Added value: +"The tool the agent wants to call, by name."
    • changedInput schema / properties / tool_temp / description
      Previous value: -"Default: 0.0."New value: +"Hotend temperature the operation would set, in °C; ``0`` when it sets none. Default: 0.0."
  2. Changed8 schema fields changedv1.5.0
    • removedInput schema / properties / bed_temp / default
      Removed value: -0
    • addedInput schema / properties / bed_temp / description
      Added value: +"Default: 0.0."
    • removedInput schema / properties / estimated_time_seconds / default
      Removed value: -0
    • addedInput schema / properties / estimated_time_seconds / description
      Added value: +"Default: 0."
    • removedInput schema / properties / material / default
      Removed value: -""
    • addedInput schema / properties / material / description
      Added value: +"Default: \"\"."
    • removedInput schema / properties / tool_temp / default
      Removed value: -0
    • addedInput schema / properties / tool_temp / description
      Added value: +"Default: 0.0."
  3. First observedv0.1.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, and the description correctly reinforces that this is a non-mutating gate rather than an action. It adds gating context (used before confirm-level tools) but never says what the returned decision contains, how emergency-level tools are handled, or whether a denial includes a reason — significant for a tool whose entire purpose is returning a judgment.

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 first two sentences are well front-loaded and do the real work. The subsequent six-line :param block duplicates a schema that already has 100% description coverage, adding length without information.

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

Completeness3/5

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

No output schema exists, so the description is the only place the return value could be described; it says only "to get a decision" without stating the shape (allow/deny, reason, level). For a small lookup tool with fully documented params this leaves a real 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 coverage is 100%, and the trailing :param block restates the schema descriptions almost verbatim (tool_name, safety_level enum values, temperature sentinels) rather than adding interpretation. The one useful framing beyond the schema is that these are the *target* tool's properties, not this tool's own, but it is only implied.

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 and resource: it checks whether the agent may execute a tool without human confirmation, which is clearly distinct from mutation tools like set_autonomy_level. It does not name closest siblings such as may_i_print, check_capability, or get_autonomy_level, 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 Guidelines4/5

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

"Use this before calling confirm-level tools to decide whether to proceed or ask" gives a concrete trigger condition and the decision it drives. No explicit when-not guidance or named alternative (e.g. may_i_print or confirm_action) is offered, which keeps it below a 5.

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