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

With no annotations, the description fully discloses side effects: injection modifies the target process (loads DLL, starts RPC thread/listener), session dies with the process, and specific error codes (2001, 2002, 2006) are explained. This is thorough and beyond the basic 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 long but every sentence carries meaningful information about prerequisites, compatibility, error handling, and side effects. The main action is front-loaded and the structure is logical, though slightly 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?

The description covers all necessary context: how to prepare, compatibility requirements, error codes, side effects, and session lifecycle. Since an output schema exists, return format details are appropriately omitted. It is complete for a tool with these complexities.

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 only lists 'pid' as an integer with no description. The description compensates by telling the user to find the pid via qt_list_processes and refers to the target process. This gives enough context for a single simple parameter, though it stops short of a formal definition.

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 function: 'Inject the helper library into a running Qt process and open a session.' This is specific and distinguishes it from sibling tools like qt_detach and qt_list_processes.

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 provides explicit guidance: use qt_list_processes to find the pid, detach before re-attaching if already attached, and check qt_list_sessions after session death. It also clarifies it does not build automatically and gives the tool sequence when build is missing.

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 full behavioral transparency. It explains toolchain selection behavior, automatic Qt-bundled Ninja usage, the consequence of qt_major mismatch (fails to inject), and the locked-file failure mode when old DLLs remain attached. This goes well beyond a simple 'build' statement.

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 lengthy, the description is densely packed with necessary operational detail and is well-structured: it starts with a purpose sentence, then explains toolchain semantics, then mandatory user-consent steps, then parameter-specific guidance, and finally a rebuild prerequisite. Every sentence earns its place, and formatting aids scanning.

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 8-parameter complexity, absence of annotations, and 0% schema coverage, this description is remarkably complete. It covers all parameters, critical preconditions, user interaction requirements, cross-tool dependencies, and failure modes. The presence of an output schema further reduces the need to document return values.

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 compensates fully by explaining every parameter: toolchain with msvc/mingw semantics, vcvars_path/qt_env roles, qt_major matching rule, with_qml purpose, build_type matching requirement, vcvars_args example, and generator override guidance. It adds meaning well beyond the raw 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 opens with a specific verb+resource: 'Build the Qt injection library and injector for the specified environment.' It clearly distinguishes this build tool from the sibling inspection/control tools like qt_list_processes, qt_attach, and qt_detach. The unique build purpose is unambiguous.

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 usage rules: the AI MUST present build environments to the user, MUST ask about QML support, MUST ask for build_type, and MUST NOT guess paths. It also gives a concrete alternative/prerequisite by directing the AI to use qt_detach with purge=True before rebuilding and to read qt_major from qt_list_processes or qt_detect_msvc_and_qt.

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 carries the full burden. It discloses critical behavioral traits: destructive with no undo, methods execute for real, deleteLater destroys the element and invalidates its id, and args are silently coerced up to 10. This goes beyond the schema and gives essential safety warnings.

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 the core purpose, followed by crucial warnings and usage guidance. It is concise with no wasted words; every sentence provides necessary 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 an output schema present, return values are covered. The description covers purpose, usage, destructive behavior, and arg constraints. However, it leaves session_id/element_id semantics and failure behavior unexplained, which is a noticeable gap for a 4-parameter 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 descriptions are 0%, so the description must compensate. It adds meaning for method (invokable, dangerous examples) and args (coerced, max 10), but session_id and element_id remain completely undefined. The description does not fully explain the parameters needed 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 clearly states the tool invokes a QMetaObject-invokable method on a UI element, with specific examples (close, deleteLater) and contrasts this with simulating user input. This distinguishes it from sibling input simulation and property 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?

Explicitly advises preferring simulating user input (clicks/keys) and using direct method calls only when a direct API invocation is intended. This provides clear when-not-to-use guidance and names an alternative category (input simulation).

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 the full burden of behavioral disclosure. It clearly states that purge=True 'ejects the injected DLL' and 'deletes the session's saved files' and marks the action as 'irreversible.' It also discloses the consequence of purge=False: the DLL stays loaded until the process exits.

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 three sentences, with the core purpose in the first line. Each subsequent sentence explains the purge behavior and links it to a real-world consequence, with no fluff.

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 covers the purpose, parameter behavior, irreversible side effects, and a practical use case. It doesn't detail return values or error handling, but an output schema exists, and the tool is simple enough that this is not a major gap.

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 provides only names and types, but the description adds deep semantic meaning for purge: default False, what it does, and why it matters. The session_id parameter is not explicitly described but is implied by the term 'session'; the description's detail on purge compensates for the 0% schema coverage.

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 clear, specific action: 'Disconnect from a Qt process session,' which uses a precise verb and resource. It distinguishes itself from sibling tools like qt_attach and qt_build through its focus on session teardown.

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 explicit guidance on when to use purge=True: 'Use purge=True before rebuilding the library: otherwise the DLL file stays locked by the target process and qt_build fails.' It also explains the alternative behavior with purge=False, helping agents choose the right parameter value.

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 full responsibility for behavioral disclosure. It clearly states the tool is read-only ('only *discovers* and *displays*'), does not modify or select anything, and describes the edge-case behavior when nothing is found. This is comprehensive for a non-mutating detection 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?

The description is longer than a single sentence, but every sentence serves a purpose: outlining the detection scope, emphasizing non-selection behavior, and giving concrete integration steps with qt_build. It is well-structured with an 'IMPORTANT' callout, though it could be slightly trimmed without losing meaning.

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 fully explains the tool's role within the workflow, including return values (vs_installations, mingw_toolchains, qt_installations), how to use the results with qt_build, and the fallback for missing installations. Given the tool has no parameters and an output schema exists, the description covers all needed 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 has zero parameters, so the baseline is 4. There is no input schema to clarify, and the description appropriately focuses on output. It does not need to add parameter information, and the baseline 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?

The description clearly states the tool detects MSVC, MinGW toolchains, and Qt installations for building. It specifies the exact resources ('vs_installations', 'mingw_toolchains', 'qt_installations') and distinguishes itself from sibling tools like qt_build and qt_attach by focusing on discovery only.

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 when-to-use guidance: it is the discovery step before qt_build. It includes a mandatory instruction to use AskUserQuestion after calling, explains how to pass results to qt_build for both MSVC and MinGW kits, and tells the user to enter paths manually if detection fails. It also clarifies what the tool does NOT do ('does NOT select an environment automatically'), preventing misuse.

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 succeeds. It discloses the AND-ed query semantics, default hidden element handling, result shape for both success and no-match, and the critical side effect: every call invalidates all previous element/window IDs. The ID lifecycle warning about stale IDs and re-running is essential 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 is longer than typical but every sentence earns its place given the tool's complexity. It is well-structured with sections for query fields, examples, result format, and ID lifecycle. Minor redundancy (explaining result format when an output schema exists) keeps it from a 5, but it is dense and highly scannable.

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 tool has a nested query object and an output schema, yet the description goes far beyond schema requirements. It covers query field semantics, depth/limit behavior, hidden element handling, error results, and ID invalidation—details an agent needs to invoke the tool correctly and handle failures gracefully. It is complete for this tool's complexity.

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 treats 'query' as an opaque object with 0% property coverage, so the description must explain all valid keys. It does so comprehensively: type, type_inherits, text/text_contains, object_name, window_title variants, properties, ancestor/window_id, depth with exact values, limit, and include_hidden. It also gives two concrete examples, fully compensating for the schema's lack of detail.

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 resource: 'Find UI elements matching a query in a session.' It clearly distinguishes this from sibling tools like qt_snapshot (snapshot creation) and qt_get_property (property inspection) by focusing on element discovery via a flexible query.

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 says 'No prior snapshot is needed; this call rebuilds the element map itself,' which clarifies when to use this instead of taking a snapshot first. It also instructs when to re-run the tool after stale IDs, referencing 'qt_find_element (or a snapshot)' as recovery options, effectively naming an alternative.

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. It discloses the best-effort nature and the specific QML limitation where the tool may report success without actually changing focus. This is valuable transparency about potential false positives, though it could mention more about error behavior or 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 brief and front-loaded: two sentences that first state the purpose and then provide essential caveats. Every sentence adds value, with no redundant 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?

Given the tool's simplicity and the presence of an output schema, the description is reasonably complete. It covers the core action and a significant behavioral quirk. However, it lacks guidance on when to use this instead of other interaction tools and could clarify the role of session_id in the context of UI automation.

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 and the tool description does not explain the parameters. The names 'session_id' and 'element_id' are somewhat self-explanatory, but the description does not even hint at their roles, and there is no mention of required context or how element_id relates to the set-focus operation.

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 function: setting focus on a UI element. This is a specific verb+resource, and it distinguishes itself from sibling tools like qt_mouse_click or qt_set_property, which perform different actions.

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

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

The description implies the use case (focusing a UI element) but does not explicitly compare to alternatives or state when not to use it. The caveat about QML items gives some context, but there is no clear directive on when to choose this over other methods.

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 read-only behavior, no side effects, and the notable rejection of hidden, disabled, and zero-size elements—even for reads. This goes beyond the schema and helps prevent common errors.

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 two sentences, front-loaded with the primary purpose. The second sentence adds a crucial behavioral note without wordiness. 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?

For a simple read operation with an output schema, the description is adequately complete. It covers the principal behavior and the critical visibility constraint. It does not enumerate property names, but the existence of an output schema reduces the need to explain return values.

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. It adds some meaning by implying 'name' is the property to read and that 'element_id' must be from a recent find/snapshot, but it does not explicitly define session_id or enumerate valid property names. The parameter clarification is thin.

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 ('Read a property from a UI element') with a specific verb and resource. This distinguishes it from siblings like qt_set_property, which performs the opposite operation.

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 context: it is read-only, and it specifies a prerequisite that the element id must come from a recent find/snapshot of a visible element. It does not explicitly name alternatives, but the sibling list and the read/write contrast imply when to use vs. qt_set_property.

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 excellently. It discloses that input is real, can overwrite existing text, triggers real app behavior, may silently redirect on stale element_id, and that focus-dependent widgets may ignore input. This is rich, safety-relevant behavioral context beyond any 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?

The description is compact and front-loaded with purpose, then adds necessary behavioral caveats. Every sentence earns its place: real-input warning, focus fallback, focus-dependent widgets, and the qt_key_combo alternative. No fluff or redundancy.

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 largely complete given the output schema exists (so return values need not be described) and the core behavior is well covered. However, the missing semantics for modifiers and session_id create a real gap for an agent trying to invoke the tool correctly with all parameters. Still, the main usage path and key pitfalls are clearly covered.

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. It explains element_id semantics (0/unresolved → focused widget, stale id redirect) and text behavior (typed, can overwrite), but it does not describe the modifiers parameter (accepted values or combination rules) or session_id. This is partial compensation; two of four parameters remain semantically under-specified.

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+resource: 'Send keyboard input (typed text) to a UI element.' It clearly identifies the primary action and object, and distinguishes itself from the sibling qt_key_combo by explicitly carving out shortcuts for that tool.

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 provides explicit usage guidance: use for typed text, use qt_key_combo for shortcuts like Enter or Ctrl+C, and call qt_focus first when text does not land. It also explains the fallback behavior when element_id is 0 or unresolved, which helps an agent decide when to invoke this tool.

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 full behavioral disclosure. It explains that input is delivered as a real key press/release pair with modifier state set, and importantly warns that shortcuts can trigger real app actions like closing windows or saving—critical risk information. This goes beyond the basic purpose.

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 three efficient sentences: purpose, format, and behavioral nuance. No fluff or redundant information, and the most important details are front-loaded.

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 covers the essential aspects: purpose, key format, target element semantics, and real-action consequences. An output schema exists, so return values need not be described. The only minor gap is the undefined session_id, but overall the tool context is sufficiently 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 property descriptions are absent (0% coverage), so the description compensates by detailing the 'keys' format and the special meaning of element_id 0 for focus targeting. However, session_id is not explained, leaving a partial gap in parameter semantics.

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 action: 'Send a keyboard shortcut to an element', with concrete examples like 'Ctrl+C'. It uses a specific verb and resource, and the sibling tools (e.g., qt_keyboard_input) are visually distinguished by this shortcut-specific focus.

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 context on how to use the tool, including the key format (modifiers joined with '+') and that element_id 0 targets the focused widget. It implies this is for shortcuts rather than general text input, but does not explicitly name alternatives or when-not-to-use conditions.

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 bears the full burden. It discloses the tool's purpose and the attachability filter, but it does not state whether the operation is read-only, what happens if no processes match, or any environmental prerequisites. The verb 'list' implies a non-destructive operation, providing some transparency.

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, concise sentence that leads with the verb 'List' and stays on point. Every word adds value, and there is no 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?

Given the tool's simplicity (0 parameters) and the presence of an output schema, the description is largely complete. It could mention that the process list is filtered by attachability, but that is included. It misses a note about potential prerequisites, but for a listing tool this is minor.

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, so the baseline is 4. The description does not need to explain parameters, and it doesn't contradict the empty input schema. There is no additional semantic information to add.

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 the specific verb 'List' with a clear resource 'running Qt processes' and a qualifier 'that may be attachable', which distinguishes it from sibling tools like qt_list_sessions or qt_attach. It immediately communicates what the tool returns and its 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?

The description implies usage in the process of attaching to Qt processes (by mentioning 'attachable'), but it does not explicitly state when to use this tool or name alternative tools. No exclusions or prerequisites are mentioned, so it relies on the agent to infer from the sibling tool names.

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 carries the full burden. It indicates the tool lists only 'active' sessions, but does not disclose whether it is read-only, requires an attached target, or has any side effects. Minimal behavioral detail.

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?

One short, front-loaded sentence with no waste. It states exactly what the tool does. Appropriate for a zero-parameter list operation.

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 a simple tool, the description is minimally viable but lacks contextual nuances. It does not explain what 'sessions' means in this domain, nor mention related tools' relationships. Output schema exists, reducing some burden, but overall the description could be more informative.

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?

There are zero parameters, and the schema is fully covered (100%) with an empty object. The baseline for 0 params is 4, and the description adds no unnecessary parameter details.

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 'List all active sessions.' uses a specific verb (List) and resource (active sessions), clearly distinguishing it from siblings like qt_list_processes. It is unambiguous and concise.

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 when to list sessions instead of using other sibling tools, nor any exclusions 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?

With no annotations, the description carries the burden and does disclose meaningful behavior: invalid button values fall back to 'left', invalid elements cause ok:false, and the reason for rejection (hidden/disabled/zero-size/stale id). It doesn't explicitly say whether the click performs real hit testing, though the contrast with the 'real Qt input pipeline' strongly implies it, so a small gap remains.

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 well-structured and front-loaded: purpose first, then usage guidance, parameter semantics, and error handling. Every sentence adds value without being bloated.

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 an output schema exists and no annotations, the description covers the essential behavioral context: what the tool does, when to use alternatives, parameter semantics, and failure behavior. It is sufficient for an agent to select and invoke the tool confidently.

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. It documents the allowed values for button and modifiers, including fallback behavior, which the schema does not provide. session_id and element_id are not elaborated, but their roles are clear from their names and the schema's required fields.

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 first sentence states a specific action ('Send a mouse click to a UI element') with a qualifier ('direct delivery') that immediately differentiates it from sibling tools like qt_mouse_click_region and qt_mouse_click_at. The rest of the description reinforces this distinction.

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 names alternative tools (qt_mouse_click_region, qt_mouse_click_at) and states when they should be used instead (QML custom components). It also explains the direct-delivery tradeoff ('cheapest option' for plain QtWidgets), giving clear selection guidance.

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 excellently. It discloses that the click goes through the real Qt pipeline, that the hit test determines the target, and that it may trigger destructive side effects like menus or close buttons. It also warns about window_id expiry, adding important temporal context beyond 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?

The description is front-loaded with the core purpose, followed by precise, high-value details. Every sentence adds necessary information without fluff. The structure is easy to scan, with coordinate semantics and window_id warnings clearly separated.

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?

Despite lacking annotations, the description is remarkably complete for a complex tool. It covers coordinate space, pipeline behavior, risk of destructive actions, and window_id lifecycle. Given an output schema exists, return-value details are not needed, and the tool's usage context is fully understood.

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 provides detailed semantics for x/y (client area, logical pixels, DPI handling) and window_id (recent snapshot, expiry, default behavior with 0). However, button and modifiers are left to schema defaults and are not explicitly explained, though their names and defaults make them reasonably clear.

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 clicks at an exact window coordinate and emphasizes 'exactly like a real mouse click at that position.' This distinguishes it from sibling coordinate/region/element-based click tools, making its purpose unambiguous.

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 clear context for when to use this tool: when you need a pixel-exact click, with coordinates in the same space as screenshots and DPI handled internally. It does not explicitly name alternatives, but the contrast with element-based clicks (via the real Qt input pipeline) strongly implies the usage boundary.

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. It discloses that the click routes through the real Qt input pipeline with real hit testing and provides a concrete example, offering meaningful behavioral context beyond a generic 'click'.

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 concise sentences that state the action and the key differentiator without waste. The description is front-loaded with the core action and the explanatory note is well-placed.

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 click operation with an output schema, the description covers the essential purpose and behavioral nuance. The missing parameter details are a minor gap, but the overall picture is clear for an agent to decide and invoke the 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?

With 0% schema description coverage, the description should explain each parameter, but it only implicitly references element_id via 'element' and doesn't mention session_id, button, or modifiers. Button and modifiers have no description either in schema or description, leaving their semantics to inference from names alone.

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 uses a specific verb ('Click at the center') and resource ('an element's on-screen region'), and explicitly contrasts with qt_mouse_click, distinguishing this tool's behavior from the sibling. The purpose is unmistakable.

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 names qt_mouse_click as an alternative and explains the difference (real hit testing vs direct delivery), providing clear guidance on when to choose this tool. However, it doesn't mention other siblings like qt_mouse_click_at, which could also be relevant.

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 must carry transparency. It adds useful behavioral detail about x/y coordinates (optional, relative to element, both-or-neither, default center). But it does not disclose broader behavior such as what happens after opening the menu, whether the call blocks, or any prerequisites for the element.

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 concise sentences. The first states the purpose, and the second adds critical coordinate semantics. No wasted words, and the most important information is front-loaded.

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 mouse action with an output schema available, the description covers core aspects: purpose and coordinate behavior. It does not discuss preconditions or interactions with other mouse tools, but given the tool's narrow scope and schema richness, this is adequately 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?

The schema has 0% description coverage, so the description compensates by explaining x/y in detail: logical-pixel offsets relative to the element's top-left, both-or-neither semantic, and default to center. The other parameters (session_id, element_id) are conventional and their purpose is evident from the 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 clearly states the tool's function: opening a context menu (right-click menu) at an element. This specific verb+resource combination immediately distinguishes it from sibling mouse action tools like qt_mouse_click, qt_mouse_dbl_click, or qt_mouse_press.

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

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

The description implies usage by specifying it is for the context menu, which is distinct from other mouse actions. However, it does not explicitly mention when not to use it or name alternatives, so it falls just short of full guidance.

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 of behavioral disclosure. It only says 'direct delivery', which vaguely implies a synthetic event, but does not mention side effects, prerequisites, cursor movement, or return behavior. This is insufficient for a tool that triggers a UI action.

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 and front-loaded with the primary action. The second sentence efficiently explains coordinate behavior. No filler or redundant content, but it could have used the brevity to include more safety or behavioral context.

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

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

Given the tool has no annotations and a non-trivial parameter surface (6 params), the description is incomplete. It lacks context about session requirements, whether physical cursor movement occurs, and how button/modifiers interact with the double-click. The output schema existence does not compensate for these 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 description explains the x/y parameters in useful detail (relative coordinates, optional, center default), which adds value beyond the schema. However, it says nothing about 'button' (even though it has a default of 'left' and possible variants) or 'modifiers', and schema description coverage is 0%. These parameters remain semantically unclear.

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: 'Send a double-click to a UI element'. This uses a specific verb and resource, and distinguishes the tool from single-click or other mouse tools. The 'direct delivery' note adds a mode distinction.

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 x/y coordinate semantics (optional, relative to element top-left, both or neither, omitted means center). However, it does not explicitly state when to use this tool over alternatives like qt_mouse_click or qt_mouse_press; usage context is only implied by the tool 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?

With no annotations, the description carries the full burden of behavioral disclosure. It discloses that the tool moves the pointer without pressing buttons, that it can be used for dragging between press/release, and that coordinates are relative to the element's top-left corner. This adds meaningful context about how the tool behaves, though it does not mention potential error conditions or return value semantics, which are partially covered by the output 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?

The description is compact and front-loaded. The first sentence states the core action and constraint ('Move the mouse pointer... no buttons'), while the second sentence provides usage context and coordinate semantics. Every sentence adds value without redundancy or fluff, making it highly concise and 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?

The tool is simple, and the description provides the essential context: what it does, how to use it (drag/hover), and coordinate meaning. An output schema exists, so return values need not be described. It lacks mention of edge cases like invalid element IDs or out-of-bounds coordinates, but for a simple mouse-move tool, the description is largely complete. A small gap is the absence of any note about whether the move is instantaneous or animated, but this is not critical.

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. It explains x/y as 'coordinates relative to the element's top-left corner,' adding meaning to those parameters. However, session_id and element_id are not explicitly described, though their roles are inferable from the tool's name and context (session-based Qt automation). The description only partially compensates for the lack of schema descriptions, so it meets the baseline but does not fully document all 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 clearly states the tool's function: 'Move the mouse pointer to an element-local position (no buttons).' This is a specific verb+resource combination that distinguishes it from sibling tools like qt_mouse_press, qt_mouse_release, and qt_mouse_click, which involve button actions. The phrase 'no buttons' explicitly differentiates it from click/press/release operations.

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 usage guidance: 'Use between qt_mouse_press and qt_mouse_release to drag, or alone to hover.' This clearly states when to use the tool in a sequence and names sibling tools, giving context for the intended workflow. It does not explicitly exclude other use cases (e.g., clicking), but the 'no buttons' note and drag/hover guidance imply the appropriate 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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It does so exceptionally well, highlighting the stateful nature of the press (must release in the same session), the risk of leaving the app in a pressed/dragging state, and the coordinate interpretation (logical pixels relative to element top-left, omitted means center).

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 three sentences, front-loaded with the core behavior, immediately followed by pairing guidance and a critical warning. Every sentence earns its place; no repetition 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?

Given the tool's moderate complexity, the description covers all essential aspects: what it does, how it relates to siblings, coordinate behavior, and the critical statefulness warning. The presence of an output schema means return values need not be described, and the description is sufficiently complete for an agent to invoke 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 must compensate. It meaningfully explains the x/y parameters (optional, both-or-neither, relative coordinates, default to center). It does not elaborate on 'button' or 'modifiers', though their names and schema defaults provide reasonable clues. This is strong compensation but not complete.

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: 'Press a mouse button on an element WITHOUT releasing it.' It clearly differentiates this from a complete click and references sibling tools like qt_mouse_release and qt_mouse_move, making the tool's unique purpose unambiguous.

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 usage guidance: pair with qt_mouse_release to split a click, or use qt_mouse_move for a drag (press -> move -> release). It also explains the optional coordinate semantics and warns about the release requirement, giving the agent clear context for when and how to use this tool.

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 of behavioral disclosure. It adds useful context about coordinate handling (optional x/y relative to top-left, default center) and typical usage scenarios. However, it does not disclose behavior in edge cases (e.g., no prior press), potential errors, or any side effects beyond the action itself, leaving gaps in transparency.

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 that efficiently convey purpose, usage context, and coordinate behavior. There is no redundant or filler content; every sentence adds necessary 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?

The tool has 6 parameters, no schema descriptions, and no annotations, so the description needs to cover essential context. It addresses the main use case and coordinate semantics, and since an output schema exists, return values need not be described. However, it omits details about parameter constraints (button values, modifier syntax) and edge-case behavior, making it less complete than ideal for a tool of moderate complexity.

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 by explaining parameter semantics. It does explain x/y coordinates and their optionality, which is valuable. However, it does not describe the 'button' parameter (values like left/right/middle) or 'modifiers' (how to specify key combinations), and does not explain the required session_id/element_id beyond what their names imply. Thus, parameter coverage is partial.

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 ('release') and resource ('previously pressed mouse button on an element'), clearly distinguishing it from sibling tools like qt_mouse_press and qt_mouse_click. It also explains the role in press/release pairs and drag sequences, leaving no ambiguity about the tool's function.

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 this tool: to complete a press/release pair (a click) or finish a drag started with qt_mouse_press + qt_mouse_move. It provides useful sequencing context, though it does not explicitly list exclusions or alternatives beyond the implied counterparts.

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 of behavioral disclosure. It explains the units for dx/dy (pixel vs line), the optional x/y coordinate semantics (both or neither, default center), and the scrollable content scope. This goes beyond the schema by clarifying intended behavior, though it does not mention error handling or return 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 three sentences: purpose, parameter details, and usage context. It is front-loaded with the action, and every sentence adds essential information without waste. The formatting with code literals improves readability.

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 moderate complexity (7 parameters) and the existence of an output schema, the description adequately covers the key nuances: wheel delta units, coordinate anchoring, and applicable UI components. It provides enough contextual richness for an agent to invoke the tool correctly without needing to guess 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 compensate. It clearly explains dx/dy (wheel deltas, pixel or line units), pixel (unit selector), and x/y (optional positioning with 'both or neither' rule). The identity parameters (session_id, element_id) are self-explanatory given the tool context. This fully compensates for the schema 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?

The description opens with a precise verb-object pair: 'Scroll the mouse wheel over an element.' This clearly distinguishes the tool from sibling tools like click, key input, and focus. It also implies the target resource (an element), making the purpose unambiguous.

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 closing sentence, 'Use this to scroll lists, tables, canvases and other scrollable content,' provides direct guidance on when to apply the tool. It gives context but does not explicitly name alternative tools or exclusions, which would merit 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 provided, the description carries the full burden and excels. It details the geometric heuristic, occlusion rules (e.g., 'widgets and QML rectangles/images occlude unless semi-transparent'), per-window behavior, file writing, and objID expiration. This provides deep transparency beyond basic read/write semantics.

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 a clear one-line purpose and is organized into coherent sections (when to use, behavior, solver details, output). It is longer than average but every sentence adds essential information about a complex algorithm. Slight verbosity around the heuristic details prevents a 5.

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 tool with no annotations and a nontrivial algorithm, the description is remarkably complete. It covers input requirements, output file, result field, edge cases (partial overlap, opacity, child reparenting), limitations (per-window occlusion), and lifecycle of objIDs. The presence of an output schema reduces the need to describe return values, allowing the description to focus on behavior.

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. It does explain the key parameter: 'snapshot_id is the value returned by the last qt_snapshot call of this session.' session_id is implied by context but not explicitly detailed. Since there are only two parameters and one is fully clarified, it earns above-baseline score but not 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?

The description opens with a specific verb and resource: 'Occlusion-prune a saved snapshot.' It clearly distinguishes this tool from siblings like qt_snapshot by explaining it computes visibility and removes covered elements, which is a 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 explicitly states when to use the tool: 'after a snapshot, when elements overlap inside the same window and you need to know which one is really on top / how much of a target is visible.' It gives concrete examples like deciding which element to click, but does not explicitly mention when not to use it or name alternative tools, so it falls 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 provided, the description carries the burden of behavioral disclosure. It reveals key behaviors: the PNG is written to a file at the returned URI, the resource must be read to obtain image bytes, and on failure no image is written and the result reports the error. This is valuable context beyond the schema, though it does not cover all potential 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 four concise sentences, front-loaded with the main action and followed by necessary operational details. No waste, and every 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?

For a tool with two simple parameters and a clear output schema, the description is nearly complete. It covers the main action, how to retrieve the screenshot bytes, and error behavior. Minor gaps remain around session_id semantics, but the description is sufficient for effective 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%, so the description must compensate for parameter meanings. It explains element_id (0 captures the entire window) but does not clarify session_id. This partial compensation earns a middle score.

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 captures a screenshot of a UI element or the entire window, with a specific verb and resource. It does not explicitly differentiate from sibling tools like qt_snapshot, but the scope is unambiguous enough to understand the primary function.

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

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

The description implies usage by explaining how element_id 0 captures the active/first visible top-level window, but it does not provide explicit when-to-use guidance or mention alternatives. It lacks exclusions or comparison with sibling tools, leaving usage context inferred.

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 full burden. It discloses that the tool is 'DESTRUCTIVE,' directly modifies application state, may trigger property-notify signals, change geometry/visibility/business state, and has no undo. It also details value parsing behavior, adding critical behavioral context beyond 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?

The description is concise and well-structured: a one-line purpose, a clear warning block, and a focused value-parsing note. Every sentence adds necessary information without redundancy.

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 that this is a destructive write operation with no annotations and a 0%-coverage schema, the description covers the key aspects: what it does, when it should be used, its side effects, and value semantics. The output schema exists, so return-value details are not needed. It is sufficiently complete 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 description coverage is 0%, so the description must compensate. It thoroughly explains the `value` parameter with JSON parsing rules ('"true" -> bool, "123" -> int'), but does not explicitly describe session_id, element_id, or name. However, their meanings are reasonably inferable from the purpose statement and parameter names, making this a partial compensation.

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 begins with 'Write a property value on a UI element,' which clearly names the action and resource. It is distinct from sibling tools like qt_get_property (reading) and qt_call_method (calling methods), making its purpose unambiguous.

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 'Prefer real user input (clicks/typing) to simulate user actions; use this only when a direct API write is intended.' This provides clear when-to-use and when-not-to-use guidance, contrasting with alternative input methods.

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 excels: it explicitly states that the tree is written to a file and not in the result, describes the ID lifecycle (previous IDs become invalid), warns about GUI thread freezes and 30s timeouts, and explains the fallback behavior for stale root_id. These are non-obvious, important behavioral traits.

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 long but well-structured: a lead sentence, a note about the output location, parameter explanations, and a clear ID LIFECYCLE section. Every sentence carries essential information, though the density makes it somewhat heavy; still, it earns a high score.

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 (6 params, resource output, ID lifecycle, GUI thread behavior), the description covers all critical aspects: what is returned, where to read the tree, node fields, parameter semantics, freshness constraints, and side effects. An output schema exists, so not detailing return values is acceptable.

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 comprehensively. Every parameter is explained with meaning, default, and allowed values (e.g., detail as 'core/extended/full', max_depth as levels, prop_depth as QObject property expansion). This adds far more value than 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 opens with a clear, specific verb+resource: 'Capture the UI element tree of the session's windows.' It clearly distinguishes this tool from siblings like qt_screenshot (visual capture) and qt_find_element (search within a 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?

Provides detailed guidance on parameter usage, including the semantics of detail, include_hidden, max_depth, prop_depth, and root_id. It notes that IDs expire on refresh and that root_id should only be passed when fresh, and warns about hidden elements being rejected by other tools. However, it does not explicitly compare against alternative tools like qt_find_element, so a 4 is appropriate.

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