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

Annotations already convey readOnly=false, openWorld=true, idempotent=false, and destructive=false, so the description need not restate those. It adds some useful behavioral context by saying 'one decided step' and 'current page,' but it still does not disclose what types of actions may occur, whether navigation or form submission may happen, or what the tool returns.

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

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

The description is a single short sentence with no filler, and the key idea 'one decided step' is front-loaded. It is concise, though the phrasing 'towards an instruction' is slightly awkward and the sentence carries less useful content than it could.

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 general browser action tool, this description is not complete enough. It leaves unclear how to phrase instructions, what values means, what observable result the agent can expect, and how browser_act relates to the many specific sibling browser_* tools.

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

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

Schema coverage is 0%, so the description must compensate for missing parameter documentation, but it does not explain the required 'instruction' beyond using the same word. It also says nothing about the optional 'values' object, which is opaque and could represent form values, options, or something else.

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 identifies the action as taking one step toward an instruction on the current page, so it communicates a general purpose rather than being a pure tautology. However, it is vague about what the step concretely does and does not distinguish browser_act from sibling tools like browser_click, browser_type, or browser_scroll.

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_act versus any of the specific sibling tools. The description only implies that the tool executes a single decided step, but it never says how to break down instructions, when a specific sibling should be preferred, or when browser_act should not be used.

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

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

The description adds a behavioral nuance about stale refs and how page_key addresses that, which goes beyond the annotations. However, it doesn't disclose side effects (e.g., navigation, state changes) or error conditions. Annotations already indicate readOnlyHint=false and destructiveHint=false, so the safety profile is partially covered, but the description adds limited 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 two sentences with no fluff, front-loading the action and the key parameter. 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 click tool, the description covers the essentials: what to click and how to avoid stale refs. It doesn't mention return values (no output schema) or failure modes, but given the tool's simplicity and the presence of sibling tools like browser_observe, it's reasonably complete. A mention of when not to use it (e.g., if you need to run JavaScript) would improve 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 schema provides no descriptions (0% coverage), so the description must compensate. It explains 'ref' as referring to an observed element and clarifies the purpose of 'page_key' (to refuse stale refs). This adds meaningful context beyond the schema, though it doesn't specify formats or 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 clearly states the action ('Click one observed element') and the required resource ('by its ref'), with a specific verb and resource. It distinguishes itself from siblings like browser_act by focusing on clicking a specific observed element and referencing browser_observe as the source of the ref.

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

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

It gives a hint about when to use the page_key parameter ('Pass the page_key from browser_observe to refuse a stale ref'), but it doesn't explicitly state when to use this tool versus alternatives like browser_act, nor does it provide exclusions or conditions for not using it. The guidance is implied rather than explicit.

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?

Annotations already provide idempotentHint=true and destructiveHint=false. The description adds only the 'held by this server' qualifier, which clarifies scope but does not disclose side effects like releasing resources or invalidating subsequent browser tool calls. Given the simplicity of the operation and annotation coverage, a modest score is appropriate.

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 wasted words. It states the action and scope directly and is immediately understandable. There is no redundancy with the schema or annotations.

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 parameterless, side-effect-simple tool with annotations covering idempotency and destructiveness, the description is fully sufficient. No output schema exists, and none is needed for a close operation. The agent has everything required to invoke it correctly.

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

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

The tool has zero parameters and the schema is trivially complete. Per the baseline rule for 0-parameter tools, this receives a 4. The description adds nothing about parameters, which is correct since there are none.

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 ('close') and a clear resource ('browser session held by this server'). It distinguishes from all siblings by naming the lifecycle termination operation, opposite of browser_open.

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?

Usage is implied by the purpose: close the session when done with it. However, there is no explicit guidance on when to use it versus alternatives, no mention of timing (e.g., after all browser actions), and no exclusions. It is not misleading, but the agent must infer the appropriate moment.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds minimal behavioral context beyond listing extractable data types; it does not disclose limitations, preconditions, or response format. No contradiction with annotations.

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, front-loaded with the core action and immediately enumerating the extractable types. No wasted words.

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

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

For a simple tool with one parameter and no output schema, the description conveys the general purpose but omits critical details like the fact that it operates on the current page (implied but not stated) and the exact accepted values for 'mode'. An agent might need to infer how to use it correctly, so completeness is adequate but not strong.

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 0% (no description for 'mode'), so the description must compensate. It lists potential values ('text, elements, links, tables or main') which hints at valid modes, but does not explicitly map them to the parameter or clarify defaults. This adds some meaning beyond the schema but not complete clarity.

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 ('Pull structured page data from the DOM') and specifies the resource (DOM) and the types of data (text, elements, links, tables, main). This is specific and reasonably distinct from sibling tools like browser_observe, though it does not explicitly name a sibling or differentiate.

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_observe or browser_search. It does not mention conditions, exclusions, or situations where a sibling would 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the concrete behavior of listing controls and visible text, but does not disclose details like pagination, element limits, or how 'observed controls' are determined. It does not contradict the annotations.

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. Every word contributes to the core meaning, and it is appropriately concise for a simple observation 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?

For a simple tool, the description gives a basic idea of what it returns, but it omits any explanation of the sole parameter max_elements and does not clarify the meaning of 'observed controls'. With no output schema, the description should carry more of the semantic load than it does.

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%, and the description does not mention max_elements at all, so the description does not compensate for the missing schema documentation. The parameter name and type give an indirect clue about its limiting behavior, but the agent gets no explicit semantics or guidance on when to provide it.

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 ('List') and a clear resource ('observed controls and visible text of the current page'), which distinguishes this read-only inspection tool from siblings like browser_click, browser_type, and browser_screenshot. Even without explicitly naming alternatives, the action and scope are 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 implies the tool is for inspecting the current page's controls and text, which is a sensible use case, but it gives no explicit guidance about when to prefer it over siblings like browser_extract, browser_search, or browser_screenshot. No exclusions or alternative conditions are 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?

Annotations already capture open-world and idempotency traits. The description adds meaningful behavioral context by noting the shared browser session and that a named profile keeps its own cookies. It does not contradict the annotations, though it does not detail navigation side effects or page-load 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 two short sentences with no filler. The core action and session context are front-loaded, and the profile/cookie note earns its place as useful additional context.

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

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

For a simple two-parameter navigation tool with annotations covering safety and side-effect class, the description supplies the session and cookie context an agent needs. It omits return-value details, but no output schema exists and the action's result is reasonably self-evident, so this is a minor gap.

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 adds meaning for the 'profile' parameter by explaining cookie isolation, and 'Open a URL' implicitly defines the url parameter. However, it does not provide format, allowed values, or behavior for the required url 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 action ('Open') and the resource ('a URL') and adds that it operates in the shared browser session. This distinguishes it from the interaction-focused sibling tools like click, type, and scroll, though it does not name a sibling explicitly.

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 useful context: use this when you want to open a URL in the shared browser session. However, it does not explicitly contrast it with alternatives such as browser_search or browser_run, nor does it state when not to use it. The usage is implied rather than fully specified.

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?

Annotations are minimal (readOnly false, destructive false, openWorld true) and do not describe side effects. The description adds no behavioral context beyond the action itself—no mention of timing, focus requirements, or what happens after the key press. It does not contradict annotations, but fails to disclose any meaningful 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, front-loaded sentence with zero wasted words. It states the action and the exact keys, making it highly efficient for the agent to parse.

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 conveys the core action. However, it lacks any context about when to use it (e.g., after focusing an element) or potential side effects. The agent must infer the browser context from the name alone, which is a notable gap.

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 0% (no description on the 'key' parameter). The description compensates partially by listing the allowed keys (Enter, Escape, Tab), giving the agent concrete examples. However, it does not clarify whether other keys are accepted, case sensitivity, or formatting, so coverage is incomplete.

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 (press) and the specific keys (Enter, Escape, Tab), distinguishing it from sibling tools like browser_click (mouse) and browser_type (text). It is a specific verb+resource, 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 provides no guidance on when to use this tool versus alternatives. It does not mention any context or exclusion criteria, leaving the agent to infer when pressing a key is appropriate. Sibling tools are not referenced, and no conditions are 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?

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds context about the resume flow and human escalation, which is behavioral. It does not contradict annotations. However, it doesn't elaborate on side effects, success/failure behavior, or page state changes beyond the resume note, so it adds only marginal transparency beyond what annotations 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 two sentences and front-loads the core purpose. It avoids unnecessary words. The second sentence is slightly convoluted with the phrase 'a needs_human escalation returned' but remains efficient. 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 tool that pursues a whole goal with four optional parameters and no output schema, the description is thin. It doesn't explain what happens on success/failure, how max_steps works, error handling, or how it relates to the other browser_* tools. It relies heavily on the annotations for safety context, but the operational behavior is underspecified for an agent to use it confidently in complex scenarios.

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

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

Schema description coverage is 0%, so the description must explain parameters. It references 'goal' implicitly via 'Pursue a whole goal', explains 'values' as 'anything that must be typed', and mentions 'resume' explicitly. It does not mention 'max_steps' at all. The explanations are high-level and don't clarify formats or constraints, so it only partially compensates for the schema's lack of 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 states a clear verb and resource: 'Pursue a whole goal on the current page.' This distinguishes it from the sibling action tools (browser_click, browser_type, etc.) which perform single actions. It's specific and unambiguous.

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

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

The description gives partial usage guidance: it instructs to supply values for typed input and explains the resume mechanism for needs_human escalation. However, it never explicitly states when to use this tool vs the alternative single-action tools, nor does it mention prerequisites or when not to use it. The guidance is useful but incomplete.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral detail (JPEG format, viewport scope) but does not reveal the output form, such as a file path or data URL, which would be helpful for a tool with no output schema.

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 filler; every word earns its place. The action, scope, and format are front-loaded and immediately parseable.

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, annotation-rich, non-destructive tool, this description is nearly complete. The only notable gap is the unspecified return format, but given the low complexity this is a minor omission.

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 schema coverage is 100%, so there is nothing meaningful for the description to add. The 'current viewport' phrase clarifies scope but does not affect parameter usage.

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

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

States an unambiguous action ('Capture'), a clear resource ('the current viewport'), and a concrete output format ('JPEG'). This is specific enough to distinguish it from sibling tools like browser_click or browser_extract without extra context.

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 about when to use this tool versus browser_observe or browser_extract, nor any mention of when it should or should not be used. The description only states what it does and leaves 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?

Annotations already indicate non-read-only, non-idempotent, and non-destructive behavior. The description adds that it scrolls by a viewport step, which is a useful detail. However, it doesn't disclose any side effects like the need for a loaded page or potential changes to focus, so transparency is moderate.

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 action and specifies the scope. Every word contributes to understanding, and there is no unnecessary 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 simple tool with one parameter and no output schema, the description is incomplete. It doesn't specify the exact values for the 'direction' parameter (e.g., 'up', 'down', or other strings), nor any prerequisites like an open page. The agent would need to guess or rely on external knowledge to use it correctly.

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

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

The schema has zero description coverage, leaving the 'direction' parameter undefined. The tool description mentions 'up or down', which suggests the valid values, but it doesn't explicitly map the parameter to these values. This adds some meaning beyond the schema but leaves ambiguity about accepted input 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 clearly states the action: scrolling the page, with a specific scope of 'one viewport step' and direction 'up or down'. This distinguishes it from sibling tools like browser_click or browser_type, which perform different 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention typical use cases (e.g., navigating long pages) or any exclusions (e.g., not for horizontal scrolling). The agent is left to infer its purpose from the name and action 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?

Annotations already provide safety and side-effect hints (readOnlyHint=false, idempotentHint=true, openWorldHint=true, destructiveHint=false). The description adds meaningful behavioral context beyond these: it reads results in parallel tabs and ranks them against the goal. This clarifies that the tool opens tabs and processes results, which is not covered by annotations. No contradictions with annotations.

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

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

The description is a single, concise sentence that front-loads the primary action (search) and includes the main purpose (read and rank). There is zero wasted text, and every word contributes to understanding. This is an exemplary model of 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?

The tool has three parameters and no output schema or parameter descriptions. The description covers the high-level behavior (search, read, rank) but omits details such as what 'best results' means, how max_pages influences the process, and what the return format is. Given the tool's relative simplicity, the description is adequate but not fully complete; an agent would need to infer some details or rely on the parameter names.

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 explains the 'goal' parameter (used for ranking) but leaves 'query' and 'max_pages' undefined. 'max_pages' is particularly ambiguous—it likely controls how many results to read, but the description doesn't say this. The description only partially clarifies parameter semantics, leaving significant gaps.

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

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

The description clearly states the tool's purpose: search the web, read best results in parallel tabs, and rank against a goal. This distinguishes it from sibling tools like browser_act or browser_click, which focus on page interaction rather than search and ranking. The verb 'search' and the resource 'web' are specific and unambiguous.

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

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

The description implies usage for information retrieval and ranking, but does not explicitly mention when to avoid it or use alternatives. The context is clear (search the web), but there are no exclusions or named alternatives. Since the sibling set includes many interaction tools, the description's focus on search inherently suggests the use case, but it doesn't spell out when not 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?

Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds meaningful behavioral context beyond annotations: it refuses stale refs, which is a safety-relevant behavior. It also clarifies that selection is by value or label, which is not in the schema. No contradiction with annotations.

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 sentence that front-loads the core action and includes a critical safety qualifier ('refusing a stale ref'). Every word earns its place; no filler 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?

For a tool with no output schema and sparse parameter documentation, the description covers the core action and one behavioral nuance, but leaves gaps: what a 'ref' is, how the option is matched (exact vs partial), and what happens on failure. Given the tool's moderate complexity and the openWorldHint, a bit more context would help an agent invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that 'option' is a value or label, which adds meaning. However, it does not explain what 'ref' refers to (presumably a reference to an observed dropdown element) or what 'page_key' is for. With 0% schema coverage, the description only partially compensates for the undocumented 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 states a specific verb ('Select') and resource ('dropdown option'), and adds a distinguishing detail: it selects by value or label and refuses stale refs. It is clear enough to differentiate from siblings like browser_click or browser_type, though it doesn't explicitly name a sibling alternative.

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

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

The description implies usage context: use this when you have observed a dropdown option and need to select it, and avoid using it with a stale ref. However, it does not explicitly state when to prefer this over browser_act or browser_click, nor does it describe prerequisites like having observed the dropdown first.

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?

Beyond the annotations, the description discloses a concrete failure mode: it refuses to act if the page has changed since the observation. The annotation set is sparse, so this stated refusal behavior is meaningful; other effects of typing are not described, but the main behavioral caveat is present.

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?

One sentence, front-loaded with the action and object, with the important refusal behavior placed in a dependent clause. Every word contributes to selection or invocation confidence; there is no 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?

For a three-argument browser mutation with no output schema, the description covers the core action and one precondition, but leaves page_key unaddressed and does not state what a successful or refused call returns. It is minimally viable but has clear gaps an agent would have to resolve by trial.

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 zero descriptions and only the titles 'Ref', 'Text', and 'Page Key', so the description must compensate. The description clarifies 'ref' as the identifier of an observed field and 'text' as what to type, but page_key is left completely unexplained, and no format or limits are given. Coverage is too low for the description to carry the full semantic burden.

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 identifies the action ('Type text') and target ('one observed field by its ref'), which conveys the core purpose. It does not explicitly differentiate from sibling tools such as browser_press or browser_run, but the notion of a ref from observation makes the target 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 phrase 'observed field by its ref' implies this tool is used after a browser_observe-like step and that a fresh ref is needed, but there is no explicit when or when-not guidance. No alternative tools are named, so an agent must infer the appropriate selection context from the wording 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds the behavioral trait that the tool pauses and then re-observes, but it leaves the wait duration vague ('a moment'). No contradiction with annotations is present.

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

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

The description is a single short sentence with no filler, and the main action appears immediately. It is appropriately sized for a zero-parameter utility 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?

For a simple zero-parameter, read-only wait-and-observe tool, the description covers the core behavior and implies the result is an observation. It could be more precise about the wait length and whether the output mirrors browser_observe, but these are minor gaps for a tool this simple.

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 no required inputs, so parameter documentation is unnecessary. Schema coverage is vacuously complete, and there is no parameter information the description would need to add.

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 clear action chain: wait a moment, then observe again, which tells the agent the tool introduces a delay and produces a fresh page observation. It is distinguishable from browser_open and browser_close, but it does not explicitly differentiate itself from browser_observe, which also produces observations.

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 browser_wait instead of browser_observe or other siblings, nor does it mention waiting for dynamic content to settle before acting. The agent must infer usage from the tool name and workflow context.

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