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, and it reveals almost nothing. It does not state whether the tool mutates page state, what side effects occur, what limitations apply, or how the step is decided and executed. This is critically insufficient for a tool that likely performs arbitrary browser actions.

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

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

The description is short and front-loaded, but it is under-specified rather than concisely informative. One vague sentence does not earn its place because it lacks the detail necessary for correct use of the 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 absence of annotations, output schema, and parameter descriptions, plus a large set of siblings, the overall context is severely incomplete. The description provides no information about return behavior, side effects, parameter semantics, or when this tool should be selected, making it impossible to invoke correctly with confidence.

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 0%, yet the description does not compensate by explaining either parameter. 'instruction' is echoed from the schema without additional meaning, and 'values' is entirely unexplained. An agent cannot reliably know what to provide for 'values' or what formats the instruction may take.

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 'Take one decided step towards an instruction on the current page' is vague and does not identify a concrete action or resource. It restates the generic act concept without specifying what kind of step (navigation, input, selection, etc.) is taken, and it does not distinguish this tool from the many 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?

No guidance is provided about when to use browser_act versus alternatives like browser_click, browser_type, or browser_run. The phrase 'towards an instruction' implies high-level task execution, but there is no explicit context, prerequisites, or exclusion criteria.

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 states what is clicked but does not mention side effects such as navigation, event firing, or invalid refs, and no auth/state changes are 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?

A single, front-loaded sentence communicates the action, target, and identifier with no filler or redundant detail.

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 core action and prerequisite are present. Missing details about ref provenance, side effects, and alternative interactions keep it from being fully complete.

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

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

Since schema description coverage is 0%, the description must compensate; it does minimally by clarifying that the 'ref' belongs to an observed element. However, it does not explain how to obtain the ref or its expected format.

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 core action ('Click') and the specific resource ('one observed element'), identified by its ref. This clearly distinguishes it from generic browser commands, though it does not explicitly differentiate it from siblings like browser_act.

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

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

The phrase 'observed element by its ref' implies the tool is for clicking elements previously returned by an observation step, providing a precondition. However, it offers no explicit when-to-use or when-not-to-use guidance and no alternatives.

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

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

No annotations are present, so the description carries the full burden. It discloses that the browser session is closed, which implies a destructive action, but does not detail consequences like losing unsaved state or invalidating other tool calls. For a simple close operation, this is adequate but not rich.

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?

A single, direct sentence with no filler. It is front-loaded and 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 zero-parameter tool with no output schema, the description is sufficient for an agent to understand its purpose. It could mention return behavior (e.g., success/failure), but this is not critical for a close operation. The description is complete enough.

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 schema is empty with 100% coverage. No parameter information is needed, and the description does not need to compensate for missing parameter docs. Baseline of 4 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 a clear verb ('close') and resource ('browser session held by this server'). It is unambiguous and distinguishes itself from siblings like browser_open or browser_act, which perform other actions.

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 does not provide explicit when-to-use guidance or mention alternatives. While it is obvious this is a cleanup operation, there is no context about when it should be called (e.g., after finishing all browsing) or what happens if called prematurely. It is minimally acceptable but lacks proactive routing.

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 burden. It discloses that the tool reads from the DOM and can return categorized structured data, which implies a non-mutating extraction. However, it does not describe response shape, limits, or behavior on dynamic or incomplete page content.

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?

A single front-loaded sentence with no filler. 'Pull structured page data from the DOM' communicates the core action, and the colon-delimited list adds helpful mode variety without bloat.

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 output schema and no annotations, the description should explain return values and exact accepted modes. It lists mode-like categories but omits details such as what 'main' returns, whether the output is JSON/text, and whether extraction waits for page readiness. This leaves meaningful gaps for an agent invoking the tool.

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

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

The schema has only a bare 'mode' string with no enum or description (0% coverage). The description compensates by listing candidate modes (text, elements, links, tables, main), but it does not explicitly define them or confirm they are valid values for the mode 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 uses a specific verb ('Pull') and resource ('structured page data from the DOM') and enumerates content categories: text, elements, links, tables, or main. It is not explicitly differentiated from browser_observe/browser_search, but the DOM/structured extraction framing gives clear 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?

There is no guidance on when to use browser_extract versus siblings like browser_observe or browser_search, nor any exclusions. The description solely states what it does, leaving selection entirely to inference.

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 carry the burden of behavioral disclosure. It only states the action and result but does not disclose whether it is read-only, what happens if no page is loaded, or any side effects. The implicit 'observe' suggests non-destructive, but this is not explicit. The description lacks transparency about 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, efficient sentence with no unnecessary words. It front-loads the action and resource. However, it is too brief, bordering on under-specification, but structurally it is concise and not 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 (one optional parameter, no annotations, no output schema), the description should provide enough information for correct invocation. It does not explain what 'observed controls' means, does not describe the output format, and does not clarify the max_elements parameter. It is incomplete for an agent to use effectively.

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 one parameter (max_elements) with 0% schema description coverage. The description does not mention this parameter at all, so the agent cannot infer its purpose or how to use it. The description fails to compensate for the missing schema documentation, leaving the parameter's meaning entirely ambiguous.

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 a specific action ('List') and a resource ('observed controls and the visible text of the current page'). It distinguishes itself from siblings like browser_search and browser_extract by specifying what it returns, though it does not explicitly name alternatives. This meets the 'clear but no sibling differentiation' criterion.

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 like browser_extract or browser_search. It does not mention contexts where this tool is preferred, nor does it state exclusions or prerequisites. No usage context is given.

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 disclosing behavior. It mentions opening a URL and summarizing the page, but does not disclose side effects such as whether the current page is replaced or a new tab is opened, whether navigation is persistent, or any potential errors (e.g., invalid URLs). The shared-session mention is a useful detail but insufficient for full transparency.

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

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

The description is a single, efficient sentence that front-loads the core action ('Open a URL') and adds the summarization behavior. Every word contributes meaning with no redundancy or filler.

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 parameter, so the description covers the basic action and output (summary). However, it lacks usage guidance and does not elaborate on return format or failure modes. Given the lack of an output schema, the description should have clarified what the summary looks like, but it is adequate for a basic tool.

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

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

The schema provides only the parameter name 'url' with type string and no description, yielding 0% schema coverage. The description adds little beyond restating 'URL' — it does not specify expected formats (e.g., http/https), whether relative paths are allowed, or any constraints. Since the description must compensate for low schema coverage, this is a notable gap.

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 a specific verb ('open') and resource ('URL'), and clarifies it operates within the 'shared browser session' and also summarizes the page. This distinguishes it from siblings like browser_search (which searches) or browser_observe (which observes), making its 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 like browser_act, browser_search, or browser_observe. There are no exclusions, prerequisites, or conditions for selection, leaving the agent to infer appropriate usage from the name and description alone.

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 present, so the description bears full responsibility. It states the keys but doesn't disclose side effects, required focus, or error behavior on invalid keys. It implies only these three keys are valid, which is helpful, but lacks depth. The description does not contradict any annotations because none exist.

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

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

A single sentence with no redundancy. The action and allowed keys are front-loaded. This is an appropriate length 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?

Given the tool's simplicity and one parameter, the description covers the allowed keys but omits context such as whether the press applies to the current page, focus requirements, or outcome. No output schema is present, so return behavior is undefined. For a key press action, this may be insufficient for an agent to use it correctly without additional assumptions.

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 has zero description coverage, so the description must explain the 'key' parameter. It lists the allowed values (Enter, Escape, Tab), which is essential and goes beyond the schema. However, it doesn't explicitly state that other values are invalid or provide format details. This adds meaning but could be more explicit.

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 a clear action (press) and specific keys (Enter, Escape, Tab), making its purpose unambiguous. It distinguishes from siblings like browser_click or browser_type by focusing on keyboard shortcuts. However, it doesn't explicitly contrast with siblings, so a 4 is appropriate.

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 doesn't mention that this is for special keys rather than text input (browser_type) or that it should be used after focusing an element. No exclusions or alternatives are given.

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 disclosing behavior. It reveals the tool may type values, but it does not disclose that the tool will likely navigate, click, wait, or perform multiple autonomous steps, nor does it mention side effects, failure modes, or the meaning of max_steps. This is a significant transparency gap for an autonomous browser-agent 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 two sentences are short and front-loaded with the core purpose, and there is no fluff. However, the description is so terse that it omits important operational details, so its brevity is not fully 'appropriate' for a tool of this complexity.

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

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

The tool is an autonomous, multi-step browser runner with no annotations and no output schema, so the description needs to explain behavior, bounds, and success/failure signals. It only mentions pursuing a goal and supplying typed values, leaving max_steps, return behavior, navigation effects, and error cases entirely 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?

Schema description coverage is 0%, so the description must compensate. It gives weak semantic hints for 'goal' and 'values' ('Supply values for anything that must be typed'), but it does not clarify the expected format of the goal, how values map to fields/inputs, or what max_steps controls. The description adds only minimal meaning beyond the raw parameter names and types.

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 a clear goal-directed action ('Pursue a whole goal on the current page') and 'whole goal' signals this is a higher-level operation than sibling primitive actions like browser_click or browser_type. It does not fully define what 'pursue' entails, but it distinguishes the tool from the surrounding action-level siblings.

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

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

The instruction to 'Supply values for anything that must be typed' gives some practical guidance, and the phrase 'whole goal' implies this is for multi-step tasks rather than single actions. However, it never explicitly says when to prefer browser_run over browser_act or the other siblings, nor does it mention exclusions such as navigation limits or page-load expectations.

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 conveys that the operation is non-mutating ('capture'), scopes it to the current viewport rather than the full page, and specifies the JPEG output format. It does not disclose resolution or encoding details, but for a zero-parameter read-only tool 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?

A single, front-loaded sentence with no filler. Every word adds meaning: capture (action), current viewport (scope), JPEG (format).

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 action with no output schema, the description covers the essential operational facts: what is captured, from where, and in what format. It omits minor details like image dimensions or return mechanism, but nothing critical is missing for invoking 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?

There are no parameters, so the schema is trivially complete and the description need not explain any inputs. The baseline of 4 for zero-parameter tools 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 names a specific verb ('capture'), a precise target ('current viewport'), and an output format ('JPEG'). This distinguishes it from action-oriented siblings like browser_click or browser_type, and from observation tools, because none claim to produce a screenshot.

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

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

No guidance is given about when a screenshot should be preferred over browser_observe or browser_extract, nor any exclusion criteria. The description simply states what it does, leaving the agent to infer when to use it.

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 mentions the step size and direction but omits details like return value, behavior at page boundaries, or whether it scrolls the main viewport or a frame. This is minimal for an unannotated 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?

A single, front-loaded sentence with no wasted words. It delivers the core action and parameter semantics efficiently.

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 one-parameter tool with no output schema, the description covers the essential action and direction. However, it omits expected return behavior and any implicit prerequisites (e.g., page must be open), which could leave the agent uncertain about what to expect.

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 only defines 'direction' as a string with default 'down' and no enum or description. The description adds critical meaning by specifying valid values ('up or down') and the step size ('one viewport step'), which the agent needs to invoke the tool correctly.

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 (scroll), the resource (page), and the scope (one viewport step up or down). It distinguishes this tool from siblings like browser_click or browser_type, which have entirely different purposes.

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, nor any conditions or prerequisites. It simply states what the tool does, leaving the agent to infer when scrolling is appropriate.

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

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

No annotations are provided, so the description carries the full burden. It discloses the workflow (search, read in parallel tabs, rank against goal) but does not mention side effects like opening or leaving browser tabs, whether it requires an existing session, or any state changes. This is a significant gap for a tool that likely manipulates browser state.

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 efficiently conveys the core action. It is concise and avoids fluff. However, it lacks structural elements like explicit use-case context or parameter hints, so it is not perfectly structured for quick agent parsing.

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, no annotations, and three parameters (one undocumented), the description is incomplete. It does not specify what the tool returns, how results are presented, what 'max_pages' controls, or any side effects. An agent would struggle to call this tool correctly without additional documentation.

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

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

Schema description coverage is 0%, so the description must explain parameters. It only hints at the 'goal' parameter ('rank them against the goal') but does not explain 'query' or 'max_pages'. 'max_pages' is especially opaque; its role in controlling the number of results or pages is unstated. The description fails to compensate for the lack of schema documentation.

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 a clear verb ('Search'), a resource ('the web'), and outlines the process ('read the best results in parallel tabs, and rank them against the goal'). It is distinct from sibling tools like browser_click or browser_screenshot, but does not explicitly name or contrast with alternatives, so it falls short of a perfect 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 gives no indication of when to use this tool versus the many sibling browser tools. It does not mention any prerequisites, exclusions, or alternative tools. The agent must infer from the name and description alone, which is insufficient 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 of disclosing behavior. It only says 'select an observed dropdown option' – it doesn't mention that this performs a UI mutation, whether it requires a preceding browser_observe call, or whether it triggers events or changes the page state. It also fails to disclose any constraints like the option needing to be visible or in the DOM.

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?

While the description is short (one sentence), it is under-specified rather than concise. It lacks any structure (e.g., prerequisites, examples, or parameter explanations) that would make it useful. Every word is needed but critical information is missing, so the brevity is a liability, not an asset.

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 is part of a complex browser automation suite with 14 siblings, no output schema, and no annotations, the description is far from complete. It doesn't explain how to obtain the 'ref', what happens after selection, or any error conditions. The agent cannot reliably call this tool correctly based on the current definition.

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 has zero description coverage, so the description must explain what 'ref' and 'option' mean. It only hints that 'option' can be a value or label, but gives no explanation of 'ref' – presumably a reference to the dropdown element obtained from observation, but this is never stated. This leaves the agent guessing about the required format and source of both 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 clearly states a specific verb ('select') and a resource ('observed dropdown option'), and specifies that it works by value or label. This distinguishes it from siblings like browser_click (which clicks any element) and browser_type (which types text). However, it doesn't explicitly contrast with browser_act, which might be a generic action tool, so it's not a perfect 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?

There is no guidance on when to use this tool versus alternatives. It doesn't state that the dropdown must be observed first, nor does it explain when to prefer this over browser_click or browser_type. The need for prior observation is implied by 'observed' but never made explicit, and no exclusions or alternative routing are 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, the description carries the full burden of explaining behavior, but it only states that text is typed. It does not disclose whether existing field content is replaced or appended, whether events fire, whether the field must be visible/focused, or what side effects occur.

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 with no filler. It is concise, though the brevity borders on under-specification.

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 action, the description omits practical details an agent needs: what the tool returns, failure conditions, whether the ref comes from a prior observe call, and how typing interacts with the page state. The lack of annotations and output schema makes these omissions more significant.

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 0%, so the description must compensate. It clarifies that 'ref' identifies the field and 'text' is what gets typed, but it doesn't explain how to obtain a valid ref, what formats are accepted for text, or any constraints such as maximum length or special characters.

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 names a specific action ('Type text') and a specific target ('one observed field by its ref'), which is clear and differentiates it from click/select/press siblings. It doesn't elaborate on what counts as an 'observed field,' but the core operation is 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 gives no guidance about when to use this tool versus browser_press, browser_act, or browser_click, and no mention of prerequisites like obtaining a ref from browser_observe. Usage context is only implied by the action itself, not 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?

No annotations are provided, so the description must disclose behavior. It says 'wait a moment' but gives no specifics on duration, conditions (e.g., network idle), timeouts, or what 'observe again' returns. The behavior is vague and under-specified.

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 efficient for a simple tool. It front-loads the key action ('wait') and includes the follow-up ('observe again'). It's not over-verbose, but it could be slightly more informative without losing 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's simplicity (no params, no output schema), the description is minimally acceptable. However, it lacks details like the default wait duration, whether it waits for a specific condition, and what the observation returns. An agent might not know what to expect when calling 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, so the baseline is 4. The description doesn't need to explain parameters, and the schema confirms there are none. No additional value needed here.

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 a clear action: wait and then observe again. It distinguishes itself from sibling tools like browser_observe by implying a preceding wait, but it doesn't explicitly differentiate from other wait-like actions 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 on when to use this tool versus other browser actions. It doesn't mention scenarios where waiting is needed (e.g., page load, element appearance) or suggest alternatives. The description is purely functional with no contextual usage hints.

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