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

With no annotations provided, the description carries the full burden of behavioral disclosure. It simply states 'Perform click' without describing side effects, requirements, or potential outcomes such as page navigation. This is insufficient for an action that could trigger significant UI changes.

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

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

The description is a single, concise sentence that front-loads the core action. It contains no unnecessary words and is easy to parse, though it sacrifices depth for brevity. It earns its place by stating the tool's purpose 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?

Despite the simplicity of a click action, the description is incomplete. It fails to mention that a page snapshot is required, that clicking may cause navigation or other side effects, or any constraints. There is no output schema or annotations to compensate, leaving the description inadequately contextualized.

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 fully documents both parameters (ref and element) with detailed descriptions, and schema description coverage is 100%. The description adds no additional parameter semantics, but the schema already provides the necessary meaning, so the baseline score 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 uses the specific verb 'click' and identifies the resource as a web page, which clearly distinguishes it from sibling tools like browser_hover, browser_type, and browser_press_key. It unambiguously states the action and target.

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 no guidance on when to use this tool versus alternatives. It does not mention any prerequisites (e.g., needing a snapshot) or context in which clicking is appropriate, leaving the agent without useful decision-making information.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without revealing what format the logs are returned in, whether logs are cleared after retrieval, or any side effects. This is minimal and lacks behavioral nuance.

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

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

The description is a single, concise sentence that directly communicates the tool's purpose. Every word is necessary and there is no redundancy or filler. It is optimally concise.

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

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

The tool is simple with no parameters or output schema. The description states the core function but omits details about the return value (e.g., format, structure, or whether it represents an array of messages). While this may be acceptable for such a simple tool, the lack of return information leaves the description slightly incomplete.

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

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

The tool has zero parameters, and the input schema is empty with high coverage by definition. The baseline for zero parameters is 4. The description adds no extra parameter semantics, but none are required since there are no parameters to explain.

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: 'Get the console logs from the browser'. It uses a specific verb and resource, and it is distinct from all sibling tools that handle navigation, interaction, or screenshots. This is a precise and unambiguous purpose.

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

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

The description implies usage for retrieving browser console logs, but it does not explicitly state when to use this tool versus others, nor does it mention any prerequisites or exclusions. Given the absence of alternative log-related tools, the intended context is somewhat implied but not formally stated.

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 for behavioral disclosure. It only states the action and does not mention browser history dependencies, behavior when no previous page exists, or whether the navigation waits for page load.

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

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

The description is a single concise sentence with no extraneous information. It is appropriately sized for a simple command.

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

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

Given the tool's simplicity (zero parameters, no output schema, low complexity), the description covers the core functionality. However, it omits edge-case behavior such as handling an empty browsing history, which slightly reduces completeness.

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

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

The tool has zero parameters, so the baseline is 4. The description appropriately adds no parameter details, as there are none to document.

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

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

The description clearly states the action ('go back') and the resource ('previous page'), distinguishing it from sibling tools like browser_go_forward and browser_navigate. It is specific and unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives such as browser_navigate or browser_go_forward. The description does not mention any context, prerequisites, or exclusions.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the action implied by the tool name. It does not specify what happens when no forward history exists, whether the tool waits for page load, or any error handling, leaving the agent without critical behavioral 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 a single concise sentence with no redundant wording. It efficiently conveys the core action without unnecessary elaboration.

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?

Although the tool is simple with no parameters, the description omits crucial context about browser history navigation and edge cases. It is minimally viable for understanding the basic action but incomplete for an agent to anticipate outcomes or decide when to invoke it relative to other navigation tools.

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

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

The tool has zero parameters, so the schema is complete with no properties. The description accurately reflects that no inputs are needed, and no additional parameter semantics are required.

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

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

The description clearly states the action 'go forward' with the target 'next page', which is specific and distinguishes it from sibling tools like browser_go_back. While it doesn't explicitly mention 'browser history', the context of the browser tool set makes 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?

No guidance is provided on when to use this tool versus alternatives such as browser_go_back or browser_navigate. It lacks any context about prerequisites (e.g., requiring prior navigation history) or how this tool fits into navigation workflows.

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 of behavioral disclosure. It only says 'Hover over element on page' and does not mention any side effects, state changes, whether a snapshot is required, or what happens after hovering. This is a significant transparency gap for a tool that can trigger UI changes via hover events.

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, short sentence that is front-loaded with the action. It is concise and has no unnecessary words. However, it is so brief that it sacrifices important behavioral context, but for pure conciseness it earns a high score.

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

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

The tool has no output schema and no annotations, so the description must provide complete context. It only states the basic action and lacks information about prerequisites, effects, or edge cases. For a tool that interacts with a live page, this is insufficient for an agent to fully understand its impact.

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%, with both 'ref' and 'element' well-described in the schema. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline score 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's function as 'Hover over element on page', which is a specific verb+resource. It distinguishes itself from sibling tools like browser_click and browser_type by the action 'hover'. However, it does not explicitly call out differences from siblings, so it misses the top score.

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 no guidance on when to use this tool versus alternatives. It does not mention typical scenarios (e.g., triggering tooltips, dropdowns) or any exclusions. The usage is only implicitly conveyed by the action itself, which is not 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 must disclose behavioral traits. It only says 'Navigate to a URL' without mentioning whether the tool waits for page load, handles redirects, returns a result, or affects the page state. This is a significant transparency gap for a tool that likely changes the browser context.

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

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

The description is a single short sentence with no fluff, making it very concise. However, it is almost too sparse, providing minimal value beyond the name. It is still well-structured and front-loaded, just lacking substance.

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 one parameter, no output schema, and no annotations, the description is expected to explain basic behavioral context. The description alone is insufficient for an agent to understand what happens after navigation (e.g., does it return a snapshot? does it block until loaded?). The low complexity mitigates the issue slightly, but the complete lack of behavioral information makes this incomplete.

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 simple with one required parameter 'url' that has a description ('The URL to navigate to'), covering 100% of the schema. The tool description adds no further meaning beyond the schema, so the baseline score 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 'Navigate to a URL' states the core action, but it essentially restates the tool name and does not distinguish from sibling navigation tools like browser_go_back or browser_go_forward. It lacks specificity about what 'navigate' entails (e.g., loading a new page vs. history 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?

There is no guidance on when to use this tool versus alternatives. For instance, it does not clarify that this tool is for navigating to a specific URL rather than using browser_go_back or browser_go_forward for history traversal. No when-to-use or when-not-to-use context is provided.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the literal action and says nothing about focus requirements, potential side effects (e.g., triggering form submission), or whether key combinations are supported.

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

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

The description is a single, concise sentence with no redundant words or irrelevant details. It is appropriately sized for a simple one-parameter tool.

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?

While the schema is rich and covers the parameter well, the description lacks usage context and behavioral details. It is adequate for a basic tool but leaves gaps in when to use it and what side effects may occur.

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 fully documents the 'key' parameter with examples such as 'ArrowLeft' or 'a', providing 100% coverage. The description adds no additional semantic meaning beyond what the schema already provides.

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 'Press a key on the keyboard' uses a specific verb and resource, clearly indicating the action. It does not explicitly differentiate from sibling tools like browser_type, but the action is distinct enough by name.

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 no guidance on when to use this tool versus alternatives, such as browser_type for typing text or browser_click. No exclusions or alternative recommendations are mentioned.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'take a screenshot' without detailing what the output looks like, whether it captures the full page or just the viewport, where the image is saved, or any side effects. This is a significant gap for a tool with no structured annotation support.

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, efficiently worded sentence that conveys the core action without any filler. Every word earns its place, and the length is perfectly matched to the tool's trivial parameter surface.

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

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

For a zero-parameter, simple tool the description is minimally adequate, but it lacks important context about the output format, whether it waits for network idle, or how it differs from the sibling browser_snapshot tool. This prevents it from being fully complete for an agent deciding between capture methods.

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

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

The tool takes no parameters, and the input schema confirms this with 0 properties. Since there are no parameters to document, the baseline of 4 is appropriate; the description correctly avoids inventing unnecessary parameter details.

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

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

The description clearly states the action ('Take a screenshot') and the target ('current page'), making its purpose immediately understandable. However, it does not differentiate from sibling tools like browser_snapshot, which could also capture page state, so it stops short of a 5.

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

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

No guidance is provided on when to use this tool versus alternatives such as browser_snapshot. The description does not mention any prerequisites (e.g., page must be loaded) or exclusion scenarios, leaving the user to infer usage.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the basic action. It does not disclose prerequisites (e.g., a visible dropdown, a prior snapshot), side effects (e.g., triggering change events), or behavior with multi-select. For a simple interaction, this minimal info leaves gaps about runtime behavior.

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

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

The description is a single concise sentence with no fluff. It is appropriately sized for the tool's simplicity, though it could include a brief usage tip without becoming verbose. It is well-structured and immediately comprehensible.

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

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

Given the tool's simplicity, 100% schema coverage, and no output schema, the description is minimally adequate. However, it lacks guidance on when to use it versus sibling tools, and it does not mention multi-select behavior or prerequisites such as a snapshot. These are clear gaps, but not severe given the straightforward nature of the operation.

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

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

Schema description coverage is 100%, so the schema fully documents all three parameters (ref, values, element). The description adds no additional meaning beyond the schema, so the baseline score of 3 applies. It does not clarify how 'values' interacts with multi-select or how ref is obtained.

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 'Select an option in a dropdown' uses a specific verb ('select') + resource ('option in a dropdown'), clearly distinguishing it from sibling tools like browser_click, browser_type, and browser_press_key. There is no ambiguity about what operation it performs.

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 no guidance on when to use this tool versus alternatives. It does not mention that it should be used specifically for dropdown elements, nor does it exclude scenarios where browser_click might be more appropriate. There is no explicit comparison or context.

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

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

With no annotations, the description carries the transparency burden. 'Capture accessibility snapshot' implies a non-destructive read operation, but it does not explicitly state side effects, return format, or limitations. It adds some context about the purpose (references for interaction) but lacks deeper behavioral disclosure.

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

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

The description is two sentences, front-loaded with the primary action, and contains no filler. Every word adds value by conveying what the tool does and why to use 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?

Given the tool has no parameters and no output schema, the description adequately covers its purpose and usage. It does not detail the snapshot's format or content, but for a simple read-only tool with no inputs, this is acceptable. The context relative to siblings is clear enough for an agent to decide when to call it.

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

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

The tool has zero parameters and 100% schema coverage (empty properties object), so the schema fully documents parameters. The description adds meaning by explaining the tool's output is used for interaction references, which is useful beyond the schema. Baseline for 0 params is 4.

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

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

The description clearly states the tool captures an accessibility snapshot of the current page, which is a specific verb+resource. This distinguishes it from siblings like browser_screenshot (visual) and browser_navigate (navigation), 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 this for getting references to elements to interact with,' providing clear context for when to use the tool. It does not mention when not to use it or name specific alternatives, but the usage context is directly stated.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Type text into editable element' without revealing whether text is appended or replaced, how the 'element' permission field works, or any error or side-effect behavior. This is minimal and leaves significant gaps.

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

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

The description is a single concise sentence with no wasted words, front-loading the core action. However, it is under-specified, which slightly detracts from its overall value despite being 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?

The tool is part of a browser automation suite, but the description fails to mention that 'ref' comes from a page snapshot, the role of the human-readable 'element' description, or the behavior of the 'submit' flag. With no output schema or annotations, these contextual details are necessary for correct 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% (all four parameters have descriptions), so the schema handles parameter semantics. The description adds no additional meaning beyond the schema, which meets the baseline for high coverage.

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

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

The description uses a specific verb ('Type') and target ('editable element'), clearly distinguishing it from sibling tools like browser_click or browser_press_key. It states exactly what the tool does 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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., obtaining a ref from a snapshot), nor any exclusions or comparisons with browser_press_key or other sibling tools.

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

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

There are no annotations, and the description does not disclose any behavioral traits beyond the bare action. It doesn't specify whether the wait is blocking, whether it can be interrupted, or whether it interacts with page load state. For a wait operation, this lack of detail leaves important behavioral aspects unaddressed.

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 one short, front-loaded sentence that conveys the core function without any fluff. Every word earns its place. It is appropriately sized for a simple, single-parameter tool.

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

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

Given the tool's simplicity and the complete schema, the description is still minimal. It doesn't explain why one might use this wait (e.g., to allow page loading), whether it blocks further actions, or what the return value is. There is no context to help the agent decide when to apply it.

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 with the parameter description ('The time to wait in seconds'). The description adds no additional meaning beyond the schema, but the baseline for high coverage is 3, and no parameter information is missing.

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: 'Wait for a specified time in seconds'. It uses a specific verb ('wait') and identifies the resource ('specified time'). It distinguishes itself from sibling browser tools which are navigation, clicking, typing, etc. No 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is a fixed delay, or that it might be preferable to wait for elements or conditions. As a result, the agent receives no context about appropriate use cases or exclusions.

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