Read UI control property values without side effects. Inspect WPF, WinForms, or Avalonia elements by name, xpath, or automation ID to gather evidence during debugging.
Read bounded UI property evidence without mutation side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| xpath | No | ||
| action | Yes | ||
| root_id | No | ||
| property | No | ||
| control_type | No | ||
| automation_id | No | ||
| property_name | No |
Changes observed during successful MCP inspections.
v0.18.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's statement of 'no mutation side effects' is redundant. It adds 'bounded' but does not explain what bounds exist (e.g., scope, limitations). No additional behavioral traits disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but at the expense of informativeness. It front-loads the core purpose but lacks necessary details, making it barely adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters and no output schema, the description should compensate with parameter explanations and return value hints. It does not, leaving the tool's usage unclear and incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 8 parameters with 0% description coverage. The description does not explain any parameter meanings, such as 'action', 'property', 'automation_id', etc., leaving the agent to infer from names alone. This is inadequate for a tool with many parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Read bounded UI property evidence' which clearly indicates a read operation on UI properties. 'Without mutation side effects' further clarifies it is non-destructive. However, 'bounded' is vague and the term 'property evidence' is not standard, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing to read UI properties safely, but it does not specify when not to use it or how it differs from similar read tools like ui_query or ui_text. No explicit alternatives or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.