Skip to main content
Glama

revoke_consent_window

Close an open consent window to stop queued print jobs from starting, or to turn off always allow so the printer asks again before running.

Instructions

Close a standing consent window now. Prints ask the person again.

        The person opened the window — in the approval dialog or at a
        terminal — and can close it here, through you, without touching
        a terminal: when they say to close it, call this.  Closing is
        the safe direction, so it needs no confirmation and no window
        can refuse it.  Jobs queued under the window will not start.

        This is also how always allow is turned off: when the person
        says "ask me first", call this with the printer's name (or the
        id on the print result) and show them the ``note`` as written.

        Args:
            window_id: The window to close (from ``consent_window_status``
                or the ``standing_window`` block on a print result).
            printer_name: Close every open window covering this printer.
            all_windows: Close every open window.
        

Input Schema

NameRequiredDescriptionDefault
window_idNo
all_windowsNoDefault: false.
printer_nameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.0

TDQS

A4.8/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: it states closing is the safe direction, requires no confirmation, cannot be refused by a window, and has the side effect that queued jobs under the window will not start. It also instructs the agent to show the returned note verbatim — behavior not derivable from 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 critical action and safety statement are front-loaded, and every paragraph adds usable information. It is slightly verbose with an embedded Args block duplicating parameter info, and the indented formatting is awkward, but no sentence is truly wasted.

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?

For a mutation tool with no annotations and no output schema, the description covers safety, side effects, and return-note handling well. It does not say what happens when zero arguments are supplied (all params optional) or how the three selectors interact if combined, which is a real gap for an agent calling it.

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 only 33% (only all_windows is documented), but the description compensates by explaining all three: window_id's provenance, printer_name closing every open window covering that printer, and all_windows closing every open window. This adds real semantics beyond the bare types.

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 first sentence gives a specific verb and resource — 'Close a standing consent window now' — and the body clarifies the scope (immediate, not scheduled). It is clearly distinguished from the read-only sibling consent_window_status, which is named as the source of the window_id.

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?

Explicit triggers are given: call this 'when they say to close it' and, for disabling always-allow, 'when the person says "ask me first"'. It also names the alternative data sources (consent_window_status, the standing_window block on a print result) so the agent knows where the id comes from.

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