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

With no annotations present, the description carries the disclosure burden. It clearly states the core behaviors—filling and submitting a login form—and the credential source, but it does not explain failure behavior, side effects of form submission, or what happens when optional selectors are omitted.

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 well-structured sentence that front-loads the core action. It contains no filler or unnecessary 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?

The description is adequate but incomplete for a tool with 5 parameters and no output schema or annotations. It does not explain the significance of optional selectors, the behavior when submitSelector is missing, or expected outcomes after the submit action.

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 parameters are already individually documented. The description adds high-level purpose but does not clarify how usernameSelector and submitSelector interact with the core behavior, such as whether password-only filling is possible.

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 gives a specific verb and resource: automatically fill and submit a login form using Keychain-stored credentials. This clearly differentiates it from sibling tools like browser_type, keychain_store_credential, and passkey_save_registration.

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 a prerequisite: credentials must already exist in macOS Keychain, and that suggests when this tool applies. However, it gives no explicit when-to-use versus when-not-to guidance and does not mention alternatives such as browser_type or passkey flows.

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 tool uses human-like mouse movement and click delays, which implies it takes time and may be slower than a direct click. However, it does not mention potential side effects like triggering navigation, opening new tabs, or requiring the element to be visible. For a click action, these are useful to know, but the human-like behavior is a notable disclosure that sets expectations.

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

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

The description is a single sentence that is concise and front-loaded with the core action (click an element) followed by the behavioral nuance (human-like movement and delays). No wasted words; it 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 with one parameter and no output schema, the description is adequate. It covers what it does and hints at the human-like behavior. However, it lacks any mention of what happens after the click (e.g., page navigation, waiting for page load) or any prerequisites (e.g., element must be visible/interactable). Given the tool's simplicity, a 3 is appropriate; it's minimally sufficient 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?

Schema coverage is 100%, so the schema fully describes the selector parameter. The description doesn't add additional parameter semantics, but it does mention in the schema example the format of the selector (CSS). Since coverage is high, baseline is 3. The description adds a bit more by implying the selector must target an element that is clickable, but it doesn't go beyond the schema. Given the schema is already thorough, a 4 is justified due to the clear example in the schema and the description's focus on the click behavior.

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

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

The description clearly states the action (click) and the target (an element on the page), and mentions the specific behavior of human-like movement and delays. It distinguishes from siblings like browser_navigate and browser_type by focusing on clicking existing elements. However, it doesn't explicitly differentiate from other element-interaction tools like browser_evaluate or browser_scroll, though those are semantically different enough that the purpose is clear.

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: when you need to click an element on the page. However, it provides no when-not-to-use guidance or mentions alternatives like browser_type for typing or browser_evaluate for programmatic interaction. The human-like clicking nuance suggests it's meant for realistic user simulation, but this is not explicitly tied to use cases like testing or automation that requires stealth. Minimal guidance beyond the core action.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the action flushes session cookies and storage to disk, which is a meaningful side effect beyond the simple name. It does not mention irreversibility or behavior if called multiple times, but for a simple close 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?

The description is a single sentence that front-loads the primary action and then adds a crucial detail (cookie/storage flushing). There is no wasted language, and every word earns its place. It is optimally concise.

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

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

For a zero-parameter tool with no output schema, the description is fully sufficient. It explains what the tool does and a key behavioral nuance. There is no missing information that an agent would need to correctly invoke this 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 tool has zero parameters, so per calibration guidance the baseline is 4. The description adds no parameter-specific details because none exist, and the schema already confirms no inputs. The description appropriately focuses on behavior rather than 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 precise verb ('close') and resource ('browser'), and adds meaningful nuance ('gracefully', 'flush session cookies/storage to disk'). It clearly distinguishes itself from sibling navigation and interaction tools since no other sibling performs a close operation.

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—when the user is done with the browser—and there are no competing close tools. However, it does not explicitly state conditions or alternatives, such as 'use browser_open_interactive_window if you need to keep the session' or any when-not-to-use guidance. Given the absence of alternatives, this is acceptable but not 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?

With no annotations to fall back on, the description must fully disclose behavioral traits. It mentions execution in the active page context and returning a result, but omits critical details: that the script can modify the page (side effects), that the result must be JSON-serializable, that errors may be thrown, and whether execution is synchronous. These gaps are significant for a tool that runs arbitrary code, leaving the agent uncertain about safety and output formatting.

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 and outcome. It contains no filler and is easily parsed. While it could benefit from a note about return value constraints, the current length is appropriate for the tool's simplicity. It is slightly under-specified in terms of structure, but that is a minor point given the brevity.

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 executes arbitrary JavaScript, the description is notably incomplete. It does not explain what happens to non-serializable results (e.g., functions, undefined), whether errors are propagated, or if the script can have persistent effects. Since there is no output schema, the description should cover return-value behavior. The absence of this information makes the tool risky for agents to use correctly, especially in a browser automation 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?

The schema description fully covers the single 'script' parameter with examples (“document.title”, “window.location.href”), so the baseline is 3. The tool description adds little beyond the schema—it restates that the script runs in the page context and that the result is returned, but does not elaborate on how the script's return value is serialized or formatted. Given high schema coverage, the description does not need to duplicate parameter details; it only adds minimal context, so a 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 that this tool executes a custom JavaScript expression in the active page context and returns the result. The verb 'execute' with the resource 'custom JavaScript expression' is specific, and it distinguishes itself from sibling tools like browser_extract_text or browser_click by focusing on arbitrary script evaluation. The purpose is unambiguous even without seeing the schema.

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 that this tool is for running arbitrary JavaScript, which is distinct from higher-level browser actions like clicking, typing, or extracting content. However, it does not explicitly say when to prefer this over alternatives or caution against using it when a more specific tool fits. The guidance is implicit rather than explicit, leaving the agent to infer the intended use case.

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 the output is outer HTML but does not explain behavior for multiple selector matches, no matches, or the fact that the default selector 'body' extracts only the body element rather than the entire page DOM, which conflicts with the description's 'entire page DOM' claim.

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 earns its place but could be slightly more precise about the default selector behavior.

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 adequately conveys the return type (outer HTML). It is incomplete regarding default behavior and edge cases, but the low complexity keeps the gap moderate.

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

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

Schema coverage is 100% and the single parameter already has a clear description ('CSS selector to extract HTML for'). The description adds the 'outer' qualifier and the element-or-page scope, but it does not clarify how the default 'body' selector relates to the 'entire page DOM' claim.

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 ('Extract outer HTML') and a resource ('a specific element or the entire page DOM'), which distinguishes it from sibling browser_extract_text by output type. However, it does not explicitly differentiate itself from siblings, and the phrase 'entire page DOM' is slightly ambiguous given the default selector is 'body'.

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 to use this tool versus browser_extract_text, browser_evaluate, or browser_screenshot. The only implied signal is the word 'HTML', but there is no explicit when-to-use or when-not-to-use instruction.

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

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

Since no annotations exist, the description carries the full burden of behavior disclosure. It states the output is 'cleaned' and includes text, links, and forms, but does not explain how cleaning works, whether scripts/styles/hidden elements are removed, or what the response structure looks like.

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 resource, with no filler. 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?

The tool is simple, but with no output schema and no annotations, the description should cover what the agent can expect back. It lists the content categories (text, links, forms) and signals LLM-readiness, but it leaves the exact return format unstated.

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 single selector parameter is fully documented in the schema with a default and description, so the baseline of 3 applies. The tool description itself adds no additional parameter-level meaning.

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

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

The description uses a specific verb ('Extract') and a specific resource ('cleaned text, links, and forms from the page'), plus a clear purpose ('for LLM reading'). This distinguishes it from the sibling tool browser_extract_html, which presumably returns raw HTML.

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 'for LLM reading' provides clear context on when this tool is appropriate, and 'cleaned' implies a contrast with raw HTML extraction. It does not explicitly name alternatives or exclusions, so it stops 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?

Annotations are absent, so the description carries the full burden. It mentions persistent authentication but does not disclose side effects like page load behavior, potential redirects, or error handling. Some details are implied by the 'waitUntil' parameter, but the description itself offers minimal behavioral insight.

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, compact sentence conveys the essential action and a key feature. No redundant or irrelevant information; perfectly sized for the simplicity 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?

The description is minimal and does not explain return values, error conditions, or whether navigation affects browser state beyond authentication. Given the absence of an output schema and annotations, this leaves some ambiguity for the agent, though the core purpose is clear.

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?

Both parameters (url, waitUntil) are documented in the schema with clear descriptions, achieving 100% coverage. The tool description adds no extra context for parameters, 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 a specific verb ('Navigate') and resource ('stealth browser') with a target URL, and mentions persistent authentication as a distinguishing feature. It is unambiguous and distinct from sibling tools like clicking or typing.

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 explicit guidance on when to use this tool versus alternatives. However, the action is self-explanatory as the primary navigation tool among the siblings, making the intended use implicit. It lacks direct comparisons or conditions.

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 the key trait of opening a visible, non-headless window for user interaction, but does not indicate whether the tool blocks or waits for the user to finish, what it returns, or potential side effects like automation suspending. This is adequate but not comprehensive.

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

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

A single, concise sentence that is front-loaded with the core action and purpose. There is no superfluous information, and every word contributes to understanding.

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

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

For a tool with one optional parameter and no output schema, the description provides enough context for an agent to decide when to invoke it and what it does. It lacks details about post-action behavior (e.g., whether it returns immediately or blocks), but this is a minor gap given the simplicity.

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 single parameter (url) is fully described in the schema, including its default behavior. The description adds no additional parameter-level details beyond the schema, so it meets the baseline for high coverage without adding extra semantic value.

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

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

States a specific verb 'opens' and a specific resource 'non-headless visible Chrome window' with a clear purpose: enabling the user to manually solve a CAPTCHA or complete 2FA. This distinguishes it from siblings like browser_navigate, which likely operate in a headless or automated 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?

The description implies the use case—when manual user intervention is required for CAPTCHA/2FA—and clearly situates it as an alternative to automated navigation. However, it does not explicitly state when not to use it or compare it to other tools, so it misses explicit 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?

The description doesn't contradict annotations (there are none), but it also doesn't add behavioral details beyond what's in the schema. The `fullPage` parameter's effect is partially inferred from its schema description, but the tool's side effects (e.g., whether it scrolls, what it returns) are not specified. Since annotations are absent, this could be more transparent.

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

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

The description is extremely concise and to the point, with no filler or redundant information. It uses a clear structure with a single sentence that directly communicates the tool's 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?

Given the simplicity of the tool (single parameter, no output schema), the description is adequate but leaves some gaps. It doesn't mention what the return value looks like (e.g., image data) or any side effects, but these may be implicitly understood in a browser automation context. With no output schema and no annotations, a bit more detail about the expected outcome would improve completeness.

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

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

The description adds minimal value for parameters since the schema already covers `fullPage` with its description. However, the schema coverage is 100% (1/1 parameter documented), and the description reinforces the parameter's purpose without conflict. The description doesn't add much beyond what's in the schema, but the schema already provides sufficient 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 clearly states the tool's purpose with a specific verb ('capture') and resource ('screenshot of the current page'). It distinguishes itself from other browser actions like navigation, clicking, and typing, though it doesn't explicitly name sibling tools or edge cases like capturing specific elements.

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 implies usage for visual inspection, which provides some contextual guidance. However, it doesn't explicitly state when to use this over alternatives (e.g., browser_extract_html or browser_extract_text), nor does it mention any prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the burden. It does disclose the core behavior (scrolling the viewport up or down) and the scope ('viewport'), but it does not mention whether the scroll is instant or smooth, whether it waits for scrolling to finish, or if any state is affected.

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 with no filler. It front-loads the action and target, and every word contributes to the meaning.

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 scrolling tool with no output schema and no annotations, the core action is clear enough to invoke. However, there are gaps such as no behavioral details, no usage guidance, and no mention of alternatives, leaving the description minimal but not 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?

Schema description coverage is 100%, so the parameters are already well documented in the schema. The description adds no additional meaning beyond what the schema provides, making 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 clearly states a specific action and target: 'Scroll the viewport up or down.' It is understandable and concise, though it does not explicitly differentiate itself from sibling tools like browser_evaluate or browser_wait_for.

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, no mention of prerequisites, and no exclusions. The description only states what the tool does, not when it should be selected.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Check' implies read-only behavior, but the description does not explicitly confirm no side effects, whether it launches or connects to a browser, or what happens when no browser instance exists. It names output subjects but leaves key behavioral traits unstated.

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 with no filler, front-loading the verb and object. Every phrase earns its place by naming distinct informational targets.

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 status tool, the description covers the core purpose and likely return areas. However, there is no output schema, and the description does not specify the return format, field structure, or error behavior, leaving some ambiguity for an agent.

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 empty schema makes parameter semantics trivial. The description still adds value by indicating what the status call will report: active tabs and persistent profile path.

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 ('check') and names three concrete targets: browser instance status, active tabs, and persistent profile path. This clearly distinguishes it from navigation, clicking, and typing siblings, though it does not explicitly name a sibling for comparison.

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 siblings. It does not state whether it should be called before navigation, whether it requires an already-open browser, or what conditions make it the right choice. Usage must be inferred from the name and description.

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 must carry the full burden of behavioral disclosure. It mentions realistic keystroke timing, which is a positive behavioral trait, but does not disclose other important traits such as whether it waits for the element to be interactable, what happens if the selector is invalid, or potential side effects like triggering events. This leaves significant gaps for a tool that interacts with a live page.

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 redundant words. It front-loads the main action and a key behavioral detail. It earns a 4 for being concise and structured well, though it does not quite merit a 5 because it could also mention a usage clause 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 complexity (typing into a live browser page), the lack of annotations and output schema means the description should explain more about behavior (e.g., focus handling, typing speed, error scenarios). It provides some context (realistic timing) but is insufficient for an agent to predict all outcomes. A tool with this interaction complexity needs more clarity.

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 the schema description coverage is 100%, the baseline is 3, and the description does not add extra meaning beyond what the schema already provides. It does not explain the exact behavior of clearFirst (e.g., whether clearing is immediate or simulated) or the selector syntax (e.g., supporting CSS selectors only). The description adds no value beyond the schema, so a 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 'Type text into an input or textarea' with a specific verb and resource, and mentions 'realistic human keystroke timing delays' which is a useful specificity. However, it does not differentiate from sibling tools like browser_click or browser_evaluate, so it loses a point for not explicitly distinguishing itself.

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 that it is for typing text into form fields, and the realistic timing suggests it is for user-like interaction, which is distinct from browser_evaluate. However, there is no explicit guidance on when to use this versus browser_autofill_login or browser_click, nor does it state 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?

With no annotations, the description must carry the full behavioral burden, but it only states the basic wait behavior. It does not disclose what happens if the selector never appears, whether there is a timeout, what the return value is, or how the two modes interact when both parameters are provided. These are material gaps for a tool that can potentially block indefinitely.

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 is front-loaded with the core action and wastes no words. It conveys both operational modes in a compact, readable way.

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 tool's low parameter count, the description omits crucial invocational details: there are no required parameters, yet the rationale for calling with neither, either, or both parameters is unexplained. The absence of an output schema makes the lack of return value information more significant, and the timeout/error behavior is unspecified, leaving an agent unable to predict failure modes.

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%, and the description adds little beyond the parameter descriptions: it clarifies that the parameters represent two alternative modes. This matches the baseline of 3 for high schema coverage; the description does not introduce new semantic pitfalls.

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 operation ('wait') and the two resources involved: a CSS selector to appear or a sleep duration in milliseconds. It is unambiguous and immediately distinguishes the tool from navigation, clicking, typing, and other browser actions. The verb-resource pairing is specific and informative.

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 contexts (wait for an element before interacting, or pause execution) but does not explicitly specify when to prefer this over alternatives or mention any exclusions. There are no sibling wait tools, so the lack of explicit alternatives is a minor gap, but the usage guidance is only 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, the description carries the full burden of explaining side effects, but it does not mention overwrite behavior, return values, errors, or whether the stored credential is immediately available to the browser. It only states that it stores securely.

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 includes the action, resource, and purpose. No unnecessary words or details are present.

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 store operation, the description gives the essential purpose, but it omits behavioral details such as whether existing credentials are overwritten or what the tool returns. Given the lack of annotations and output schema, this is a moderate 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?

The schema already provides clear descriptions for all three parameters with 100% coverage. The description does not add extra meaning beyond what is already in 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 clearly states a specific action (store), a specific resource (macOS Keychain), and the intended purpose (so the browser agent can log in automatically later). It distinguishes the tool from siblings like browser_autofill_login and passkey_save_registration.

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 the tool (before an automated login), but it does not explicitly mention alternatives or conditions for not using it. The purpose is strong enough that an agent can infer the primary use case.

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

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

No annotations are provided, so the description carries the full burden of disclosing side effects. It mentions enabling a virtual authenticator and optionally injecting a credential, but does not say whether this alters the current browser session, requires a prior CDP connection, overwrites existing authenticators, or what happens when the optional credential is absent.

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, well-structured sentence conveys the core capability and optional behavior without wasted words. The main action is front-loaded, and the optional injection is clearly appended.

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 is too thin for an agent to confidently call this tool. It does not explain the context needed (e.g., a browser/CDP session), when the two optional-looking parameters are actually needed, or what observable effect the tool produces.

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

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

Schema description coverage is 100%, so the schema fully documents rpId and account. The description does not add meaning beyond the schema, only implying that both relate to the stored passkey injection, which keeps this at the baseline 3.

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 ('Enables') and resource ('CDP WebAuthn virtual authenticator'), and adds the optional injection of a stored passkey. It is clearly distinct from the browser_* navigation/automation siblings, though it does not explicitly differentiate itself from passkey_save_registration or keychain_store_credential.

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 explains what the tool does but gives no guidance on when to use it versus alternatives like passkey_save_registration or keychain_store_credential. It also lacks prerequisites or any exclusions, so the agent must infer the intended context.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It does state the main side effect (saving to macOS Keychain), but it does not mention whether the captured credential is consumed/cleared from the virtual authenticator, whether repeated calls overwrite data, or whether any prior setup is required. This is a meaningful gap for a state-changing 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 sentence with no filler. It front-loads the action and destination, and every part contributes to understanding what the tool does.

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

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

For a tool with no output schema and no annotations, the description lacks important context: it does not explain the required ordering relative to passkey_enable_virtual_authenticator, what happens to captured credentials, or how it differs from keychain_store_credential. An agent would struggle to know when exactly to invoke this tool in a multi-step browser/passkey flow.

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%, and the description adds no parameter-specific meaning beyond what the schema already provides. The rpId and account descriptions are sufficient for understanding their values, so a 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 a specific verb ('Captures... and saves') and a specific resource ('newly registered Passkey credentials from the virtual authenticator', 'macOS Keychain'). It is easy to understand what the tool does, though it does not explicitly contrast itself with sibling tools like keychain_store_credential.

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 'newly registered Passkey credentials' implies this tool is used after a passkey registration flow, but there is no explicit guidance about when to choose it over alternatives like keychain_store_credential or how it fits with passkey_enable_virtual_authenticator. Usage context is only implied, not stated.

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