Skip to main content
Glama
mario-andreschak

MCP Windows Desktop Automation

opt

Destructive

Sets an AutoIt option by name to an integer value, enabling adjustment of Windows desktop automation behavior for UI control tasks.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueYesOption value
optionYesOption name

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

C2.4/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, and non-idempotent/non-read-only behavior. The description adds genuine context beyond them by stating the execution preconditions (trusted owner, interactive Windows x64 desktop), which matters for an AutoIt host-level call. It does not, however, say which option is mutated or what the effect/destruction is, so 3 rather than 4.

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

Conciseness3/5

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

Two short sentences with no padding, which is appropriate, but the first sentence is pure tautology and earns none of its space. Structure is acceptable, content of the lead sentence is wasted.

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

Completeness2/5

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

For a destructive, non-idempotent host-level mutation with no output schema, the agent needs to know what is being changed and what the response or failure mode looks like. The description supplies only environmental preconditions and leaves the core mutation semantics and return behavior 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 100%, so the baseline is 3. However, the schema's own text is generic ("Option name", "Option value") and the description adds nothing about which option names are valid or what range of values is meaningful, so the 3 is not exceeded.

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

Purpose2/5

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

"Windows AutoIt opt" restates the tool name and resource without stating a verb or what the tool actually does to the option/value pair. It is not distinguishable from the sibling autoItSetOption, which appears to do the same conceptual job, and no agent could tell which one applies here.

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?

The description names no when-to-use condition and never routes the agent between this tool and autoItSetOption. The only constraint given (trusted owner, interactive desktop) is an environment prerequisite, not guidance on choosing this tool.

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