Loading ToolBench
MCP server for inspecting WPF application Visual Trees - enables AI agents to debug and analyze WPF UI hierarchies in real-time
This WPF Visual Tree MCP server demonstrates good overall definition quality with 19 well-named, domain-specific tools. All tools have descriptions and input schemas are present and properly typed. However, there are systematic gaps in parameter descriptions, inconsistencies between mcp.json and source definitions, and missing output schema documentation. Tool naming is strong (verb_noun pattern, action-focused). Descriptions are generally clear but vary significantly in length (34-450 chars) and depth. Most tools lack documented return types, making it harder for LLMs to plan multi-step operations. Error handling and recovery guidance are minimal across the board.
Attach to a WPF application by process ID or name. Set auto_inject=true to automatically inject the Inspector into processes that don't have it pre-loaded.
Clear the captured binding errors list. Useful before testing specific scenarios.
Evaluate a binding on a property. Returns the binding path, mode, source, converter, and any errors. If the binding is broken, returns the exact point where resolution failed.
Analyze triggers affecting a property value. Returns which triggers are active, what they set the value to, and the final computed value. Essential for debugging complex trigger-based styles.
Export visual tree to XAML or JSON format
Query elements across all open windows. Filters combine with AND: type_name (partial match, e.g. 'Button' matches 'System.Windows.Controls.Button'), element_name (x:Name substring), text (visible text content — matches a Button's caption, TextBlock text, Window title, AutomationProperties.Name, ToolTip; case-insensitive substring), property_filter (object of property name → expected value substring, e.g. {"IsEnabled": "True"}), visible_only (exclude collapsed/hidden elements — recommended when looking for something the user can see). PREFER text over dumping the tree: e.g. text='Save' + type_name='Button' finds the Save button directly. Results include text, automationId, isVisible, isEnabled and screenBounds (device pixels) so you can pick the right element without extra calls. Returns up to max_results (default 50).
mcp.json schema definitions lag behind source code implementations. wpf_attach in mcp.json lacks auto_inject parameter (present in README and source). wpf_find_elements in mcp.json lacks text and visible_only parameters (present in source). This creates schema-implementation mismatch that will confuse clients.
Most tools lack documented return/output schemas. While tools clearly return structured data (tree hierarchy, element properties, binding info), mcp.json and source code do not declare what fields are returned or their types. LLMs cannot plan multi-step operations or extract chaining IDs without explicit output schemas. Example: wpf_get_visual_tree returns nodes with handles, but this is not documented in the schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 76 | 2026-07-28+ | v2 |
Deep search for ALL elements matching criteria (no result limit). Requires at least type_name, element_name or text to avoid returning the entire tree. Same filters as wpf_find_elements: type_name (partial match), element_name (x:Name substring), text (visible text content), property_filter, visible_only. Use root_handle to limit scope.
List all binding errors captured since application start. Errors are detected via WPF trace listener. Use wpf_clear_binding_errors to reset the list.
Get all data bindings for an element with their status
Get the DataContext for an element, including type info, properties, INPC status, and inheritance chain up the visual tree. Essential for diagnosing binding path errors.
Get all dependency properties of a UI element
Get layout information (ActualWidth, ActualHeight, Margin, Padding, etc.)
Enumerate resource dictionaries and their contents
Get applied styles and templates for an element
Get the visual tree hierarchy. Use root_handle to start from a specific element (from wpf_find_elements). Use max_depth to control depth (1-100, default 25). For deep UIs like AvalonDock, increase max_depth or use root_handle to zoom into a subtree.
Visually highlight an element in the running application
List all running WPF applications available for inspection
Wait until an element matching the criteria satisfies a condition, polling in the target app so you don't have to sleep-and-retry. Identify the element with type_name, element_name and/or text (same matching as wpf_find_elements). Then specify the condition: timeout_ms (max wait time, default 25000), poll_interval_ms (how often to check, default 200), visible_only (only consider visible elements), property_equals (property name and expected value for that property), property_contains (property name and substring), exists (true = wait for element to appear, false = wait for it to disappear).
Monitor a property for changes
Several tools have minimal or generic descriptions (20-60 chars) that fail to guide LLM tool selection. Examples: wpf_get_element_properties (50 chars), wpf_get_styles (50 chars), wpf_watch_property (50 chars), wpf_get_layout_info (50 chars). These do not explain WHEN to use them, WHAT they return, or HOW they differ from related tools. Rubric baseline is 194 chars average; these are 75% below baseline.
wpf_attach description in mcp.json does not mention auto_inject parameter (which is critical for the tool's functionality), but source README does. Parameter descriptions in source are also missing for property_filter's additionalProperties semantics, what format should values take? Are they regex, substring, or exact match?
No error handling or recovery guidance in any tool description. No indication of which errors are retryable vs user-fixable (e.g., 'process not found' vs 'permission denied'). No guidance on what to do if an element is not found or a binding fails. This violates recovery-guide and error-classification patterns.
Tool composition clarity issue: wpf_find_elements and wpf_find_elements_deep have very similar names and overlapping functionality (both search by type_name, element_name, text). The distinction (limit vs no limit) is not obvious from names. Consider renaming to wpf_search_elements (with limit) and wpf_search_elements_unlimited or clarify in descriptions when to use each.
wpf_watch_property description (50 chars) does not specify: What does 'watch' mean? Does it block? Does it return a stream? Is it a one-shot observation or continuous monitoring? This is critical for agent behavior.
max_depth parameter default differs between mcp.json (default: 10) and README (default: 25). This inconsistency may cause unexpected behavior for agents relying on mcp.json schema.