desktop-touch-mcp

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

With no annotations provided, the description carries the full burden of behavioral disclosure and excels. It details the subscription mechanism (returns subscriptionId, buffered internally at 500ms intervals via EnumWindows), buffer limits (holds up to 50 events with oldest dropped on overflow), event structure ({type, hwnd, title, timestamp}), and critical caveats (events before subscribe not included, need to poll frequently to avoid overflow). This provides comprehensive behavioral context beyond basic functionality.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with labeled sections (Purpose, Details, Prefer, Caveats, Examples) and efficiently conveys necessary information. However, the example section is somewhat verbose and could be more concise, slightly reducing the score from perfect efficiency.

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

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

Given the tool's complexity (event subscription with buffering and polling), no annotations, and no output schema, the description provides exceptional completeness. It explains the subscription lifecycle, buffer behavior, event format, usage alternatives, caveats, and includes a practical example, leaving no significant gaps for an agent to understand and use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so the baseline is 3. The description does not explicitly mention the 'types' parameter, but it implies event types in the purpose ('window-state change events') and details. However, it doesn't add significant semantic value beyond what the schema provides (which already describes 'Event types to listen for' with enum values), warranting a score slightly above baseline for contextual reinforcement.

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

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

The description explicitly states the tool's purpose as 'Subscribe to window-state change events (appear/disappear/focus) for continuous monitoring without repeated polling.' This provides a specific verb ('subscribe') and resource ('window-state change events'), and distinguishes it from sibling tools like wait_until by mentioning continuous monitoring versus one-shot waiting.

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

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

The description includes explicit guidance on when to use this tool versus alternatives: 'Prefer: Use instead of wait_until(window_appears) when you need to monitor multiple events simultaneously or over an extended period. Use wait_until for one-shot, single-condition waiting.' It also specifies when to call events_poll and events_unsubscribe, providing clear context and exclusions.

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