WpfVisualTreeMcp

Overview Schema Source Related Servers Discussions Admin

wpf_move_mouse

Move the real mouse cursor to a visible WPF element to trigger hover and tooltip handlers without clicking, with optional hover delay and window activation.

Instructions

Move the real mouse to a visible element without clicking. Optional x/y are paired local WPF DIPs, default center. hover_ms (0-5000, default 500) waits with the UI responsive for hover/tooltip handlers. Supports native content hosted in HwndHost. Activates the target window; requires a visible unobstructed desktop. Verify tooltips with a screen screenshot. STATE-CHANGING. Target by exactly one of element_handle or automation_id (exact, case-sensitive AutomationProperties.AutomationId). Use root_handle with automation_id to scope lookup; missing or duplicate IDs fail before input.

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

Input Schema

Name	Required	Description	Default
`x`	No
`y`	No
`hover_ms`	No
`root_handle`	No
`automation_id`	No
`element_handle`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.17.2Oct 24, 2026
- addedInput schema / properties / automation_id
```
Added value: +{
+  "default": null,
+  "type": "string"
+}
```
- addedInput schema / properties / element_handle / default
```
Added value: +null
```
- addedInput schema / properties / root_handle
```
Added value: +{
+  "default": null,
+  "type": "string"
+}
```
- removedInput schema / required
```
Removed value: -[
-  "element_handle"
-]
```
Addedv0.17.1Oct 22, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it flags STATE-CHANGING, window activation, the visible-unobstructed-desktop prerequisite, HwndHost/native content support, UI-responsive hover waiting, and that missing/duplicate IDs fail before any input is sent.

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?

Dense and front-loaded with the core action first, then constraints and targeting rules. Every sentence carries information, though the packed clauses make it slightly telegraphic rather than optimally structured.

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?

Given six untyped params, no annotations, and no output schema, the description covers safety, prerequisites, targeting rules, and hover behavior fully enough for an agent to invoke it correctly.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate, and it does: x/y are paired local WPF DIPs defaulting to center, hover_ms is bounded 0-5000 with default 500, root_handle scopes automation_id lookup, and exactly-one-of element_handle/automation_id (case-sensitive exact match) is spelled out.

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 ('Move the real mouse to a visible element without clicking'), immediately distinguishing it from wpf_click_element and wpf_drag by explicitly excluding the click.

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

Usage Guidelines4/5

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

Provides strong calling context: activates the target window, requires a visible unobstructed desktop, verify tooltips with a screenshot, and target by exactly one of element_handle or automation_id. It doesn't explicitly route to a sibling alternative (e.g., click_element when a click is wanted), so not quite a 5.

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