Better Browser MCP

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 simply states 'Perform click' with no mention of side effects (e.g., navigation), permission requirements, or prerequisites like obtaining an element reference from a snapshot. This is a significant transparency gap for a potentially mutating action.

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

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

The description is a single succinct sentence that immediately states the tool's purpose without any filler or redundant words. It is optimally structured for a tool with a clear verb and resource, earning a high score for 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 the tool has 3 parameters, no annotations, and no output schema, the description is too sparse to be contextually complete. It fails to explain how to identify the element (e.g., via snapshot) or when clicking is appropriate relative to other browser actions, leaving important gaps for an agent to resolve.

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 provides 100% coverage with descriptions for all three parameters, so the baseline is 3. The description adds no parameter-specific information; it does not clarify how the 'element' or 'ref' parameters should be used beyond what the schema already states.

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 'Perform click on a web page' clearly identifies the action (click) and the resource (web page), distinguishing it from sibling actions like hover or type. However, it lacks specificity about clicking on a particular element or the need for a snapshot reference, which keeps it from 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?

The description provides no guidance on when to use this tool versus alternatives such as browser_hover or browser_type. It does not mention that a snapshot reference is required or that clicking might trigger navigation, leaving the agent to infer usage from the schema.

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

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

With no annotations, the description carries the full burden. It discloses a key side effect: 'The tab's binding is automatically removed.' However, it does not state whether the operation is reversible, what happens if the tabId is invalid or not bound, or any permissions needed. The destructive nature is implied by 'close' but not elaborated.

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

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

The description is extremely concise—two short sentences with no filler. It front-loads the primary action ('Close a browser tab') and then provides a single important side effect. Every word earns its place.

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

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

For a simple one-parameter tool with no output schema, the description is largely adequate. It covers the main purpose, the binding prerequisite, and a key side effect. It does not detail error handling or return values, but given the simplicity and the absence of an output schema, this is sufficient. Sibling tools like browser_list_tabs can provide tabId details.

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

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

Although the schema already describes tabId as 'Tab ID to close' (100% coverage), the description adds semantic value by clarifying that the tab must be 'previously bound to this agent.' This goes beyond the schema's definition and helps the agent select the correct tab.

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: 'Close a browser tab previously bound to this agent.' It uses a specific verb ('close') and resource ('browser tab') and adds a crucial constraint ('previously bound'), distinguishing it from siblings like browser_open_tab or browser_set_active_tab.

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 when to use it (to close a bound tab) but does not explicitly provide when-not-to-use scenarios or alternatives. It does not mention that tabId can be obtained via browser_list_tabs, though this is a reasonable inference. No exclusions or alternative tool references are given, leaving usage guidance implicit.

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 discloses behavior: it patches navigator.clipboard.writeText to capture the value, returns plain text, and advises secure handling of secrets. This goes well beyond what structured fields reveal and gives the agent a strong mental model.

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

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

The description is concise, front-loaded with the core action and use cases, then adds necessary security context. Every sentence serves a purpose without redundancy. It is well-structured and easy to scan.

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

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

Despite lacking an output schema, the description explains the return value and handling, covers usage context, and mentions implementation details. Combined with a fully documented parameter schema, the tool is complete enough for an 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%, so the baseline is 3. The description does not add parameter-level semantics beyond the schema, but it does clarify the return value's nature, which indirectly informs what the 'element' should be. The schema itself is sufficient for the three parameters.

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

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

The description uses a specific verb and resource: 'Click a Click to copy button on the page and return the value the page wrote to the clipboard.' It clearly distinguishes from siblings by focusing on copy-button UI patterns and explicitly lists examples (Stripe, GitHub PAT, AWS keys), making the tool's 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 says 'Use this for Stripe's ... and any other click to copy UI patterns,' giving clear when-to-use context. It does not explicitly name alternative tools like browser_click for non-copy interactions, so it stops short of a full when-not/alternatives list, but the guidance is nonetheless clear.

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

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

With no annotations, the description carries full burden. It discloses indirect eval, global scope access (window/document), persistent side effects, JSON-serializability requirement, and the 10KB result cap. This is rich behavioral context beyond what any structured field would provide.

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

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

The description is three dense, front-loaded sentences. The first sentence states the core function, the second explains when to use it, and the third covers technical constraints and safety. Every sentence earns its place without redundancy.

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

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

For a powerful and potentially dangerous tool, the description covers purpose, use case, execution model, constraints, and safety. It lacks explicit error-handling details, but given no output schema and no annotations, it provides sufficient context for the 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% for both parameters, providing a solid baseline (3). The description adds further meaning by detailing the execution environment (indirect eval, global scope, side effects persist) and result constraints, enriching the semantics of the 'expression' parameter.

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

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

The description clearly states the tool runs arbitrary JavaScript in the page's main frame context and returns a JSON-serializable result. It also positions itself as an escape hatch for ARIA snapshot limitations, effectively distinguishing it from sibling 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?

The description explicitly tells when to use the tool: when ARIA snapshots cannot introspect React/Vue state, computed styles, custom data attributes, third-party widget internals, or hidden DOM. It also warns about persistent side effects, implying safer alternatives for ordinary interactions.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It reveals the operation is read-only ('Extract'), specifies the return format ('plain string with whitespace normalized'), and notes a performance trait ('Cheaper than a full snapshot'). However, it does not describe behavior for invalid refs or when the element is not found, which would be useful but is a minor gap for a read operation.

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

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

The description is compact and front-loaded: the first sentence presents the core action and object, followed by the efficiency rationale, return behavior, and use-case examples. Every sentence contributes information without redundancy, making it efficient and well-structured.

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

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

For a simple read tool, the description integrates purpose, usage guidance, return behavior, and performance context. The schema covers all parameters, and the description states the output format (plain string) even without an output schema. It is sufficiently complete for an agent to select and invoke the tool correctly among its siblings.

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 describes all three parameters (ref, tabId, element) with details, achieving 100% coverage. The tool description adds minimal parameter-specific semantics, only reinforcing that the element is selected 'by ref.' Since the schema already handles parameter meaning, 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 states the exact operation: 'Extract the `textContent` of a single element by ref.' It uses a specific verb and target, and distinguishes itself from the full snapshot by noting it is 'Cheaper than a full snapshot' and returns only one element's text. This clearly differentiates it from sibling tools like browser_snapshot or browser_get_attribute.

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

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

Explicitly states when to use this tool ('when you just need the visible text of one element'), gives concrete use cases ('grab a heading, a status message, or a single field's value'), and contrasts it with the alternative of taking a full snapshot at higher cost. This provides clear selection guidance.

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

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

With no annotations, the description carries the full burden. It clearly communicates the read-only nature ('Read'), the return behavior (string, empty string if not set), and performance characteristics (cheaper than snapshot). It doesn't explicitly state it has no side effects, but 'Read' strongly implies that.

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 tight sentences: purpose, examples, and return/performance note. Every sentence adds useful information, with no filler or redundancy.

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

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

For a simple read-only tool, the description adequately covers its purpose, usage, and output. It doesn't address error cases like invalid references, but that's acceptable given the tool's simplicity and the schema's clarity. The absence of an output schema is compensated by the return type explanation.

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

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

Schema coverage is 100% with all parameters already described. The description adds value by giving practical examples for the 'attr' parameter and explaining the return behavior for unset attributes, enriching 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 reads a single HTML attribute from a snapshot-referenced element. It differentiates itself from siblings by noting it's 'cheaper and more precise than a full snapshot', making its unique value distinct.

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

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

Provides explicit usage context with concrete examples (href for links, value for inputs, aria-label for accessibility) and implies the alternative scenario: use this instead of a full snapshot when only one value is needed. This gives clear guidance on when to choose the tool.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure, but it simply restates the operation. It does not mention return format, whether logs are cleared, or the scope (active tab vs. all tabs), leaving the agent without important 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, concise sentence with no filler. It is front-loaded with the verb and object, making it easy to parse quickly.

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

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

The tool is simple with one optional parameter and no output schema, so some minimalism is acceptable. However, the description does not mention what the returned console logs look like or whether they are filtered by tab, which could leave the agent uncertain. It is minimally viable but not rich.

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 single optional parameter 'tabId' with a clear description of active-tab fallback and reference to browser_list_tabs. The description itself adds no parameter-level detail, so it receives the baseline score for high schema coverage.

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

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

The description uses a specific verb ('Get') and resource ('console logs'), making the tool's function immediately clear. It also distinguishes itself from sibling browser tools, none of which explicitly target console log retrieval.

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 offers no guidance on when to use this tool versus alternatives like browser_evaluate or browser_get_attribute. There is no mention of appropriate contexts, exclusions, or prerequisites.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action. It does not mention edge cases like missing history, side effects, or what happens after going back.

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, direct sentence with no unnecessary words. It is appropriately sized for the simple purpose.

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

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

The description is incomplete for a tool with no output schema and an optional tabId parameter. It does not explain the result of the action or how the tabId affects behavior, leaving significant context unaddressed.

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

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

The schema already fully documents the tabId parameter (100% coverage). The description adds no additional parameter semantics, so the baseline score of 3 applies.

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 'Go back to the previous page' uses a specific verb and resource, clearly distinguishing it from siblings like browser_go_forward and browser_navigate.

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. It does not mention browser_go_forward, browser_navigate, or any context about browser history.

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 the action, with no mention of side effects, what happens if there is no forward history, or how tabId routing works. The behavior is underexplained for a navigation-triggering tool.

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

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

The description is a single seven-word sentence with zero wasted words. It is front-loaded and perfectly sized for the simple action it describes, though it could have added more value without becoming 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 the tool's simplicity, the description is minimal, but it lacks essential context such as when forward navigation is applicable, behavior at the end of history, and differentiation from sibling tools. The schema covers the parameter but not the operational context, making the description 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 already has 100% coverage for the sole tabId parameter, including guidance to use browser_list_tabs. The description adds nothing 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 'Go forward to the next page' clearly states the action (go forward) and the resource (next page). It is not a tautology and inherently distinguishes from the sibling tool browser_go_back by direction, though it does not explicitly refer to browsing history or name alternatives.

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 like browser_navigate or browser_go_back. There is no mention of prerequisites, when forward navigation is applicable, or conditions under which this tool should be preferred.

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 simply states 'Hover over element on page' without explaining that this moves the mouse cursor, may trigger hover/JavaScript events, or requires a page snapshot reference. The behavioral impact is not disclosed beyond the tautological action.

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

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

The description is a single, concise sentence with no filler. It front-loads the primary action clearly, though it omits behavioral context that other dimensions require.

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

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

For a simple action tool without an output schema and without annotations, the description is minimal but not wholly inadequate. However, it does not explain return behavior, prerequisites (e.g., need for a snapshot), or potential side effects, which the absence of annotations makes necessary.

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

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

Schema descriptions cover all three parameters (element, ref, tabId) at 100% coverage, so the description need not add parameter meaning. The description adds no semantic detail beyond the schema, leaving the baseline score of 3 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 a specific verb ('Hover') and resource ('element on page'), clearly distinguishing it from siblings like browser_click or browser_type. The intent is immediately obvious and unambiguous.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions. The only implied usage is that hovering is the desired action, which is evident from the name itself.

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 states the output fields (tabId, label, URL, title, active tab) and the verb 'List' implies a non-mutating operation. This is sufficient for a read-only listing tool, though it does not explicitly declare 'read-only' or discuss error conditions.

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 with no superfluous words. The first sentence states the core function, and the second sentence provides output details and usage context. Every word earns its place, making it highly concise and well-structured.

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

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

This is a simple tool with no parameters and no output schema. The description covers purpose, output fields, and usage context, which is complete for an agent to decide when and how to use it. The lack of an output schema is mitigated by listing the returned fields directly in the description.

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 zero parameters, so the baseline per the rubric is 4. The description does not need to explain parameters, and the schema coverage is effectively 100% since there are no parameters. No additional semantic information is 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 opens with a specific verb and resource: 'List all browser tabs bound to this agent.' This clearly states what the tool does and inherently distinguishes it from sibling tools, which are all actions (close, navigate, click, etc.) rather than listing operations. The mention of returned fields reinforces the 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 provides explicit guidance: 'Use this to discover what's available before issuing tool calls that need a specific tab.' This tells the agent when to invoke the tool, which is a clear context. However, it does not explicitly mention alternatives or when-not-to-use scenarios, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Navigate to a URL' is essentially a restatement of the tool name and provides no details about page load behavior, tab routing, failure handling, or side effects. It exceeds the minimal transparency seen in 'Process' descriptions.

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

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

The description is extremely brief and under-specified. While it contains no wasted words, it does not earn its place by providing sufficient information for a navigation tool. The three-word sentence lacks the balance of conciseness and informativeness seen in higher-scoring examples.

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 navigation tool with 2 parameters and no output schema, the description is incomplete. It omits mention of tab targeting, waits for page load, error behavior, and relationship to sibling tools. The schema helps, but the description alone does not give an agent enough context 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 coverage is 100%: both 'url' and 'tabId' are described in the input schema, including optional behavior and reference to browser_list_tabs. The description adds no extra parameter semantics, so the baseline of 3 applies.

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 'Navigate' and resource 'URL', clearly indicating the primary function. It distinguishes from sibling tools like browser_close_tab or browser_click, though it doesn't explicitly differentiate from related navigation tools like browser_open_tab or browser_go_back/forward.

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. The input schema mentions tabId and references browser_list_tabs, but the description itself offers no context or exclusions. Agents receive no situational cues for selecting this over other browser navigation 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 provided, the description carries the full burden of behavioral disclosure. It discloses key side effects: the tab is bound to the agent, set as the active tab, and optionally navigates to a URL. It also explains the label's role in subsequent calls. While it doesn't cover edge cases like invalid URLs or tab management on agent termination, it provides substantial transparency for a simple open-tab operation.

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

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

The description is concise and well-structured, consisting of two sentences that front-load the core purpose. Every sentence adds value: the first defines the action, and the second explains parameters and the active-tab side effect. No fluff or redundancy.

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

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

For a tool with two optional parameters and no output schema, the description covers the essential aspects: what it does, how parameters behave, and immediate side effects. It could explicitly state what happens when no URL is provided (e.g., opens a blank tab), but this is implied. The description is adequate for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%: both 'url' and 'label' have detailed descriptions in the schema. The tool description adds some context beyond the schema, such as the label being used by the LLM to refer to the tab in subsequent calls, and the URL navigating after open. However, this is minor additional meaning; the schema already does the heavy lifting.

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

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

The description clearly states the tool's action: 'Open a new browser tab and bind it to this agent.' It specifies the resource (browser tab) and the binding behavior, which distinguishes it from sibling tools like browser_close_tab or browser_navigate. The additional note about setting the tab as active further clarifies its unique role.

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 for when to use this tool: when a new tab needs to be opened and bound to the agent. It explains optional URL and label parameters, implying use cases. However, it does not explicitly name alternatives or state when not to use it (e.g., when an existing tab should be navigated instead).

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

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

With no annotations, the description carries the full burden. It discloses the synthetic paste event (clipboardData.setData + 'insertFromPaste'), focus behavior, and controlled-input compatibility. It omits failure modes and permission nuances, but provides substantial behavioral detail beyond the name.

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

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

Five sentences, each earning its place: purpose, ref behavior, counterpart workflow, event mechanism, and concrete use cases. Front-loaded and free of fluff.

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

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

Given no output schema and no annotations, the description covers purpose, behavior, use cases, and integration with the copy tool. It leaves tabId routing and the element permission requirement to the schema, which is acceptable, though it could mention potential failure scenarios.

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

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

Schema coverage is 100%, so baseline is 3. The description adds little beyond the schema: it restates ref focus behavior and text purpose but does not elaborate on tabId or element semantics. It paraphrases rather than adds meaning over 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 opens with a specific verb+resource+scope: 'Paste text into a focused element on the page.' It clearly distinguishes itself from copy via 'Counterpart to browser_copy_to_clipboard', but does not explicitly contrast with browser_type or browser_press_key, so sibling differentiation is limited.

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 use cases ('Use for Stripe webhook secret fields, generated API key fields, or any text you need to push into a form') and a copy-then-paste workflow. However, it does not state when to prefer this over browser_type or other input tools, nor does it mention 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 full behavioral disclosure burden, but it merely states the action without revealing any side effects, such as keydown/keyup behavior, target element requirements, or impact on page state. This is a significant gap for a tool that simulates user input.

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, compact sentence with no superfluous words. It is appropriately sized for the simplicity of the action, and every word contributes to conveying the primary function.

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

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

Despite the schema covering parameters, the description lacks crucial context for an agent: it does not mention the optional tabId behavior (even though the schema does), nor any return value or side effects. For a tool with no annotations and no output schema, this level of under-specification leaves the agent with an incomplete picture.

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 provides descriptions for both parameters, covering 100% of them. The description adds no extra parameter meaning, so the baseline score of 3 is appropriate since the schema already handles parameter semantics effectively.

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

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

The description clearly states the verb 'Press' and the resource 'a key on the keyboard', making the core action obvious. It does not explicitly distinguish from sibling tools like browser_type, but the specific mention of keyboard key press separates it adequately from clicking or typing text.

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 such as browser_type or browser_click. The description does not mention scenarios, prerequisites (e.g., focused element), or exclusion cases, leaving the agent without decision support.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the label affects how the LLM refers to the tab and appears in browser_list_tabs output, giving important behavioral context beyond the schema. It does not mention reversibility or permissions, but for a simple rename operation, this is adequate.

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

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

Two concise sentences, front-loaded with the action, and every word adds value. No fluff or repetition.

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

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

For a simple 2-parameter tool with no output schema and no annotations, the description is complete. It explains the tool's purpose, the label's significance, and its effect on output. No additional details are necessary.

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 adds meaning by explaining that the label is 'human-readable' and used by the LLM and list output, clarifying the semantic purpose of the 'label' parameter beyond the schema's 'New label for the tab'.

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 ('Set a human-readable label') and the resource ('a bound tab'). It distinguishes itself from sibling tools like browser_close_tab or browser_set_active_tab by focusing on labeling, and mentions the label's role in conversation and list output.

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 clear context on when to use this tool: when you want to assign a human-readable label to a tab for LLM reference and list output. It does not explicitly name alternatives or exclusions, but the context is sufficient for appropriate 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 carries full burden for behavioral disclosure. It states only that it takes a screenshot, but does not disclose return format, whether it captures viewport or full page, or any side effects. This is minimal and leaves the agent guessing about the tool's 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, succinct sentence with no redundant wording. It earns its place without extra fluff.

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

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

For a simple tool with full schema coverage, the description is minimally viable. However, it lacks context about output behavior and does not clarify differences from sibling tools like browser_snapshot, so completeness is only average.

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

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

The schema provides a full description of the optional tabId parameter, covering 100% of parameters. The description adds no additional meaning, so 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 uses a specific verb ('Take') and resource ('screenshot of the current page'), clearly indicating the tool's purpose. It distinguishes from the sibling tool browser_snapshot, which implies capturing DOM state rather than visual pixels.

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. The description does not mention browser_snapshot or other browser tools, leaving the agent without context for selection.

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

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

With no annotations provided, the description carries the full burden. It merely restates the tool name; it does not disclose that it operates on snapshot references, that it may trigger change events, or that permission may be required. There is no added behavioral context.

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

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

The description is a single, concise sentence that is front-loaded and directly states the tool's purpose. Every word earns its place; there is no waste.

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 browser automation tool with no annotations and no output schema, the description is severely lacking. It does not explain how elements are identified (ref), what 'values' means, whether multiple selection is supported, or any side effects. The tool is much more complex than the description suggests.

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 description does not need to add parameter details. It adds nothing beyond the schema, which is acceptable but not enriching. The baseline of 3 is appropriate since the schema handles semantics.

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

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

The description clearly states the action ('Select') and the resource ('an option in a dropdown'), which is specific enough to distinguish from sibling tools like browser_click or browser_type. It could explicitly mention 'HTML select element' or 'multiple values', but it is still 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. The description does not mention that it is for native dropdowns, how it relates to clicking, or any preconditions like having a snapshot.

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

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

With no annotations provided, the description carries the full burden. It discloses a key behavioral trait—that tool calls not specifying a tabId route to the active tab—which is beyond the name and schema. While it doesn't elaborate on side effects (like state changes to the previous tab), this is a simple setter and the core behavior is adequately disclosed.

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 long, direct, and front-loaded. The first sentence states the core action, and the second explains the routing implication. No filler or redundant content, every sentence earns its place.

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

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

For a simple one-parameter tool, the description is complete. It explains what the tool does, the effect on other tool calls, and the intended use case. The schema provides the remaining parameter detail, and no output schema is needed. There are no major gaps in 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 description coverage is 100%, so the baseline is 3. The description does not add significant meaning about the tabId parameter beyond what the schema already states. It implies the parameter's role in routing, but the schema already describes it as 'Tab ID to make active.' No extra nuance is provided.

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 with a specific verb and resource: 'Set which bound tab is the agent's active tab.' It also distinguishes itself from sibling tools by explaining the routing behavior (calls without tabId go to the active tab), which differentiates it from tab-management siblings like browser_open_tab or browser_list_tabs.

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 for when to use the tool: 'Use this to switch the agent's focus between bound tabs.' It also explains the effect on other tool calls. However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of the top 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?

With no annotations provided, the description carries the full burden. It discloses that the tool captures a snapshot and lists bound tabs, implying it is a read-only operation, but does not explicitly state safety characteristics or potential side effects. It provides useful behavioral context (e.g., using tabId on subsequent calls) but lacks explicit non-destructive statements or permission requirements.

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 concise sentences, front-loaded with the tool's core purpose. Every sentence contributes meaningful information without fluff or repetition of schema 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?

Given the tool's simplicity (one optional param, no output schema) and the absence of annotations, the description sufficiently explains what the tool returns (element references and tab list) and how it fits into the broader workflow. It doesn't enumerate return format details, but the purpose and key behaviors are covered. Minor gap: it doesn't explicitly state that the snapshot reflects the current page state, but that is implied.

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 already provides 100% coverage for the single 'tabId' parameter, including its optionality and how to see available IDs. The description adds a small contextual clue about using tabId on subsequent calls, but this does not significantly go 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 uses a specific verb ('capture') and resource ('accessibility snapshot of the current page'), clearly stating what the tool does. It further distinguishes itself from siblings by highlighting its dual purpose: providing element references for interaction and listing all bound tabs.

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

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

The description gives clear context on when to use the tool ('getting references to elements to interact with') and explains how the tab listing helps with tab selection. However, it does not explicitly mention when not to use it or name alternative tools, such as browser_list_tabs for tabs or browser_extract_text for text extraction, which would strengthen the 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, and the description only says 'Type text into editable element'. It fails to disclose whether text replaces existing content, how focus is handled, whether the element must already be editable, or what the submit option does. This is a minimal statement with no behavioral depth.

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, which is concise and front-loaded. However, it is under-specified for a tool with 5 parameters and complex browser context, so it is not appropriately sized for 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?

With no annotations and no output schema, the description carries the full contextual burden. It doesn't explain tab targeting, permissions, or return behavior, and it's too brief to give the agent enough context for confident selection and invocation. It's not completely empty, but it's clearly inadequate.

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% for all 5 parameters, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions, but it also doesn't need to since the schema already covers them.

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 'type' and the resource 'text into editable element', which communicates the core action. However, it doesn't differentiate this tool from siblings like browser_paste_text or browser_press_key, so it falls 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?

The description provides no guidance on when to use this tool versus alternatives such as browser_paste_text or browser_press_key. There are no usage contexts, prerequisites, or exclusions mentioned, leaving the agent to infer appropriateness.

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 but only states the basic function. It does not disclose that the wait is blocking, whether it returns a value, or how invalid inputs are handled. The description essentially restates the schema parameter description, adding no behavioral context.

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

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

The description is a single, front-loaded sentence that conveys the essential information without any fluff. It is appropriately sized for a simple 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?

The tool is simple with one well-described parameter, so the description covers the core functionality. However, it lacks details about return behavior, potential blocking nature, and differentiation from browser_wait_for_text. These gaps prevent a higher score.

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 already has 100% coverage with a clear description for the single 'time' parameter ('The time to wait in seconds'). The tool description adds no additional parameter semantics, 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 action ('Wait') and the target ('time in seconds'), making the tool's purpose unmistakable. It also distinguishes from sibling tools like browser_wait_for_text by specifying a fixed time delay rather than waiting for a condition.

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. While the tool name and description imply a time-based wait, there is no explicit mention of browser_wait_for_text or other context, leaving the agent to infer usage.

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

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

Despite no annotations, the description discloses key behaviors: polling every 500ms, returning a fresh ARIA snapshot, and returning an error with current page text length on timeout. This gives the agent a complete picture of side effects and failure modes.

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

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

The description is compact and front-loaded, delivering purpose, usage, behavior, and error handling in four sentences with no redundant content. Every sentence adds useful 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?

For a tool with no output schema, the description explains the return value (ARIA snapshot), polling behavior, timeout error handling, and parameter tuning guidance. It is fully self-contained and leaves no critical 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?

While the schema covers 100% of parameters, the description adds valuable semantics: text is whitespace-normalized, tabId defaults to the agent's active tab, and timeout suggests 5-10s for fast SPAs. These details go beyond the schema descriptions.

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

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

The description opens with a specific verb and resource: "Wait for a specific text to appear anywhere in the page DOM (case-insensitive substring match)." It clearly distinguishes from the sibling browser_wait by stating it "Replaces blind browser_wait(time) calls."

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 usage context: "Use after clicking a submit button, or to wait for a Stripe dashboard to finish loading." It also names the alternative tool (browser_wait) and explains when to prefer this tool over that one.

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