Skip to main content
Glama
faze79

WpfVisualTreeMcp

by faze79
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

wpf_click_element

Clicks a WPF UI element by handle or automation ID using UI Automation, or performs a physical mouse click. Use it to trigger buttons, menu items, and other controls in Windows apps.

Instructions

Click a UI element. Supply exactly one of element_handle or automation_id (exact, case-sensitive AutomationProperties.AutomationId; no handle lookup needed). IDs must match a unique control across all open windows, including hidden controls. Use root_handle with automation_id to scope to a window or subtree if IDs repeat. Missing or ambiguous IDs return an error without clicking. By default invokes the control's action via UI Automation (works for buttons, menu items, checkboxes, radio buttons, tabs, list items, expanders) without moving the mouse or focusing the window. Set physical=true to perform a real OS mouse click at the element's on-screen position (works on any visible element but moves the cursor and brings the window forward; auto-scrolls the element into view first). Optional paired x/y select a point in local WPF DIPs and imply physical input; omitted coordinates use the center. click_type: 'single' (default), 'double' (open items), 'right' (context menus) — double and right are always physical. After opening a context menu or dropdown, use wpf_capture_screenshot with mode='screen' to see it. STATE-CHANGING.

Input Schema

NameRequiredDescriptionDefault
xNo
yNo
physicalNo
click_typeNo
root_handleNo
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"
+}
    • removedInput schema / required
      Removed value: -[
-  "element_handle"
-]
  2. Changed2 schema fields changedv0.17.1
    • addedInput schema / properties / x
      Added value: +{
+  "default": null,
+  "type": [
+    "number",
+    "null"
+  ]
+}
    • addedInput schema / properties / y
      Added value: +{
+  "default": null,
+  "type": [
+    "number",
+    "null"
+  ]
+}
  3. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/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 well: it flags STATE-CHANGING, explains that physical clicks move the cursor and bring the window forward, auto-scrolls into view, and that double/right clicks are always physical. It omits what the tool returns on success (no output schema exists), which is the one behavioral gap.

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 but front-loaded – the critical exactly-one-identifier rule and the UIA-vs-physical split come first, and each sentence adds distinct information. It is a single unbroken block, so bullet-style structuring of the mode/parameter rules would improve scannability.

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

Completeness4/5

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

For a 7-parameter, zero-annotation mutation tool this covers nearly everything an agent needs: identifier selection, ambiguity handling, mode selection, coordinate semantics, and follow-up tooling. The only missing piece is success/return behavior, which would matter given the absence of an output schema.

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%, yet all seven parameters are given meaning beyond their names: element_handle vs. automation_id are mutually exclusive with exactly-one semantics and case-sensitivity, root_handle scopes IDs, physical toggles the input mode, x/y are paired local WPF DIPs that imply physical input and default to center, and click_type enumerates single/double/right with intent notes.

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

Purpose4/5

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

Opens with a specific verb+resource ('Click a UI element') and immediately splits the behavior into two clear modes: UI Automation invoke vs. physical OS mouse click. That distinction is enough to tell it apart from wpf_move_mouse, though it never names sibling tools like wpf_select_item even though the stated scope (tabs, list items, radio buttons) overlaps with them.

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

Usage Guidelines5/5

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

Explicit routing is given: default to UIA invoke for buttons/menu items/checkboxes, set physical=true only when a real cursor click is required, use root_handle with automation_id when IDs repeat, and follow context-menu clicks with wpf_capture_screenshot mode='screen'. Failure conditions ('missing or ambiguous IDs return an error without clicking') are stated up front.

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