Skip to main content
Glama

manage_window

Idempotent

[Tauri Apps Only] Manage Tauri windows. Actions: "list" - List all windows with labels, titles, URLs, and state. "info" - Get detailed info for a window (size, position, title, focus, visibility).

Instructions

[Tauri Apps Only] Manage Tauri windows. Actions: "list" - List all windows with labels, titles, URLs, and state. "info" - Get detailed info for a window (size, position, title, focus, visibility). "resize" - Resize a window (requires width/height, uses logical pixels by default). "focus" - Focus a window (bring to front). "minimize" - Minimize a window. "maximize" - Maximize a window. Desktop-only actions (focus, minimize, maximize) require tauri-plugin-mcp-bridge 0.13.0+ and return a version error on older plugins. Requires active driver_session. For browser windows, use Chrome DevTools MCP instead.

Input Schema

NameRequiredDescriptionDefault
widthNoWidth in pixels (required for "resize" action)
actionYesAction: "list" all windows, get "info" for one window, "resize" a window, "focus" a window, "minimize" a window, or "maximize" a window
heightNoHeight in pixels (required for "resize" action)
logicalNoUse logical pixels (true, default) or physical pixels (false). Only for "resize"
windowIdNoWindow label to target (defaults to "main"). Required for "info", optional for "resize", "focus", "minimize", "maximize"
appIdentifierNoApp port or bundle ID to target. Defaults to the only connected app or the default app if multiple are connected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.0.1
    • changedInput schema / properties / action / description
      Previous value: -"Action: \"list\" all windows, get \"info\" for one window, or \"resize\" a window"New value: +"Action: \"list\" all windows, get \"info\" for one window, \"resize\" a window, \"focus\" a window, \"minimize\" a window, or \"maximize\" a window"
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "list",
      -  "info",
      -  "resize"
      -]New value: +[
      +  "list",
      +  "info",
      +  "resize",
      +  "focus",
      +  "minimize",
      +  "maximize"
      +]
    • changedInput schema / properties / windowId / description
      Previous value: -"Window label to target (defaults to \"main\"). Required for \"info\", optional for \"resize\""New value: +"Window label to target (defaults to \"main\"). Required for \"info\", optional for \"resize\", \"focus\", \"minimize\", \"maximize\""
  2. Addedv0.11.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the bar is lower. The description adds real context the annotations cannot: the driver_session prerequisite and the plugin-version-dependent error behavior for focus/minimize/maximize.

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-loads the Tauri-only scope, then a scannable per-action breakdown, then prerequisites and the alternative tool. Every sentence carries distinct information with no filler.

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?

No output schema exists, but the description sketches what 'list' and 'info' return and covers prerequisites, version gating, and the browser alternative. Nothing needed to call any of the six actions correctly is missing.

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%, so each parameter (width, height, logical, windowId, appIdentifier) is already documented. The description adds only marginal hints ('requires width/height', 'logical pixels by default') that duplicate the schema, making the baseline 3 appropriate.

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+resource ('Manage Tauri windows') and enumerates all six actions with their effects, so an agent knows exactly what each call does. The '[Tauri Apps Only]' prefix and the 'For browser windows, use Chrome DevTools MCP instead' line cleanly separate it from the webview_* siblings.

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 gives the prerequisites (requires active driver_session), the version constraint for desktop-only actions (tauri-plugin-mcp-bridge 0.13.0+), and the alternative to use for browser windows. When-to-use and when-not-to-use are both stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.