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

The description explains the core behavior (adding a header before sending) but fails to address the navigateUrl and clickSelector parameters in the schema, which reference actions not mentioned in the description. With no annotations, this omission leaves behavior ambiguous for those parameters. It also doesn't clarify matching semantics (e.g., glob vs regex) or side effects.

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 exactly two sentences, with the core action front-loaded in the first sentence and the sibling comparison in the second. No extraneous words, and the structure is ideal for quick scanning.

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 its concise core, the tool has six parameters and no output schema or annotations. The description fails to reconcile the presence of navigateUrl and clickSelector, which appear to belong to a different action model, leaving an agent uncertain about when those parameters are relevant. This incompleteness is significant for a mutation 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 input schema provides descriptions for all six parameters (100% coverage), so the baseline is 3. The description adds only a high-level reference to 'flat parameters' and does not elaborate on individual parameter usage beyond what the schema already states.

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

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

The description uses a specific verb and resource ('Add a custom header to matching requests before sending') and explicitly distinguishes from a sibling tool ('Simpler alternative to intercept_and_modify_traffic'). This makes the tool's purpose unambiguous and clearly differentiates it from the most related sibling.

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

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

The description provides clear context by positioning this tool as a 'simpler alternative' to intercept_and_modify_traffic, implying it should be used for straightforward header additions. However, it does not explicitly state when not to use it or provide alternative conditions beyond that single comparison.

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 but only lists actions without disclosing behavioral traits such as page unload/reload consequences, timeout behavior, or error conditions. It does not contradict anything, but it is too minimal to be transparent about side effects.

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 concise sentence that immediately states the tool's purpose and lists the actions. No wasted words.

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

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

The description is adequate for identifying the tool's basic function but lacks details on optional parameters' effects, return values (no output schema), and guidance on when to use this versus sibling navigation tools. It's not fully complete given the tool's multi-action nature.

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 covers all 5 parameters with clear descriptions (100% coverage). The description adds no additional parameter information beyond restating that navigation uses a URL, so baseline 3 applies.

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

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

The description clearly states the tool controls browser navigation and enumerates the specific actions (navigate, back, forward, reload). It distinguishes itself from sibling tools like navigate_and_extract_content which go beyond navigation to extract content.

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 use for basic browser navigation actions but does not explicitly state when to use this tool over alternatives such as navigate_and_extract_content or manage_tabs. No exclusions or alternative recommendations are provided.

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

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It states the tool performs an action (click, navigate, type) and captures resulting network requests, which implies side effects on the browser state. However, it does not explicitly warn that the action will be executed (e.g., navigation away from current page) or mention any other behavioral traits like waiting behavior or potential failures. This is a moderate gap given the tool's mutating nature.

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 main purpose and includes key return details. There is no wasted wording, and it earns every word.

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 seven parameters and no output schema, the description provides a clear purpose and a partial description of return values (URL, headers, body, method). It does not mention filtering or waiting behavior, but those are adequately documented in the schema. The description is complete enough for basic selection and invocation, though it could be richer given the complexity of browser actions.

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

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

The input schema provides 100% coverage with descriptions for all seven parameters. The description adds little beyond the schema, only mentioning action types in parentheses and the output format. Since schema_description_coverage is high, a baseline score of 3 is appropriate, and the description does not meaningfully enhance parameter understanding.

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 captures network requests triggered by user actions (click, navigate, type) and specifies the return details (URL, headers, body, method). This differentiates it from sibling tools like intercept_and_modify_traffic, which modify traffic, and extract_api_data, which extracts API data.

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

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

The description provides clear context on when to use this tool: when you need to capture network requests generated by specific browser actions. It does not explicitly exclude alternatives or mention when not to use it, but the purpose is unambiguous and sufficient for an agent to know its 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?

With no annotations, the description must disclose behavioral traits, but it only states the action. It does not mention that clearing cookies is destructive (e.g., logs users out), whether the operation is reversible, or what happens to other session data. The optional tabId parameter's effect on scope is also left unexplained.

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

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

The description is a single short sentence that immediately conveys the tool's function. Every word is purposeful; there is no fluff or repetition.

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

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

The tool is simple, but the description leaves important questions unanswered: What does tabId do exactly? What happens if neither tabId nor allDomains is provided? Since there is no output schema or annotations, these ambiguities make the description insufficient for reliable tool invocation.

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

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

The input schema already provides descriptions for both parameters (tabId and allDomains), covering 100% of the schema. The description adds the notion of 'specific domain or all domains,' but it does not clarify how tabId selects a domain or the interplay between the parameters. This does not go beyond the baseline for high schema coverage.

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

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

The description uses a specific verb ('Clear') and resource ('cookies') and clearly states the scope ('specific domain or all domains'). This distinguishes it from sibling tools like delete_cookie (singular) and get_cookies (read-only).

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

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

The description gives no guidance on when to use this tool versus alternatives such as delete_cookie or set_cookie. It does not mention any exclusions, prerequisites, or scenarios where another tool would be more appropriate.

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

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

No annotations are provided, so the description carries the full burden. It states what is cleared and the domain scope, but does not disclose irreversibility, whether the action affects all tabs, or the role of the optional tabId parameter.

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

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

The description is a single, short sentence that directly states the action and scope. It is concise, front-loaded, and wastes no words.

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

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

For a simple tool with no output schema, the description provides the core action but lacks context about return values, the effect of omitting tabId, and how 'current domain' is determined. It is minimally sufficient but leaves some contextual gaps.

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

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

Schema coverage is 100%, so the description need not add parameter details. The tabId is described in the schema as optional, but the description does not enhance understanding of that parameter beyond the schema.

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

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

The description uses a specific verb ('Clear') and resource ('all localStorage items'), and scopes it to 'current domain', making it unambiguous and distinct from sibling tools like get_local_storage and set_local_storage.

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 instead of alternatives such as clear_cookies or get_local_storage. It does not mention prerequisites, exclusions, or typical scenarios, leaving the agent to infer usage from the description alone.

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

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

With no annotations, the description carries the burden of disclosure. It mentions the side effects of closing the browser and releasing all connections, and specifies the availability constraint. This is adequate for a simple no-parameter 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 two concise sentences, front-loading the action and impact, with no redundant information. It earns its place by providing both the primary effect and the important limitation.

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

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

For a simple tool with no parameters and no output schema, the description adequately explains what it does and its constraint. It could mention when to prefer this over sibling session-management tools, but the current scope is sufficient.

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 schema is fully covered by having no properties. The description does not need to add parameter semantics, and the baseline for zero-parameter tools is 4.

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

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

The description clearly states the verb 'close' and the resource 'Playwright-managed browser', and specifies the exact scope: browsers launched by this MCP. It distinguishes itself by noting the managed nature, which is relevant given siblings like manage_browser_session.

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 'Only works for browsers launched by this MCP' provides a clear exclusion, guiding the agent not to use it for external browsers. It doesn't explicitly compare to sibling tools like manage_browser_session, but it gives enough context for when it's applicable.

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 disclose behavioral details. It only states the deletion action and hints at the need for exact name/domain, but does not address side effects, permissions, reversibility, or behavior on missing cookies. This is insufficient for a mutation tool with zero annotation coverage.

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

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

The description is two sentences, front-loaded with the primary action, and contains no fluff. Every word contributes to understanding the tool's purpose or usage.

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 deletion tool with complete schema documentation, the description covers the core task and prereq. It lacks return value details, but given the simplicity and no output schema, the description is reasonably complete. The lack of annotations and mutation context prevents a higher score.

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

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

Schema coverage is 100%, providing a baseline of 3. The description adds value by emphasizing that get_cookies should be used to retrieve the exact name and domain, which implies that cookie matching requires precise values—this goes beyond the schema's basic parameter descriptions.

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

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

The description states 'Delete a specific cookie by name' with a clear verb and resource, and the qualifier 'specific' distinguishes it from clear_cookies. This makes the tool's purpose unambiguous.

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

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

The description provides explicit guidance to use get_cookies first to find the exact name and domain, setting up a correct usage workflow. It does not explicitly mention when not to use it or alternatives, but the context is clear.

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

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

No annotations are provided, so the description must fully disclose behavior. It omits crucial aspects like the ability to modify page state, potential destructive effects, return value semantics, and error behavior. Telling users to include a return statement is a requirement, not a transparent description of side effects.

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, with a single purpose statement followed by two essential usage notes. It is well-front-loaded and contains no filler or redundancy.

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

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

Given no output schema and no annotations, the description is under-specified for a powerful script execution tool. It fails to explain what the function returns, how to handle results, what happens on errors, or potential side effects, leaving significant gaps for an agent to safely and correctly invoke the tool.

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

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

Schema coverage is 100%, so baseline is 3. The description's parameter-related advice ('Must include a return statement', 'Set awaitPromise=true') largely duplicates the schema descriptions, adding no significant extra meaning beyond what structured fields already communicate.

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 specific verb 'Execute' and resource 'JavaScript in the page context', which distinguishes it from sibling tools like perform_interaction or navigate_and_extract_content. It immediately conveys the tool's core function and scope.

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

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

Usage is implied: executing JS in the page context. The description adds 'how-to' guidance, such as requiring a return statement and setting awaitPromise for async code, but does not explicitly state when to prefer this over alternatives or mention exclusions.

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

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

With no annotations, the description carries full burden. It states what data is exported and the output format, but does not clarify whether the operation is read-only, how the optional tabId affects scope (specific tab vs all), or any limitations. The verb "export" implies non-destructive, but this is not explicit, and the tabId ambiguity creates a transparency gap.

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

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

The description is a single, front-loaded sentence that conveys the essential information without fluff. Every phrase earns its place: it names the verb, resource, included components, and output format, making it highly concise and well-structured.

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

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

For a tool with one optional parameter and no output schema, the description covers the core purpose and output format but omits clarification on how tabId affects the export scope. Without this, the agent may not understand whether omitting tabId exports all sessions or only the current one. The description is adequate but has a clear 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 input schema already documents the single optional parameter (tabId) with 100% coverage. The description does not add any additional meaning about how tabId influences the exported session state, so it relies entirely on the schema. This meets the baseline for high schema coverage but adds no extra 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?

The description uses a specific verb ("Export") and resource ("complete session state") and explicitly lists the contained data types (cookies, localStorage, sessionStorage) and output format (JSON). This clearly distinguishes it from sibling tools like set_cookie or import_session.

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 later import" explicitly indicates the primary use case (saving state to restore later), which implies pairing with the import_session sibling. It does not state when not to use it or name alternatives, but the context is clear enough for an agent to select it appropriately.

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 disclose behavioral traits. It mentions navigation and returning parsed JSON, but fails to clarify side effects such as tab behavior, whether the current page is replaced, filtering behavior of apiPattern, or how waitForSelector affects capture. This leaves significant uncertainty for a network-capturing 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 two short sentences with no filler. It front-loads the core action ('Navigate to URL and capture all API/XHR responses') and adds a concise outcome ('Returns parsed JSON data').

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 6 parameters, no output schema, and no annotations, the description is too minimal. It does not explain return structure, filtering behavior, timeouts, or how parameters interact. The tool appears more complex than the description supports, leaving the agent to infer key operational details.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds minimal meaning beyond the schema—it implies capturing API/XHR responses aligns with apiPattern but does not explain extractFields or waitForSelector. No additional value is provided over the schema descriptions.

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

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

The description clearly states the tool navigates to a URL and captures API/XHR responses, returning parsed JSON data. This is a specific verb+resource combination, but it does not explicitly differentiate from sibling tools like capture_network_on_action or navigate_and_extract_content.

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

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

No guidance is provided on when to use this tool versus alternatives such as capture_network_on_action or intercept_and_modify_traffic. The description only states what it does, not when it should be preferred.

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

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

With no annotations provided, the description must carry the transparency burden. It implies read-only behavior ('Extract') but does not explicitly confirm read-only status, nor does it disclose what happens on no match, whether it returns all matches or the first, or error conditions. Minimal insight beyond the obvious.

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

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

The description is a single, front-loaded sentence that effectively captures the tool's essence without redundancy or filler. Every word adds value.

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

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

The tool has no output schema and no annotations, yet the description does not explain the return format, what happens if multiple elements match, or how tabId affects execution. This leaves critical gaps for an agent to invoke and interpret results correctly.

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

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

The input schema provides complete descriptions for all four parameters, including the enum for action and the conditional requirement for attributeName. The description adds no additional semantic meaning beyond what the schema already communicates, so the baseline of 3 applies.

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

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

The description clearly states the tool's function: extracting text or HTML attributes from page elements using CSS selectors. This specifies the verb, resource, and method, and distinguishes it from sibling tools like get_html or extract_api_data.

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 its use case—when you need to extract specific element data via CSS selectors—but does not explicitly state when to prefer it over alternatives such as get_html or navigate_and_extract_content. No exclusionary guidance is provided.

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

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

With no annotations, the description carries the full burden of disclosing behavioral traits. It states what is returned but does not explicitly mention read-only behavior, permissions, side effects, or return format. The 'get' prefix implies read-only, but the description does not confirm this, and no output schema exists to clarify.

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 purpose and specific content. There is no redundant or extraneous information.

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

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

For a simple tool with one optional parameter and no output schema, the description provides a functional overview but lacks details on return structure and usage context. It does not explain how the returned accessibility tree is represented, which is important given the absence of an output schema. The lack of behavioral transparency further detracts from 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 input schema documents the only parameter (tabId) as optional, with 100% coverage. The description adds no additional meaning about parameters, so the baseline score of 3 applies.

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

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

The description clearly states the tool's function with a specific verb ('Get') and resource ('accessibility tree'), and enumerates the included elements (ARIA roles, labels, interactive elements). This distinguishes it from sibling tools like get_html or extract_element_data, which serve different purposes.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention use cases, prerequisites, or exclusions, leaving the agent to infer when accessibility tree retrieval is appropriate.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It clearly states what is checked (connection status, CDP port, manager type), but it does not explicitly state that it is a read-only operation, nor does it describe behavior when no browser is connected or if errors occur.

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

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

The description is a single concise sentence that conveys all necessary information with no filler or redundancy.

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

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

Given the zero-parameter, no-output-schema nature, the description adequately covers what the tool does. It could be slightly more explicit about the return format, but the listed items (connection status, CDP port, manager) imply the output.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and no parameter details are missing.

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 identifies a clear resource (browser connection status) plus specific details (CDP port, manager type). This distinguishes it from sibling tools like manage_browser_session or close_browser, which have different purposes.

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

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

No guidance is given on when to use this tool versus alternatives. It does not mention prerequisites, when to call it (e.g., before other browser operations), or which sibling tools are alternatives. The usage context is entirely implied.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It adds the current page vs. specific URL scope, but does not describe the return format, permissions, or potential side effects. The read-only nature is implied but not fully elaborated.

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

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

The description is a single, clear, front-loaded sentence with no unnecessary words. It efficiently conveys the tool's purpose and scope.

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

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

For a simple read tool without an output schema, the description should explain what the tool returns (e.g., a list of cookies). It does not, nor does it address edge cases like missing tabId. The basic usage is covered, but completeness is limited.

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 has 100% coverage with descriptions for both parameters. The description's mention of 'current page or a specific URL' aligns with the schema's url parameter but does not add new meaning beyond it.

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

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

The description clearly states the verb 'Get' and the resource 'browser cookies', with scope 'current page or a specific URL'. This distinguishes it from sibling tools like set_cookie and delete_cookie.

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

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

The description provides clear context for when to use the tool (retrieving cookies for the current page or a specific URL), though it does not explicitly mention exclusions or alternative tools.

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

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

With no annotations provided, the description carries the full burden. It does disclose a key behavioral trait: 'Output truncated at 50k chars.' However, it does not mention error handling (e.g., invalid selector, missing tab), scope of 'page' (current tab?), or other edge cases. The truncation note is useful, but the description remains thin on behavioral detail.

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 exceptionally concise: two sentences, 16 words, no fluff. The core purpose is front-loaded, and the truncation constraint is the only additional context, making every word valuable.

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 low complexity (3 optional params, no output schema, no annotations), the description covers the essential purpose and a critical limitation. It says what is returned (HTML source) and the truncation behavior. It falls short of addressing edge cases like selector not found, but for a simple read tool, it is sufficiently 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 baseline is 3. The description's mention of 'page or a specific CSS selector' partially aligns with the selector parameter, but it adds no extra semantics beyond the schema. tabId and outerHTML are not addressed in the description.

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 ('Extract'), the resource ('HTML source'), and the scope ('from the page or a specific CSS selector'). It distinctly identifies the tool's purpose and differentiates it from siblings like extract_element_data, which focuses on structured data extraction.

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 this tool (when raw HTML is needed) but does not explicitly mention alternatives or exclusion criteria. It lacks guidance on when to prefer get_html over extract_element_data or execute_script, so usage is only implied.

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 burden of disclosing behavior. 'Get' signals a read-only operation and 'current domain' scopes the data, but it does not mention return shape, empty storage behavior, or how tabId affects the results. This is decent but not rich.

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

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

The description is a single, front-loaded sentence that states action and scope without filler. It is appropriately concise for a low-complexity tool.

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

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

For a low-complexity tool with no annotations and no output schema, the description sufficiently covers what the tool does and where it operates (current domain). It does not detail error conditions or return format, but these are not critical for a simple getter.

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 covers 100% of the parameter (tabId) with its own description and marks it optional. The tool description adds no parameter-specific meaning, but the baseline of 3 applies given full schema coverage and a single optional parameter.

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

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

The description uses a specific verb and resource: 'Get all localStorage key-value pairs,' clearly identifying a read operation. The 'current domain' scope and sibling names like set_local_storage and clear_local_storage distinguish this as the retrieval tool.

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 clearly implies use when you need to read localStorage values for the current domain. It does not explicitly contrast with set_local_storage/clear_local_storage, but the context is unambiguous enough for a simple tool.

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

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

With no annotations provided, the description carries full responsibility for disclosing behavior. It only says 'get layout metrics', implying a read operation, but does not mention any side effects, prerequisites, return format, or whether it requires a live page. This is a significant gap for a tool that likely has some browser-side context requirements.

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

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

The description is a single, clear sentence with no unnecessary words. It is appropriately sized for a tool with one optional parameter, but it may be too terse to fully convey the purpose. Still, it is structurally well-organized and front-loaded with the verb.

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 that there is no output schema and the tool is relatively simple, the description should at least hint at what 'layout metrics' includes and when to use this tool. It does neither, leaving the agent to guess the return value and applicability. While the low complexity reduces the burden, the lack of any context beyond the verb phrase makes it incomplete.

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

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

The schema already provides 100% coverage for the only parameter (tabId with description 'Tab ID (optional)'). The tool description adds no additional semantic detail about the parameter, so it neither enhances nor detracts from the schema. The baseline of 3 applies.

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

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

The description clearly states the verb 'Get' and the resource 'layout metrics of the page', making it distinct from sibling tools like get_html or get_accessibility_tree. However, 'layout metrics' is somewhat ambiguous—it doesn't specify whether these are dimensions, positions, or visual layout data. Still, it conveys the core action and object.

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

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

No guidance is provided on when to use this tool versus alternatives or in what context (e.g., after page load, for a specific element). The description merely states what it does, leaving the agent to infer usage. There are no exclusions or alternative tool references.

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

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

No annotations are provided, so the description carries the full burden. It discloses the core behavior (hides advanced tools) and importantly states that the action is reversible via 'show_advanced_tools.' However, it omits details such as persistence scope (session vs. global) or any side effects, though these are minimal for a toggle tool. The transparency is good but not exhaustive.

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 highly concise: two short sentences that immediately convey the action and the reversal mechanism. It is front-loaded with the primary purpose and contains no filler or redundancy.

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

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

Given the tool's simplicity (zero parameters, no output schema, simple toggle behavior), the description is complete. It explains what the tool does and how to restore the previous state, which fully satisfies the context for an agent deciding to use it.

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

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

The input schema is empty, and there are no parameters. The description adds no parameter information, but none is needed. With zero params, the baseline is 4, and the description adequately serves its purpose without redundant detail.

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: 'Hide advanced tools to simplify the tool list.' It uses a specific verb ('hide') and resource ('advanced tools'), and directly distinguishes itself from the sibling tool 'show_advanced_tools' by referencing how to undo the action.

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

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

The description explicitly names the alternative tool 'show_advanced_tools' for reversing the hide action, providing clear guidance on when to use this tool versus its counterpart. It also implies the primary use case (simplifying the tool list) with no ambiguity.

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 restores cookies and storage and that navigation is required for the import to take effect, which is a key behavioral trait. However, it does not mention potential side effects such as overwriting existing session data or whether the tool requires any prior state, leaving some ambiguity.

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

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

The description is two sentences with no wasted words. The first sentence front-loads the purpose, and the second provides a crucial usage instruction. It is appropriately sized for the tool's simplicity.

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 (two parameters, no output schema, no annotations), the description covers the core behavior and the activation step, making it sufficient for an agent to understand when and how to use it. It does not detail tab targeting or return values, but the schema covers parameter specifics, and the description is adequate for this straightforward operation.

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

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

The schema provides descriptions for both parameters (sessionData and tabId), achieving 100% coverage. The tool description does not add extra parameter semantics beyond implying that sessionData comes from a prior export, but it does not explain format or specific usage of tabId further.

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

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

The description clearly identifies the tool's function as importing previously exported session data to restore cookies and storage, using a specific verb and resource. This distinguishes it from sibling tools like export_session (which exports) and set_cookie (which sets individual cookies).

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 after a prior export and explicitly instructs the user to navigate after import to activate the session, providing clear context on when to use the tool. It doesn't explicitly mention alternatives or exclusions, but the sibling context and the restoration purpose make the intended use fairly evident.

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

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

The description adds some behavioral context by stating it preserves cookies and authentication and operates 'before sending'. However, it does not disclose potential side effects, whether modifications are temporary or persistent, or how it interacts with response capture. With no annotations, the description carries the full burden but only partially covers it.

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

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

The description is two sentences, directly states the main purpose, and adds key capabilities without redundancy. It is concise and well-structured, front-loading the core 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?

For a tool of moderate complexity with a rich input schema and no output schema, the description adequately covers the purpose, key preservation behavior, and modification scope. It could be more complete with added context on when to use it or relationship to capture tools, but it is sufficient for the basic use case.

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 schema already provides detailed parameter descriptions, including examples and type clarifications (e.g., 'NOT string'). The description does not add further parameter semantics, 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 the tool's function: intercepting and modifying network requests in real-time. It lists specific capabilities (header/body/method changes) and distinguishes itself from sibling tools like add_custom_header_to_request (which only adds headers) and capture_network_on_action (which only captures).

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

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

The description implies usage for when network requests need to be modified before sending, but does not explicitly state when to use this tool versus alternatives. There is no mention of exclusions or alternative tools, so the guidance relies on inference from the description and sibling names.

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 itself must disclose behaviors. It mentions using the 'real profile' which implies access to persistent data, but does not disclose potential side effects like profile locking, impact on existing Chrome instances, or whether the tool blocks or returns immediately.

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

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

The description is two sentences, front-loaded with the primary purpose and followed by an essential usage warning. Every word earns its place with no redundancy or irrelevant information.

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

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

For a simple tool with one optional parameter and no output schema, the description covers purpose and usage constraints adequately. It does not mention what happens after launch (e.g., return values), but this is not critical for this simple launch 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?

The input schema already covers the single parameter (profileDirectory) with a clear description and default value. The tool description adds minimal additional semantic value beyond the schema, so it does not need to compensate.

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 ('Launch Google Chrome') and the specific resource ('with your real profile'), including details about cookies, extensions, and sessions. This distinguishes it from sibling tools that manage existing sessions or 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.

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

Explicitly states when to use the tool ('only when the user EXPLICITLY asks') and when not to ('Do NOT call it automatically or proactively'). This provides clear usage boundaries, though it does not name alternatives, the guidance is strong.

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 bears full responsibility for disclosing behavior. It notes the scope (cookies + storage) but does not reveal important traits such as the destructive nature of 'clear', the overwriting behavior of 'load', or any side effects like logging out. The schema provides some hints (e.g., 'clear (logout)'), but the description itself is minimal and lacks these disclosures.

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, tightly-written sentence that lists all four operations and the resource scope. Every word contributes to the core meaning, with no filler or repetition. This is exemplary conciseness for a multi-function tool.

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

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

The tool has moderate complexity (6 params, 4 operations) and no output schema, but the schema descriptions are detailed. Yet the description misses return values (e.g., what export returns, result of save/load/clear) and important caveats like loading overwriting the current session. It is adequate for a high-level overview but leaves gaps that require the agent to infer from operation names.

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

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

The input schema has 100% description coverage for all six parameters, so the description adds no additional meaning. The description aligns with the parameter concepts (cookies/storage) but does not enrich beyond what the schema already explains. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function with specific verbs (save, load, clear, export) and resource (browser session: cookies + storage). It is distinct in that it performs multiple operations in one call, but it doesn't explicitly differentiate from sibling tools that handle individual operations (e.g., clear_cookies, export_session).

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 'in one call' implies a combined usage scenario, suggesting users should use this when they want to handle multiple session operations together. However, it does not explicitly state when to prefer this over individual cookie/storage tools or mention any exclusions, leaving the guidance implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions the tabId requirement, which is essentially schema information. It doesn't indicate which actions are read-only versus mutating (e.g., list/get_url are safe reads, while close/switch/create modify state), nor does it disclose side effects or return behavior.

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

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

The description is two sentences, front-loaded with the main purpose, and contains no redundant or filler text. 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?

This is a multi-action tool with no output schema, so the description should clarify what each action returns or does behaviorally. It only lists actions without explaining results (e.g., what 'list' returns, what 'get_url' provides). The lack of behavioral and return-value detail makes the description incomplete for confident tool invocation.

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

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

Schema coverage is 100% with each parameter described, including enum values and field purposes. The description adds the explicit note about tabId being required for close/switch, but this is already present in the schema. Thus, the description adds little beyond the schema, earning the baseline score.

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 manages browser tabs and enumerates specific actions: list, create, close, switch, or get current URL. This specific verb+resource combination distinguishes it from broader sibling tools like browser_action or perform_interaction.

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 provides clear context that this tool is for tab-level operations and includes a useful constraint: 'Tab ID required for close/switch.' However, it doesn't explicitly state when to use this tool over alternatives or mention any exclusions, so it misses the top score.

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

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

With no annotations and no output schema, the description carries the full burden of behavioral disclosure. It mentions navigation and extraction but does not explain side effects (e.g., does it open a new tab? modify browser state?), what happens on navigation failure, or the format of the extracted content. The description is too thin to prepare an agent for real-world behavior.

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

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

The description is a single, well-structured sentence that front-loads the primary action ('Navigate to URL') and lists the content types in parentheses. Every word contributes to the purpose, with zero wasted content.

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 having 8 parameters and no output schema, the description is only one sentence. It fails to explain return values, pagination or size limits, navigation failure handling, or how this tool integrates with session/tab management. Given the tool's complexity and lack of structured output metadata, the description is incomplete for an agent to know what to expect.

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

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

The input schema covers 100% of parameters with clear descriptions, so the baseline is 3. The description adds minimal semantic value by grouping content types ('text, links, images, metadata') which maps directly to the boolean parameters, but it does not add meaning beyond the schema's own documentation.

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

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

The description clearly states the tool's function: 'Navigate to URL and extract page content (text, links, images, metadata) in one call.' The verb 'navigate' and resource 'URL' are specific, and the extraction content types are enumerated, distinguishing this tool from simpler siblings like 'get_html' or 'extract_element_data' by combining navigation and extraction in a single 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 usage when both navigation and content extraction are needed in one step, but it does not explicitly state when to prefer this over alternatives or when not to use it. No exclusions or alternative tool references are provided, so the guidance is implied rather than explicit.

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

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

No annotations are provided, so the description must carry the burden of disclosing behavioral traits. It only lists action names without explaining side effects, return values, or failure behavior (e.g., what happens if the selector is not found, or if a click triggers navigation). The 'verify selectors' hint is minimal.

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

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

Two sentences, with the primary purpose front-loaded and zero wasted words. The list of actions is compact and information-dense.

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

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

Given no output schema and 100% schema coverage, the description is adequate for a broad interaction tool but lacks depth about error handling or return behavior. The explicit 'use get_html first' guidance adds context, but more detail on what each action entails 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?

Schema coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema; it mentions selectors but not specific parameters like text, value, or coordinates. It repeats the action list already present in the enum.

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

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

The description clearly states the tool's function with specific verbs (click, type, select, scroll, wait) and identifies the resource (page elements). It distinguishes from sibling tools like get_html or execute_script by enumerating concrete interaction actions.

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

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

Explicitly instructs to use get_html first to verify selectors, providing a clear usage prerequisite. This implicitly advises when to use this tool (after confirming element presence) and points to an alternative (get_html) for inspection.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without revealing side effects, return values, whether it saves to disk or opens a dialog, or any other behavioral traits.

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

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

The description is a single concise sentence with no fluff, but it is arguably too minimal. It is appropriately front-loaded and every word counts, yet it lacks any structured detail about parameters or behaviors.

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

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

This tool has 7 optional parameters and no output schema, yet the description provides no context about return values, side effects, or typical use cases. It is incomplete for a tool of this complexity.

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

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

The schema provides comprehensive descriptions for all 7 parameters (100% coverage), so the description adds no additional parameter meaning. Baseline 3 applies because the schema handles parameter semantics.

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

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

The description clearly states the tool prints the current page to PDF, using a specific verb and resource. It distinguishes itself from sibling tools like screenshot by specifying PDF output, though it does not explicitly contrast with alternatives.

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

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

The description provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or exclusions, leaving the agent without decision support.

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

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

No annotations are provided, so the description carries full burden. It does not disclose behavioral details such as the need for an active tab, how clip coordinates are interpreted, or what the response contains. The phrase 'specific element/area' is ambiguous because the schema has no element selector, only clip coordinates.

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 redundant or extraneous words, making it concise and well-structured.

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

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

With 8 optional parameters and no output schema or annotations, the description is too sparse. It does not explain how clip coordinates combine with fullPage, how to capture a specific element (given no selector), or what the tool returns. The ambiguity around 'element/area' remains a significant gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema by loosely referencing full page and element/area, but it does not clarify parameter interdependencies or the meaning of clip coordinates.

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 (Capture), format (PNG/JPEG), and scope (full page or specific element/area). This distinguishes it from sibling tools like print_to_pdf and extract_element_data.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not reference any sibling tools or exclusion criteria, leaving the agent to infer usage from the purpose alone.

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

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

No annotations are provided, so the description carries full burden. It only restates the action without disclosing side effects (e.g., overwriting existing cookies), scope (whether tabId is required or how it affects behavior), permissions, or response. This is minimal for a mutation 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?

One sentence, front-loaded with the core action, no filler. Efficient and easy to scan.

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

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

The schema is complete and covers all parameters, but with no output schema and no annotations, the description does not explain important behavioral nuances like tabId scoping or how cookie overwriting works. It's adequate but not complete for a tool with 9 parameters.

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 baseline is 3. The description adds some value by grouping the optional flags (secure, httpOnly, sameSite), but does not explain path, expires, or tabId beyond what the schema already states.

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

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

The description uses a specific verb ('Set') and names the resource ('browser cookie') plus key parameters (name, value, domain, flags). It clearly distinguishes from sibling tools like get_cookies, delete_cookie, and clear_cookies.

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 clearly implies when to use this tool (when you need to set a cookie) and its context. It doesn't explicitly mention alternatives or when not to use it, but the siblings are obvious enough that no exclusions are needed.

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

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

With no annotations, the description carries the full burden. It only mentions the set operation and a value-format tip. It does not disclose overwriting behavior, persistence across sessions, tab scoping, or any side effects, which is a significant gap for a mutating 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?

Two sentences, front-loaded with the primary action, and no wasted words. The JSON.stringify tip adds practical value without bloating the description.

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 localStorage set operation, the description is minimally viable, but it lacks any mention of return behavior, validation, or error conditions. Given no output schema or annotations, more completeness could be expected.

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

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

Schema coverage is 100% with descriptions for key, value, and tabId. The description adds value by advising JSON.stringify for objects, which clarifies the value parameter beyond the schema's simple 'Storage 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?

The description clearly states the tool sets a localStorage key-value pair, using the specific verb 'Set' and naming the resource (localStorage). It is unambiguous and distinct from sibling tools like get_local_storage or clear_local_storage.

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

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

The description implies usage for localStorage operations but does not explicitly state when to use this tool versus alternatives like set_cookie or clear_local_storage. The JSON.stringify tip provides a usage hint but no when-not-to-use guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Unlock advanced tools' and lists examples, without detailing side effects, persistence, toggling behavior, or any impact on the system. This is a significant gap for a tool that likely changes the available toolset.

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 action 'Unlock'. It efficiently lists the advanced tools without unnecessary words, making it easy for an agent to grasp the purpose quickly.

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

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

Given the tool's simplicity (no parameters, no output schema), the description is largely complete in explaining what it does. It enumerates the unlocked tools. However, it does not clarify the nature of 'unlock' (e.g., UI display vs. feature activation) or mention the opposite action (hide_advanced_tools), which would provide fuller 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 tool has no parameters, so the baseline is 4 per the rubric. The description does not need to add parameter semantics because there are none, and the schema is empty with 100% coverage.

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

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

The description uses the verb 'Unlock' and specifies the resource 'advanced tools', followed by a concrete enumeration of capabilities (network interception, request replay, API mocking, etc.). It clearly distinguishes itself from sibling tools like 'hide_advanced_tools' by indicating it is the action to expose these tools.

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

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

The description implies that this tool should be used to gain access to advanced tools, but it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites. The list of tools serves as indirect context, but there is no direct guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'automatically' and lists action types, but fails to disclose side effects, whether it requires an existing browser session, what happens on failure, or how it interacts with tabs. This is a significant gap for a tool that executes a sequence of operations.

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, concise and front-loaded with the core purpose. It earns its place with the action examples, though it could be slightly more informative without becoming overly lengthy.

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

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

This tool has moderate complexity (4 params, 1 required), no output schema, and no annotations. The description is too brief to be fully contextual. It doesn't explain return values, error handling, prerequisites, or when to choose this over sibling tools, leaving a substantial knowledge gap for the 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?

Schema description coverage is 100%, so the baseline is 3. The description's list of action types (click, type, etc.) adds some context for the 'steps' parameter, but doesn't provide additional meaning beyond what the schema already states. No param-specific details are given for tabId, stopOnError, or captureScreenshots.

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 executes a sequence of user actions, with specific examples (click, type, wait, navigate, screenshot). This conveys the verb and resource, but it doesn't explicitly differentiate from sibling tools like perform_interaction or browser_action that may also handle individual actions.

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

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

No guidance is provided on when to use this tool versus alternatives. It doesn't mention that it's for multi-step sequences or which sibling tools are better for single actions. The description simply states what it does without contextual or comparative usage advice.

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

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

With no annotations, the description carries the full burden. It discloses that auth cookies are handled automatically, which is useful, but it omits side effects, response structure, error behavior, or whether cookies are modified. For a tool that sends HTTP requests, this is minimal transparency.

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

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

Two sentences: the first states the primary action, the second adds a key behavioral trait. Both earn their place with no fluff or repetition. Front-loaded and efficient.

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 six parameters and no output schema, the description is only two sentences. It doesn't describe the captured response format, error handling, or how auth is handled beyond a vague note. The tool's behavior in edge cases or with different methods/headers is unaddressed, leaving significant gaps for an HTTP request 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?

Schema description coverage is 100%, so the baseline is 3. The description adds 'handles auth cookies automatically' which relates to includeCredentials but doesn't explain parameter usage beyond the schema. It neither compensates nor detracts from the schema's 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 sends HTTP requests and captures responses, with an additional note about auth cookies. It distinguishes itself from sibling tools like extract_api_data by focusing on sending and capturing rather than extracting data from a page. However, it doesn't explicitly name alternatives, so it's not a 5.

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

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

No mention of when to use this tool versus alternatives like add_custom_header_to_request or intercept_and_modify_traffic. The description implies testing API endpoints, but provides no exclusions, prerequisites, or context for choosing this tool over others.

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

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

With no annotations provided, the description carries the burden of disclosing side effects. It transparently describes the save/apply/restore cycle ('Saves original cookies, applies test cookies, optionally restores'), which is the key behavioral trait regarding state modification. It could also mention that content extraction occurs (based on extractContent), but the core behavior is well communicated.

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

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

The description is two sentences long, front-loaded with the primary purpose, and contains no filler. Every word adds value, making it exceptionally concise and well-structured.

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

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

The description covers the main workflow and safety net (save/restore), which is crucial for a test tool modifying cookies. However, it does not explain what 'test' entails (e.g., navigation or content extraction) or what output to expect, but this is partially covered by the extractContent parameter schema. Given the tool complexity with 5 parameters and no output schema, the description is adequate but not exhaustive.

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?

All five parameters have schema descriptions, so schema coverage is 100%. The tool description adds general workflow context but does not go beyond the schema's parameter descriptions. According to the baseline for high schema coverage, a 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 ('Test a page') with a clear scope ('with modified cookies'), and the additional sentence details the workflow. This distinguishes it from sibling cookie tools like set_cookie or get_cookies, which focus on individual cookie operations rather than testing page behavior under modified cookies.

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 testing a page under modified cookies, but it does not explicitly state when to use this tool versus alternatives like set_cookie or clear_cookies. There is no mention of when not to use it or comparison with sibling tools, so usage guidance is only implied.

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?

Without annotations, the description carries the burden and does well by disclosing a key behavioral trait: it checks current readyState first and only waits for an event if the target state is not reached. It also explains the three states clearly. No contradictory annotations exist.

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

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

Two concise sentences that are front-loaded with the primary purpose, followed by a useful behavioral detail and state definitions. Every sentence earns its place with no redundancy.

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

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

There is no output schema, and the description does not mention return values, timeout failure behavior, or error handling. While the action is simple and the schema covers all parameters, an agent might not know what happens on timeout or whether the function returns a status.

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

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

Schema coverage is 100% with descriptions for all three parameters. The description adds significant value by expanding on the 'state' parameter with explanations of what each enum value means ('load', 'domcontentloaded', 'networkidle'), which goes beyond the schema's brief 'State to wait for'.

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

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

The description uses a specific verb and resource ('Wait for page to reach a specific load state') and clearly distinguishes this tool from sibling browser automation tools by focusing on load state synchronization. It also enumerates the possible states with definitions, eliminating ambiguity.

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

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

Usage is implied: the tool is for waiting on page load states, but there is no explicit guidance on when to use this versus alternatives like 'perform_interaction' or 'execute_script'. No exclusions or alternative recommendations are provided.

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