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

With no annotations, the description carries full burden and excels: details the by-axis resolution algorithm (climbing ancestors, hit-testing), error codes, modal blocking detection, verifyDelivery status with observedSignals, and disclaimers about delivery signals. It is remarkably transparent about internal behavior and edge cases.

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 clear sections and front-loaded with the core purpose. However, it is somewhat verbose and could be trimmed without losing essential information. Still, the organization helps an agent parse it.

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 13 parameters and no output schema, the description covers all behavioral aspects: input modes, error handling, output parameters like verifyDelivery and post.perception, and linkages to other tools. An agent has sufficient information to use the tool correctly in diverse 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 description coverage is 100%, but the description adds significant value beyond the schema: explains the semantics of by-axis parameters (e.g., how they resolve to actionable elements), the interaction between parameters (by+pattern vs selector), and detailed behavior of scrollIntoView and verifyDelivery. This greatly aids correct invocation.

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

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

The description clearly states 'Click a DOM element in Chrome/Edge' and details two distinct targeting modes (selector and by-axis), distinguishing itself from siblings like browser_locate and mouse_click. It specifies the browser context and core action without ambiguity.

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?

Extensive guidance on when to use each targeting mode, how to handle error codes (BrowserAmbiguousTarget, BrowserNoActionableTarget, BrowserModalBlocking), and explicit caveats about viewport scrolling. It provides alternatives like scrollIntoView and browser_eval, and contrasts with sibling tools implicitly.

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 fully discloses behaviors: actions, truncation, withPerception wrapping, readyState checks, error codes (BrowserNotConnected, AutoGuardBlocked), serialization limitations, and execution timeout. 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 well-structured with clear sections (Purpose, Details, Prefer, Caveats, Examples) and front-loads the purpose. It is slightly verbose but 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 the complexity (12 parameters, 3 actions), the description covers all aspects, including return structures, error types, and recommended usage patterns. Examples illustrate typical calls. No output schema exists, but the description adequately hints at return shapes.

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 context beyond the schema, such as the purpose of each action, the effect of withPerception, and the use of selectors for appState. It provides examples that clarify parameter usage.

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: 'Inspect or operate on a browser tab via 3 actions'. It specifies each action (js, dom, appState) and differentiates from sibling tools by focusing on evaluation/scripting rather than navigation, clicks, etc.

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 'Prefer:' section explicitly tells when to use each action, e.g., 'Use action='appState' BEFORE 'dom' or 'js' on SPAs'. The 'Caveats' section specifies when not to use this tool (e.g., for controlled inputs) and provides error handling 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 fully discloses behavioral traits including CDP usage, controlled input handling, resolution logic, error codes (BrowserAmbiguousTarget, BrowserNoActionableTarget, BrowserFillNotDelivered), and the false-positive case for controlled input transforms. It also advises verifying actual value.

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 bullet points and clear sections, front-loaded with main purpose, and every sentence adds value without being 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?

Given 11 parameters, no output schema, and no annotations, the description is thoroughly complete, covering targeting, error handling, usage, and caveats for all 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?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema: explaining how by-axis targeting works, mutual exclusivity with selector, role filtering, scope narrowing, case sensitivity, port default, and error handling. It also integrates with browser_overview/locate.

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

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

The description begins with 'Fill a form input with a value via CDP' and specifies it works on React/Vue/Svelte controlled inputs, clearly distinguishing it from sibling tools like browser_eval.

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 states when to use this tool over browser_eval and provides two targeting methods with clear caveats on ambiguity and error handling. It also notes the prerequisite of browser_open.

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 prerequisites (CDP active), default behavior (hidden excluded), value truncation, and label resolution order. Lacks mention of performance or side effects, but covers key behavioral traits.

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

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

Description is concise, well-structured, and front-loaded with purpose, followed by usage guide and caveats. No redundant information; 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 details what fields are returned but not the exact structure. Lacks error handling or empty-selector behavior. However, it covers prerequisites, parameter defaults, and integration with browser_fill, which is sufficient for most use cases.

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%, baseline 3. Description adds meaningful context: why includeHidden defaults to false (avoid clutter), order of label resolution, and that includeContext adds activeTab/readyState. Provides value 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 the tool inspects form fields within a CSS selector container, returning details like name, type, id, value, etc. It distinguishes from sibling tools by mentioning its use before browser_fill to discover exact field selectors.

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 tells when to use ('Use this before browser_fill to discover exact field selectors') and provides caveats: requires browser_open, hidden inputs excluded by default, value truncation at 200 chars. Guides against accidental targeting of wrong inputs.

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 capture-time coordinates, staleness risk, and typed errors. Could mention more about response shape, but sufficient for safe use.

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, front-loaded with purpose, zero wasted words. Caveats and error patterns are clearly separated.

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

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

No output schema, but description states return of physical screen coordinates. More detail on return format (e.g., object with x,y) would improve completeness, but error types and compatibility hints are good.

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%, baseline 3. Description adds little beyond schema for parameters, but mentions coordinate compatibility with mouse_click, which is helpful context.

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 action (find DOM element) and output (physical screen coordinates), explicitly distinguishing from sibling tools browser_click and browser_overview.

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 using browser_click for find+click in one step and browser_overview to discover selectors. Also includes caveat about stale coordinates after page reflow.

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 fully discloses behavioral traits: navigation does not block until page load, auto-guard verifies tab readyState, and detailed typed errors (NavigateFailed, BrowserNotConnected, AutoGuardBlocked) with recovery steps. It explains optional behaviors like waitForLoad and loadTimeoutMs, providing comprehensive transparency.

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

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

The description is well-structured into paragraphs covering purpose, caveats, and errors, but is somewhat verbose with detailed error explanations. It could be slightly more concise while maintaining clarity. Still, it is effectively organized and mostly front-loaded with key information.

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

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

Despite no output schema, the description covers all 8 parameters, behavioral nuances, error handling, and practical advice (e.g., follow with wait_until). It mentions the response shape (post.perception.status, envelope option) sufficiently for agent invocation, making it complete for this tool's complexity.

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

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

Schema description coverage is 100%, but the description adds significant context beyond the schema: explains the role of port, tabId, lensId (advanced pinned-tab workflows), include (response shape), narrate (narration level), waitForLoad, and loadTimeoutMs. This enriches the parameter meaning beyond basic 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 a browser tab to a URL via CDP Page.navigate, distinguishing itself from siblings by noting it is more reliable than clicking the address bar. It specifies the action verb 'navigate' and the resource 'browser tab to a URL', 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 extensive usage context, including caveats (navigation non-blocking, follow with wait_until), error handling guidance (typed errors), and optional parameters (lensId). However, it does not explicitly state when to avoid this tool or list direct alternatives, though sibling tools are available. This slight gap prevents a perfect score.

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?

Despite no annotations, the description fully discloses behavior: returns tabs array with specific fields, idempotent launch, error codes, killExisting warning data loss, and CDP connection per-process. 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?

Single paragraph but well-structured with clear logical flow. Slightly redundant on 'idempotent' but overall concise given the information density.

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 all necessary aspects: prerequisite, input/output, errors, edge cases (browser restart, existing session, unreachable endpoint). References sibling tools. Complete for a setup 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 already describes all parameters, but description adds context: explains launch parameter purpose, default behavior, example usage, and caveats for killExisting. Adds 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?

The description clearly states the tool connects to a debug-mode browser and returns open tab IDs, and it distinguishes from siblings by being the prerequisite for all other browser_* 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?

Explicit instructions on when to use (required before other browser tools), when to use launch:{} vs pure connect, and caveats (Chrome restart, cannot take over existing session without debug port). Also gives error handling 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, so description carries full burden. It details return state for ARIA controls, modal detection logic, caveats about CDP snapshots, input hint text behavior, error codes, and scope fallback. Exceptionally 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?

Well-structured with main purpose, usage guidance, modal section, and caveats. Slightly long but each sentence adds value. Good front-loading.

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 8 parameters and no output schema, the description is highly comprehensive. Covers behavior, caveats, errors, modal detection, input nuance, and scope fallback. Return value format is inferred sufficiently.

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%, baseline 3. Description adds meaning beyond schema by explaining parameter behaviors like scope fallback, types default, and include envelope option, thus adding 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?

The description clearly states the tool lists interactive elements with CSS selectors, text, and viewport status. It distinguishes from siblings by advising use before browser_click and preference over screenshot for state verification.

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 when to use (before browser_click, instead of screenshot) and mentions scope limitation and modal detection. Lacks explicit 'when not to use' but context 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?

With no annotations, the description is transparent about result sorting ('confidence descending'), pagination, and options like visibleOnly and inViewportOnly with behavior notes. It mentions error codes and conditions. Lacks an explicit statement of non-destructiveness but implies it.

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?

Compact and well-structured: purpose, axes, result usage, pagination, caveats, then error codes. Every sentence serves a purpose 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?

For a complex tool with 11 parameters and no output schema, the description covers core functionality, error handling, and usage context. Could include a sample result structure but sufficient given the chaining hint.

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%, baseline 3. Description adds value beyond schema by explaining search axes with examples (literal substring, CSS), result chaining, and parameter adjustments implied in error codes (e.g., 'broaden the by:text substring').

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 this is a 'Grep-like element search' with specific axes (text, regex, role, ariaLabel, selector) and explains result usage ('pass results[0].selector to browser_click'). It distinguishes from sibling browser_overview for broad discovery.

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 when to use this tool ('when you know specific text or role to target') vs browser_overview for broad discovery. Also provides detailed error code remedies, guiding the agent on corrective actions (e.g., broaden substring, reduce maxResults).

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, but description fully covers behavior: auto-guard with windowTitle, returns perception status, lists all typed errors with recovery actions. Mentions custom controls may not support InvokePattern.

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: main purpose, then usage advice, then caveats and error handling. No unnecessary repetition; 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 adequately explains return (perception status, envelope). Covers prerequisites (desktop_discover), error recovery, and optional parameters. Complete for a complex tool with 9 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 100%, but description adds rich context: explains fixId TTL, lensId guard evaluation, include options, narrate defaults, controlType filter, windowTitle '@active', and hwnd precedence. Goes 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 describes invoking a UI element via UIA InvokePattern without coordinates. Distinguishes from mouse_click and browser_click by specifying native Windows apps and fallback conditions.

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 prefer over mouse_click for buttons, menu items, links. Advises to use desktop_discover first for automationIds. Provides detailed fallback instructions for errors like InvokePatternNotSupported, ElementDisabled, GuardFailed.

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 fully discloses behavior: non-text returns empty string, write verifies via byte-by-byte comparison, and lists specific failure codes and causes (third-party managers, DLP, RDP, etc.). It also describes recovery actions.

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 clear sections (purpose, examples, caveats), but it is slightly verbose. However, every sentence adds value, and it is front-loaded with the core actions.

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 return values (text for read, no explicit return for write but implies a result object with code). It covers error conditions, edge cases, and provides examples. No gaps remain.

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 critical meaning: it explains the 'action' enum values in detail (read vs write behavior), the 'text' parameter's role in write, and the 'include' parameter's response-shaping effect. This goes beyond the schema's basic 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 reads or writes the Windows clipboard, with specific verb-resource pairs: 'action='read' returns current text content' and 'action='write' replaces clipboard with given text'. It distinguishes itself from sibling tools (e.g., keyboard, mouse) by focusing on clipboard operations.

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

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

The description explicitly says when to use read vs write, provides recovery strategies (retry or fallback to keyboard action), and explains caveats like non-text payloads and write verification failures. It gives clear context for when-not-to-use 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?

With no annotations, the description fully discloses behavior: always-returned fields, optional fields, Chromium-specific quirks (cursorOverElement null, fallback to CDP), limitations (non-UIA elements, modal detection), and sessionState heuristics. It is thoroughly 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?

The description is structured with Purpose, Details, Prefer, and Caveats sections, front-loading key info. While lengthy, every section adds essential context; slight wordiness is justified given the tool's 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 thoroughly explains all return fields, optional behaviors, and edge cases (e.g., includeDocument silently omitted). It covers prerequisites (browser_open), limitations, and interaction with siblings, making it 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?

All parameters have schema descriptions, achieving 100% coverage. The description adds value by explaining absorbed tools (e.g., includeCursor absorbs get_cursor_position) and nuances (includeSessionContext's ADR-017 context). It enhances understanding 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's purpose: 'Read-only observation of the current desktop state.' It lists specific return fields and distinguishes from siblings like desktop_discover and screenshot. The verb 'observe' and resource 'desktop state' are explicit.

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: 'Use after each action to confirm state.' It notes cost (cheapest), mentions when to use optional flags, and suggests alternatives (desktop_discover for actionable lists). It also explains attention signals and conditions for recovery.

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 fully discloses behavioral traits: required registry keys (AccessVBOM=1, VBAWarnings=1), Trusted Location setup, need for Excel restart, COM STA serialization causing blocking, and the requirement that macroName must match the Sub name in code. Failure modes (HRESULT 0x800a03ec) are also noted.

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 clear sections (Purpose, Details, Prefer, Caveats, Examples). It is comprehensive but each sentence adds necessary information, avoiding redundancy. Front-loading the purpose and distinction aids quick understanding.

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 (VBA execution, COM, permissions), the description covers all essential aspects: purpose, setup requirements, prevalidation, caveats about naming and blocking, and complete examples with return values. No gaps remain despite the lack of an output schema.

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

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

The input schema is empty with additionalProperties: true, so it provides no parameter definitions. The description compensates by defining the key parameters (action, code, macroName, visible) and their meanings, including constraints like macroName must match Sub name. Examples show expected parameter combinations and their effects.

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 purpose: author and run VBA macros against Excel via COM late binding. It distinguishes from 'Claude for Excel' which writes formulas but cannot run VBA. The two actions run_vba and check_access_vbom are explicitly defined, making the tool's functionality 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 direct guidance: 'Prefer: Run check_access_vbom first when a workflow depends on macro execution'. It explains the preflight check and remediation for failures. Examples illustrate correct usage for both actions, clarifying when to use each.

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 case-insensitivity, partial match, CDP availability (silently skipped), focus stealing, Win11 foreground refusal with specific error code, and recovery options. 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?

Description is relatively long but every sentence adds value. Front-loaded with core purpose. Well-structured, no redundancy. Concisely covers all necessary aspects.

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), description covers usage, alternatives, failure modes, caveats, and error recovery. Complete for an AI agent to select and invoke correctly.

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

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

Schema description coverage is 100%. Description adds context beyond schema: explains when to use chromeTabUrlContains ('when the target is a Chrome tab that is not currently active'), details forceFocus behavior (auto-escalation), and include parameter options. Adds meaning 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 states 'Bring a window to the foreground by partial title match (case-insensitive)', which is a specific verb and resource. It distinguishes from siblings by mentioning when to use focus_window vs chromeTabUrlContains and other tools like desktop_act.

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: 'Use when a tool does not accept a windowTitle param, or when you need to switch focus before a sequence of actions.' Also details when to use chromeTabUrlContains and provides alternatives for recovery from ForegroundRestricted (desktop_act, click_element, keyboard).

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 the description bears full burden. It exhaustively covers auto-clipboard for non-ASCII, background vs foreground methods, focus leashes, abort behavior, sequence verification, error contexts like FocusLostDuringType, and more. 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 long but structured with clear headings (Purpose, Details, Prefer, Caveats, Examples). It front-loads the main purpose. While verbose, every sentence adds value for a complex tool. Slightly longer than ideal but justified by 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?

No output schema, so description must cover return behavior. It discusses return context like typed/remaining, error types (FocusLostDuringType, BackgroundInputNotDelivered), verification outcomes, and suggested fixes. Comprehensive for 19 parameters 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%, offering baseline of 3. The description adds substantial context beyond schema: e.g., for 'action' it enumerates sub-actions, for 'keys' it lists blocked combos, for 'steps' it explains gapMs and holdMs semantics, for 'fixId' it describes TTL, etc. This significantly enriches parameter 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 starts with 'Purpose: Send keyboard input to a window' specifying the verb and resource. It further distinguishes three sub-actions (type, press, sequence) and mentions an alternative (desktop_act for setValue), clearly differentiating 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 includes a 'Prefer:' section advising when to use windowTitle and lensId, and suggests desktop_act for value patterns. Examples illustrate usage. However, it does not explicitly compare with siblings like browser_fill or clipboard, though the caveats provide context for when not to use certain actions.

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 fully discloses behavioral traits: the guarding mechanism (verifies target identity, foreground, coordinate inside rect), return statuses ('ok', 'unguarded', 'unverifiable'), error conditions (ForegroundRestricted, MouseClickNotDelivered reserved), and verifyDelivery hint behavior. It also explains origin+scale conversion and lensId advanced workflow.

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 lengthy but each sentence adds value. It is front-loaded with the core purpose and examples. However, it could be more structured (e.g., bullet points or sections) to improve readability. Slightly verbose but still 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 21 parameters, no output schema, the description covers behavioral aspects, output status, error handling, usage examples, and caveats. It addresses all likely agent questions, including edge cases like fixId expiration, origin+scale constraints, and Win11 restrictions. Highly 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%, baseline 3. The description adds significant semantic value beyond the schema: explains how windowTitle triggers auto-guarding, how origin+scale convert image-local to screen coords, fixId expiry and one-shot nature, lensId purpose, and verifyDelivery status meanings. It also clarifies that doubleClick and tripleClick interactions (tripleClick precedence) and that speed=0 is instant.

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 at screen coordinates' and distinguishes guarded (with windowTitle) and unguarded clicks. It explicitly mentions double-click and triple-click behaviors. It also differentiates from sibling tools: 'Prefer click_element (UIA) for native apps, prefer browser_click for Chrome.'

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 when-to-use guidance: prefers click_element for UIA apps and browser_click for Chrome. It explains when to use windowTitle for auto-guarding vs unguarded clicks. It also covers fixId usage for suggested fixes, and warns about Win11 foreground restrictions and how to recover. Examples illustrate both guarded and unguarded scenarios.

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

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

With no annotations provided, the description fully covers behavioral traits: left button only, guarded start/end points, blocking cross-window drags by default, Win11 foreground refusal, and detailed hints.verifyDelivery status values.

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

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

Well-structured but slightly verbose. Starts with core action and examples before diving into parameters and caveats. Every sentence is informative, but some repetition (e.g., block details) slightly reduces conciseness.

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 14 parameters, no output schema, and no annotations, the description is remarkably complete. Covers use cases, edge cases (cross-window, tab drag), Win11 restrictions, and hints response shape. No obvious 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?

Adds significant meaning beyond schema: explains lensId's advanced usage, verifyDelivery shape, allowTabDrag purpose, and homing behavior. Schema coverage is 71%, but description fills gaps with context and examples.

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 action ('Click and drag'), the resources (mouse coordinates), and specific use cases (sliders, drag-and-drop, canvas drawing, window resizing). It clearly distinguishes from sibling tools like mouse_click.

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

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

Provides explicit when-to-use examples and when-not: cross-window drags blocked by default, tab drags blocked unless allowed. Includes examples and notes on optional parameters (lensId) and intentional overrides (allowCrossWindowDrag, allowTabDrag).

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

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

With no annotations provided, the description carries the full burden. It discloses that the successful response always includes a hints.verifyDelivery object with status 'unverifiable' and explains the reasons (Focus Assist, DND, consent UI). It also mentions the underlying technology (System.Windows.Forms) and that no external modules are needed. However, it does not clarify if the tool is blocking or asynchronous.

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 concise but includes Japanese text and a JSON literal that may hinder readability. The first sentence is clear, followed by technical caveats that are all relevant but could be more structured. Every sentence serves a purpose, but the mix of languages and technical jargon reduces conciseness.

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

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

Given that the tool has only 3 parameters, no output schema, and no nested objects, the description covers the key aspects: purpose, usage context, delivery verification behavior, and a suggested indirect observation method. It is complete enough for an agent to use correctly, though it does not cover behavior for multiple rapid calls or notification click handling.

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 baseline is 3. The description does not add significant new meaning beyond what the schema already provides for the title, body, and include parameters. The description focuses on behavioral aspects rather than parameter details.

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

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

The description clearly states 'Show a Windows system tray balloon notification to alert the user', providing a specific verb and resource. It distinguishes from sibling tools which are focused on browser interactions, desktop actions, and data processing, 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 explicitly says 'Use at the end of a long-running task so the user knows it finished without watching the screen', providing clear context for when to use. It also includes caveats about delivery verification and suggests indirect observation via wait_until, but does not mention alternative tools or explicitly state when not to use.

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

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

With no annotations, the description fully discloses critical traits: sequential execution, max 50 steps, sleep pseudo-step limitation (max 10s), stop_on_error default, inability to inspect intermediate results, and per-screenshot token cost. This is 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 well-organized with labeled sections (Purpose, Details, Prefer, Caveats, Examples), making it scannable. It front-loads the core purpose. While a few sentences could be tightened (e.g., the token cost note), nothing is wasted.

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 (3 parameters, nested objects, behavioral nuances) and no output schema, the description covers nearly everything an agent needs to use the tool correctly. It could mention the format of the error output (e.g., partial results when stop_on_error=false), but the missing detail is minor.

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

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

Baseline is 3 because schema coverage is 100%. The description adds value by explaining the steps array structure, the sleep pseudo-step, the stop_on_error behavior, and the include parameter's influence on response shape. The examples further clarify usage. A minor gap: the 'include' parameter's envelope description could be clearer, but overall adds 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 opens with a clear verb and resource: 'Execute multiple tools sequentially in one MCP call'. It immediately distinguishes from individual tool calls by highlighting latency elimination, and the sibling context (many atomic tools) makes the differentiation obvious.

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: 'Prefer: Use for predictable fixed sequences... Do not use for conditional logic'. It tells the agent when to split a macro and provides caveats about conditional failures, making the usage boundary very 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?

Despite no annotations, the description thoroughly discloses behavioral traits: default scaling, diffMode cold-start behavior, background capture constraints, OCR fallback logic, and coordinate computation. 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?

Long but well-structured with sections for purpose, details, prefer, caveats, and examples. Front-loaded with key info. Could be slightly more concise, but justified by tool 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?

No output schema, but description covers return types (resource_link, inline image, elements) and important notes like the need for a baseline for diffMode. Addresses all key aspects for a complex 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 adds value with examples, inter-parameter dependencies (e.g., region with windowTitle), and business logic (e.g., confirmImage 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 explicitly states the tool captures desktop, window, or region with multiple detail levels and capture modes. It distinguishes from sibling tools like browser_* and screenshot_gc, and provides clear usage boundaries.

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?

Extensive guidance on when to use each detail level, mode, and combination. Includes a 'Prefer' section with explicit recommendations and a 'Caveats' section detailing restrictions and prerequisites.

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

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

No annotations provided, so description fully bears burden. Discloses dry-run default, two-flag safety gate, retention cap behaviors (always keeps newest), and scope limitation to screenshot cache only. Thoroughly covers behavioral traits.

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

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

Single dense paragraph, front-loaded with key behavior and safety. Every sentence provides value; however, could benefit from clearer structure (e.g., bullet points for retention caps). Still highly 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?

Covers all 8 parameters, defaults, safety, scope, and return value in dry-run (candidates + orphan stats). No output schema, but description adequately explains what the call returns. Complete for a cleanup 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%, but description adds value: explains default retention values (newest 200 / 256 MiB), safety interplay of dryRun/confirm, purpose of include (response shape), and includeOrphans default. Goes 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 'Reclaim disk space from cached screenshots by retention policy', specifying the action (reclaim) and resource (cached screenshots). It distinguishes from sibling tools like screenshot (capture) and screenshot_query (query) by focusing on garbage collection and cache cleanup.

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 explains dry-run default and safety condition (dryRun:false + confirm:true for actual deletion). Provides context on when to use (disk space reclamation) and scope options (tag, includeOrphans, retention caps). Implicitly distinguishes from capture/query 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?

With no annotations, the description fully discloses behavior: non-destructive, lists returned fields (captureId, by-ref uri, dimensions, size, timestamp, tag/window, totals), notes ordering (newest-first), and warns about token costs for reading pixels. Also explains response shape options via 'include' parameter.

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 well-structured sentences: first states core purpose, then elaborates on return content, cost warning, filter/paging options, and ordering. No fluff, front-loaded with the main action.

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

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

Given 7 parameters (0 required) and no output schema, the description covers the tool's purpose, return shape (fields and totals), filtering, pagination, ordering, and token-cost warning. It adequately equips an agent to use the tool correctly without needing 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. Description adds extra context: defaults for limit (50), offsets, case-insensitivity for tag, and ordering (newest-first). While some info repeats schema, the description organizes and clarifies usage for pagination and filtering, adding meaningful 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 verb 'List' and resource 'screenshots saved in the disk-cache', emphasizing it is non-destructive and fast. It distinguishes from sibling tools like 'screenshot' and 'screenshot_gc' by describing its specific function.

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

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

Provides explicit use cases: 'so you can find and re-open a specific earlier capture, or check how much the cache holds before reclaiming space with screenshot_gc.' Also warns against unnecessary token cost when opening by-ref links. Differentiates from siblings and advises on when to use.

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 fully covers behavioral traits: scroll scaling details (UIA vs legacy), destructive mutations (expandHidden), OCR accuracy, image stitching size implications, typed errors, and delivery verification. It transparently explains all important side effects and constraints.

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 lengthy but well-structured with clear sections (Purpose, Details, Prefer, Caveats, Examples). Every sentence adds value for a complex tool. Minor redundancy could be trimmed, but the organization compensates for length.

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 32 parameters, no output schema, and no annotations, the description covers all necessary details: each action's mechanics, parameters, error codes, and usage contexts. It includes multiple examples covering all actions, making it complete for an AI 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?

Schema coverage is 100%, but the description adds significant meaning beyond the schema. For example, it explains the 'action' parameter's sub-behaviors, the 'amount' parameter's effect across different app tiers, and the 'strategy' parameter's fallback order. This extra context is critical for correct parameter usage.

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 'Purpose: Scroll a window or page.' and details 5 distinct actions (raw, to_element, smart, capture, read), each with specific use cases. It effectively distinguishes from sibling tools like browser_* and mouse_click by focusing on scroll-specific operations.

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

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

The 'Prefer:' section explicitly states when to use each action (e.g., action='to_element' for click target recovery, action='capture' for reading long pages, action='read' for text extraction from native apps). Caveats further clarify limitations and alternatives, providing comprehensive 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 fully handles behavioral disclosure. It explains what each field returns, notes that engine values are stable while health values change per call, and mentions a limitation (lastRpc only tracks stdio transport). 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 relatively long but well-structured with clear sections for engine, imageDiff, and health. It front-loads the purpose and each sentence adds value. Slight verbosity in health subfields but acceptable.

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 (three main components with subfields), one optional parameter, and no output schema, the description is complete. It explains return value semantics, stable vs changing fields, and a transport limitation. 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?

Only one parameter ('include') with 100% schema description coverage. The description does not add extra meaning beyond the schema; the schema already clearly explains the parameter. 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 starts with 'Return MCP server status.' which is a clear verb+resource. It then details the specific components (engine, imageDiff, health) and distinguishes the tool from siblings by being about server diagnostics, not UI automation.

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

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

The description provides clear context on when to use ('Diagnostic metadata — do not surface unless the user asks about performance/troubleshooting.'), implying a conditional use. However, it does not explicitly state when not to use or name 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?

Despite no annotations, the description thoroughly discloses behavior: actions list, exit code handling (ok:false with specific error code for non-zero), ring buffer cap (1MB), concurrency limit (16 sessions), Windows powershell hidden nature, and that it does not open a visible window. 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 well-structured with sections (Purpose, Actions, Details, Prefer, Caveats, Examples) and front-loaded with essential distinctions. It is longer than minimal but each sentence adds value given the complexity and missing schema. Not excessively 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?

For a tool with no output schema and no annotations, the description is remarkably complete: covers all actions, error handling, limits, platform specifics, and provides multiple examples. Agent can correctly invoke and interpret results based on this description alone.

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 no parameters, but the description fully compensates by detailing each action's parameters (action, id, input, waitMs, shell, clear) with examples for exec, start, write, read, stop. Schema coverage is effectively 100% due to description.

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 is a 'reliable background shell channel backed by a real OS process' and instructs to use it for 'installs, scripts, file ops, and any command that must actually finish'. It explicitly distinguishes from the sibling 'terminal' tool, making the purpose and scope 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: prefer 'exec' for one-shot, 'start+write+read' for interactive sessions, and to use 'terminal' only when a visible console is needed. Also includes caveats about not using when the user needs to see the UI, with concrete alternatives.

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

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

With no annotations, the description fully carries the burden. It details completion reasons, outputIntegrity, baseline_lost, file lock collisions, hidden-input prompts, and background/foreground method behavior. This comprehensive disclosure exceeds expectations.

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 top-down flow (purpose, details, prefer, caveats, examples). However, it is quite lengthy; some repetition could be trimmed without losing essential information.

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

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

Given the tool's complexity (9 parameters, nested objects, no output schema), the description covers all necessary aspects: actions, return values, edge cases, and error handling. It provides enough context for an agent to use the tool correctly in various 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 high (89%), but the description adds significant value beyond the schema: it explains the 'until' parameter structure, illustrates with examples, clarifies the deprecated 'command' alias, and describes action-specific required fields. This greatly enhances 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 it is for interacting with a terminal window, with three specific actions (read, send, run). It distinguishes each action's role and scope, making it easy for an agent to understand what the tool does.

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 each action, including preferring 'run' for command execution, using pattern mode for long-running commands, and avoiding screenshotting. It also advises on fine-grained control with read/send. This effectively helps the agent choose the correct action.

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 behavior: polling mechanics, return format ({ok:true, elapsedMs, observed}), timeout behavior (WaitTimeout with suggest hints), non-timeout failure modes (ToolError, BrowserNotConnected), and implementation details (UIA process per poll, interval clamping).

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 clear sections (Purpose, Details, Prefer, Caveats, Examples) and front-loaded purpose. While verbose, each sentence adds unique value; minor redundancy in some examples could be trimmed.

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 (9 conditions, multiple error paths, prerequisites), the description is exhaustive: it covers all conditions, target requirements, error codes, and provides examples for various use cases. The lack of an output schema is compensated by clear return value documentation.

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 significant value by explaining each condition's target requirements, providing examples, and elaborating on optional parameters like intervalMs and include, making the tool far more usable than 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 as a server-side poll for observable conditions, listing specific conditions (e.g., window_appears, url_matches) and distinguishing it from screenshot-polling loops by sibling tools like run_macro and screenshot.

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 when to use this tool over alternatives (e.g., 'Use instead of run_macro({sleep:N}) + screenshot loops'), provides condition-specific guidance (use url_matches for SPA route changes), and includes caveats about prerequisites (browser CDP connection) and error handling with suggested actions.

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 of behavioral disclosure. It explains pin survival across minimize/restore, need for explicit unpin, dock failure on elevated processes, override of Windows snap, and auto-restoration of minimized windows before docking.

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 labeled sections (Purpose, Details, Prefer, Caveats, Examples), front-loads the purpose, and every sentence adds value. It is concise yet comprehensive, fitting all necessary information into a manageable length.

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, 3 actions) and lack of output schema, the description provides thorough coverage of usage and behavior, including examples. However, it does not describe the return value or error handling, which would improve completeness.

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

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

Schema coverage is 100%, and the description adds value beyond the schema by explaining defaults (480×360 bottom-right), the relationship between action and required fields, and the interplay between pin and duration_ms. However, the schema itself is already clear, so the description only slightly enhances 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 tool's purpose with specific verbs (decorate, pin, unpin, dock) and resources (window), distinguishing it from sibling tools like focus_window. The three actions are explicitly listed and explained.

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 'Prefer' section advising when to use action='dock' versus action='pin' alone, and includes caveats about elevated processes and overriding snap arrangements, giving clear guidance on appropriate 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?

Without annotations, description fully discloses behavioral traits: ShellExecute, window snapshot polling, HWND-based detection, localized title handling, timeout and detach behaviors, and single-instance caveat. 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?

Well-structured with clear headings and front-loaded purpose. No fluff, but includes inaccurate parameter references that harm conciseness. Slight deduction for misleading details.

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?

Explains return format, gives examples, and covers caveats. However, the mismatch with actual schema parameters (timeoutMs vs waitMs, missing args and include) leaves gaps in accurate understanding. Adequate but imperfect.

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, description introduces parameters 'timeoutMs' and 'detach' that do not exist in the input schema, and states a default timeout of 10000 while schema shows 'waitMs' default 2000. This inconsistency misleads the agent and reduces 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?

The description clearly states the verb 'launch' and resource 'application', and specifies the waiting behavior and return values. It explicitly distinguishes from sibling tool 'run_macro' by recommending use instead of manual combos.

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: prefer over run_macro, follow with focus_window, and caveats for single-instance apps. Also covers detach=true scenario. No ambiguity about when to use.

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 important behavioral traits: parallel execution, resetting the diffMode buffer, side effects on diff baseline and identity tracker. It also warns about thumbnail scaling and recommends tracking the reset point. This is thorough and 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?

The description is well-structured with headings (Purpose, Details, Prefer, Caveats) and each section adds value. However, it is somewhat verbose, especially the caveat referencing ADR-010. It could be slightly more concise without losing information, but it remains 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 has 3 parameters, no output schema, and no annotations, the description is remarkably complete. It explains what is returned, side effects, usage patterns, and caveats. It fully equips the 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?

Schema description coverage is 100% (all three parameters have descriptions in the input schema). The description does not add significant new meaning beyond the schema; it references 'includeUiSummary' indirectly and mentions thumbnail dimensions, but the schema already covers these. 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's purpose: 'Orient fully in one call' and enumerates what it returns (display layouts, thumbnails, actionable element lists). It is a specific verb+resource combination and distinguishes from sibling tools like screenshot and screenshot variants.

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

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

The description provides explicit usage guidance: 'Use at session start or after major workspace changes.' It also offers alternatives: 'Use screenshot(detail='meta') for cheap re-orientation' and 'screenshot(detail='text', windowTitle=X) for a single-window update.' This helps the agent decide when to use this tool versus others.

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