Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

give_print_code

Destructive

Approves a refused 3D print by relaying the exact code the user typed after Kiln displayed it; append 2h or today to allow continued printing on that printer, then start the print again.

Instructions

Relay the code the person typed after Kiln showed one on their screen.

        When a print is refused with "a code was just shown in a notification",
        ask the person to type it here, then pass their exact words: the code
        alone approves that one print; the code followed by ``2h`` or ``today``
        also keeps printing on that printer without asking for a while. Then
        call the start tool again. Nothing you can call reveals the code; a
        wrong guess counts, and three wrong guesses void every code for a minute.
        When the reply carries ``phone_next_time``, pass that one line on once
        the print has started.

        Args:
            words: Exactly what the person typed, e.g. ``4821`` or ``4821 2h``.

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": {
      "words": "<words>"
    },
    "name": "give_print_code"
  }
}

Input Schema

NameRequiredDescriptionDefault
wordsYesExactly what the person typed, e.g. ``4821`` or ``4821 2h``.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.1
    • addedInput schema / properties / words / description
      Added value: +"Exactly what the person typed, e.g. ``4821`` or ``4821 2h``."
  2. Addedv1.5.0

TDQS

A4.5/5.0
Behavior3/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false; the description goes further by explaining consequences the annotations cannot convey: a wrong guess counts, three wrong guesses void every code for a minute, and no callable tool reveals the code. It also documents the suffix semantics (2h/today extends approval to that printer) and the phone_next_time hand-off. This is strong context, though it never states what the call returns or how success/failure is signalled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the single-sentence purpose, followed by the triggering condition, the procedure, the risks, and the aftercare note. Every sentence carries operational information; nothing is padding, even at this length.

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 one-parameter relay tool with no output schema, the description covers when it is needed, what to pass, the consequence of error, the follow-up call, and the phone_next_time edge case. An agent has everything required to invoke it correctly and recover from a refusal.

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

Parameters4/5

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

Schema coverage is 100% and the schema already carries the example, so the baseline would be 3. The description nonetheless adds real meaning the schema does not: that the value is verbatim human input and that an appended 2h or today changes scope from one print to a timed approval window.

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: relay the code the person typed after Kiln displayed one. It is unmistakably distinct from siblings like start_print, monitor_print, and kiln_signin_poll, and an agent can place it in the print-approval flow without opening the schema.

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?

Gives an explicit trigger ('when a print is refused with a code was just shown in a notification'), the exact procedure (ask the person, pass their exact words), and the required follow-up (call the start tool again). It also handles the secondary case of passing on phone_next_time once printing has started.

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