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

With no annotations, the description carries the full burden and does well: it discloses that mismatch throws, that passing assertions are persisted while recording, and that ambiguous or absent IDs fail before any input is used. It stops short of describing what a successful call returns or whether other state changes occur.

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?

Dense and front-loaded with the core behavior first, then alternatives, then targeting rules. The semicolon-chained clauses make a few statements terse to the point of being cryptic (e.g. 'missing or duplicate IDs fail before input').

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?

For a five-parameter assertion tool with no output schema and no annotations, the description covers targeting, comparison semantics, failure behavior, and recording side effects. The main gap is the return value/result shape on success, which nothing else supplies.

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?

Schema description coverage is 0%, so the description must compensate, and it does: mutual exclusivity of element_handle vs automation_id, case-sensitive exact AutomationId matching, root_handle as a scoping modifier, and the '{null}' sentinel for expected_value. This adds substantial meaning beyond the bare schema types.

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?

States a specific verb and resource: asserts an element's dependency-property value via exact ordinal comparison of the invariant string. It also distinguishes itself from siblings by naming wpf_wait_for_element as the tool for asynchronous changes, so an agent can separate it from discovery/wait tools.

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?

Gives explicit preconditions and alternatives: 'Use wpf_wait_for_element first for asynchronous changes', and 'Target by exactly one of element_handle or automation_id'. The root_handle scoping rule and the fail-fast behavior for missing/duplicate IDs further constrain correct invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description must fully disclose behavior. It mentions auto_inject for injecting the Inspector but does not disclose side effects on the target process, error conditions, or prerequisites (e.g., administrator rights, Inspector installation). The description lacks sufficient behavioral context.

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 consists of two sentences: the first states the core purpose, and the second adds essential parameter guidance. It is front-loaded, concise, and contains no filler content.

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 three parameters and no output schema, the description covers the main action and parameter semantics but does not address what happens after attachment (e.g., return value, readiness for other tools). It omits the context that this tool is a prerequisite for most other WPF tools, which would be valuable for the agent.

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?

With 0% schema description coverage, the description clarifies the purpose of process_id and process_name as identification methods and explains auto_inject for injection. However, it does not address scenarios like both identifiers provided, the default behavior of null, or the difference between the two parameters in terms of precedence.

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 clearly states the action ('Attach'), the target ('WPF application'), and the two identification methods ('process ID or name'). This distinguishes it from sibling tools like wpf_click_element or wpf_capture_screenshot, which operate on an already-attached application.

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 provides guidance on when to set auto_inject=true, but does not explain when this tool should be used versus alternatives (e.g., wpf_list_processes as a prerequisite). No explicit when-not-to-use or context for choosing between process_id and process_name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries the full burden, and it does: it names a real failure mode (render returns a blank image for native content, so explicit render 'rejects native content'), lists exactly what render cannot see (popups, ComboBox dropdowns, context menus, tooltips), notes screen mode uses GDI on actual pixels, and discloses the side effect that full_content restores the original scroll position.

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?

Purpose is front-loaded in the first sentence, then mode behavior in decreasing order of importance. Despite being a long paragraph, nearly every clause adds decision-relevant information (which mode, what each can and cannot see, the scroll-restore side effect); nothing is filler.

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?

With no output schema and no annotations, the description usefully states that it returns an image for visual analysis and that the response reports the mode used, which covers the return-value gap. The remaining hole is how max_width/max_height affect output size/aspect, which matters for an agent consuming the image.

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?

Schema coverage is 0% and the schema has no descriptions, so the description must compensate. It gives real semantics for mode (auto/render/screen with distinct behaviors), element_handle ('omit for the entire window'), and full_content (requires render mode, includes virtualized content). max_width and max_height are never mentioned, leaving their scaling behavior undocumented.

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?

States a specific verb and resource ('Capture a screenshot of the WPF window or a specific element') and immediately delimits scope with 'or a specific element... or omit for the entire window'. An agent can distinguish this from tree/property inspection siblings like wpf_snapshot or wpf_get_visual_tree without opening the schema.

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?

Explicitly routes between the three modes: 'use it right after clicking something that opened a popup/menu' for screen, render when the window is covered, and auto as the default that picks based on native HwndHost content. It also states the preconditions for each (visible unobstructed desktop) so the agent can decide rather than guess.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries full burden. It discloses that the tool clears a list, implying mutation, but doesn't specify side effects, scope (all errors or filtered), or behavior when list is already empty. This is adequate but leaves gaps.

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?

Two efficient sentences, front-loaded with the main action and a use case. No wasted words.

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?

For a simple no-parameter tool with no output schema, the description covers the essential purpose and usage context. Could clarify scope, but complete enough for basic tool operation.

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 tool has zero parameters and 100% schema description coverage. With no parameters, the description adds no parameter-specific info, but this is acceptable as the baseline is 4 for 0 params.

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 tool name 'wpf_clear_binding_errors' combined with description 'Clear the captured binding errors list' clearly states the action and resource. It distinguishes itself from sibling 'wpf_get_binding_errors' which captures errors.

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 adds 'Useful before testing specific scenarios,' providing clear usage context. However, no explicit when-not-to-use or alternatives are given, but given the tool's simplicity, this is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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

No annotations are provided, so the description carries full burden. It clearly discloses the output: 'Returns a summary (counts) plus, for each element that changed, the exact properties that changed (from → to), keyed by stable element handle; plus elements added or removed between the two snapshots.' No contradictions.

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 concise, front-loaded with the purpose, and efficiently describes the output structure without superfluous text. Every sentence earns its place.

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?

The description explains the return value in detail (compensating for no output schema) but lacks parameter semantics. For a 2-parameter tool, this is a notable gap, making it somewhat incomplete for an agent to use correctly without additional context.

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?

Schema coverage is 0%, so the description must add meaning. It mentions 'before' and 'after' as snapshot names but does not explain their format (e.g., file paths, data content). The description only implies they are snapshots captured with wpf_snapshot, leaving ambiguity for the agent.

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 uses specific verbs and resources: 'Diff two snapshots captured with wpf_snapshot, to measure the effect of a change.' It clearly distinguishes from sibling tools like wpf_snapshot (which captures) and others.

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 explicitly states when to use the tool: 'Use this to verify a planned UI tweak did what you expected' and provides concrete examples. It implies a workflow with wpf_snapshot but does not explicitly mention when not to use it or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 thoroughly: it discloses that this is STATE-CHANGING, brings the source window forward, moves the cursor, requires visible unobstructed endpoints, prohibits scrolling, and fails before input on missing or duplicate IDs. It also gives an important post-condition warning that success reports input delivery, not drop acceptance, and recommends verifying afterward.

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?

Although long, the length is justified by the 14 undocumented parameters and the lack of annotations. The core action is front-loaded, and the remaining clauses each add necessary targeting, coordinate, side-effect, or verification information without redundant filler.

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?

For a 14-parameter, state-changing input tool with no annotations and no output schema, the description is complete. It explains prerequisites, targeting rules, coordinate systems, side effects, failure conditions, and a post-call verification strategy, leaving little an agent would need to infer before invoking it safely.

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?

Schema description coverage is 0%, so the description must explain all 14 parameters, and it largely does. It covers source versus target targeting, element handles versus automation IDs, target_root_handle scoping, coordinate pairs measured from top-left in WPF DIPs with center default, delta units in source local DIPs including transforms, button choices, and duration_ms range/default.

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 opens with a specific verb and mechanism: 'Drag using the real OS mouse: press, move gradually, release.' It clearly distinguishes this as a real-input drag operation rather than a synthetic property change or touch gesture, and the subsequent sentences sharpen the scope with source/target selection and coordinate semantics.

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 gives strong conditions for use: supply a source and either a target element/ID or deltas, ensure both endpoints are visible and unobstructed, and do not scroll during the drag. It also states this is state-changing and that success only means input delivery, not drop acceptance. It falls short of explicitly naming sibling alternatives like wpf_move_mouse, wpf_click_element, or wpf_touch_gesture, so it is not a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full burden for behavioral transparency. It details what the tool reports: value source, effective value, animation/coercion status, and for bindings, a hop-by-hop path resolution. It does not mention side effects, permissions, or error handling, but the disclosed behavior is sufficient for an agent to understand the tool's operation.

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 several sentences but each sentence adds value: first states purpose, then details output, then differentiates from sibling. It is well-structured and front-loaded. Could be slightly more concise, but no wasted words.

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 no annotations, no output schema, and two parameters with 0% schema coverage, the description provides substantial context about what the tool returns and its diagnostic role. It does not cover return format or error scenarios, but the level of detail is adequate for a diagnostic tool in a rich sibling set.

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?

Schema description coverage is 0% (no descriptions in the input schema), so the description must add meaning. While the tool name and description imply that 'element_handle' identifies the UI element and 'property_name' the property, it does not explicitly describe their types, formats, or constraints. The context helps, but explicit parameter explanations would improve clarity.

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 clearly states the tool's purpose: explain why a property has its current value. It specifies the resource (a property) and the action (evaluate binding). It directly distinguishes itself from sibling tool 'wpf_get_bindings' by noting that it evaluates one binding while the other lists them.

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 explicitly tells when to use this tool: it is the 'go-to tool for why is X empty/wrong/disabled?' and states it complements 'wpf_get_bindings' by evaluating a specific binding. It provides clear context on when to invoke it versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description fully covers behavioral aspects: it lists triggers, evaluates conditions, shows current values, match status, active status, and setters. It also explains the optional property_name parameter for value attribution. No contradictions.

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 detailed but each sentence adds value. It is front-loaded with the primary purpose and use cases. Minor redundancy could be trimmed, but overall it is well-structured.

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 no annotations, no output schema, and only two parameters, the description is complete: it explains both parameters, the output (list of triggers with evaluation), and the optional behavior when property_name is provided. It covers all necessary information for an AI agent to use the tool correctly.

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 schema has 0% description coverage, so the description adds meaning: element_handle is implied as the target element, and property_name is explained as 'attribute that property's effective value to its source'. This compensates for the lack of schema descriptions.

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 clearly states it explains triggers and value sources for WPF elements, with specific use cases like 'why doesn't this trigger fire?' and 'which style/setter set this value?'. It distinguishes itself from sibling tools by focusing on trigger evaluation and property attribution.

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 provides clear use cases for when to use this tool, such as debugging trigger firing and identifying value sources. However, it does not explicitly mention when not to use it or compare it to alternatives like wpf_get_styles or wpf_get_element_properties.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full burden and does substantial work: it discloses the output shape (file-name/content pairs), the exact difference between formats, that tests spawn a fresh app, and that recorded assertions verify outcomes. It omits auth requirements, filesystem overwrite behavior for the target directory, and any rate/performance notes, keeping it short of a 5.

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 purpose and format distinction are front-loaded, and each sentence carries operational information (artifacts, env vars, test behavior). It reads as a dense run-on with several clauses packed together, which slightly hurts scannability but wastes no words.

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?

There is no output schema and no annotations, so the description must cover both behavior and result format; it explains the returned file-name/content pairs and the downstream steps needed to use them. It is nearly complete for a one-param export tool, missing only edge cases such as directory-exists or missing-recording errors.

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 single 'format' param has 0% schema description coverage, so the description must compensate, and it does: it names both accepted values, marks 'xunit' as the default, and explains what each produces. Only the absence of an explicit enum/validation note in prose keeps it from a 5.

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?

States a specific verb (Export) and resource (a stopped recording), and enumerates the concrete artifacts produced per format (runnable .NET 8 test project + workflow.json vs workflow.json only). An agent can distinguish this from siblings like wpf_record, wpf_replay, and wpf_report without opening any schema.

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 phrase 'a stopped recording' implies the prerequisite that a recording must exist and be stopped first, and the description walks through the post-export workflow (save files, set env vars, dotnet test). However, it never names an explicit alternative tool or states when NOT to use this versus wpf_replay/wpf_report, so usage context is clear but not fully bounded.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No behavioral traits disclosed beyond the action. No annotations provided, so description should cover safety, auth, or side effects, but it does not. Unclear if operation is read-only or modifies state.

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?

Extremely short (one sentence) but omits critical details. Not effectively concise; would benefit from clarifying parameters and output format.

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?

Very incomplete. No output schema, no parameter documentation, no annotations. Agent lacks information to invoke tool correctly (valid format values, element_handle usage, return format).

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?

Schema coverage is 0%. Description does not explain the format parameter's valid values (only suggests XAML/JSON) or the element_handle parameter's purpose (e.g., root element handle). No default values clarified.

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?

Description clearly states the action (Export) and resource (visual tree) with format options (XAML or JSON). It distinguishes from sibling tool wpf_get_visual_tree by implying file/string output, but could specify whether output is to file or returned.

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?

No guidance on when to use this tool vs alternatives like wpf_get_visual_tree. No context about prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full burden and does disclose useful behavior: filters combine with AND, exact vs partial vs case-insensitive matching, the returned fields (text, automationId, isVisible, isEnabled, screenBounds), and the max_results default. However it never states that an attach/session is required, nor whether the call is read-only or what happens when nothing matches — meaningful gaps for an 8-param query tool with zero annotation coverage.

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?

Front-loaded with the core purpose in sentence one, followed by per-filter definitions and a usage recommendation; nearly every clause adds information. It is dense — a single long parenthetical sentence for 'text' — but not padded.

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?

No output schema exists, and the description usefully enumerates return fields and the result cap so the agent can act on results. Missing root_handle semantics and the session/attach prerequisite keep it from being fully complete.

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?

Schema coverage is 0%, so the description must compensate and largely does: it defines text, type_name, element_name, automation_id, property_filter (with a JSON example) and visible_only precisely, plus max_results. Only root_handle is left entirely undefined, which is why this falls short of 5.

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?

Opens with a specific verb+resource ('Query elements across all open windows') and enumerates the filter dimensions, so an agent knows exactly what it does. It never differentiates itself from the sibling wpf_find_elements_deep, leaving ambiguity about which finder to call.

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?

Gives actionable guidance: 'PREFER text over dumping the tree' with a worked example (text='Save' + type_name='Button'), and recommends visible_only 'when looking for something the user can see'. It omits when to prefer wpf_get_visual_tree or wpf_find_elements_deep, so exclusion guidance is incomplete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full burden and does disclose two important behaviors: unbounded result sets and the guard against returning the entire tree. It omits return format, performance/rate implications of an unlimited deep traversal, and any permission requirements, leaving meaningful gaps for a potentially expensive operation.

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?

Front-loads the distinguishing trait (deep search, no limit) and then the safety constraint. Dense and purposeful with little waste, though the filter enumeration is somewhat list-like.

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 7 undocumented params, no annotations, and no output schema, the description covers matching semantics and scoping adequately. It still leaves the return value (presumably a list of element handles) and the practical cost of unbounded traversal unstated.

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?

Schema coverage is 0%, so the description must compensate, and it does well: it specifies matching semantics for the key filters (automation_id exact case-sensitive, type_name partial, element_name x:Name substring, text visible content) and the role of visible_only and root_handle. Only property_filter's shape is left unexplained.

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?

States a specific verb and resource (deep search for all elements) and distinguishes itself from the sibling wpf_find_elements via the 'no result limit' trait and 'Same filters as' reference. The core action is unambiguous, though it leans on the sibling for the full picture rather than fully standing alone.

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?

Provides a hard usage constraint ('Requires at least type_name, element_name, text or automation_id') and a scoping hint ('Use root_handle to limit scope'), which is useful guidance. However it never explicitly says when to prefer this over wpf_find_elements or the reverse, so the routing decision is only implied by the 'no result limit' remark.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

In absence of annotations, description notes detection via WPF trace listener but does not cover behavior like empty list or performance. Adequate for a simple read-only tool.

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?

Two efficient sentences: first states purpose and scope, second provides guidance. No extraneous content.

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 zero parameters and no output schema, the description covers purpose, detection method, and related tool. Complete for this simple tool.

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?

No parameters exist; schema coverage is trivially 100%. Baseline 4 for 0-parameter tools.

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 clearly states 'List all binding errors captured since application start' with a specific verb (list) and resource (binding errors), and distinguishes from sibling wpf_clear_binding_errors.

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?

Provides explicit alternative tool for resetting (wpf_clear_binding_errors) but lacks broader guidance on when to use this vs other get tools like wpf_get_bindings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Without annotations, the description carries full burden. It implies a read operation and mentions 'status', but lacks details on output format, potential size, or performance impact. Not contradictory but minimal.

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?

Single sentence conveying the core functionality with no waste; front-loaded information.

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?

For a simple 1-param tool with no output schema or annotations, the description tells what it does but not what the output looks like or how to use the parameter, leaving gaps.

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 only parameter 'element_handle' is not described in the schema (0% coverage) and the description does not explain how to obtain or format it, leaving ambiguity.

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 clearly states the verb 'get', the resource 'data bindings', and specifies 'for an element' and 'with their status', distinguishing it from siblings like wpf_get_binding_errors and wpf_get_data_context.

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?

No guidance on when to use this tool versus alternatives, prerequisites (e.g., element must exist), or conditions under which it should not be used.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries full burden. It transparently describes what the tool returns (DataContext with type info, properties, INPC status, inheritance chain). It does not mention side effects, but as a read-only diagnostic tool, that is acceptable.

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?

Two sentences, no redundancy. The first sentence front-loads the action and output, the second adds practical context. Every word earns its place.

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 one parameter, no output schema, and no annotations, the description is fairly complete: it specifies what is included and why. It could mention that the element must be in the visual tree, but overall it covers essentials.

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?

Schema coverage is 0%, requiring description to compensate. The description implies element_handle identifies an element but does not explicitly define the parameter. Context helps, but explicit description is lacking.

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 clearly states the tool gets the DataContext for an element, listing included data (type info, properties, INPC status, inheritance chain) and its use case (diagnosing binding path errors). This distinguishes it from siblings like wpf_get_bindings and wpf_get_visual_tree.

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 explicitly states it is 'essential for diagnosing binding path errors,' providing a clear use case. However, it does not specify when not to use this tool or mention alternatives, but the context is strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are present, so the description must fully disclose behavior. It does not state that this is a read-only operation or what 'all dependency properties' entails (e.g., attached properties, inherited values). The lack of detail leaves the agent uncertain about side effects or scope.

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 concise at one sentence, but it is underspecified rather than efficiently informative. It earns its place but fails to add necessary detail.

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?

For a simple tool with one parameter and no output schema, the description should still provide enough to use it correctly. It is incomplete because it omits parameter guidance and return value expectations.

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 schema has 0% description coverage for the single required parameter 'element_handle'. The description does not explain what a valid handle is, how to obtain it, or its expected format. This is a critical gap for correct invocation.

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 'Get all dependency properties of a UI element', which is a clear verb+resource pair. However, it does not differentiate from sibling tools like 'wpf_get_bindings' or 'wpf_get_data_context', which may cause confusion about scope.

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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as needing to attach to a WPF application first, or when other property-related tools might be more appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The description implies a read-only operation ('Get'), but with no annotations and no explicit statement about side effects, permissions, or state requirements, it fails to clarify behavioral traits. A simple read-only hint is absent.

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 sentence, which is concise but lacks structure (no sections for usage, parameters, or output). While not verbose, it sacrifices completeness for brevity.

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?

With one parameter, no output schema, and many sibling tools, the description is insufficient. It does not explain what 'layout information' includes beyond examples, nor does it clarify that the output is likely a dictionary of properties. The agent would struggle to use it correctly.

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 schema has 0% description coverage for the only parameter (element_handle), and the tool description does not add any meaning to what this parameter represents or how to obtain it. The parameter is completely opaque.

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 clearly states the tool's purpose: retrieving layout information (ActualWidth, ActualHeight, Margin, etc.) for a WPF element. The verb 'Get' and the specific properties differentiate it from sibling tools like wpf_get_element_properties, though it doesn't explicitly contrast them.

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?

No guidance is provided on when to use this tool versus alternatives like wpf_get_element_properties or wpf_get_data_context. There are no examples or prerequisites mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full behavioral burden. It does disclose one meaningful trait beyond the name — the output uses 'stable selectors instead of session handles' — but it is silent on permissions, whether a recording must be running, error behavior, and the shape/size of the returned JSON.

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?

A single front-loaded sentence with no filler; the return contents come first and the selector caveat last. It is appropriately sized, though slightly dense in phrasing.

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?

For a zero-param getter with no output schema and no annotations, the description should describe what comes back more concretely. It names the two payload components but not their structure, and omits preconditions for calling it, leaving an agent to guess at the operational context.

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 tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. No parameter information is missing because none exists.

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?

States a specific verb ('Get') plus the resource returned (current recording state and versioned workflow JSON), which is far more informative than the bare name. It does not explicitly differentiate itself from the sibling wpf_record, but the noun 'recording state/JSON' clearly separates a read of the recording from starting one.

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?

Usage is only implied — an agent must infer this is meant to be called after or alongside wpf_record to retrieve the captured workflow. There is no explicit statement of when to use it versus wpf_replay, wpf_report, or wpf_export_test, and no prerequisites (e.g., whether a recording must be active) are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description must disclose side effects and behavior. It only states enumeration, lacking details on whether this is read-only, impacts state, or what happens with different scope values.

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 sentence without fluff, but it omits critical details, making it under-specified rather than optimally concise.

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 two parameters, no output schema, and a complex domain (WPF resources), the description is incomplete. It does not explain return values, parameter roles, or usage scenarios.

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?

Schema coverage is 0% and description fails to explain the two parameters ('scope' and 'element_handle'). Their purpose, allowed values, and defaults are not clarified, providing no additional meaning.

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 'Enumerate resource dictionaries and their contents' clearly states the action and resource, distinguishing it from sibling tools like wpf_get_styles which focus on specific resource types.

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?

No guidance is provided on when to use this tool versus alternatives like wpf_get_styles or wpf_get_bindings. The description does not mention context or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations provided, so description must disclose behavioral traits. It only states the action without mentioning side effects, data freshness, or requirements, leaving significant gaps.

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?

Single sentence is concise but overly sparse; it states purpose adequately but omits necessary details, making it minimally acceptable in structure.

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 no output schema and simple parameters, the description should explain return value or style format. It provides no such context, making it incomplete for effective tool use.

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?

Schema description coverage is 0%, yet the description adds no meaning to the single parameter 'element_handle' beyond the schema, failing to explain its format or scope.

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?

Description clearly states verb 'Get', resource 'applied styles and templates', and target 'element', distinguishing it from sibling get tools like get_bindings or get_element_properties.

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?

No guidance on when to use this tool versus alternatives, nor any prerequisites or limitations. The description is silent on usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authorization needs, or side effects. Since it's a 'get' operation, it likely does not modify state, but this is not explicitly stated.

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 extremely concise with two sentences, no redundant words, and the purpose is front-loaded. Each sentence adds value.

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?

No output schema is present, and the description does not explain the return format. Behavioral details are missing, but for a simple hierarchical retrieval, the description is minimally viable.

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 description adds meaning to both parameters beyond the schema: root_handle is linked to wpf_find_elements, and max_depth has a suggested range (1-100) with a default of 25. Schema coverage is 0%, so the description compensates well.

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 clearly states 'Get the visual tree hierarchy' with a specific verb and resource. It distinguishes itself from sibling tools by referencing 'root_handle to start from a specific element (from wpf_find_elements)', indicating its unique purpose.

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 provides explicit guidance on using root_handle and max_depth parameters, including a tip for deep UIs like AvalonDock. It does not explicitly mention when not to use or alternatives, but the context is sufficient for typical usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The description only states the basic action without any behavioral details. It does not mention that the highlight is temporary, that duration_ms controls the time, or any other effects. With no annotations, this leaves the agent guessing about the tool's side effects.

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 very short and to the point, but it lacks structure. It is a single sentence without breaking down purpose, parameters, or behavior. While concise, it sacrifices clarity.

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?

The description is incomplete for an agent to use confidently. It lacks information about the preconditions (element must exist), the effect on UI state, and how the duration works. With no annotations or output schema, the description carries full responsibility for completeness.

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 description does not mention or explain any parameters. With 0% schema coverage, the agent has no information about 'element_handle' or 'duration_ms' beyond their types. The description should have clarified these.

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 uses a specific verb 'highlight' and resource 'element', making the purpose clear. While it doesn't explicitly distinguish from siblings, the action is unique among the listed tools.

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?

No usage guidelines provided. The description does not indicate when to use this tool versus other element-related tools like wpf_click_element or wpf_find_elements.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations provided; description only states basic listing without disclosing details like output format, performance implications, or safety.

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?

Single sentence, concise and front-loaded with verb and resource, no wasted words.

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?

Description covers the basic purpose but omits output format or how it integrates with sibling tools. Given no output schema, more detail on return value would be beneficial.

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?

No parameters, so schema coverage is trivially 100%. Description adds no parameter info beyond schema, but none is needed. Baseline of 3 is appropriate.

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?

Description clearly states verb 'list' and resource 'running WPF applications', distinguishing it from sibling tools that perform actions like attaching or clicking.

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?

No explicit guidance on when to use vs alternatives, but the purpose implies usage before attaching or inspecting applications. Lacks explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 well: it flags STATE-CHANGING, window activation, the visible-unobstructed-desktop prerequisite, HwndHost/native content support, UI-responsive hover waiting, and that missing/duplicate IDs fail before any input is sent.

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?

Dense and front-loaded with the core action first, then constraints and targeting rules. Every sentence carries information, though the packed clauses make it slightly telegraphic rather than optimally structured.

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 six untyped params, no annotations, and no output schema, the description covers safety, prerequisites, targeting rules, and hover behavior fully enough for an agent to invoke it correctly.

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?

Schema coverage is 0%, so the description must compensate, and it does: x/y are paired local WPF DIPs defaulting to center, hover_ms is bounded 0-5000 with default 500, root_handle scopes automation_id lookup, and exactly-one-of element_handle/automation_id (case-sensitive exact match) is spelled out.

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?

States a specific verb+resource ('Move the real mouse to a visible element without clicking'), immediately distinguishing it from wpf_click_element and wpf_drag by explicitly excluding the click.

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?

Provides strong calling context: activates the target window, requires a visible unobstructed desktop, verify tooltips with a screenshot, and target by exactly one of element_handle or automation_id. It doesn't explicitly route to a sibling alternative (e.g., click_element when a click is wanted), so not quite a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full behavioral burden, and it does so well: it discloses what gets captured (input actions including drag/touch, finds, successful waits and assertions), persistence across CLI invocations, plain-text value storage, and the sequential-call constraint. It leaves out the destructive nature of 'clear' and any error/auth behavior, but the added context is substantive.

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 core purpose is front-loaded in the first clause, and the following sentences each add a distinct operational fact (capture scope, ordering rule, persistence, sequencing). No redundant or padded sentences, though the density makes it slightly harder to scan.

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?

For a stateful, multi-action tool with no annotations, no output schema, and 0% schema coverage, the description supplies the essential lifecycle (persistence until target exit), capture semantics, and constraints. It remains incomplete on the exact action contract and the `name` parameter, but is largely sufficient to call the tool correctly.

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?

Schema coverage is 0%, so the description must compensate. It effectively enumerates the valid values for the `action` parameter (start/stop/status/clear) but never states these map to `action`, and provides no meaning at all for the optional `name` parameter. This is partial compensation with a clear remaining gap.

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?

States a specific set of verbs (start/stop/status/clear) applied to a concrete resource (linear workflow recording in the attached app). An agent can distinguish this control tool from retrieval (wpf_get_recording), replay (wpf_replay), and export (wpf_export_test). It stops short of naming any sibling explicitly, which keeps it just below the top band.

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?

Implied usage is present: 'Start/stop/status/clear' plus the ordering rule 'Stop and export before clearing' and the sequencing constraint 'Calls must be sequential while recording.' However, it never states when to prefer this over recording alternatives like wpf_replay or wpf_export_test, or what prerequisites (attached app) gate invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 well: mutates app state, stops at first failure with no rollback, failedStep numbering, a 120s deadline, concurrent queries still allowed while other mutations are rejected, and async waits. This is unusually rich behavioral disclosure for a write tool.

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?

Terse, front-loaded, and information-dense; the primary action leads and every subsequent clause adds a distinct operational constraint without padding.

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?

Behavioral context is thorough, but for a tool whose only required parameter is a complex nested schema at 0% description coverage and with no output schema, the description leaves the agent unable to construct a valid `workflow` payload without inspecting the schema.

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?

Schema description coverage is 0% and the required `workflow` parameter is a deeply nested object (steps/action/target/root/destination/arguments) that the description never explains. Only `timeout_ms` is partially addressed via the 'Deadline max 120 seconds' clause, so the description does not compensate for the coverage gap.

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?

States a specific verb+resource ('Replay a versioned workflow against the attached app') with a distinctive mechanism ('resolving fresh unique selectors'). This cleanly separates it from the recording siblings (wpf_record, wpf_get_recording) without needing to name them.

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?

Gives a clear precondition ('stop recording first') and an environment requirement ('Physical actions need an interactive desktop'), which tells the agent when the tool is viable. It does not name alternatives or state when-not to use it, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries the full burden and does substantial work: it declares the operation is non-mutating ('does not change the UI'), discloses a significant limitation ('does not realize virtualized items'), and states that output includes coverage and truncation reasons. Remaining gaps are permissions/attach prerequisites and rough cost of a process-wide trace scan.

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?

Front-loaded with the purpose, then limits, then behavioral caveats — a sensible ordering with no filler. It is dense to the point of terseness ('State counts are observations, not defects'), requiring some parsing, but every sentence carries information.

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?

With no annotations and no output schema, the description covers the essentials an agent needs: scope, bounds, non-mutation, truncation reporting, and the interpretive caveat about state counts. It stops short of describing the report's shape (sections, per-element vs aggregate counts), which matters for a multi-section diagnostic payload.

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?

Schema coverage is 0% with four parameters, so the description must compensate. It does give usable bounds for three of them (max_elements 1-2000, max_depth 1-100, max_findings 1-500), which is real added value, but root_handle is only obliquely implied by 'or a subtree' and its null default/format is never explained.

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?

States a specific verb and resource ('Collect a bounded diagnostic report') plus the scope ('across open windows or a subtree') and enumerates what the report contains: binding/validation errors, state counts, and process-wide binding traces. This clearly distinguishes it as an aggregate report rather than a single-purpose call, though it never names the siblings it overlaps with (e.g. wpf_get_binding_errors, wpf_snapshot).

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 'across open windows or a subtree' phrasing implies scope selection but never states the condition explicitly (that omitting root_handle targets all windows). No guidance on when to prefer this over wpf_get_binding_errors, wpf_get_visual_tree, or wpf_snapshot, which cover overlapping territory.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description does heavy lifting: it discloses restore semantics (binding, local value, or nothing, falling back to style/inherited/default), the return content (count reverted, count remaining), and a failure mode ('missing or duplicate IDs fail before input'). It stops short of stating prerequisites such as needing an attached process or whether reverts survive a new snapshot/recording session.

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?

Four tight sentences, front-loaded with the inverse-of-set_property framing, then targeting, then restore behavior, then return/failure info. No redundancy or filler.

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?

Covers return values despite no output schema and explains failure behavior, which is strong for a 5-param mutation. The only omission is session/attach prerequisites that gate whether the tool can be invoked at all.

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?

Schema coverage is 0%, so the description must carry all meaning, and it does: it explains all five parameters — all, element_handle, property_name, automation_id (exact, case-sensitive AutomationProperties.AutomationId), and root_handle scoping. It even adds semantics the schema lacks, such as the exactly-one-of targeting constraint.

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?

States a specific verb+resource ('Undo live property edits') and ties it directly to the sibling that creates them (wpf_set_property), so the inverse relationship is unambiguous. Defaults and override modes are named up front, letting an agent distinguish it from wpf_set_property or wpf_get_element_properties immediately.

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?

Gives explicit when-to-use conditions: default = most recent edit, element_handle/property_name = targeted, all=true = every pending edit. Also names the mutual exclusivity rule ('exactly one of element_handle or automation_id') and the root_handle scoping pattern, with no inference required.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full burden, and it does well: it openly flags "STATE-CHANGING," warns that the mouse is moved and the app activated, and discloses pre-input failure conditions (missing or duplicate IDs fail before input) plus support for native hosted canvases. It doesn't say whether the scroll is reversible or what the response looks like, which keeps it from a 5.

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?

Purpose is front-loaded in the first clause, followed by parameter semantics, then behavioral warnings, then targeting rules. Every sentence carries information, though the dense, semicolon-heavy packing makes it harder to scan.

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?

For a 7-parameter, no-annotation, no-output-schema tool, the definition covers targeting resolution, parameter meaning, side effects, and expected verification steps. Nothing an agent needs to invoke it correctly is missing.

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?

Schema coverage is 0%, so the description must compensate, and it does for the critical parameters: delta units/sign/range (-12000..12000, 120 per notch), x/y as local WPF DIPs defaulting to center, horizontal axis flipping, and the mutually exclusive element_handle/automation_id targeting with root_handle scoping. Only root_handle's standalone behavior is left somewhat implicit.

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?

Names a specific verb and resource: "Send a real mouse wheel event over a visible element." It implicitly distinguishes itself from siblings like wpf_click_element and wpf_move_mouse by emphasizing the wheel event and noting that mouse movement is only a side effect, not the purpose.

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?

Gives concrete when-to-use mechanics (targeting by element_handle or automation_id, scoping via root_handle) and tells the agent to verify results because "The app decides whether to scroll, zoom or ignore input." It never names an alternative sibling tool or states when NOT to use this one, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the full behavioral burden and discloses key traits: OS-level keyboard input, foreground activation, state-changing behavior, and pre-input failure for invalid target resolution. It does not describe timing, return behavior, or focus restoration after execution.

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 front-loaded with purpose, examples, and behavioral warnings, and every listed key/modifier earns its place given the 0% schema coverage. It is dense but not bloated; small readability improvements could split the targeting constraints and key syntax more clearly.

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?

For a state-changing tool with no annotations, no output schema, and undocumented parameters, the description is nearly complete: purpose, targeting, syntax, foregrounding, and failure modes are all covered. It could say more about timing or what happens after the key sequence is sent, but an agent has enough to invoke it correctly.

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?

Schema description coverage is 0%, so the description must compensate, and it does: it documents syntax for keys, supported modifiers and key names, exact targeting by element_handle or automation_id, case-sensitive AutomationId matching, and root_handle scoping. This covers all four parameters with meaningful semantics beyond the bare schema.

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 a specific verb and resource: sending a keyboard shortcut or key combination to a WPF element or current focus. It clearly distinguishes the tool from siblings like wpf_click_element and wpf_set_text by explaining keyboard input targeting.

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?

It gives clear targeting rules: use exactly one of element_handle or automation_id, and when both are omitted input goes to current focus. It also explains root_handle scoping and failure for missing or duplicate IDs. It lacks explicit comparison to alternative tools such as using wpf_set_text for text insertion instead of key sequences.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries the full burden and does so: it declares STATE-CHANGING, reversible, explains that setting a bound property replaces the binding with a local value, describes the return (coerced value plus previous holder: Binding/Local/Unset), and warns missing/duplicate IDs fail before input.

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?

Dense but front-loaded: purpose first, then value-format examples, then behavioral caveats, then targeting rules. Every sentence adds operational information the agent needs; nothing is filler.

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?

For a 5-parameter mutation tool with no annotations and no output schema, the description covers purpose, coercion semantics, binding side effects, reversal path, return shape, and targeting failures. Nothing an agent needs to call it correctly is missing.

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?

Schema coverage is 0%, so the description must compensate and does: value is a string coerced to the property's type with concrete examples (Margin '20,0,20,0', Visibility 'Collapsed', Background 'Red'/'#FF0000', '{null}' for null); property_name is exemplified; element_handle/automation_id/root_handle targeting rules are spelled out.

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?

States a specific verb (live-edit), a specific resource (a dependency property on an element at runtime), and the goal (test a UI change without rebuilding). An agent can immediately distinguish this from wpf_set_text or wpf_click_element.

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?

Gives explicit workflow guidance (pair with wpf_capture_screenshot, then revert via wpf_revert_property) and alternatives. Also states targeting prerequisites: 'exactly one of element_handle or automation_id', and how root_handle scopes lookup.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 well: it declares STATE-CHANGING, notes that physical mode moves window focus and clears text via Ctrl+A/Delete, mentions proper event raising, and states that missing or duplicate automation IDs fail before input. This is rich behavioral context beyond what structured fields provide.

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?

Front-loaded with the core purpose, then mechanics and targeting rules. It is dense but has no filler; a bulleted structure would improve scanability, but every sentence is informative.

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 five parameters, no annotations, no output schema, and mutation behavior, the description covers mechanics, targeting, side effects, and failure conditions. It lacks a note on success return value, but that is a minor gap for a setter-style tool.

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?

Schema coverage is 0%, but the description documents all five parameters: text, physical (with detailed mechanics), root_handle scoping, automation_id case sensitivity, and mutual exclusivity between element_handle and automation_id. It adds substantial meaning beyond the bare schema types.

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?

States a specific verb ('Set') and resource ('text/value of a UI element'), enumerating element types like TextBox and ComboBox. It does not explicitly name sibling tools such as wpf_set_property, so differentiation is implicit through its text-specific focus rather than stated.

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?

Explains the default UIA behavior, fallback paths, and when to use physical=true with details about focus and clearing existing text. Also states the targeting rule (exactly one of element_handle or automation_id) and root_handle scoping. It does not explicitly say when to prefer wpf_send_keys or wpf_set_property instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full burden. It discloses what data is captured (layout metrics, etc.) and the workflow. It does not detail whether the snapshot is deep or shallow, whether overwriting a label is allowed, or any side effects. It is decent but could be more explicit about safety (e.g., it's read-only).

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 concise, using three sentences. The first sentence states the core purpose, the second gives workflow context, and the third clarifies parameters. No redundant or filler words.

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?

Considering the tool has 3 parameters and no output schema, the description covers the workflow, parameter usage, and return (label and count). It is missing details about label uniqueness and persistence, but overall it provides sufficient context for an agent to use the tool correctly.

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 0% description coverage, so the description must compensate. It explains each parameter: label is for storing, max_depth default 25, element_handle sets subtree root or whole window. This adds meaningful context beyond the schema types.

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 clearly states the verb 'capture a snapshot' and specifies the resource: an element's subtree with details about what is captured (layout metrics, visibility, alignment, brushes, text). It distinguishes itself from the sibling tool wpf_diff, which compares snapshots, by explaining its role in the workflow.

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 provides explicit guidance on when to use this tool: in a workflow with wpf_snapshot before and after a change, followed by wpf_diff. It explains that element_handle sets the subtree root and max_depth defaults to 25. However, it does not mention when not to use it or alternatives beyond wpf_diff.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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

No annotations are provided, so the description carries the full burden and does so well: it discloses polling mechanics, the default and max timeout (10000/25000), poll interval (250ms), what each condition means, and even the return shape (matched, waited_ms, matched_handle/element_type). It also explains the non-obvious 'hidden' condition (no matching visible element, e.g. a spinner disappeared), which is exactly the kind of semantic an agent could not infer.

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?

Front-loaded with purpose and dense with content; the condition list, return values, usage scenario, and timing defaults each earn their place. It is a single long block with no formatting breaks, which slightly hurts scanability for a definition this dense.

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 no annotations, no output schema, and 8 parameters with zero schema descriptions, the description supplies everything an agent needs: element matching semantics, condition definitions, timing bounds, and return values. Only root_handle is unaddressed, which is a minor gap against otherwise complete coverage.

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?

Schema description coverage is 0%, so the description must compensate, and it does for 7 of 8 parameters — including the critical condition enum values, which are absent from the schema, plus automation_id case-sensitivity and timing defaults/ranges. root_handle is never mentioned anywhere, leaving one parameter fully undefined.

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?

States a specific verb+resource ('Wait until an element matching the criteria satisfies a condition') and immediately distinguishes itself from the sibling finder by noting it uses 'the same matching as wpf_find_elements'. An agent can tell this is a polling wait, not a one-shot lookup, without opening the schema.

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?

Gives a concrete trigger scenario ('Use after a click that triggers async work (dialog opens, spinner clears, button enables) before the next step') and frames the tool against the sleep-and-retry antipattern, which effectively routes the agent away from alternatives. It stops short of an explicit when-not (e.g., 'if the element is already present, use wpf_find_elements'), so it lands at 4 rather than 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations exist, so the description must fully disclose behavior. It only says 'Monitor a property for changes' without stating if it blocks, returns immediately, is continuous, or has side effects. This is insufficient for an agent to predict tool impact.

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?

Extremely concise at 4 words, but at the expense of critical information. Conciseness should not sacrifice completeness; this is under-specification, not efficient brevity.

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 no output schema, no annotations, and only two bare parameters, the description is severely incomplete. A tool that monitors properties requires details on return format, duration, error handling, and interaction with the UI thread—none provided.

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?

With 0% schema coverage, the description should add meaning to parameters. Neither 'property_name' nor 'element_handle' are explained beyond their names. No hints on format, constraints, or relationship between 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 uses verb 'Monitor' and resource 'property', indicating a watching function. However, 'monitor' is vague—does it set up a subscription, poll, or return on change? It distinguishes from siblings like 'wpf_get_element_properties' (snapshot) and 'wpf_set_property' (mutation), but the lack of specificity reduces 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?

No guidance on when to use this tool vs alternatives like 'wpf_get_element_properties' for one-time retrieval or 'wpf_get_bindings' for binding info. The description does not explain context, prerequisites, or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.