Skip to main content
Glama

consent_window_status

Read-only

Lists open standing consent windows, showing what each covers and when it ends, with an optional printer filter. Use it to check current print permissions before asking for 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.
        

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "consent_window_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
printer_nameNoShow only the window covering this printer. Omit for every open window.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.1
    • addedInput schema / properties / printer_name / description
      Added value: +"Show only the window covering this printer. Omit for every open window."
  2. Addedv1.5.0

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the readOnly/non-destructive annotations, it explains the semantics that matter: windows are opened only by the person (via dialog or CLI), agents cannot create or extend them, each print is still previewed first, and `turned_off` surfaces windows Kiln itself disabled in the last day. That is real behavioral context an agent cannot get from annotations or 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 answer-bearing summary is front-loaded in the first line, and the following paragraphs explain the domain concepts an agent needs before interpreting results. Some of the narrative ('the person's "yes, for a while"', the CLI reference) is slightly verbose, but no sentence is purely filler.

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

Completeness4/5

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

There is no output schema, so the description carries the burden of explaining return shape, and it does define the meaningful fields (`always`, `until`, `opened_via`, `turned_off`) and their consequences. It does not enumerate every field of an entry (e.g., printer identity, opened timestamp), leaving some return-value ambiguity, but an agent has enough to act.

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 description coverage is 100% and the 'Args: printer_name' text repeats the schema description verbatim ('Show only the window covering this printer. Omit for every open window.'). No additional filtering syntax, matching behavior (exact name vs alias), or format guidance is added, so this is baseline for a fully documented single parameter.

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 'Which standing consent windows are open, for what, until when' names the exact resource and the scope of the answer, and the 'always: true' paragraph makes clear this is a read of open windows rather than a mutation. It also disambiguates from the sibling `revoke_consent_window`, which is the closing action.

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?

The description states the key usage constraint explicitly: 'Nothing an agent can call opens or extends one' and 'Closing one is always allowed: see revoke_consent_window.' That routes the agent away from trying to grant consent and toward the correct sibling for revoking. It stops short of saying when to call this status tool in a print workflow (e.g., before a start_print that might prompt), so it's clear context but not fully prescriptive.

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