Skip to main content
Glama
faze79

WpfVisualTreeMcp

by faze79
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

wpf_touch_gesture

Inject native Windows touch gestures (tap, long press, swipe, pinch, rotate) into a visible WPF element to test or automate touch-enabled UI behavior.

Instructions

Inject native Windows touch input into a visible WPF element. gesture: tap, long_press, swipe (pan), pinch (zoom), rotate. x/y is an optional local WPF DIP pair (default center). swipe requires delta_x/delta_y (omitted axis zero). pinch requires scale (0.1-10, excluding 1; above 1 spreads two fingers). rotate requires angle_degrees (-360 to 360, nonzero; positive clockwise). radius optionally sets initial finger distance from center in local DIPs for pinch/rotate (minimum 4); default fits the element. The complete path must stay visible inside the element. duration_ms defaults: tap 100, long_press 1000, others 700; limits: tap 50-500, long_press 500-10000, others 100-10000. Requires an interactive Windows 8+ desktop. Activates the window. Success means touch input sent, not gesture recognition: the application must support touch/manipulations. 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.

Input Schema

NameRequiredDescriptionDefault
xNo
yNo
scaleNo
radiusNo
delta_xNo
delta_yNo
gestureYes
duration_msNo
root_handleNo
angle_degreesNo
automation_idNo
element_handleNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.17.2
    • 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"
+}
    • changedInput schema / required
      Previous value: -[
-  "element_handle",
-  "gesture"
-]New value: +[
+  "gesture"
+]
  2. Addedv0.12.1

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so well: it marks the tool as STATE-CHANGING, states that it activates the window, requires an interactive desktop, and depends on application touch/manipulation support. It also discloses targeting rules, visibility constraints, duplicate-ID failure behavior, and success semantics beyond mere injection.

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?

The description is dense and front-loads the core purpose and gesture list, then adds necessary constraints. For a 12-parameter gesture tool with no annotation or schema-description support, most sentences earn their place, though the single-paragraph run-on formatting could be structured more cleanly.

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 the tool's complexity, 12 parameters, no annotations, no output schema, and 0% schema-description coverage, the description is complete enough to invoke correctly. It covers target lookup, gesture-specific requirements, defaults and limits, desktop prerequisites, visibility constraints, and failure semantics.

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 description coverage is 0%, so the description must supply parameter meaning and it does: x/y are local WPF DIPs defaulting to center, swipe requires delta_x/delta_y, pinch requires scale excluding 1, rotate requires nonzero angle, and radius/duration defaults and limits are specified. It also explains target selection via exactly one of element_handle or automation_id and scoping with root_handle.

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?

The description states a specific verb and resource: injecting native Windows touch input into a visible WPF element. It enumerates the supported gestures (tap, long_press, swipe, pinch, rotate), so an agent can distinguish this tool from sibling input tools such as wpf_click_element, wpf_drag, or wpf_scroll.

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?

Usage context is clear: it requires an interactive Windows 8+ desktop, activates the window, and success means touch input was sent rather than gesture recognition. It also explains when gesture-specific parameters are required. It does not explicitly compare against siblings like wpf_click_element or wpf_drag, which keeps it below a 5.

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