Server Quality Checklist

Tool Scores

• select_optionC
  2.6/5.0
  Behavior2/5

  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 does not mention whether the option is chosen by value, text, or index, what happens if the option isn't found, whether it triggers change events, or any side effects. This is a significant gap for a UI interaction tool.

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

  Conciseness3/5

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

  The description is a single short sentence with no fluff, but it's under-specified. Conciseness is fine, but the brevity comes at the cost of necessary details, so it doesn't fully earn its place as adequate documentation.

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

  Completeness2/5

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

  Given no annotations knead no output schema provided (though indicated as present, it's empty in the prompt), the description is incomplete: it doesn't cover failure modes, waiting behavior, or whether the element must be a native <select>. The tool is simple, but more context is expected for a UI interaction tool.

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

  Parameters2/5

  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 explain the parameters. It only explains 'option_text' as being visible text, and says nothing about 'selector' (CSS selector? XPath? ID?). Thus, half the parameters are left ambiguous.

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

  Purpose4/5

  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 (<select>) option) and clarifies the selection is by visible text, which distinguishes it from generic 'click' or 'type'. However, it doesn't explicitly contrast with sibling tools that might overlap (e.g., type_text or execute_script), so it loses one point.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives, such as whether it's preferred over click for dropdowns, or if it requires the element to be already visible or if it handles native vs custom selects. The context of use is not explained.

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

• execute_scriptC
  2.9/5.0
  Behavior2/5

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

  There are no annotations, so the description carries the full burden of behavioral disclosure. It mentions that execution happens in the page context and that a result is returned, but it does not disclose potential side effects, page mutations, navigation, async behavior, or the risk of arbitrary code execution.

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

  Conciseness4/5

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

  The description is a single, clear, front-loaded sentence with no filler. It is concise and easy to parse, though the brevity leaves important details out.

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

  Completeness2/5

  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, this one-line description is not complete enough for a powerful arbitrary-code execution tool. It lacks side-effect warnings, execution model details, and any usage boundaries that an agent would need to invoke the tool safely and correctly.

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

  Parameters2/5

  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, but it adds only minimal meaning beyond the schema's 'script' property. It tells the agent that the script is JavaScript executed in the page context, but it does not clarify acceptable script format, whether expressions versus statements are allowed, or how return values are serialized.

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

  Purpose5/5

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

  The description clearly states a specific action—executing JavaScript in the page context—and notes that a result is returned. This distinguishes it from the sibling browser automation tools, which handle navigation, clicking, typing, and reading page content rather than arbitrary script execution.

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

  Usage Guidelines2/5

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

  No guidance is provided about when to use this tool versus the many sibling tools, nor are there any exclusions or warnings. An agent must infer that this is for cases where dedicated browser commands do not suffice, but the description does not say so explicitly.

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

• navigateB
  3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Navigate to a URL.' It doesn't explain what happens on failure (e.g., invalid URL), whether it waits for page load, whether it replaces the current history entry, or any side effects. For a navigation tool, this is a significant behavioral gap. It's not misleading but severely under-discloses.

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

  Conciseness5/5

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

  Extremely concise: one short sentence. No fluff, front-loaded and to the point. There is nothing redundant.

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

  Completeness2/5

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

  Despite having an output schema (likely just success/failure status), the description is too thin. The tool exists in a browser automation context with many siblings; an agent would benefit from knowing whether navigation resets the browser state (e.g., from iframe contexts) or if it's only for top-level navigation. Without annotations, the description must do more, but it doesn't mention error handling, page load waiting, or interaction with other tools like switch_to_frame.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description only says 'Navigate to a URL.' It doesn't add any meaning to the 'url' parameter beyond what the schema shows. The parameter is a string, but the description doesn't clarify what format (e.g., must include http://, or can be relative), or what counts as a valid URL. This is a real gap for an agent.

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

  Purpose4/5

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

  Purpose is clear: navigate to a URL. Uses a specific verb (navigate) and resource (URL). Distinguishes from siblings like go_back/go_forward/refresh_page but doesn't explicitly mention them. The description is minimal but adequate.

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

  Usage Guidelines3/5

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

  Implied usage: the tool is for initial navigation to a URL. No explicit guidance on when to use it vs. go_back/go_forward, but those are semantically distinct enough. The description doesn't state when not to use it, which is a small gap. Could mention that it's for direct navigation, not in-page actions.

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

• switch_to_frameB
  3.2/5.0
  Behavior2/5

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

  No annotations and the description omits side effects, error handling (e.g., if selector not found), or state changes beyond 'focus'. Does not mention whether it waits for the frame to load.

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

  Conciseness5/5

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

  Single, clear sentence with no redundancy. The essential information is front-loaded.

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

  Completeness3/5

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

  Adequate for a straightforward switch action, but lacks details about expected outcomes, potential errors, or return values. Since an output schema exists but is not provided, it's uncertain if return values need explanation.

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

  Parameters4/5

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

  The only parameter, 'selector', is described as a CSS selector in the text, which adds meaning beyond the bare schema label. This compensates for the lack of parameter description in the schema.

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

  Purpose4/5

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

  Clearly states the action (switch focus) and target (iframe) with a specific selection method (CSS selector). Distinct from the sibling switch_to_default_content, though it doesn't explicitly contrast them.

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

  Usage Guidelines2/5

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

  Provides no guidance on when to use this tool versus other navigation or frame-related tools. It states what it does but not the context or prerequisites.

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

• assert_textB
  3.3/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It does disclose the key behavior that an error is raised and returned as a tool error when text is not found, which is useful. However, it doesn't disclose matching semantics (exact vs substring, case sensitivity) or whether the tool waits for text to appear.

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

  Conciseness5/5

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

  Two short sentences. The first states the core operation, and the second clarifies the failure mode. No filler, no redundant details.

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

  Completeness3/5

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

  For a simple assertion tool, the description gives the essential behavior of erroring when not found. But it is incomplete in important contexts: it doesn't say whether the assertion is instantaneous or waits, and it doesn't distinguish itself from wait_for_element, which is especially important given the sibling list.

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

  Parameters3/5

  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 does add broad meaning for text and selector by saying text can be on the page or within an element, but it never defines the selector syntax or the exact matching behavior for text. That leaves important parameter semantics unresolved.

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

  Purpose4/5

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

  The description clearly states the action: assert that text is present on the page or within an element. It's specific enough to separate it from tools like get_text, since it explicitly raises an error when text is missing, though it doesn't name sibling tools.

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

  Usage Guidelines2/5

  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 assertion instead of alternatives like wait_for_element, get_text, or is_element_visible. The description implies it is a check, but does not explain timing, retries, or when a user should choose a waiting/reading tool.

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

• solve_captchaB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely says 'attempt to solve,' hinting at possible failure but not explaining what the tool actually does (e.g., clicking, submitting, waiting), whether it requires user interaction, or what happens on success or failure. This is a significant gap for a tool with no annotation backup.

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

  Conciseness4/5

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

  The description is a single concise sentence with no wasted words. It front-loads the core action and resource. The word 'attempt' could be seen as slightly vague, but overall it is efficient and appropriately brief for a simple tool.

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

  Completeness3/5

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

  The tool has no parameters and an output schema exists, but the description does not explain what the tool returns, what side effects occur (e.g., page state changes), or how to interpret failure. While the output schema may cover return values, the description leaves the overall operation ambiguous. For a tool that might be called in a critical flow, more context would help.

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

  Parameters4/5

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

  The tool has zero parameters, and the input schema is empty. Since there is no parameter to document, the description adds no parameter-level meaning, but the baseline of 4 applies because no compensation is needed. The description's mention of 'captcha' and the example provides context that the schema cannot, but it is not parameter-specific.

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

  Purpose4/5

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

  The description states a specific verb ('solve') and resource ('captcha') and gives a concrete example (Cloudflare Turnstile), making the tool's purpose clear. It is distinct from all sibling tools, none of which mention captcha handling. However, it lacks an explicit contrast with alternatives, so it falls short of a 5.

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

  Usage Guidelines3/5

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

  The description implies that this tool is for solving captchas, but it provides no explicit guidance on when to invoke it versus other actions. There are no stated preconditions, exclusions, or alternatives. The usage is inferred from the name and example rather than clearly instructed.

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

• activate_cdp_modeB
  3.4/5.0
  Behavior2/5

  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 a side effect: switching session mode affects subsequent actions. It also notes the prerequisite 'uc=True'. However, it doesn't disclose potential side effects like whether the session state is altered irreversibly, or whether it conflicts with other operations. Since it's a state-changing operation, more disclosure would be expected.

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

  Conciseness4/5

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

  The description is two sentences, which is concise. It front-loads the primary action and then provides additional context. Every sentence adds relevant information without fluff.

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

  Completeness3/5

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

  The tool has an output schema (though not shown in the input), and the description is adequate for a simple parameter. However, given it's a session state change, the description could be more complete about what changes and how it affects subsequent actions. The prerequisite 'uc=True' is a critical detail, but other caveats like session reset or limitations are not mentioned. Overall, it's minimally viable but has gaps.

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

  Parameters3/5

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

  The schema has 0% coverage for the parameter, but the description mentions 'optionally navigating to a URL', which explains the purpose of the 'url' parameter. Since there is only one parameter and the description covers its purpose, it adds some value beyond the bare schema. However, it doesn't detail the format or expectations for the URL, even though the schema is minimal.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: it switches the current session into Pure CDP Mode and optionally navigates to a URL. The verb 'switch' and resource 'session into Pure CDP Mode' are specific. It also mentions 'CDP-only capabilities' which distinguishes it from general navigation tools like 'navigate'.

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

  Usage Guidelines4/5

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

  The description gives context that this mode applies to subsequent actions and mentions a prerequisite: 'Requires uc=True.' However, it doesn't explicitly state when to use this over alternatives or when not to use it. The context of 'more thorough stealth' implies a use case, but there's no direct comparison with siblings like 'navigate'.

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

• go_forwardB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the basic action and does not mention what happens when there is no forward history, whether navigation waits for page load, or that this changes current page state.

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

  Conciseness5/5

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

  The description is a single, direct sentence with no filler or redundancy. The action is front-loaded and immediately actionable.

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

  Completeness3/5

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

  For a zero-parameter tool with an output schema, the core invocation is covered adequately. However, it lacks useful context such as the prerequisite that forward history exists only after a prior back navigation, and the behavior when the forward history is empty.

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

  Parameters4/5

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

  The tool accepts zero parameters, and the schema already fully documents this with an empty properties object. With no parameters to explain, the baseline of 4 applies and the description does not need to add parameter-level detail.

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

  Purpose4/5

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

  The description uses a specific verb phrase, 'go forward one page in browser history,' which clearly identifies the operation and resource. It does not explicitly differentiate itself from the sibling go_back, but the direction and history scope make the purpose unambiguous.

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

  Usage Guidelines3/5

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

  The phrase 'in browser history' implies this tool is for moving forward after a previous back navigation, giving some usage context. However, it does not explicitly state when to use this over go_back or navigate, nor does it mention prerequisites or exclusions.

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

• screenshotB
  3.4/5.0
  Behavior2/5

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

  The description only mentions that it saves the screenshot to disk. It does not disclose whether existing files are overwritten, what happens on failure (e.g., if the page is not loaded), or any side effects. Since no annotations are provided, the description carries the full burden but provides minimal behavioral details.

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

  Conciseness5/5

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

  The description is a single, clear sentence with no unnecessary words. It is well-structured and immediately conveys the core action without fluff.

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

  Completeness3/5

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

  While the description covers the primary action, it lacks detail on expected output (even though an output schema exists, its content is not described), error conditions, or interactions with other tools. For a simple tool, this might be sufficient, but given the absence of annotations and the lack of output clarification, it is not fully complete.

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

  Parameters2/5

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

  The only parameter, 'filename', is mentioned in the schema but not explained in the description. There is no indication of whether it expects a full path, a relative path, or just a base name, nor any constraints on format. The default 'screenshot.png' gives a hint but does not clarify semantics.

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

  Purpose5/5

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

  The description states a specific verb ('Take') and resource ('screenshot of the current page') and clearly conveys the action of saving to disk. It is easily distinguished from sibling tools like click, type, or navigate, which perform other browser actions.

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

  Usage Guidelines3/5

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

  The description does not explicitly state when to use this tool or provide alternatives. However, the purpose is self-evident in the context of browser automation, and it is clear that this tool is for capturing a visual state. No explicit guidance on when not to use or under what conditions it is appropriate is given.

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

• type_textB
  3.4/5.0
  Behavior3/5

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

  There are no annotations, so the description has to carry behavioral clarity by itself. It does explicitly disclose clear_first's destructive effect, but it does not mention focus requirements, key events, failure behavior, or what happens when clear_first is false.

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

  Conciseness4/5

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

  The description is compact and well organized: one purpose line followed by three clear parameter lines. It loses a point only because the text parameter line repeats what the parameter name already conveys.

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

  Completeness3/5

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

  For a simple browser automation tool the description covers the main inputs and the clear_first option, but with no annotations it leaves edge cases and behavior assumptions unexplained. The existence of an output schema reduces the need for return-value descriptions, but usage context and failure conditions are still missing.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the Args section is the primary source of parameter meaning. It usefully explains that selector is a CSS selector and clear_first empties the field first, but 'text: Text to type' is essentially a tautology and adds little beyond the schema's type.

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

  Purpose5/5

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

  'Type text into an input field' names a concrete action and a specific resource, which makes the tool's purpose immediately obvious. It is also qualitatively distinct from sibling tools like click, select_option, and execute_script.

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

  Usage Guidelines2/5

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

  The description does not specify when to prefer this tool over alternatives, nor does it exclude cases like select fields, file inputs, or elements managed by JavaScript. The only usage signal an agent gets is inferred from the description's first sentence.

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

• wait_for_elementB
  3.4/5.0
  Behavior3/5

  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 states the waiting behavior (poll until appears) but does not disclose what happens on timeout (error? return value?), polling interval, or whether it interacts with page loading. Since there is an output schema, the return behavior might be partially covered, but the description adds minimal behavioral context beyond 'wait until appears'.

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

  Conciseness4/5

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

  The description is short and front-loaded: it states the action and the criteria in a single sentence. No wasted words, but the timeout semantics are missing, which could be a single addendum.

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

  Completeness3/5

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

  For a 2-parameter tool with an output schema, the description is minimally complete. It specifies the selector usage but leaves timeout behavior unaddressed. Since the tool name and description make the main purpose clear, an agent could likely call it correctly, but would need to infer timeout details. Given the complexity (browser automation) and the absence of annotations, a bit more detail would be expected.

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

  Parameters3/5

  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 selector parameter implicitly ('matched by a CSS selector') but does not explain the timeout parameter. The timeout parameter's semantics (units, what happens when exceeded) are not described. The description adds some value for selector but not for timeout, which is a key parameter.

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

  Purpose4/5

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

  The description states a clear verb and resource: waiting until an element appears, identified by a CSS selector. It distinguishes from siblings like is_element_visible by focusing on appearance/waiting rather than visibility checking. Missing explicit title, but the description is sufficiently clear.

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

  Usage Guidelines3/5

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

  The description implies usage when an element is expected to appear after some action, but does not explicitly state when to use versus alternatives like is_element_visible or find_elements_count. No explicit when-not or alternative guidance. The agent must infer from context, which is adequate but not explicit.

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

• close_browserA
  3.5/5.0
  Behavior2/5

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

  With no annotations available, the description carries the full burden of behavioral disclosure. It says 'end the session' but does not disclose that subsequent browser operations will fail, that state is irreversibly lost, or any error conditions (e.g., if no browser is open). This is a significant gap for a destructive action.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no wasted words. It states the action and its immediate consequence concisely.

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

  Completeness3/5

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

  While the tool is simple and an output schema exists, the description omits post-conditions and error behavior. An agent may not know that calling this tool invalidates all other browser-tool calls until start_browser is invoked again, making the description somewhat incomplete.

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

  Parameters4/5

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

  The tool has zero parameters and the schema coverage is 100%, so the baseline is 4. The description does not need to add parameter details since there are none.

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

  Purpose5/5

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

  The description states a clear verb ('close') and resource ('browser') and also mentions ending the session. It is unambiguous and distinct from all sibling tools like start_browser or refresh_page, making the purpose immediately obvious.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to call this tool, such as 'use after all browser operations are complete' or warnings about calling it prematurely. There are no alternatives mentioned, but no explicit context or exclusions either, so it falls into 'no guidance'.

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

• get_current_urlA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It does not mention side effects, prerequisites (e.g., an open page), error conditions, or return format. The description is a bare statement of the action without any added context.

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

  Conciseness5/5

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

  The description is a single, focused sentence without any filler or redundancy. It is front-loaded with the key information and is appropriately sized for a simple getter tool. Every word adds value.

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

  Completeness3/5

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

  While the tool is simple and the output schema exists, the description omits any context about the runtime environment (e.g., requiring an active page) or potential failure states. It is minimally adequate but lacks explicit completion of the usage context that an agent might need to call it correctly.

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

  Parameters4/5

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

  The tool has zero parameters, so the schema is trivially 100% covered. The description correctly implies no parameters are needed. According to the baseline for zero-parameter tools, a score of 4 is appropriate since the description aligns with the schema and adds no ambiguity.

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

  Purpose5/5

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

  The description clearly states the action (get) and the resource (URL of current page), making it unambiguous and distinct from siblings like get_title or get_page_source. It precisely names what the tool returns without ambiguity.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives or when not to use it. The description only states what it does, leaving the agent to infer context. Unlike the sibling tools, no explicit routing or exclusions are given.

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

• clickA
  3.6/5.0
  Behavior2/5

  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 does not mention side effects such as navigation, event triggers, waiting behavior, or failure modes like hidden or non-clickable elements. The description names the action but exposes nothing about its runtime behavior beyond the arguments.

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

  Conciseness5/5

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

  The description is appropriately terse and front-loaded. The main action appears first, followed by a minimal argument breakdown, with no redundant or decorative wording. Every sentence adds needed information.

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

  Completeness4/5

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

  For a simple, two-parameter click action, the description plus input schema is largely sufficient. The output schema reduces the need to describe return values. However, the missing usage-side guidance and behavioral caveats mean it is not fully complete, though the low complexity here keeps the gap small.

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

  Parameters4/5

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

  The input schema has 0% description coverage, so the description must compensate. It does: it explains that selector is CSS or XPath and that by is limited to 'css' or 'xpath', adding semantic meaning beyond the raw schema fields and defaults.

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

  Purpose5/5

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

  The description states a specific action ('Click') and a specific target ('an element'), which immediately distinguishes it from siblings like type_text, get_text, and screenshot. The first line is unambiguous and defines exactly what the tool does.

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

  Usage Guidelines2/5

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

  There is no guidance about when to use this tool versus alternatives, nor any exclusionary conditions. An agent must infer from the tool name and sibling list that this is the action for clicking an element. No context about preconditions or alternatives is provided.

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

• get_page_sourceA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose the return type ('full HTML source') and scope ('current page'), which is helpful. However, it doesn't address common behaviors like whether this reflects the DOM after JavaScript execution, if it's a snapshot, or performance implications. The description is honest but minimal, missing opportunities to disclose that HTML can be large or that it might include sensitive information.

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

  Conciseness5/5

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

  A single sentence that is front-loaded with the action ('Get') and the resource ('full HTML source'), ending with the scope ('current page'). Every word earns its place. It is appropriately sized and clearly written.

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

  Completeness3/5

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

  For a simple getter with no parameters and no output schema defined, the description provides the core value: the HTML source of the current page. The biggest gap is that it doesn't clarify whether the HTML is the live, post-JavaScript DOM or the raw source, which can be a critical difference. Also, it doesn't mention if this might be resource-heavy or have size limits. Given the tool's simplicity, it's adequate but leaves an agent wondering about the timing of the snapshot.

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

  Parameters4/5

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

  With zero parameters and 100% schema coverage (vacuously), there's no parameter semantics for the description to clarify. The description doesn't need to add parameter meaning since there are none. However, it could have clarified if this is a simple getter or if it interacts with the page in any way. The score is based on the fact that the description is sufficient for what it does, but a 4 is warranted because an ideal description might clarify that no arguments are needed for any interactive capabilities.

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

  Purpose4/5

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

  The description uses a clear verb ('Get') and a specific resource ('full HTML source of the current page'), making the tool's purpose immediately understandable. It distinguishes itself from related sibling tools like get_current_url or get_text by explicitly stating 'full HTML source,' which is a strong differentiator. However, it could be slightly more specific about what 'current page' means in relation to iframes or popups, which are common contexts in browser automation.

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

  Usage Guidelines3/5

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

  The description doesn't explicitly state when to use this tool versus alternatives, but the phrase 'current page' implies a session context that an agent would need to have set up. It doesn't provide explicit exclusions or alternatives, but the siblings list (navigate, get_current_url, get_text) gives some implicit context. The description is adequate but doesn't clearly help an agent decide between this and get_text when HTML vs text is a factor.

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

• get_textA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description must carry behavioral disclosure, and it does indicate a read operation returning visible text. However, it does not disclose behavior when the selector matches no element or multiple elements, whether it waits for the element, or how whitespace/hidden content is normalized.

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

  Conciseness5/5

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

  The entire definition is one concise, front-loaded sentence 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.

  Completeness3/5

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

  The description is adequate for a simple getter and the output schema covers return values, but it leaves out failure behavior and whether the element must already exist. Given sibling tools like wait_for_element and is_element_visible, an agent would benefit from knowing whether get_text is synchronous and what happens on no match.

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

  Parameters4/5

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

  With no schema description coverage, the description is the only source of parameter meaning, and it usefully clarifies that 'selector' is a CSS selector used to match an element. The role of the single required parameter is explicit, though details like first-match or empty-result behavior are absent.

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

  Purpose5/5

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

  The description states a specific action ('Get') and resource ('visible text of an element matched by a CSS selector'), clearly separating it from sibling tools like get_title, get_page_source, and assert_text. Even without a title, an agent can infer exactly what this tool returns.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use get_text versus assert_text, wait_for_element, or is_element_visible. The description implies a usage pattern but never states prerequisites, exclusions, or alternatives.

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

• find_elements_countA
  3.8/5.0
  Behavior3/5

  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 clearly states the core read-only behavior, but it does not mention whether hidden elements are counted, whether it waits for elements to appear, or how invalid selectors are handled.

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

  Conciseness5/5

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

  The description is a single sentence with no filler or repetition. The key action and target are front-loaded and immediately understandable.

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

  Completeness4/5

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

  For a simple one-parameter counting tool with an output schema, the description provides sufficient information to understand the tool's purpose and invoke it correctly. Minor gaps remain around edge-case behavior and usage context, but these do not undermine the core operation.

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

  Parameters4/5

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

  The schema only defines 'selector' as a plain string with 0% description coverage. The description adds meaning by specifying that the selector is a CSS selector used to match elements on the page, which compensates for the schema's lack of detail.

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

  Purpose5/5

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

  The description uses a specific verb ('Count') and a clear resource ('elements on the page match a CSS selector'). It clearly distinguishes itself from sibling tools like click, get_text, or is_element_visible by focusing solely on counting matching elements.

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

  Usage Guidelines2/5

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

  No guidance is provided about when to use this tool versus alternatives such as is_element_visible or wait_for_element. The usage context is only implied by the tool's function, and no exclusions or alternative routing are mentioned.

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

• go_backA
  3.8/5.0
  Behavior2/5

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

  There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the intended action, but does not mention behavior when no history exists, whether frames are involved, or what happens to the current page state. This is acceptable for a simple tool, but still minimal.

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

  Conciseness5/5

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

  One short, front-loaded sentence with no filler. It directly states the action and the resource it operates on, which is the appropriate level of detail for a tool with no arguments.

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

  Completeness4/5

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

  For a zero-argument browser navigation action, the description is essentially complete: it tells the agent what happens and the tool's scope. A small caveat about empty history or frame context would add robustness, but the core call is fully specified.

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

  Parameters4/5

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

  The input schema has zero parameters, so there are no parameter semantics to add. The empty schema plus the clear description fully covers the invocation contract.

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

  Purpose5/5

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

  The description uses a specific verb and resource: 'Go back one page in browser history.' This clearly communicates the action and distinguishes it from siblings like go_forward, navigate, and get_current_url, even without needing their schemas.

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

  Usage Guidelines3/5

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

  The description implies when the tool should be used: to move one step backward in the browser history. However, it does not explicitly state when not to use it or how it differs from navigate or go_forward, so some routing guidance is left to inference.

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

• is_element_visibleA
  3.8/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of explaining behavior, but it only states the check without detailing the return value (e.g., boolean), whether it waits for the element, or how 'visible' is defined. This lack of behavioral detail could mislead an agent.

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

  Conciseness5/5

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

  The description is a single, concise sentence with no redundant words. It directly conveys the tool's function without excessive detail, making it easy to parse.

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

  Completeness4/5

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

  Given the tool's simplicity and the existence of an output schema (though not shown), the description covers the essential context of checking visibility. It could be more explicit about the meaning of 'visible', but the core functionality is clear.

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

  Parameters4/5

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

  The sole parameter 'selector' is adequately clarified by the description as a CSS selector, adding meaning beyond the schema's type definition. The schema coverage is high, and the description reinforces the expected format.

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

  Purpose5/5

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

  The description clearly states the specific verb 'check' and the resource 'element matched by a CSS selector', making its purpose unambiguous. It is distinct from sibling tools like click or type_text, which perform actions rather than checks.

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

  Usage Guidelines3/5

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

  The description implies usage for verifying visibility, but it does not explicitly state when to choose this over other assertion tools like assert_text or wait_for_element. No alternative tools are mentioned, leaving some ambiguity for an agent.

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

• refresh_pageA
  3.8/5.0
  Behavior3/5

  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 clearly states that the action targets the current page, which is useful, but it does not disclose potential side effects like unsaved form data loss, behavior during page load failure, or whether the action waits for the reload to complete.

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

  Conciseness5/5

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

  The description is a single sentence with no filler or redundancy. It is front-loaded with the action and target, making it maximally scannable and efficient.

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

  Completeness4/5

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

  For a zero-parameter browser action, the description is largely complete for invocation: the action and target are unambiguous, and an output schema exists to cover return values. Minor gaps such as preconditions (browser must be open) and when to choose this over navigate are present, but they are not critical for a tool this simple.

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

  Parameters4/5

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

  The tool has zero parameters, so the 100% schema coverage is vacuously satisfied. The baseline of 4 for a parameterless tool applies; no parameter details are needed in the description.

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

  Purpose5/5

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

  The description uses a specific verb, 'Refresh,' and a clear resource, 'the current page,' making the tool's function immediately understandable. It also distinguishes itself naturally from navigation siblings like go_back, go_forward, and navigate by naming a distinct browser action.

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

  Usage Guidelines2/5

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

  There is no guidance about when to use this tool versus alternatives, nor any mention of exclusions or preconditions. The description simply states what it does without providing situational context, so an agent receives no help deciding between refresh and other navigation tools.

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

• start_browserA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It adds useful context like the ordering requirement and headless-mode caveats, but it does not disclose what happens if called twice, whether a session is reused, or what cleanup is required.

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

  Conciseness5/5

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

  The description is short, front-loaded with the most important fact, and the Args section is cleanly structured. Every sentence adds value without fluff.

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

  Completeness2/5

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

  For a tool with 7 parameters and no annotations, the description is incomplete: three parameters are undocumented and session lifecycle behavior is not covered. The output schema covers return values, but the missing parameter semantics leave a significant gap.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It gives meaningful semantics for headless, browser, uc, and incognito, but omits proxy, ad_block, and guest_mode entirely. This is partial compensation, not full.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Start a new browser session.' This clearly distinguishes it from sibling tools like close_browser, navigate, and refresh_page, and it is not a tautology of the tool name.

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

  Usage Guidelines4/5

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

  The description explicitly says 'Must be called before any other tool,' which gives clear when-to-use guidance. It does not discuss when not to use it or alternatives, but there is no real alternative for starting a browser session among the siblings.

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

• get_titleA
  4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does, not how it behaves—such as whether it waits for page load, returns null on missing title, or throws exceptions. For a tool with no annotation support, this is a notable gap.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that states the exact operation with zero waste. It is as concise as possible while remaining informative.

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

  Completeness4/5

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

  Given the tool has no parameters and an output schema exists, the description is largely complete. It does not need to explain return values due to the output schema. Minor gaps like prerequisites (e.g., requiring a loaded page) are not stated, but these are inferred from the sibling set and the simple nature of the tool.

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

  Parameters4/5

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

  There are zero parameters, so the schema is trivially covered. Per the rubric, 0 params baseline is 4. The description adds no parameter-specific information (none needed), so this score is appropriate.

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

  Purpose5/5

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

  The description states a specific verb ('Get') and resource ('title of the current page'), clearly distinguishing it from siblings like get_current_url and get_text. It is immediately obvious what this tool does and how it differs from related browser-read tools.

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

  Usage Guidelines4/5

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

  The usage context is implicitly clear: it is used to fetch the page title. However, it does not explicitly mention when to prefer this over siblings or any exclusions. For a simple read operation, this is adequate, though not as explicit as providing alternatives.

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

• switch_to_default_contentA
  4.5/5.0
  Behavior4/5

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

  No annotations exist, so the description carries the behavioral disclosure burden. It fully states the core behavior: resetting driver focus from any iframe to the main page. It does not discuss edge cases like already being on the main page, but that is a minor omission for such a simple operation.

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

  Conciseness5/5

  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 meaning, and the destination/target is stated immediately.

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

  Completeness5/5

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

  For a zero-parameter, single-purpose tool, the description is complete: it says exactly what action is performed and the target context. The presence of the sibling switch_to_frame in the same list completes the mental model without requiring more detail.

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

  Parameters4/5

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

  The tool takes zero parameters, so there is no parameter semantics to explain. The description adds value by clarifying the tool's scope, and the baseline for a zero-parameter tool is 4.

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

  Purpose5/5

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

  The description uses a specific verb and resource: 'Switch driver focus back out to the main page (out of any iframe).' It clearly differentiates this tool from its sibling switch_to_frame, which moves focus into an iframe.

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

  Usage Guidelines4/5

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

  The phrase 'back out... out of any iframe' clearly establishes the context of having previously switched into a frame, so an agent knows when to call this. It does not explicitly name switch_to_frame or list when-not conditions, which keeps it from a 5.

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