Skip to main content
Glama
codeofaxel

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

give_print_code

Relay the exact code a person types after a refused print to approve one print or allow timed printing on that printer, then start the job 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``.

Input Schema

NameRequiredDescriptionDefault
wordsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description fully carries the behavioral burden: nothing callable reveals the code, wrong guesses count, three wrong guesses void every code for a minute, and a phone_next_time reply must be relayed once printing starts. These are exactly the side-effect/failure-mode details an agent cannot infer from the schema.

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 action is front-loaded in the first sentence and each following sentence (code semantics, penalty for wrong guesses, phone_next_time) carries distinct operational value. It is slightly long and shows pasted-docstring indentation artifacts, but there is no genuinely redundant content.

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 tool with no annotations and no output schema, the description covers the trigger, the input format, the consequences of success/failure, the follow-up call, and out-of-band handling of phone_next_time. An agent has everything needed to call it correctly and recover from errors.

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

Parameters5/5

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

Schema coverage is 0% and there is one param, but the description documents it as 'Exactly what the person typed' with concrete format examples ('4821' or '4821 2h') and explains that the suffix changes behavior. This more than compensates for the empty schema and clarifies the format an agent would otherwise have to guess.

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 ('relay') and resource ('the code the person typed') tied to an exact triggering situation (a print refused with 'a code was just shown in a notification'). It also implicitly distinguishes itself from the flow's other step by saying 'Then call the start tool again', so the agent knows this feeds back into the start path rather than replacing it.

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?

Explicitly says when to use it (print refused, person has a code), what to ask the person to do, and what to do afterward ('Then call the start tool again'). It even branches the semantics of the input (code alone approves one print; code plus 2h/today extends printing) so the agent knows the consequence of what it passes.

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