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

No annotations provided, so description carries full burden. Explains two modes, mark numbering, parameter interactions (clipTo precedence), and annotate option. Implied read-only, no destructive side effects mentioned.

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 paragraph packs all essential information, front-loading modes and usage. Could be slightly more structured (e.g., bullet points) but clear and 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?

Covers both capture modes, all parameters, and use cases. Output format not mentioned but likely standard for screenshots. Sufficient for agent to understand tool selection and 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 coverage is 100%, but description adds context: modes, precedence rules, mark numbering convention, and usage scenarios for parameters like scale, padding, annotate.

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 two screenshot modes (overview with numbered marks tied to uids, element-scoped crop via clipTo). Specifies use cases for visual/spatial questions, zooming, element confirmation, distinguishing from sibling 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 says when to use ('when text tools are not enough... spatial or visual-layout questions'), but does not explicitly list when not to use or compare to many close siblings like inspect_element or pick_element.

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 the tool's behavior: it checks alignment, gap rhythm, size consistency, grid conformance, and pixel-snap warnings. Since no annotations exist, the description carries the full burden; it is transparent but could explicitly state it is read-only and non-destructive.

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 main purpose, then lists capabilities, provides usage examples, and points to an alternative. Every sentence adds value; there is no wasted 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?

The description covers what the tool does, when to use it, and how it relates to siblings. Given the absence of an output schema, the description sets clear expectations about the audit results (alignment deviations, gap outliers, etc.). It stops short of specifying the exact output format, but the level of detail is sufficient 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?

With 100% schema coverage, the baseline is 3. The description adds context beyond the schema by explaining the overall purpose and use cases for each parameter (e.g., 'audits ALL matches' for selector). It does not simply repeat schema descriptions, making it helpful for the agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs ('audit', 'align', 'checks') and identifies the resource as a GROUP of elements via selector or uids. It distinguishes from sibling tool 'measure_element' which handles single-element glyph centering.

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 when-to-use examples are provided ('unevenly spaced', 'one card sits lower', etc.), and an alternative is given: 'For ONE element's internal glyph centering use measure_element instead.'

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

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

With no annotations provided, the description carries full burden. It discloses that connect starts/restarts a session, can launch Chrome or attach to an existing browser, and that every other tool depends on a live session. It also mentions the reset behavior (call again if wedged). This is adequate for a setup tool, though it could explicitly state that it closes any previous session.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (two sentences) and front-loads the key message ('ALWAYS the first call'). However, the first sentence is dense and could be broken into shorter sentences or bullet points for easier scanning. Overall, it is efficient and avoids 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?

Given the tool's role as a session initiator with 6 parameters and sibling tools that depend on it, the description covers essential aspects: when to call, modes, parameter usage, and recovery behavior. It does not describe return values (no output schema) or error cases in detail, but that is acceptable for a connection setup 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?

The input schema has 100% coverage for all 6 parameters. The description adds value beyond the schema by explaining the purpose of each parameter in context: url loads immediately, mode defaults to 'launch', width/height set viewport, headless only in launch mode, and browserUrl for attach mode with an example. This provides useful 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's purpose: 'start (or restart) the browser session'. It specifies it is always the first call and distinguishes between launching a local Chrome or attaching to an existing browser via browserUrl. This differentiates it from sibling tools that require an active session.

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 says 'ALWAYS the first call' and instructs when to call it again ('if a tool reports no session or a wedged browser'). It also explains the two modes (launch vs attach) with examples. However, it does not explicitly state when not to use it, though the context implies that if a session is active, it should not be called.

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 mentions the JS is trusted (authored by agent), result is returned verbatim and size-capped. However, it does not explicitly caution about potential side effects on page state, which is a notable omission for an arbitrary execution 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 highly concise (3 sentences) and front-loaded with the label 'ESCAPE HATCH' to immediately convey its nature. Every sentence adds value: purpose, usage restrictions, and behavioral notes. 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 the tool's complexity (arbitrary JS execution) and absence of output schema, the description adequately states that the result is JSON and size-capped. It does not mention error handling (e.g., JS exceptions), which is a minor gap, but overall 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 description coverage is 100%, so baseline is 3. The description does not add parameter-specific information beyond what the schema already provides for timeoutMs, expression, and awaitPromise. The context given is general and does not enhance parameter 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 clearly states the function: 'run arbitrary agent-authored JavaScript in the page and get the JSON result.' It distinguishes the tool from siblings by explicitly naming alternative tools (explain_styles, measure_element, etc.) and their applicability.

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 'Use ONLY when no purpose-built tool covers the need' and provides concrete examples (custom measurement, forcing UI state, reading framework state). It also directs to prefer specific sibling tools, giving clear when-to-use and when-not-to 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?

Since no annotations are provided, the description carries the full burden. It adequately describes what the tool does: gathers running animation information, checks against a closed ruleset, and attributes rules to file:line. It does not disclose any potential performance overhead or side effects, but the described behavior is read-only and well-scoped.

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 that is information-dense yet readable. It front-loads the main action and provides usage conditions. While it could benefit from bullet points or clearer separation of sections, it contains no unnecessary words and earns its place.

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

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

Given the complexity (5 parameters, no annotations, no output schema), the description covers the tool's purpose, usage guidelines, and parameter hints adequately. It does not explicitly describe the output format, but the term 'census' implies a structured summary. It is complete enough for an agent to understand when and how to 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?

Schema coverage is 100% with descriptions for all 5 parameters. The description adds value by explaining that the 'property' parameter enables a specific 'changes are instant' check, which goes beyond the schema description. For x/y, it reinforces their combined use. Overall, it adds semantic context without redundancy.

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: explaining animations and transitions on one element, including a census of running animations and declared rules. It distinguishes itself from sibling tool 'record_interaction' by specifying its use case for diagnosing animation issues and not for timeline recording.

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 when-to-use scenarios: when an animation is not smooth, doesn't run, or jumps/pops. Also specifies when to use an alternative: for timeline of clicks/hovers, use 'record_interaction'. This guides correct tool selection.

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

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

No annotations provided, so description carries full burden. It discloses output content (winner, losers, reasons, blast radius, scoped selector) and implies read-only diagnostic nature. Does not explicitly state 'non-destructive', but context makes it clear. Could be more explicit about read-only 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?

Description is verbose (about 150 words) with some redundancy (e.g., repeated mention of winners and losers). The front-loaded bold phrase 'The core WHY' is effective, but overall could be more concise. Structure is good with bullet-like points but still longer than ideal.

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 complexity (5 params, no output schema, no annotations), the description covers key aspects: what the tool returns (verdict, reasons, blast radius, scoped selector) and how to use parameters. It lacks exact output format but is sufficient for correct invocation. Could be more complete for detailed output expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage with descriptions, and description adds value by explaining the 'property' parameter with an example ('margin-bottom') and context for other parameters (x/y as viewport, uid from prior snapshot). It also notes the optional property to focus, enhancing schema meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool explains the CSS cascade verdict per property, naming winners and losers with reasons. It uses specific verbs like 'explain' and 'diagnose', and distinguishes from siblings by comparing to source search and style_diff. The resource is explicitly the CSS cascade.

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 when-to-use scenarios (wrong style, won't apply, overriding rule) and when-not (prefer over grepping source). It gives examples of symptoms and recommends diagnosing before editing. However, it doesn't explicitly contrast with all sibling tools like explain_animations or style_diff, but the guidance is strong 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?

No annotations are provided, so the description carries full burden. It discloses key behaviors: criteria are AND-combined by default, match:'any' enables OR, visibleOnly:false includes hidden elements, anchors include resolved href. It does not mention potential side-effects (e.g., scrolling) or confirm it is read-only, but as a search tool the transparency is high.

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 with clear logical flow: output statement, example, criteria details, usage recommendation. It is front-loaded with the core purpose. While efficient, it could be slightly more concise by removing one clause, but overall it is well-structured.

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

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

The tool has 7 parameters including a nested region object and no output schema. The description covers search criteria, combination modes, visibility, region intersection, and provides usage context. It lacks explicit output format details (beyond 'compact uid-keyed matches') but the overall completeness is high for a search 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 71%, so baseline is 3. The description adds semantic value beyond the schema by explaining the AND/OR combination logic ('Criteria are AND-combined by default; pass match:'any' for a union (OR) when over-specifying returns nothing') and the anchor href inclusion. This provides practical usage context the schema alone does not.

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 performs a 'deterministic search' using explicit criteria (visible text, CSS selector, ARIA role, screen region) and outputs 'compact uid-keyed matches'. It distinguishes itself from sibling tools like node_at_point (point in screenshot) and pick_element (physical click) by naming them directly.

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

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

The description provides explicit guidance on when to use this tool: 'Use to locate the element a user described in words ... before inspecting it. Prefer this (or page_snapshot) over guessing a selector.' It also gives clear exclusions: 'For a point in a screenshot use node_at_point; to have the human physically click the element use pick_element.' This is comprehensive.

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

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

With no annotations provided, the description fully bears the burden. It discloses default inclusion of delegated listeners, returned data (event type, source location, flags), and scope. No contradictions, but could mention performance or same-origin limitations.

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 coherent paragraph that front-loads the core action, then provides use cases and alternatives without fluff. Could be slightly more structured but 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?

Given 6 optional parameters, no output schema, and no annotations, the description adequately covers purpose, usage, what is returned, and alternatives. It could specify the return format (list) but is otherwise 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%; all 6 parameters have descriptions. The description adds little new meaning beyond the schema, except clarifying includeAncestors default and purpose (delegated handlers). Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists event listeners on an element and delegated listeners up the ancestor chain, providing specific details about the returned info (event type, handler file:line, flags). It distinguishes from sibling tool record_interaction.

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 provides use cases (e.g., 'which JS file handles this button?', debugging passive listeners) and recommends record_interaction for step-by-step interaction analysis, offering clear when-to-use and when-not-to-use 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 discloses that trials use !important, reports changed properties, and patches are temporary. It omits potential side effects like performance impact or security constraints, but covers key behavioral traits for a testing 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 moderately long but well-organized with clear sections and front-loaded main action. Some redundancy could be trimmed, but it remains efficient and readable.

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 hints at return (reports changed properties for trial mode) but lacks full details on success/error messages. However, it sufficiently covers the tool's purpose, parameters, and usage 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 has 100% parameter coverage; description adds contextual meaning: explains the dual functionality via parameters (css vs declarations+uid/selector), !important application, and revert behavior, 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 description clearly states it applies CSS to the live page for testing, with two modes (trial on one element with !important, or raw page-wide rules). It distinguishes from siblings like explain_styles and style_diff by positioning it as the fix-loop 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?

Explicitly outlines the workflow: explain_styles → inject_css → verify with measure_element/style_diff/annotated_screenshot → write source → revert. Also mentions use case for hiding overlays and warns patches are trial-only.

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

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

No annotations provided, so description carries full burden. It discloses the tool analyzes one concern per call and flags the binding constraint. While it doesn't mention side effects or auth needs, as a read-only analysis tool, the behavioral description is sufficient and accurate.

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 usage sentence, all front-loaded and each adding value. No redundant phrases, and information is prioritized clearly.

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

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

Given 5 parameters, full schema coverage, no output schema, and complexity of ancestor analysis, the description covers purpose, usage, and relation to siblings. It is complete for a read-only analysis 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 description coverage is 100%, so baseline is 3. The description adds minimal new parameter info beyond what schema provides, but it frames the overall flow (walk ancestor chain for one concern) which adds context. No additional parameter details are needed.

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 walks an element's ancestor chain for one concern (width, height, position, overflow, or stacking) and flags the binding constraint. It uses specific verbs like 'walk' and 'flag' and distinguishes itself from sibling 'explain_styles'.

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 lists when to use: when cause lives above the element (too wide/narrow, clipped, won't scroll, mysteriously positioned, or z-index ineffective). It mentions complementing 'explain_styles' but does not explicitly state when not to use, though the positive guidance 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?

No annotations provided, so description carries full burden. Discloses tool returns rendered values (not authored), catches overridden styles, and provides specific data categories. Lacks details on error handling or output format, but adequate for a read-only inspection 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?

Front-loaded with purpose, concise sentences, no wasted words. Parenthetical clarifications are 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 5 parameters, no output schema, and no annotations, description provides good context: explains when to use and what data is returned. Lacks explicit output format details but sufficient for agent to understand tool's role.

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 does not add parameter-specific details beyond schema; no extra meaning for parameters like x, y, uid, verbose, or selector.

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 box model, computed styles, visibility verdict, and layout context for one element, using specific verbs and distinguishing from sibling tools like 'explain_styles' and 'inspect_ancestors'.

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 (need current rendered state) and when not to (use explain_styles for 'why it looks like this', inspect_ancestors for ancestor constraints), plus highlights benefit of catching overridden styles.

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

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

No annotations provided, so description carries full burden. It discloses that the tool does not record or teardown, reports post-action visibility and content box, and uses targeting methods. It could mention if scrolling into view is handled, but overall 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?

Somewhat lengthy but well-structured and front-loaded. Every sentence adds value: purpose, usage guidance, examples, output details, targeting methods. Could be slightly more concise, but 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 6 parameters and no output schema, the description is highly complete. It explains what to expect after action (visibility+content box), how to use different targeting, and distinguishes from sibling. Missing error conditions but still 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?

Schema coverage is 100% with all parameters described. The description adds valuable context beyond schema, such as 'first match is used' for selectors and the default for action. Enriches understanding of 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 tool performs one action (click/hover/focus) at a target and leaves the resulting state in place. It uses specific verbs and resource descriptions, and distinguishes itself from the sibling tool record_interaction.

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 this tool (to drive the UI into a state) and when to use record_interaction instead (for causal timeline). Also suggests subsequent tools like inspect_element, showing clear usage context.

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

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

No annotations are provided, so the description carries full burden. It discloses determinism, returns content box and ink bounding box dimensions, sub-pixel centering, and alignment delta with reference elements. It does not mention error handling or prerequisites, but for a measurement tool this is adequate. Slightly less transparency due to no mention of what happens with invalid inputs.

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-loads the core capability. Every sentence adds value, though it could be more structured (e.g., bullet points). No wasted words, but brevity is slightly sacrificed for thoroughness.

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 explains what the tool returns (content box dimensions, ink bounding box, centering verdict). It covers both single-element and two-element comparison use cases. Missing details on edge cases (e.g., element not found) but otherwise complete for a measurement tool with 6 parameters.

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 value by contextualizing parameters (e.g., 'x,y' as viewport coordinates, 'uid' from prior page_snapshot, 'referenceUid' for alignment delta). It goes beyond schema by explaining how parameters relate to the tool's purpose and behavior.

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 determines rendered-pixel geometry (content box and true text ink bounding box) and sub-pixel centering. It provides concrete examples like 'the × in the close button looks a bit high' and distinguishes from siblings like explain_styles by focusing on visual alignment invisible to the box model.

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: 'when the caller is fussing over VISUAL alignment that the box model can't see' with specific examples. It also explains how to use referenceUid/referenceSelector for comparing two elements, and differentiates from explain_styles by noting the latter tells which rule set the value while measure_element tells if the painted glyph lands correctly.

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 fully discloses behavioral traits: navigation makes all element uids stale, recommends a fresh page_snapshot, and bypassCache disables caching for the session.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. The first sentence states the main action, the second adds important caveats. 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?

For a tool with two simple parameters and no output schema, the description covers the primary behavior, side effects (stale uids), and post-condition (take snapshot). 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 by explaining that omitting url reloads and bypassCache disables cache for the session, which goes 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 tool navigates to a URL or reloads the current page. It distinguishes itself from sibling tools like page_snapshot or interact by focusing on navigation.

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 when to use bypassCache (for stale cached assets) and implies when navigation is needed. It could be improved by explicitly stating when not to use this tool or alternatives, but it is still 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?

With no annotations, the description carries the full burden. It explains the return values but does not disclose behavior for out-of-bounds coordinates or performance characteristics. Adequate but not thorough.

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 superfluous content. The first sentence defines the core function, the second provides usage context. Every word earns its place.

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

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

For a simple two-parameter tool with no output schema, the description adequately covers the return values and usage. Could mention failure cases (e.g., no element at coordinates) but overall complete given low 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 concise descriptions. The description adds context by explaining the parameters as viewport coordinates in CSS px and providing usage examples, 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 the tool maps viewport coordinates to an element and specifies the return values (uid, identity, ancestor chain). It distinguishes itself from siblings like pick_element by focusing on coordinate-to-element mapping.

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 use cases (e.g., from annotated_screenshot or user-given pixel coords) but does not explicitly mention when not to use it or compare with 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?

No annotations are provided, so the description carries the full burden. It describes the output but does not explicitly state that the tool is read-only and safe. It lacks mention of permissions or side effects. For an inventory tool, this is adequate but not comprehensive.

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 main purpose. Every sentence adds value, with no wasted words.

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

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

Given no parameters and no output schema, the description effectively explains what the tool returns (stylesheet details and platform detection) and when to use it. It could be slightly more specific about the return format (e.g., list, object) but is otherwise 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?

Input schema has zero parameters, so schema coverage is 100% and no parameter documentation is needed. The description correctly does not discuss params, earning the baseline of 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 it inventories stylesheets (URL, byte size, origin, source-map) and detects platform details (WordPress version, theme, page builder, optimizer). This is specific and distinguishes it from siblings like 'explain_styles' or 'style_diff'.

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 says 'Use before proposing edits' and gives three concrete scenarios: learning where CSS lives, finding true source for minified bundles, and answering platform/ownership questions. This provides clear when-to-use 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. It discloses that the tool is a read-only census (implied, not explicit), token-budgeted, and provides stable uids. However, it does not explicitly state that it is non-destructive or whether it requires permissions, which would be ideal. Nevertheless, the behavior is well implied and no contradictions exist.

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 sentences, each adding value: purpose, when to call, and when to use alternatives. Front-loaded with core function, no wasted words. 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 tool's complexity (3 parameters, nested object) and no output schema, the description explains the output nature (element tree with geometry/visibility), token budget, and usage context with clear alternatives. It lacks a detailed node structure, but covers the essential needs for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds context like 'token-budgeted' and explains that scope limits to one subtree, but does not significantly elaborate on parameter details beyond what the schema provides. It is adequate but not exceptional.

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: a token-budgeted census of the rendered page returning a nested, uid-keyed element tree with geometry and visibility flags. It explicitly distinguishes from siblings like find_elements and annotated_screenshot, 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?

Provides explicit guidance: 'Call this FIRST after connect' and 'Reach for it whenever you do not yet know the page structure or an element uid.' It also tells when to use alternatives ('To find one specific element by description use find_elements; to see the page visually use annotated_screenshot'). This is model usage 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?

Describes behavioral traits: samples composited truth, not computed styles; includes WCAG contrast verdict; explains 'at' parameter behavior (top-left vs center). Lacks mention of side effects or performance implications, but as a read-only sampling tool it is sufficiently 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 front-loaded with main purpose and usage tips. Each sentence adds value, though it could be slightly more concise. Structured well for an AI agent to parse quickly.

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 covers what the tool returns (composited truth, computed color/background, WCAG contrast) and how to use parameters. Adequate for understanding the tool's functionality and output.

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 is 3. The description adds value by explaining the difference between center and top-left sampling, and implicitly suggests using uid/selector or coordinates. Adds 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?

The description clearly states the tool samples the actual painted pixel, gives composited truth, computed colors, and WCAG contrast. It distinguishes from sibling tools like explain_styles and annotated_screenshot by focusing on exact pixel color and contrast.

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: 'the color looks off', 'is this the exact brand hex?', 'is this text readable on that background?'. Provides guidance on using 'at:top-left' for pure background and suggests explain_styles for finding which rule set a wrong color.

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 the interactive nature (hover highlight, waiting for click), return data, and environment requirement. It does not mention potential side effects, but the tool appears non-destructive. Slightly lacking in not stating that no changes are made to the page.

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 explains the tool's core functionality, second gives usage guidance. No wasted words, 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 tool with one optional parameter and no output schema, the description covers what it does, when to use, prerequisites, and return value. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not add significant value beyond the schema's description of timeoutSeconds, which is already well-documented. Schema coverage is 100%, so 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 it turns on a DevTools-style hover highlight, waits for user click, and returns the clicked element's uid and ancestor chain. This clearly differentiates from sibling tools like find_elements or annotated_screenshot which are automated.

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 explicitly says to use when the user says 'I'll show you' or when find_elements/annotated_screenshot fail, and notes the requirement for a visible browser window. This provides clear context for when to use vs 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?

No annotations provided, so description carries full burden. It discloses dispatch of real input, observation window, and types of events recorded. Could be more explicit about potential side effects like navigation, but still 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?

Front-loaded with core action and output, followed by use cases and alternatives. Slightly verbose but each sentence adds value.

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

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

Given no output schema and 7 parameters, description covers purpose, usage, and output (timeline). Lacks detailed return structure but sufficient for selection.

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 no extra parameter-specific meaning beyond schema descriptions (e.g., x/y coordinates, uid from page_snapshot). Adequate but not enhanced.

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 (perform one interaction), resource (click/hover/manual), and output (causal timeline). It distinguishes from siblings like get_listeners and explain_animations.

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 lists use cases (e.g., 'the sidebar does not hide smoothly') and when-not-to-use (e.g., 'for static listener attribution without triggering it, use get_listeners'). Provides clear 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?

No annotations are provided, so the description must disclose all behaviors. It mentions re-inspecting after setting the viewport but does not explain side effects (e.g., whether the page reloads, if other state is affected) or any constraints like permissions or rate limits.

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 main action. Every sentence adds value: the action, use cases, and follow-up steps. 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?

Given no output schema, the description logically explains the tool's purpose and suggests next steps. It covers the key aspects for an agent to use the tool effectively, though more detail on return behavior would be beneficial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already describes the parameters. The description only mentions the optional 'deviceScaleFactor' and does not add meaning beyond the schema's default value of 1. 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 clearly states the tool emulates a viewport size and re-inspects, with specific verb 'Emulate' and resource 'viewport on the connected tab'. It provides concrete examples of responsive bugs, distinguishing it from sibling tools that focus on elements or styling.

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 says 'Use for responsive bugs' and gives examples like 'it breaks on mobile'. It suggests following with page_snapshot or explain_styles, providing clear context. However, it does not list alternatives or cases where this tool should not be used.

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

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

No annotations are provided, so the description carries the full burden. It discloses the recording slot mechanism and that compare only reports changed properties. However, it does not mention edge cases (e.g., missing prior record, element not found) or any destructive 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 concise (3-4 sentences) with no filler words. It front-loads the purpose and quickly explains the usage pattern in a structured way.

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 6 parameters, no output schema, and no annotations, the description does a good job explaining the core workflow and use case. It could be more complete by mentioning error handling or slot behavior, but it is sufficient for most scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds additional meaning by explaining the workflow and the purpose of the slot parameter ('named slot'). It also implies how uid and selector are used in the context of recording and comparing.

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 performs a BEFORE/AFTER comparison for one element, recording styles into a named slot and comparing to show only changed properties. It uses specific verbs ('record', 'compare') and distinguishes from sibling tools like check_alignment or explain_styles.

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 it ('did my fix actually change anything?') and provides a concrete usage loop (record → apply change → compare). It does not explicitly list alternatives or when not to use it, but the context is clear.

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