Skip to main content
Glama
Sign In
DeskPilot

DeskPilot

by iamtahiralvi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

window

Control desktop application panels by title or app text to list, focus, minimize, maximize, restore, close, or move them between displays.

Instructions

Manage windows. target = window ref (w3) or title/app text; default = top window on your screen. move_here brings a window from another screen onto yours.

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": "window"
  }
}

Input Schema

NameRequiredDescriptionDefault
opNolist
targetNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden. It does disclose two real behaviors beyond the schema: target defaults to the top window on your screen, and move_here relocates a window from another screen. It says nothing about whether close is destructive, whether focus raises or switches screens, or what permissions are needed.

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?

Two short sentences with no filler, and the most load-bearing detail (target format and default) is placed early. The opening "Manage windows" is the only near-redundant phrase.

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

Completeness3/5

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

For a two-parameter tool with no output schema and no annotations, the essentials for a call are covered, but a seven-operation tool warrants more: what list returns, what close does to unsaved state, and whether focus changes screen focus remain unstated.

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 0%, so the description must supply parameter meaning, and it does well for target: accepted formats (window ref such as w3, or title/app text) plus the default. The op enum's seven values are left to self-interpretation except move_here, so half the parameter surface still relies on inference.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Manage windows" names a resource and a general verb, and the description hints at scope via the target default and move_here. But "manage" is generic and the entry point does not distinguish this tool from siblings like screenshot, snapshot, or screen_info, which an agent could plausibly confuse with window handling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance, and no named alternatives. The only usage signal is a behavioral note about the default target and about move_here crossing screens, which helps invocation but not tool selection.

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