Skip to main content
Glama
mario-andreschak

MCP Windows Desktop Automation

toolTip

Destructive

Displays a pop-up text hint at specified X/Y coordinates on an interactive Windows x64 desktop. Requires a trusted owner, letting AutoIt automation scripts show contextual UI hints.

Instructions

Windows AutoIt toolTip. Requires a trusted owner and an interactive Windows x64 desktop.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNoX coordinate
yNoY coordinate
textYesTooltip text

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

B3.1/5.0
Behavior3/5

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

The annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered structurally. The description contributes the trusted-owner and interactive-desktop prerequisites, which are real added context, but says nothing about duration, blocking, or cleanup of the tooltip. Nothing contradicts the annotations.

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 tight sentences with the platform and prerequisites front-loaded and zero padding. It is efficient, though arguably under-specified rather than genuinely concise.

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 simple 3-parameter UI tool with full schema coverage and no output schema, the description is minimally adequate: it names the platform and prerequisites. It would benefit from noting whether the call blocks, the tooltip's lifetime, and any return/handle, which is a meaningful gap for a UI-mutating call.

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 x, y, and text are already documented in the schema, making 3 the baseline. The description adds no coordinate format, default position behavior, or text handling detail beyond the schema's 'Tooltip text' and 'X/Y coordinate' notes.

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?

The description states 'Windows AutoIt toolTip', which identifies the resource but mostly restates the tool name rather than giving a specific verb like 'display a tooltip at coordinates'. An agent can infer it shows a tooltip on a Windows desktop, but the phrasing is close to tautology. No sibling in the list offers tooltips, so no differentiation is required.

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

Usage Guidelines3/5

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

'Requires a trusted owner and an interactive Windows x64 desktop' gives an environmental prerequisite for when this can run, which is useful context. However, it offers no guidance on when to prefer this over alternatives (none exist) or any exclusion conditions beyond the desktop requirement.

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