Skip to main content
Glama

consent_window_status

List open standing consent windows for a 3D printer, showing what each allows and when it ends, so you can check if prints start without per-print approval.

Instructions

Which standing consent windows are open, for what, until when.

        A standing window is the person's "yes, for a while": inside it,
        prints start on the named printer without asking each time (each
        one still previewed first).  Only the person opens one — by
        picking "yes, and for the next…" in the approval dialog, or with
        ``kiln consent window`` at a terminal.  Nothing an agent can call
        opens or extends one.  Closing one is always allowed: see
        ``revoke_consent_window``.

        An entry with ``always: true`` is always allow: the person turned
        it on for one printer — at a terminal, or on their Kiln account
        page (``opened_via`` says which) — it has no end (``until`` is
        null), and prints there start without asking until it is turned
        off.  ``turned_off`` lists any that Kiln turned off itself in the
        last day because a different printer was set up under the name.

        Args:
            printer_name: Show only the window covering this printer.
                Omit for every open window.
        

Input Schema

NameRequiredDescriptionDefault
printer_nameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it explains that prints start without asking but are still previewed, that agents cannot open/extend a window, that closing is always allowed, and it decodes return semantics (always:true, until=null, opened_via, turned_off). This is substantial behavioral disclosure beyond structured data.

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 key question is front-loaded and every paragraph earns its place given the non-obvious domain concept. It is on the long side with indented prose, but the density of useful information is high rather than padded.

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 read-style status tool with no output schema and no annotations, the description supplies the concept, the agent's constraints, and the meaning of returned fields, leaving nothing essential for correct invocation unstated.

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% (the single parameter has no description), so the description must compensate and does: it explains printer_name filters to the window covering that printer and that omitting it returns every open 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?

The opening line states a precise verb+resource+scope: reporting which standing consent windows are open, for what, and until when. It distinguishes itself from siblings by explicitly naming revoke_consent_window as the tool for closing one.

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?

It gives strong context: only a person can open a window, nothing an agent can call opens or extends one, and closing routes to revoke_consent_window. It stops short of explicitly telling the agent when to consult this status versus other print-authorization tools like may_i_print, but the routing it does provide is clear.

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