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

The description adds significant behavioral context beyond the readOnlyHint=true annotation, including that it is a single check without polling, details about missing attributes returning null, and that a missing element is a precondition failure (not a retry). It also specifies all error types and constraints on regex flags. No contradiction with annotations.

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 information-dense, starting with the core purpose, then detailing targeting, matching, return value, and errors. Every sentence adds value, though it could be slightly trimmed without losing clarity. It is appropriately 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?

Given the tool has 8 parameters, no output schema, and no nested objects, the description compensates thoroughly: it explains targeting, matching options, flags, return fields, and all error types. It is complete enough for an agent to select and invoke 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?

Although the schema already provides descriptions for all 8 parameters (100% coverage), the tool description adds meaningful semantics: explaining that exactly one predicate must be provided, the effect of the attribute parameter on the value read, and the constraints on regex flags (g and y rejected as stateful). This goes beyond the schema 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?

The description clearly states the tool's purpose: 'Validate, in a single check (no polling), that an element's text or a named attribute matches a pattern.' It specifies the verb (validate) and resource (element text/attribute) and distinguishes it from sibling tools like electron_expect_text or electron_get_text by emphasizing the single-shot nature and pattern matching.

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 instructions on how to target elements (by ref or selector), how to choose between text and attribute validation, and the requirement to provide exactly one of equals/contains/matches_regex. However, it does not explicitly mention when this tool should be used over alternatives or when not to use it, such as when polling is needed.

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?

Annotations (readOnlyHint=false, openWorldHint=false) are complemented by detailed behavioral disclosure: the transport supports 'eval/read/observe and core interaction surfaces', errors are listed (TRANSPORT_UNSUPPORTED, CDP_DISCONNECTED, etc.), and the side effect of pid enabling SIGKILL is noted. This adds value beyond annotations.

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 paragraph but densely packs essential information with clear sections for returns and errors. It is front-loaded with the purpose. Minor improvement could be gained from more structural formatting (e.g., bullet points), but it remains efficient.

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 5 parameters, no required, and no output schema, the description covers all needs: purpose, parameter guidance, behavior, error conditions, and return structure. It is completely adequate for an agent to use this 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?

While schema coverage is 100% (baseline 3), the description adds meaningful context: explains how port and host resolve the endpoint from /json/version, that cdpUrl must be loopback, that pid alone is insufficient but aids stop, and timeoutMs for handshake. This extra guidance merits a 4.

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: 'Attach to an already-running Electron app exposing a CDP debug endpoint'. It uses specific verb ('attach') and resource ('running Electron app'), and distinguishes from siblings like electron_launch and electron_discover_running by requiring an existing debug endpoint.

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 guidance is provided: use when you have a running app with a CDP endpoint, mention alternative electron_discover_running to find one, and specify that 'pid alone is not attachable over CDP'. It also clarifies which parameters to use (port+host or cdpUrl) and that pid is optional for stop escalation.

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 discloses behavioral traits: no-op if already checked, and lists error types including retryable ones. Annotations confirm mutation, no contradiction.

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 plus a concise list of options and errors, front-loaded with the main action. 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 5 parameters, no output schema, the description covers the main action, return format, and errors. Could explain the 'target' field in return, but adequate.

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 100%, so baseline is 3. The description adds value by specifying return format, error types, and the no-op condition, going beyond 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 title and description clearly state the tool checks a checkbox/radio, with explicit mention of no-op if already checked. It distinguishes from sibling tools like electron_uncheck.

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 for checkbox/radio elements and mentions no-op behavior, but does not explicitly state when to use this over alternatives like electron_click or electron_uncheck.

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?

Annotations indicate readOnlyHint=false, aligning with the mutation behavior. The description adds details about options (force bypasses actionability checks), return structure, and specific error types with retryability hints, going beyond what annotations 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?

Two sentences plus compact lists of options, returns, and errors. Every element is essential and informative with no 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?

Covers core action, identification options, options, return shape, and errors. Does not mention event firing or mutual exclusivity of ref/selector explicitly, but the schema covers the latter. Sufficient for a clear-input 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 100%, so baseline is 3. The description summarizes parameters (ref/selector, force, timeoutMs) and lists errors, but adds little new meaning beyond the 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 the verb-resource pair: 'Clear the value of the input/textarea' and distinguishes it from sibling tools like electron_type or electron_get_value.

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 that the tool clears an input to empty, but does not explicitly contrast with alternatives like electron_type ' ' or electron_press_sequence. The context is sufficient for an agent to infer 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?

Annotations only indicate the tool is not read-only and not open-world. The description adds extensive behavioral context: mouse button options, double-click via clickCount, force bypassing actionability, timeoutMs, and detailed error conditions with retryability semantics. This far exceeds annotation disclosure.

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 well-structured paragraph that front-loads the core action, then lists options, return value, and errors. Every sentence contributes necessary information without redundancy. Highly efficient.

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 complexity (7 params, no output schema, rich error handling), the description covers the main action, options, return shape, and error semantics comprehensively. Minor gap: the 'target' field in the return is not explained, and the description does not mention that omitting both ref and selector triggers BAD_ARGUMENT, but this is inferable.

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 100% with clear descriptions for all 7 parameters. The description summarizes options but does not add new parameter-level meaning beyond the schema. The baseline of 3 is appropriate as the description adds organizational value but no new semantic 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 clearly states 'Click the element identified by ref (from a snapshot) or selector', combining a specific verb (click) with a specific resource (element). It distinguishes this from sibling tools by specifying input methods (ref or selector) and options like button and clickCount.

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 usage guidance for parameters (e.g., ref vs selector, double-click via clickCount) and error handling (e.g., re-snapshot on REF_NOT_FOUND), but does not explicitly compare to alternatives or state when to use this tool over sibling actions like hover or drag. Implied use case for clicking is clear, but lacking 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?

Annotations already indicate readOnlyHint=true. Description adds value by detailing ordering, overflow behavior, error conditions (NOT_RUNNING, BAD_ARGUMENT). This goes beyond what annotations provide, making behavior fully transparent.

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?

Description is concise yet comprehensive, using parentheses and bullet-like structure. It front-loads the purpose, then lists filters and returns. Every sentence adds value 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?

Despite no output schema, description fully details return structure (entries with fields, count, overflowed) and lists errors. For a tool with 5 optional parameters and filtering logic, this is complete and covers all relevant 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 100%, so baseline is 3. Description adds extra context: 'ANDed' for filters, 'epoch ms' for since, 'most recent are kept' for limit. This enhances understanding beyond raw 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?

Description states 'Read the captured renderer console output for the session' with a specific verb and resource. It also clarifies ordering ('newest-relevant entries last'), distinguishing it from sibling tools that perform different actions like clicking or waiting.

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?

Description explains all optional filters and their effects (ANDed, regex, epoch ms, limit). It implies usage for reading logs, but doesn't explicitly state when not to use or compare with alternatives. However, the context is clear enough for most use cases.

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 fully discloses behavior: dialogs block the renderer, policy is applied automatically, default is dismiss to prevent hangs, overflow behavior, and error conditions (NOT_RUNNING, BAD_ARGUMENT). It does not contradict annotations (readOnlyHint=false).

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 with a clear separation of arming and reading arguments. It is fairly long but every sentence adds value, explaining modes, defaults, and edge cases. Slightly verbose but efficient for the complexity.

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 no output schema, the description fully documents the return object (ok, session_id, policy, entries, count, overflowed). It covers all modes, parameter interactions, and errors. Given the tool's complexity (two modes, 9 params), the description is 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 100%, but the description adds essential context: action is the default, perType overrides, promptText requires accepting prompt, oneShot is for next dialog then revert, limit defaults/max, clear flushes whole buffer, overflowed counts across full buffer. This goes far beyond 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 dual function: arming an auto-responder for native dialogs and reading fired dialogs. It distinguishes between the two modes and explains the default policy. No sibling tool handles dialogs, so it is distinct.

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 explains when to use arming vs. reading (e.g., 'With NO arming args the call is inspect-only'). It mentions that dialogs block the renderer and why the default policy is dismiss. It does not explicitly exclude alternatives, but no siblings exist for this purpose.

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?

Annotations already declare readOnlyHint=true, indicating safe read. The description adds detailed behavior: scans specified ports, returns diagnostic structure, reports errors (BAD_ARGUMENT for invalid inputs), and clarifies that a failed probe is simply 'no target'. 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 compact (3-4 sentences) and front-loaded: purpose first, then return format, error types, and failure behavior. Every sentence adds value, 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?

Despite no output schema, the description fully specifies the return structure (ok, targets, count, scanned with subfields) and error cases. Given 0 required parameters and clear defaults, the agent can use this tool without ambiguity.

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 100%, but the description adds extra constraints: default values (9222-9225, 127.0.0.1, 300ms), maximum port count (64), maximum timeout (5000ms), and host enum restriction to loopback. This adds meaningful context beyond 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 verb 'Scan' and the resource 'already-running, debuggable Electron apps', specifying the scope 'on loopback only' and default port range. This distinguishes it from sibling tools like electron_launch or electron_attach.

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 indicates this tool requires no session, implying it's a preliminary diagnostic step. It mentions error types and failure behavior, but does not explicitly compare to alternatives or state when not to use it. The context is clear enough.

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?

Describes tool as non-mutating, which aligns with readOnlyHint annotation. Additionally details what checks are performed and the return structure (including runtime facts and native-addon inventory), going well beyond the annotation.

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 sentences with high information density: purpose, checks, return value, usage guidance, and error handling. No redundant words; every sentence serves a clear function.

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-parameter diagnostic tool, the description fully explains the checks performed, the return structure, usage context, and error behavior. There is no missing information needed for correct invocation or interpretation.

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 has zero parameters with 100% coverage. Description adds no parameter info but doesn't need to; baseline of 4 is appropriate as the description cannot add value over an empty 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?

Description clearly states it runs non-mutating preflight checks for the Electron Stagewright environment, listing specific resources checked (Node, Playwright, Electron, etc.). This distinctively separates it from siblings that perform actions like launching, clicking, or attaching.

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 to inspect results before electron_launch, providing clear temporal guidance. While it doesn't name alternatives, the sibling list includes electron_launch and other tools, making the pre-launch use case unambiguous.

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?

Annotations only indicate readOnlyHint=false, but the description extensively covers behavior: dispatches dragenter/dragover/drop events with a real DataTransfer, explains default_prevented meaning, details file size and path restrictions, and lists possible errors. This goes well beyond the annotations.

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 with the core purpose first, followed by mechanism, constraints, and error enumeration. It is comprehensive but slightly lengthy; some redundancy exists (e.g., file counts repeated). Still, it earns its sentences.

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 having no output schema, the description fully documents the return object fields (ok, session_id, target, files, default_prevented) and all error types. It also clarifies edge cases (default_prevented false). For a complex tool, this provides complete guidance.

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 100% description coverage, but the description adds critical constraints not in the schema: absolute paths required, max 10 files, 5242880 bytes each. It also explains the mimeType override behavior and clarifies that ref and selector are mutually exclusive. This adds significant value.

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 tool simulates dropping OS files onto an element identified by ref or selector. It distinguishes itself from sibling tools by detailing the DataTransfer mechanism and contrasting with apps needing native IPC paths. The verb 'simulate dropping' and the resource 'OS files onto an element' are specific and 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 when to use (simulate file drops) and when not to (apps requiring native OS paths via IPC). It also provides constraints like absolute paths, file limits, and timeout. However, it does not directly compare to sibling tools like electron_drag or electron_set_files, so some implicit guidance 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?

Beyond readOnlyHint=true, description reveals that no-match is a normal result (exists: false) not an error, and enumerates all error types. This provides significant behavioral clarity.

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 front-loaded sentences: purpose, key behavior (no-match non-error), then returns/errors. 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?

Given no output schema, description fully covers return format, error types, and use case (polling). With annotations and high schema coverage, no 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?

Schema coverage is 100%, so baseline is 3. Description mentions 'ref OR selector' but schema already specifies this. No additional semantic detail beyond 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?

Clearly states the verb 'return' and resource 'whether element exists'. Distinguishes from siblings like electron_find (which returns element data) and visibility checks. No-match clarification clarifies 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?

Explicitly suggests polling use case for appearance/disappearance. Lists error conditions but omits when not to use (e.g., when needing visibility or text).

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?

Annotations provide readOnlyHint=true and openWorldHint=false, indicating a read-only side-effect-free operation. The description adds extensive behavioral context: polling semantics, timeout clamping, exact predicate matching, rejection of stateful regex flags (g, y), and detailed error payloads (similar_refs for stale refs, expected+actual for assertion failure). No contradiction with annotations.

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 efficiently structured: front-loaded with core purpose and polling behavior, then a clear bullet of predicate options, followed by flags and error categories. Each sentence serves a distinct purpose without redundancy. Length is justified by the parameter count and error complexity.

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 no output schema, the description fully documents the return object ({ ok, session_id, matched, actual }) and all possible errors with sufficient detail for an agent to handle failures. It covers polling timeout, predicate constraints, and the ref/selector duality. For a tool with 10 parameters, this is comprehensive.

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 100% schema description coverage, the baseline is 3. However, the description adds critical semantic constraints beyond the schema: the mutual exclusivity of predicates ('exactly one'), the relationship between 'flags' and 'regex', and the behavior of timeoutMs (0 = check once). This enriches the agent's understanding of parameter interactions.

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: asserting text of an element via ref/selector with polling. It identifies the specific verb ('Assert'), resource ('text of the element'), and mechanism ('polling until it holds or timeoutMs elapses'). This distinguishes it from siblings like electron_get_text (retrieval without assertion) and other expect_ tools (e.g., expect_url, expect_state) which target different resources.

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 selection constraints: 'Provide exactly one of: equals, contains, regex, not_equals, not_contains' and clarifies flags applicability only to regex. It also details error types (EXPECTATION_FAILED, REF_NOT_FOUND, etc.) and their retryability. However, it does not explicitly contrast with alternatives like electron_get_text for cases where the agent might want to fetch text without assertion, though the sibling list implies differentiation.

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?

Annotations already declare readOnlyHint=true, and the description adds rich behavioral details: polling until timeout, the exact error types (EXPECTATION_FAILED, REF_NOT_FOUND, etc.) with their semantics and retryability, and timeout clamping. No contradiction with annotations.

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 dense paragraph but front-loaded with the primary purpose. It could be slightly more structured (e.g., bullet points for predicates and errors), but every sentence adds value and there is no redundancy. Slightly lower for 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 complexity (10 parameters, no output schema), the description sufficiently covers return values (ok, session_id, matched, actual), all error types with conditions, and predicate rules. It is complete enough 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 100%, so baseline is 3. However, the description adds significant value beyond the schema: it explains mutual exclusivity of predicates, valid regex flags (rejecting stateful ones), the meaning of timeoutMs=0, and the return format. This is excellent parameter-level guidance.

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 asserts the value of an element against a predicate, with polling. It uses specific verbs ('assert') and resource ('form control value'), and distinguishes well from sibling tools like electron_expect_text or electron_expect_state which handle different checks.

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 specifies that exactly one predicate from a list must be provided, and explains flags for regex. However, it does not explicitly contrast with alternatives like electron_expect_text for text content, leaving some ambiguity about when to use this vs similar tools.

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?

Annotations already indicate destructive nature. Description adds specific details: uses SIGKILL, returns {ok, session_id, killed: true}, lists error types. No contradiction.

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: first captures purpose and use case, second covers return and errors. Every word earns its place; no 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?

For a simple destructive tool with one parameter, the description covers purpose, usage, return format, and error handling. Annotations handle safety profile. Complete for agent decision-making.

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?

Single parameter 'sessionId' with 100% schema coverage. Description adds value by explaining that omission works when single session is active and that errors include BAD_ARGUMENT for multiple sessions without sessionId.

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?

Describes a specific verb ('force kill'), resource ('session'), and context ('escape hatch when stop hangs'). Clearly distinguishes from sibling 'electron_stop' by stating it's the hard kill option.

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?

States when to use ('when stop hangs') and lists error conditions (NOT_RUNNING, BAD_ARGUMENT). Could be improved by explicitly stating when NOT to use (e.g., prefer stop first).

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?

Annotations already indicate readOnlyHint=true and openWorldHint=false. The description adds behavioral detail beyond annotations: returns null for absent attribute (not an error), lists specific error types, and describes the return format. This provides helpful context for safe 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 relatively concise with core purpose upfront. It includes error list and return format in a single paragraph. A bit dense but not overly verbose. Could be slightly more structured, but overall effective.

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 (4 parameters, no output schema, no nested objects), the description covers return values, error types, null behavior, and the element identification methods. It does not mention the mutual exclusivity of ref and selector, which is in the schema, but still provides sufficient context for correct usage.

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 covers all 4 parameters with descriptions (100% coverage). The description itself does not add new parameter-level information beyond what the schema provides. Baseline 3 is appropriate as schema does the heavy lifting.

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 returns the value of an attribute on an element, distinguishing it from sibling tools like get_text or get_value. It specifies the verb (return), resource (attribute on element), and handles the null case for absent attributes.

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 explains how to use it (by ref or selector) and mentions null behavior, but does not provide explicit guidance on when to use this tool over alternatives or when not to use it. Sibling tools are not referenced.

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?

Annotations already declare readOnlyHint=true, so the description adds value by detailing the return shape (list of states, role, name) and listing possible errors (REF_NOT_FOUND, etc.). 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 highly concise: three sentences that front-load the main purpose, then list states and error types. Every sentence adds value with no 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 no output schema, the description fully explains the return value structure and all possible errors. For a simple read-only tool, this is 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 100%, so the description does not need to add much. It reiterates that ref or selector should be provided, not both, which is already implied by the schema descriptions. Baseline 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?

The description explicitly states the tool returns the full state envelope of an element, listing all boolean properties plus role and name. It clearly distinguishes from sibling tools like electron_expect_state or electron_get_attribute by being a comprehensive state 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 gives a strong usage hint: 'One call answers is this clickable / checked / focused'. It implies use when multiple state properties are needed. However, it does not explicitly contrast with siblings like electron_expect_state (which asserts a state) or electron_exists, leaving some ambiguity about when to prefer this over 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?

Annotations (readOnlyHint=false) indicate mutation, and the description lists return fields and errors but does not elaborate on side effects like triggering UI events or actionability checks (e.g., force parameter behavior).

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 (one sentence plus a compact list), front-loading the core purpose without unnecessary 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?

The description covers purpose, parameters, returns, and errors. It lacks an explanation of the return object fields (ok, session_id, target) but given no output schema, the listing is adequate.

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 100% schema coverage, the description adds no new parameter details beyond listing options (force, timeoutMs); the schema already sufficiently documents each parameter.

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 (hover), the target (element by ref or selector), and an example use case (reveal tooltip/menu), distinguishing it from sibling tools like click or drag.

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 a clear use context (reveal tooltip/menu) but does not explicitly state when not to use this tool or mention alternatives, leaving room for ambiguity among sibling tools.

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?

Annotations indicate readOnlyHint=false, confirming mutation. The description adds valuable behavioral details: focus behavior, force usage, error types (including retryable ELEMENT_NOT_VISIBLE), and return values. No contradiction with annotations.

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 dense paragraph that efficiently covers purpose, behavior, exceptions, and return values. It is front-loaded with the core action. Minor redundancy (e.g., repeating 'ref/selector') but overall 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 the complexity (6 parameters, mutating action, multiple error types), the description covers all essential aspects: focus behavior, force guidelines, timeout, error conditions, and return format. Without an output schema, the return description suffices. Some details like sessionId are implicit but clear.

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 100%, so each parameter has a description. The tool description adds context beyond the schema, such as the focusing logic for ref/selector and when to use force. The key parameter examples enhance understanding.

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 explicitly states 'Press a key or chord' and provides concrete examples ('Enter', 'Control+A', 'ArrowDown'). It clearly distinguishes this tool from siblings like electron_keyboard_type (which types strings) and electron_press_sequence (which presses multiple keys), 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 description provides explicit when-to-use guidance: 'Focuses ref/selector first when given; otherwise presses against the active element.' It advises for editors to 'click the visible content area first' and warns to 'reserve force:true for offscreen inputs that truly accept focus.' This helps the agent decide between this tool and 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?

Annotations only provide readOnlyHint=false. The description adds substantial behavioral context: it explains the event sequence, focusing behavior (focuses ref/selector first, else active element), the effect of force:true on offscreen inputs, and specific error types (TYPE_NO_EFFECT with remedy, retryable ELEMENT_NOT_VISIBLE, etc.). This goes well beyond the annotation's minimal information.

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 key differentiator (real keystrokes vs value setting), then alternates between usage guidance, focusing behavior, force option, return value, and errors. Every sentence adds essential information without redundancy. It is concise given the complexity.

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 return format ({ok, session_id, typed}) and lists all possible errors. Given the tool's complexity (6 params, multiple behaviors), the description is thorough. However, it does not mention the maximum input length (10000 chars from schema) or the exact default timeout, but the schema provides these. Slight gap but overall 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 100%, so baseline is 3. The description adds value beyond the schema by explaining how 'force' bypasses actionability checks and that a swallowed keystroke returns TYPE_NO_EFFECT, and by clarifying the timeoutMs as an 'actionability budget'. However, it does not repeat parameter descriptions, which 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 explicitly states the tool types text as real per-character keystrokes, differentiating it from electron_type which sets the value directly. It also specifies the event sequence (keydown/keypress/input/keyup) and provides guidance on when to use electron_type_into_editor for code editors, making the purpose very clear and distinguishing it from siblings.

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 when-to-use and when-not-to-use guidance: use for real keystrokes, but for code editors use electron_type_into_editor. It warns against targeting the hidden textarea in editors and explains the force:true option. It also references sibling tool electron_type_into_editor by 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?

Annotations only indicate mutation (readOnlyHint: false) and constrained world (openWorldHint: false). The description adds extensive behavioral details: wait for renderer, error types with retryability, single-instance lock, timeout behavior, instrumentNative effects, and the fact that a session with renderer_ready:false is still usable.

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 and well-structured, front-loading the main action. It is somewhat long but every sentence adds value. Minor room for improvement in 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 10 parameters, no output schema, and 30 sibling tools, the description comprehensively covers launch behavior, return values, error types, timeout, single instance handling, and caveats. It is fully complete for an 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?

Schema coverage is 100%, but the description adds significant meaning: precedence rules (executablePath > runtime), context of runtime resolution, default readyTimeoutMs, cap at 60000, and concrete examples of instrumentNative behavior. This goes well beyond 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 'Launch an Electron app and start a driving session,' specifying the verb (launch) and resource (Electron app). It details key parameters and distinguishes from siblings like electron_attach and electron_discover_running.

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 contrasts launching vs. attaching, explains when to use allowMultiple or runtime, and provides guidance on retryability of errors. It includes concrete when-to-use and when-not-to-use advice.

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?

Beyond annotations (readOnlyHint=false, openWorldHint=false), the description adds: focuses ref/selector first, force bypasses actionability checks, return structure { ok, session_id, keys }, and specific errors. This fully discloses behavior.

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: action statement, usage tip, parameters, return, errors. Every sentence adds value 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?

Despite no output schema, the description covers return format and errors. With 6 parameters and 1 required, it provides sufficient context for the agent to invoke correctly, including edge cases like empty keys or both ref and selector.

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 100%, but the description adds meaning: 'Focuses ref/selector first' clarifies ref/selector usage, and 'reserve force:true for offscreen inputs' adds semantic nuance beyond the schema description of force.

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 'Press' and resource 'each key in keys' with an example. It distinguishes from sibling tools like electron_key (single key) and electron_keyboard_type (typing text) by specifying sequential key pressing.

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 guidance is given: for editors, click the visible content area first; reserve force:true for offscreen inputs. It also implies when to use focus via ref/selector and lists error types like ELEMENT_NOT_VISIBLE which aids retry decisions.

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?

Annotations provide readOnlyHint=true which aligns with screenshot being non-destructive. The description adds significant context: image is written server-side, bytes not returned inline, error types, and return format. No contradiction.

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?

Description is fairly long but well-structured: summary, then targeting, options, output, errors. Front-loaded with core action. Some redundancy (e.g., mentioning dir twice) but overall efficient.

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 complex tool with 12 params and no output schema, the description is thorough. It covers targeting, output details (with field names), error types, and server configuration. All necessary context is 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?

All 12 parameters are in schema (100% coverage). The description adds essential semantics: mutual exclusivity of dir/path, ref/selector, windowId precedence, format defaults, quality applicability. This goes well beyond 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 explicitly states 'Capture a screenshot to an image file and return its path', clearly specifying the verb and resource. It distinguishes from sibling tools like electron_snapshot by focusing on image capture.

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 guidance on targeting (ref/selector vs window, windowId precedence) and output options (dir vs path, format, quality). It could be improved by explicitly stating when not to use this tool (e.g., for structured data extraction use electron_snapshot).

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?

Annotations declare readOnlyHint, description confirms read-only and adds rich behavior: diff encoding, text format, ref tagging, shadow root handling, truncation, and return fields. No contradiction.

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?

Description is somewhat verbose but efficiently front-loads purpose. Every sentence adds useful info; could be tighter but appropriate for complexity.

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 no output schema, description explicitly lists return fields (ok, surface_id, kind, snapshot, diff, etc.) and covers errors, special modes, and edge cases (shadow roots). Complete for a 7-param 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 100% schema coverage, description adds meaning: 'since' explains delta, 'format' details token savings, 'budgetTokens' describes truncation logic. Adds significant value beyond 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?

Description clearly states 'Capture the selected renderer surface accessibility tree' with specific elements (role, name, state, bbox, ref). Distinct from sibling tools like electron_click or electron_get_state.

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 context for when to use parameters (since, format, interactiveOnly, etc.) and mentions errors (NOT_RUNNING, BAD_ARGUMENT) with prerequisites. Lacks explicit comparison to siblings but purpose is obvious.

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?

Beyond readOnlyHint, describes exact return fields and explicitly lists what is not returned (window arrays, logs, stack traces, etc.). Also states errors are none, adding significant 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?

Well-structured: front-loads purpose, lists exclusions, provides alternatives, then return format and error info. Each sentence adds value, though slightly verbose.

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?

Fully describes what the tool returns and what it excludes. With no parameters, complete annotations, and no output schema, the description provides all necessary 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?

No parameters exist, so baseline is 4. Description doesn't need to explain parameters; it correctly omits any param discussion.

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?

Clearly states it returns compact orientation with specific fields: version, uptime, active-session count, and session details. Distinguishes from siblings by explicitly stating what it never returns and naming alternative 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?

Provides explicit guidance: use for compact status; for detailed state, use electron_windows_list, electron_surfaces_list, or relevant plugin tool. No ambiguity about when 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?

Annotations already indicate destructive behavior, but the description adds vital details: auto-escalation to SIGKILL, timeout, response fields, and specific errors, providing thorough behavioral insight.

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 primary action, and efficiently covers details, return values, and errors in a structured manner.

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: usage, parameters, return values, escalation behavior, and errors, making it complete for a stop tool with no 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 100%, so baseline 3. The description adds meaning for 'sessionId' (omit if single session) and 'timeoutMs' (graceful closing budget), raising the 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 verb 'stop' and resource 'session', and distinguishes it from siblings like 'electron_force_kill' by emphasizing graceful stop with auto-escalation.

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 context for when to use (stop a session) and error conditions (NOT_RUNNING, BAD_ARGUMENT). It could explicitly mention when to use 'electron_force_kill' instead, but the graceful vs force distinction is clear.

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?

Annotations already indicate readOnlyHint=true and openWorldHint=false. Description adds that opaque ids are stable only while surface is live, need to select with switch_surface, and details return structure. 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?

Five sentences front-loaded with purpose, then usage, return, and errors. Every sentence adds value; 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 one optional parameter and no output schema, description provides return structure, error conditions, and usage guidance. Sufficient for agent to understand invocation and results.

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 covers sessionId with description; description adds 'Omit when a single session is running' and mentions errors for multiple sessions, adding context beyond 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?

Description clearly states verb 'List', resource 'session renderer surfaces', and specifies order and types (BrowserWindow roots, WebContentsViews, etc.). Differentiates from sibling tools by mentioning relationship to electron_switch_surface and existing window 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 states when to use (before snapshot/find/renderer interactions) and when not to use (window-only flows). Lists error conditions with guidance on retryability and provides context for optional sessionId.

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?

Discloses that the surface must be from electron_surfaces_list, that old refs from other surfaces are rejected, and lists possible errors. Since annotations only indicate not read-only, the description provides necessary behavioral details.

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?

Concise: three sentences covering purpose, effect, return, and errors. No redundant information, all sentences earn their 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 two parameters, no output schema, and minimal annotations, the description explains the effect on subsequent operations and error conditions well. Some context about state management could be added, but sufficient for the 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?

Schema coverage is 100% with descriptions, providing baseline 3. Description adds value by clarifying surfaceId's source and sessionId's optionality, enhancing understanding beyond 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?

Clearly states it selects a live renderer surface using an opaque ID from electron_surfaces_list. Explains that subsequent operations target that surface, distinguishing it from sibling tools like electron_surfaces_list.

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?

Implies when to use by stating that operations like snapshot and interactions target the switched surface. Explicitly notes that references from different surfaces are rejected. Could be more precise about when not to use, but adequate.

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?

Annotations indicate readOnlyHint=false, and the description adds that it changes the renderer target without promising OS focus. It also lists error types. No contradiction with annotations.

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 and an error list, front-loaded with the main purpose. No superfluous text.

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 moderate complexity, the description covers return format, errors, and behavioral nuance. It is nearly complete for agent invocation.

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 covers all 4 parameters with descriptions. The tool description adds the precedence order and notes that sessionId can be omitted for single sessions, adding value beyond 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 it selects the active window with a defined precedence order. It distinguishes the tool's action from siblings like electron_switch_surface but does not explicitly differentiate.

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 explains what the tool does and does not do (no OS focus guarantee) and lists errors. However, it does not specify when to use this tool vs sibling tools like electron_switch_surface.

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?

Discloses no-op behavior, options (force, timeoutMs), return shape, and error types with retryability hints. Annotations are minimal, so description fully carries behavioral disclosure.

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 covering purpose, options, returns, and errors. Concise but could benefit from structured sections for 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?

Includes return value shape and key errors given no output schema. Covers most behavioral aspects, though 'actionability checks' could be elaborated.

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 100%, so baseline 3. Description lists options but doesn't add new semantics beyond what schema already provides for each parameter.

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?

Clearly states verb 'uncheck' and resource 'checkbox', with identification via ref or selector. Distinguishes from sibling tool 'electron_check' which does the opposite.

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 when-to-use or when-not-to-use guidance. The 'no-op if already unchecked' implies idempotency, but no differentiation from alternatives like 'electron_click'.

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?

Discloses return format, error types (NOT_RUNNING, BAD_ARGUMENT), and clamping behavior. Annotations already indicate readOnlyHint=true, and description adds context on error conditions and return value, with 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?

Two sentences with no redundant text. Front-loads purpose, then usage guidance, then return/errors. 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 simple fixed-wait tool, the description covers purpose, alternatives, parameters, return value, and error cases. No output schema needed; return format is described.

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 covers both parameters (ms, sessionId). Description adds 'clamped to 60000' for ms and guidance for sessionId: 'Omit when a single session is running.' Also explains BAD_ARGUMENT error related to sessionId.

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 'Pause for ms milliseconds' and distinguishes from siblings by recommending electron_wait_for_state and electron_wait_for_selector. It specifies verb (pause), resource (milliseconds), and scope (clamped).

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 against using this tool for condition-based waiting: 'Prefer electron_wait_for_state or electron_wait_for_selector — a fixed wait is slower and more brittle.' Also notes error conditions for multiple sessions.

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