Skip to main content
Glama
faze79

WpfVisualTreeMcp

by faze79
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

wpf_select_item

Selects items in WPF ComboBox, ListBox, ListView or TabControl controls by visible text or zero-based index, working even with virtualized items. Raises proper selection events and reports available items on failure.

Instructions

Select an item in a ComboBox, ListBox, ListView or TabControl by visible text (item_text, case-insensitive substring) or zero-based index. PREFER this over clicking for dropdowns/lists: it works even when items are virtualized (not yet in the visual tree) and raises proper selection events. On failure the error lists the available items. 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
indexNo
item_textNo
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. First observedv0.1.0

TDQS

A4.9/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: it flags STATE-CHANGING, explains virtualization handling, states that proper selection events are raised, and discloses that errors enumerate available items. It also specifies pre-input validation ('missing or duplicate IDs fail before input'), which is behavioral context found nowhere in the schema.

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

Conciseness5/5

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

Three dense sentences, all front-loaded: capability and targeting first, then the preference/trade-off, then state-change and failure semantics. No filler and nothing repeated from structured fields.

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?

For a mutation tool with no annotations and no output schema, the description covers what changes (selection state), how targeting resolves, what happens on ambiguity, and what a failure looks like. There is no meaningful return-value explanation needed for a select action, so nothing critical is missing.

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

Parameters4/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 for most parameters: item_text is a case-insensitive substring, index is zero-based, element_handle and automation_id are mutually exclusive, and root_handle scopes automation_id lookup. It does not state whether index and item_text are mutually exclusive or what happens when neither is supplied, leaving one gap in an otherwise strong explanation.

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 and resource ('Select an item') and enumerates the supported control types (ComboBox, ListBox, ListView, TabControl). It also explicitly distinguishes itself from wpf_click_element, so an agent can choose between them without opening either schema.

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?

Gives an explicit preference directive ('PREFER this over clicking for dropdowns/lists') plus the reason (virtualized items, proper selection events), which is exactly the when-to-use signal an agent needs against a sibling like wpf_click_element. It also states the failure behavior, implying this is the route for list-like controls rather than raw clicking.

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