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

With no annotations, the description carries the behavioral burden. It does disclose that the tool returns a compact snapshot rather than a raw tree, implying a read-only action. It does not explicitly confirm non-mutation or describe the snapshot format, but for a simple snapshot tool this is minimally adequate.

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

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

A single front-loaded sentence with no filler; the key operation and output qualifier come first. Every word earns its place.

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

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

For a zero-parameter tool with no output schema, the description gives the essential outcome and purpose. It is slightly thin on what 'compact view' means concretely and on whether it applies to the current page, but it is largely complete for 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 input schema has zero parameters and 100% description coverage, so there is no parameter burden for the description to carry. The baseline for zero-parameter tools is 4, and nothing in the description misleads about parameters.

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

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

The description uses a specific verb and resource ('Get accessibility tree snapshot') and adds a distinctive qualifier ('compact view of page structure for LLM understanding'). This clearly distinguishes it from sibling snapshot tools like browser_snapshot or wait_and_snapshot by naming the accessibility tree as the resource.

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 'compact view... for LLM understanding' implies this is for obtaining a lightweight, LLM-oriented structured snapshot rather than a full DOM/screenshot. However, it does not explicitly name sibling alternatives or state when not to use it.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It clearly states that no click occurs, that it hit-tests, and that it reports an intercepting element when something covers the target. This is meaningful non-obvious behavior beyond the tool name.

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 key distinction, and every sentence adds value. There is no filler or repetition of the tool name.

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 and the description covers purpose and core behavior, but it is incomplete for correct invocation because an agent cannot tell how to populate ref or selector. With no output schema, the description also does not fully describe the result shape beyond 'reports the element that would intercept'.

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

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

The schema has two parameters, ref and selector, with 0% schema description coverage, and the description adds no information about either. It never explains ref vs selector, whether they are alternatives, required, or how they locate the element. The description does not compensate for the empty schema at all.

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 precise verb-resource combination: 'Hit-test an element WITHOUT clicking' and clarifies the intent by asking 'would a real click actually land on it?' This distinguishes the tool from siblings like click, click_text, and click_role while also differentiating it from visibility assertions by focusing on hit-testing rather than visibility.

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 usage context: use it to answer 'why did my click do nothing?' before spending a real click. This implies the right moment to invoke it and contrasts it with click tools, though it does not explicitly name alternative tools or state when not to use it.

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

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

With no annotations provided, the description carries the disclosure burden, and it does disclose an important behavioral trait: it returns success/fail rather than throwing. It also indicates both existence and visibility are required. It could add detail on waiting/retry behavior, but for a simple assertion this is meaningful transparency.

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

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

The description is two short sentences, front-loads the core action, and every clause adds value. There is no redundant framing or boilerplate.

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

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

For a one-parameter assertion tool, the description is close to sufficient: it states the action and the non-throwing result. It is incomplete only because selector syntax and timing behavior are left unstated, and there are no annotations or output schema to fill those 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 description coverage is 0%, and the description does not explain the selector parameter's expected format (e.g., CSS selector vs XPath). The only implicit connection is that the element is identified by the 'selector' argument; that is too thin to compensate for the low 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 states a clear verb ('Assert') and resource ('element') with specific criteria: exists and is visible. The phrase 'Returns success/fail (no throw)' clarifies that this is a boolean-style assertion, which separates it from element inspection/retrieval tools like inspect_element or query_selector_all.

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 assertion phrasing makes its intended use obvious: verify an element is both present and visible. It does not explicitly name alternatives or exclusions such as assert_clickable or assert_text_present, so it misses full when-to-use guidance, 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully states the substring behavior and case sensitivity, but it does not disclose what happens on failure (e.g., whether it throws, returns false, or waits) or whether hidden or off-screen text is included, which are important for an assertion tool.

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

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

The description is a single, front-loaded sentence with zero filler. Every word contributes to understanding the tool's scope and matching behavior, making it highly 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?

For a simple one-parameter tool, the description is mostly sufficient to invoke it correctly. However, the absence of any statement about failure behavior or return value, combined with no output schema and no annotations, leaves a notable gap for an assertion tool where failure semantics are central to the caller's control flow.

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

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

The single parameter 'text' is named clearly and the description clarifies that it is the case-sensitive substring being asserted. Since schema description coverage is 0%, the description compensates somewhat by explaining the meaning of the parameter through the tool's purpose, though it adds no additional details such as trimming, encoding, or special characters.

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

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

The description clearly identifies the action (assert), the target resource (text on the page), and the exact matching semantics (case-sensitive substring, anywhere on page). It distinguishes itself from sibling assertions like assert_element_visible and assert_url_matches by specifying text content rather than element state or URL.

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

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

The description implies when to use it: whenever you need to verify that a specific substring appears anywhere on the current page. However, it does not explicitly mention alternatives, exclusions, or when to prefer sibling tools such as assert_element_visible or find_by_text, leaving the routing decision partly to the agent.

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 it only discloses the matching modes (substring or regex). It does not say what happens when the assertion fails, whether the tool waits or retries, or how the result is reported to the agent.

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 one tightly worded sentence with no filler, and the core purpose is front-loaded. It is appropriately concise, though it sacrifices behavioral context.

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

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

For a simple two-parameter tool with no output schema or annotations, the description is not fully complete. An agent still lacks information about failure behavior and return values, which is critical for an assertion 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 0%, so the description must explain the parameters. It adds useful meaning by clarifying that pattern can be a substring or regex depending on the regex flag, but it does not specify the default mode/substring semantics, regex syntax, or case sensitivity.

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 ('Assert') with a clear resource ('current URL') and defines what matching means ('substring or regex'). This makes it distinguishable from retrieval tools like get_url and waiting tools like wait_for_url, though it does not name those alternatives.

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

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

No guidance is given about when to use this assertion versus alternatives such as wait_for_url or get_url. The verb 'Assert' implies immediate verification, but the description never states this or provides any exclusions or preconditions.

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 reveals that the tool writes the current session's auth state to a named JSON file at a specific path, which is a concrete side effect. It does not mention overwrite behavior or security implications of stored auth state, but for a save-related convenience wrapper the key behavior is adequately disclosed.

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

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

The description is two compact sentences with no filler. The core action is front-loaded, followed by the target path and an illustrative example, and every clause contributes useful 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 single-parameter tool with no output schema and no nested objects, this description is nearly complete. It names the underlying storage_state_save operation and the exact output location, though it does not spell out what 'auth state' includes or what happens if the destination file already exists.

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 documents the 'name' parameter with examples, and the description adds meaningful context by showing exactly how the parameter is used: it becomes the filename in ~/.camoufox-mcp/sessions/<name>.json. This goes beyond the schema's static description and clarifies the parameter's real effect.

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

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

The description states a specific action ('Save current session as named auth state') with a clear resource (current session) and output (named auth state). It also gives an example ('logged-in user') and distinguishes itself by naming storage_state_save as the underlying wrapper, so an agent can tell it apart from related session/save 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 explicitly references storage_state_save and shows the default target path, giving an agent a clear sense of when this convenience wrapper is appropriate. It does not explicitly state exclusions, such as 'use storage_state_save for custom paths,' but the wrapper relationship strongly implies the usage context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says what happens at a high level, but provides no details about waiting for navigation, failure handling, whether it preserves or changes session state, or what format the snapshot takes.

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 very compact and front-loaded with no filler or redundancy. It earns its place, though its brevity does leave some behavioral gaps unaddressed.

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 no-parameter tool, the description is minimally adequate, but the absence of an output schema means the agent cannot know what a 'snapshot' actually contains. It also does not clarify how this tool relates to the many sibling navigation-and-snapshot combinations.

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

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

The tool has zero parameters and the input schema confirms this with full coverage. There is nothing for the description to add about parameter meaning, so the baseline of 4 is appropriate.

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

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

The description states a clear action and result: navigate the browser back and return a snapshot. It distinguishes itself from go_back alone and browser_snapshot alone by combining both, though it does not explicitly differentiate itself from other snapshot-combo siblings like navigate_and_snapshot or reload_and_snapshot.

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

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

Usage is implied by the verb phrase: use this when you want to go back in history and capture the resulting page state. However, it does not explain when to prefer this over chaining go_back with browser_snapshot, or over navigate_and_snapshot, nor does it mention limitations or preconditions.

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 behavioral disclosure burden. It mentions that actions are executed in one call, but it does not explain ordering guarantees, partial failure behavior, atomicity, return values, or what happens if one action fails. These are important unknowns for a batch execution 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 short and front-loaded with the core behavior. However, it includes an unlisted url field and omits timeout, so it is concise but not fully accurate.

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

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

For a tool with no output schema and no annotations, the description is incomplete. It lacks information about supported action types, execution semantics, failure handling, and what the caller should expect after invoking the batch.

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 documents the actions parameter and its properties in detail, so the description adds little semantic value. It also lists 'url?' as an optional action field even though url is not present in the schema, and it omits the timeout field that is present, which could mislead an agent.

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

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

The description clearly states that the tool executes multiple actions in a single call, which identifies the verb and resource. It does not explicitly contrast itself with the many sibling single-action tools, so it stops short of full sibling differentiation.

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

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

There is no guidance on when to use batch_actions instead of individual action tools such as click, fill, type_text, press_key, or wait_for. The batching benefit is implied by the name and description, but no explicit when-to-use or alternatives are provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully explains that cookies persist in a specified profile path and that a fresh-profile launch removes the temporary profile. This goes beyond the bare verb 'close' and gives the agent crucial context about state persistence and destructive 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?

Two concise sentences deliver the core action first, then the persistence caveats. No unnecessary filler. Every sentence contributes meaningful 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?

Given the tool's simplicity, zero parameters, and absence of an output schema, the description covers all essential aspects: what it closes, what is preserved, and what is removed under fresh-profile mode. An agent has enough information to invoke and anticipate side effects correctly.

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

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

The tool has zero parameters, so there is no parameter information for the description to add beyond the schema. With 0 params, the baseline of 4 applies. The description appropriately focuses on behavioral effects instead of parameter details.

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 opens with a specific verb and resource: 'Close the browser.' This clearly distinguishes it from sibling tools like tab_close (which closes only a tab), browser_launch (which starts the browser), and browser_recover (which attempts recovery). The scope is unambiguous.

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

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

The intended use is implied: call this when you want to end the browser session. However, it provides no explicit guidance about when this should be preferred over alternatives like reset_profile or browser_recover, nor any 'when not to use' statement. The context is clear but the routing guidance is absent.

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

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

With no annotations provided, the description carries the full burden. It discloses key behaviors beyond the schema: browser persistence, default profile path (~/.camoufox-mcp/profile), and auto-cleaning of temp profiles on browser_close. It does not mention side effects like visible windows when headless=false, but that is covered in the schema. Overall, it adds meaningful behavioral context.

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

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

The description is efficient and front-loaded: the first sentence states the action, the second explains persistence, and the third covers the fresh-profile option. Every sentence earns its place with no redundancy or fluff.

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 behavioral aspects needed to use the tool correctly: persistence, profile handling, and a key use case for fresh_profile. The schema covers all 9 parameters in detail, so the description doesn't need to repeat them. A minor gap is ambiguity about calling browser_launch again when a browser already exists, but overall 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% and each parameter is already well-documented, so the baseline is 3. The description adds minor extra context (e.g., the default profile path and account-switching use case) but does not significantly expand on the parameter meanings beyond what the schema provides.

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

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

The description states a specific verb and resource: 'Launch Camoufox stealth browser and navigate to URL.' It clearly defines the tool's core purpose and distinguishes it from navigation/other sibling tools by being the launcher. The phrase 'Browser persists between calls' further clarifies its role as the session initiator.

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 clear context on when to use the tool: it launches a browser and persists between calls, implying it should be used once at the start of a session. It also provides practical guidance on when to set fresh_profile=true (switching between accounts on the same domain). It does not explicitly name alternatives or state when-not-to-use, but the context 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 provided, the description carries the full behavioral burden. It discloses that the tool force-drops the connection, resets server state, and reports profile-lock diagnostics. It does not fully spell out side effects such as whether all browser state/session is lost, but it is honest about the reset 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?

Two sentences deliver the trigger condition, the action taken, the expected outcome, and a common underlying cause. The most important information is front-loaded, and there is no filler 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?

For a zero-parameter escape-hatch tool with no output schema, the description covers when to use it, what it does, and what to expect afterward. It is slightly vague about what 'resets server state' entails in terms of data loss and does not differentiate from the sibling reset_profile tool, but it is otherwise 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 and an empty input schema, so there is no parameter semantics to convey. The baseline for zero-parameter tools is 4, and the description appropriately spends no space on parameter details.

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

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

The description names a specific recovery operation ('force-drops the connection and resets server state') tied to a clear precondition: the browser is wedged and browser_close cannot complete. It also distinguishes itself from browser_launch and browser_close by explaining how it enables relaunching.

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 explicitly states when to use the tool: as an escape hatch when browser_close fails and the browser is wedged, with the goal of making browser_launch work again. It does not explicitly contrast with related tools like reset_profile, so it stops short of full alternative 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 disclosure burden. It usefully reveals that large-page responses can be truncated, that refs stay stable regardless of filters, and that visible elements remain numbered. This is meaningful behavioral context, though it does not describe output shape or explicitly state side-effect-free 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 four tight sentences, each earning its place. The core purpose is front-loaded, followed by usage guidance, a caveat about large pages, and a clarification about ref stability. There is no fluff or repetition of schema details.

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

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

For a tool with three optional, well-documented parameters and no output schema, the description covers the essential operational context: when to call it, how refs relate to click/fill, truncation risk, and mitigation strategies. It is not fully exhaustive about return shape, but it is complete enough for effective 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 description coverage is 100%, so the baseline is 3, but the description adds value beyond the schema by explaining how parameters are used together: narrowing with roles, paginating with offset/limit, and the stability of ref numbering under filtering. This elevates it above the baseline.

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 opens with a specific verb and resource: 'Get visible interactive elements with ref IDs.' This clearly states what the tool does and is not a tautology. However, it does not explicitly distinguish itself from sibling tools such as accessibility_snapshot or describe_page, so it falls short of a 5.

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

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

The description gives practical usage context: 'Always call after navigation' and 'Use refs with click/fill.' It also explains how to handle large pages by narrowing with roles or paginating with offset/limit. It does not name alternatives or explicitly state when not to use the tool, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It explains the fire-all-then-collect parallel strategy, the fact that it saves to disk, that an authenticated session is required, and the per-job result structure. This is substantial and accurate behavioral transparency.

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

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

The description is front-loaded with the core action and parallel behavior, then covers consistency, authentication, and return values. There is some redundancy between 'IN PARALLEL', 'one tab per job, fire-all-then-collect', and 'Submits every job first WITHOUT waiting', but each sentence still contributes useful detail.

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

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

For a complex batch tool with no annotations and no output schema, the description is complete: it covers authentication prerequisites, parallel execution semantics, consistency-related parameters, and return values. An agent has enough information to invoke the tool correctly and understand what will happen.

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 meaningful semantics beyond the schema by explaining that `shared_image_paths` are uploaded to EVERY tab and `style_suffix` is appended to every prompt for consistency. It also clarifies `jobs` as per-image jobs with prompts and output paths.

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

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

The description states a specific action ('Generate MANY images on chatgpt.com IN PARALLEL') with a clear resource (chatgpt.com) and outcome (save each to disk). It also differentiates itself from the single-image sibling `chatgpt_generate_image` through the emphasis on batching and parallelism.

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 clear context for when to use it: generating many images in parallel and saving results to disk. It provides conditional guidance for consistent feeds using `shared_image_paths` and `style_suffix`, plus a prerequisite ('Requires an authenticated chatgpt.com session'). It does not explicitly name alternatives or state when not to use it, but the use case is clear enough.

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 clearly explains side effects: opens a fresh chat, optionally uploads reference images, submits the prompt, waits for completion, and writes a PNG to disk. It also discloses authentication requirements and a realistic performance caveat (~60-120s), giving the agent important operational expectations.

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

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

The description is well-structured and front-loaded with the core purpose, followed by the workflow, prerequisites, return value, and performance warning. Every sentence adds useful information; there is 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 moderate complexity, the absence of annotations, and the absence of an output schema, the description is remarkably complete. It covers behavior, prerequisites, return data (saved path and pixel dimensions), and a critical timeout consideration. An agent has enough context to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds some color, such as reference images being used for inputs like a brand logo and output being a PNG at output_path, but it does not provide substantial meaning beyond what the input 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 clearly identifies the tool's purpose: generate or edit an image on chatgpt.com, save it to disk in one call. It uses specific verbs and resources, and describes the full pipeline. However, it does not explicitly distinguish itself from the sibling chatgpt_generate_batch, so an agent must infer which one to choose based on 'ONE call' wording.

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: requires an authenticated chatgpt.com session, instructs to import cookies first via cookie_import, and warns to set timeout_ms because generation is slow. It does not explicitly state when to use this tool versus chatgpt_generate_batch or other image-related tools, so it stops short of full when/when-not 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and target; it does not explain behavior for already-checked elements, disabled elements, whether the action dispatches native events, or whether it forces checking a radio button.

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

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

The description is extremely concise and front-loaded, with no wasted words. It earns its place but is minimal to the point of omitting useful operational detail.

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

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

The tool is simple, but the description leaves critical context undefined: what 'ref' accepts, whether it can be used on radio buttons and checkboxes both, and how it differs from 'uncheck'. Without annotations or an output schema, the description alone is not enough for reliable 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 sole required parameter 'ref' has 0% schema description coverage, and the description does not explain what 'ref' refers to. An agent cannot tell whether it is a selector, element ID, or snapshot reference from this definition alone.

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 ('Check') and the target resource ('checkbox or radio button'), so an agent can infer what the tool does. It is distinguishable from 'uncheck' by the opposite action, though it does not explicitly differentiate itself from generic 'click' or selection 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?

Usage is implied by the verb: use this tool when you want to check a checkbox or radio button. However, there is no guidance about when to prefer this over 'click', 'click_role', or 'select_option', and no mention of prerequisites like element visibility or enabled state.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add a useful behavioral detail: 'Auto JS-fallback for overlays.' However, it does not mention side effects such as navigation, dialog handling, waiting behavior, or return values, which are relevant for a mutation-like action.

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, front-loaded sentences with no filler. The primary action and a key behavioral fallback are stated efficiently, making it easy for an agent to parse 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?

For a simple click tool, the description covers the core input (ref from snapshot) and one behavioral detail, but it omits explanation of optional parameters, possible side effects, and return behavior. Without annotations or an output schema, this is adequate but not fully complete for robust tool selection and 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 description coverage is only 33%, with only 'ref' documented in the schema. The description adds nothing about the 'button' or 'dblclick' parameters, which are left to their enum/default values and names. With low schema coverage, the description should compensate but does not.

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 ('Click'), the resource ('element by ref ID'), and the source ('from browser_snapshot'). This directly distinguishes it from siblings like click_text, click_role, and mouse_click_xy, which use different selection mechanisms.

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

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

The description implies the prerequisite of having a ref from a browser_snapshot, but it does not explicitly state when to prefer this tool over alternatives like click_text, click_role, or mouse_click_xy, nor does it provide any when-not-to-use guidance. The usage context is clear but the comparison to siblings is left to inference.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It transparently describes the sequence: click, wait, then return a snapshot. It also signals the likely side effect that clicks may trigger navigation or dialogs. It does not detail failure behavior or edge cases, but the core behavior is clearly disclosed.

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

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

The description is a single, well-structured sentence that front-loads the operational behavior and then adds the target use case. There is no filler or redundant 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?

For a tool with two parameters, full schema coverage, and no output schema, the description is sufficiently complete. It explains the operation, the return value ('snapshot'), and the intended scenario. Nothing essential is missing for an agent to decide when and how to call 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?

Schema description coverage is 100%, so the schema already documents both parameters. The description reinforces that 'ref' is used for clicking and 'wait' happens before snapshot, but it does not add significant new meaning beyond the schema's own 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 a specific compound action: 'Click element by ref + wait + return snapshot.' It clearly identifies the resource (element by ref), the action (click), and the follow-up behavior (wait and snapshot). It also distinguishes itself from sibling click tools by mentioning the snapshot return and the navigation/dialog context.

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

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

The description provides clear usage context: 'Perfect for buttons that trigger navigation/dialog.' This tells the agent when the tool is appropriate. However, it does not explicitly mention when not to use it or name alternatives like click_and_wait or browser_snapshot.

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 discloses the key behavior: the tool clicks, then waits, and the operation is atomic. However, it leaves unspecified what happens when both wait_for_url and wait_for_selector are provided, what a timeout does, how navigation is detected, and what the response looks like on success or failure. With no annotations, this is only moderate 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 short sentences with no filler. The action sequence is front-loaded and the atomicity benefit is stated in a tight second sentence, making the description 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?

For a five-parameter operation with no annotations and no output schema, this description is too thin. An agent cannot determine how to provide the click target, how the wait conditions interact, or what constitutes a successful call, so the tool is not fully callable from the description alone.

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 only 40%, with ref, selector, and timeout_ms undocumented. The description does not clarify how to specify the click target via ref versus selector, how timeout_ms behaves, or whether wait_for_url and wait_for_selector are mutually exclusive. It loosely maps 'navigation or selector' to parameters but fails to compensate for the schema gap.

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

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

The description states a specific compound action: 'Click element then wait for navigation or selector.' This clearly distinguishes the tool from plain click, wait_for, and wait_for_navigation by naming its core sequence and the two wait targets.

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?

Atomic — fewer roundtrips than separate click + wait_for' explicitly positions the tool as the combined alternative to two separate calls. It gives enough context for an agent to prefer it when both actions are needed, though it does not enumerate when not to use it or compare with click_and_snapshot.

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 explaining the action, and it does say this performs a click at an element corner rather than the centre. However, it does not disclose details such as how coordinates are computed, whether the element is scrolled into view, or what happens if the element cannot be found.

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 wasted words. It conveys the action, the target location, and the typical use case efficiently.

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

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

Given there are no annotations, no output schema, low schema coverage, and many sibling click-related tools, this description is not complete enough. An agent still lacks guidance on required fields, whether `ref` or `selector` must be used, return behavior, and how this differs from tools like `click_element_offset` or `humanize_click`.

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 low, with only `offset` having a schema description. The tool description does not explain how to specify the target element via `ref` or `selector`, nor does it clarify the relationship between `corner`, `offset`, and the click position. It adds purpose-level context but fails to compensate for the undocumented parameters.

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

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

The description states a specific action ('Click a corner of an element') and immediately clarifies the intended use case with close/X buttons, delete icons, and dismiss controls. It explicitly contrasts with centre clicks, which distinguishes it from the sibling `click` tool and other click variants.

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 clear context about when this tool is appropriate: clicking corner-positioned controls like close buttons and dismiss icons. It does not explicitly name alternatives or state when not to use it, so it falls just short of full 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 behavioral burden. It explains the coordinate model (percentage position inside an element) and contrasts with center-clicking. However, it does not disclose how the element is targeted (ref vs selector), whether scrolling or waiting occurs, or what happens for invalid percentages.

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

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

The description is a single efficient sentence that front-loads the purpose and immediately gives relevant use cases. Every clause adds value with no redundant filler.

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

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

The tool has four parameters with no required fields, no annotations, and no output schema, so the description must do more to make invocation unambiguous. It fails to explain the relationship and expected usage of ref versus selector, and does not cover edge behavior for coordinates. This makes correct selection and invocation less certain for an autonomous 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 only 50%, and the description does not clarify the two undocumented parameters ref and selector. It adds conceptual meaning to x_percent and y_percent but relies on schema text for the boundary definitions. This leaves ambiguity about how to specify the target element.

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: clicking at a percentage position inside an element rather than its center. It also gives concrete examples (wide labels, sliders, split buttons) that convey the intended use case. However, it does not explicitly distinguish itself from related sibling tools like click_at_corner or mouse_click_xy.

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 usage context with real-world examples such as wide labels and sliders, which helps an agent know when this tool is appropriate. It lacks explicit exclusion guidance or named alternatives, but the context is sufficient for most cases.

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 behavioral burden. It usefully discloses that multiple matches produce a candidate list rather than an arbitrary click. However, it does not describe behavior for unique matches, no matches, or what happens after a successful click, which are relevant for a mutating action.

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 tight sentences with no filler. The main action and targeting mechanism come first, and the ambiguity guard is explained concisely by referencing click_text.

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 relatively simple and the schema covers all parameters, but there are no annotations and no output schema. The description covers the key ambiguity behavior yet omits edge-case behavior and post-click expectations, leaving the definition only partially complete for an agent with no other 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?

Schema coverage is 100%, so the input schema already documents all four parameters. The description adds no extra meaning beyond confirming that role and name are the targeting criteria and that ambiguity is handled via the candidate-list behavior.

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

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

The description states a specific action ('Click element') with a clear targeting mechanism ('by ARIA role and name'). It also references the sibling click_text and signals how this tool differs, helping an agent select it over 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 implies when to use this tool: when the element is identified by ARIA role and accessible name. It references click_text for the ambiguity guard but does not explicitly say when to prefer click_role over click_text or other click variants, nor does it state 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 the behavioral disclosure burden, and it does disclose the important non-obvious trait: ambiguous matches cause an explicit failure with a numbered candidate list rather than a silent first click. It also explains the narrowing options. It doesn't cover exact-match behavior or post-click waiting, but the core behavior is transparent.

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

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

The description is a single dense sentence that front-loads the primary action, then adds the highest-value behavioral caveat and disambiguation instructions. Every clause earns its place; no repetition of schema fields.

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 click-by-text tool with no output schema, the description covers the essential operation, failure mode, and how to resolve ambiguity. The remaining gaps are minor: exact matching semantics and the success return value, neither of which is fatal to correct 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 75%, and the description adds useful practical examples for `within` and clarifies index semantics (0-based, -1 requires unique match). However, the `exact` parameter has no schema description and is never explained in the tool description, leaving a notable semantic gap about whether matching is exact or substring-based.

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 opening sentence "Click element by visible text" names the exact verb, resource, and locator strategy, setting it apart from siblings like click_role, click, and find_by_text. The rest of the description clarifies scope without muddying the core purpose.

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

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

The context for using click_text (clicking by visible text) is implied by the first sentence, and the ambiguity-failure note gives practical guidance on narrowing or choosing among matches. However, it never explicitly says when to prefer this over click, click_role, or find_by_text, nor does it state when not to use it.

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

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

With no annotations provided, the description carries the full burden, and it is exceptionally detailed: it discloses shadow-root handling via the frame API, render polling, skip-if-solved behavior, humanized real-mouse clicking with retries and nudges, and per-attempt token verification. This gives an agent a realistic model of what the tool does.

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?

Three sentences, front-loaded with the core purpose, followed by mechanism and a final limitation note. Every sentence earns its place and the structure is easy to parse.

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

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

For a complex anti-bot interaction with no annotations or output schema, the description covers behavior, retries, verification, and limitations well. It is only slightly incomplete in not specifying the explicit return or failure behavior when max_attempts is exhausted or the widget is never found.

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

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

Schema description coverage is 100%, so the schema already documents all 4 optional parameters. The description adds some conceptual color, such as polling for render and retrying with a nudge, but it does not add material detail beyond what the parameter descriptions already provide.

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 first sentence states a specific verb+resource: 'Auto-solve Cloudflare Interactive Turnstile checkbox.' The rest of the description explains the exact mechanism, and the Cloudflare Turnstile focus clearly differentiates it from generic sibling tools like click, click_text, and humanize_click.

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 gives a usage boundary: 'Managed Challenge full-page interstitials still need mcp-stealth-chrome,' telling agents when this tool is not sufficient and naming the alternative. It also notes the tool skips if already solved, which helps an agent decide when to call it.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read-like operation but does not explain what the returned messages contain, whether capture must be active, or whether calling it clears or preserves the captured log.

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

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

The description is a single, front-loaded sentence with no filler. Every word earns its place, and there is nothing redundant or extraneous.

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 too thin to be fully actionable. It does not explain the relationship to console_start, the expected return format, or behavior in edge cases such as an empty capture buffer. An agent could call this tool without knowing whether it depends on prior state.

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 there is no parameter-level semantic burden on the description. The schema coverage is effectively 100%, and no additional parameter explanation is needed.

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

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

The description clearly states the operation ('Get') and the resource ('captured console messages'), making the tool's purpose immediately understandable. It is distinguishable from sibling console_start by the get-vs-start verb, though it does not explicitly mention that 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?

No guidance is provided about when to call this tool versus related tools such as console_start. The description does not mention prerequisites like needing to start capture first, or what happens if no console messages have been captured.

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

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

With no annotations, the description must carry full behavioral disclosure. It mentions the scope ('all tabs') but does not state side effects, whether capturing is idempotent, whether previous messages are cleared, or whether console_get is required to retrieve the captured messages. This leaves important behavioral 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 a single sentence that is immediately actionable and front-loaded with the verb. No filler or redundant wording.

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

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

For a zero-parameter start command, the core action is stated, but the description leaves uncertainty about the return value, how to stop capturing, and the need to pair with console_get. Given no output schema and no annotations, a little more context would improve completeness.

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

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

The tool has zero parameters, so the schema coverage is trivially 100% and there is nothing for the description to add about parameters. The baseline 4 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 uses a specific verb and resource: 'Start capturing console messages from all tabs.' This clearly distinguishes the starting action from related tools like console_get, which likely retrieves captured messages, and network_start, which starts a different kind of capture.

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

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

No guidance is given about when to invoke this tool versus alternatives, what prerequisites exist, or how it relates to console_get. The description simply states what it does without explaining the intended workflow or when not to use it.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal the important destructive condition 'Both empty = clear all', but it does not state that deletion is irreversible, how name and domain narrowing works, or whether clearing cookies affects all tabs or only the current context. This leaves significant behavior unexplained for a destructive 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 extremely short and front-loaded: the core action comes first, followed by the critical clearing condition. Both sentences earn their place and there is no filler. It sacrifices completeness for brevity, which is appropriate given 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?

For a destructive tool with no annotations and no output schema, the description is incomplete. It does not clarify how to target a single cookie, what the exact matching behavior is, or what happens when only one parameter is provided. An agent can invoke it safely only for the 'clear all' case; targeted deletion remains ambiguous.

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

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

Schema description coverage is 0%, so the description must explain the two parameters. It only explains the case where both are empty; it never explains what happens when name is set, domain is set, or both are set. The agent is left to guess the matching semantics for a specific cookie deletion.

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

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

The description states a clear verb and resource: 'Delete cookies'. It also adds the key scope detail that leaving both parameters empty clears all cookies, which distinguishes it from cookie_set, cookie_list, and cookie_export. It does not differentiate sibling delete-like tools because there are none, so clarity is high but not maximum.

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

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

There is no guidance on when to use this tool versus alternatives. The only contextual hint is 'Both empty = clear all', which describes invocation behavior rather than the situations where deletion is appropriate. It does not mention conflicts with cookie_set, cookie_export, or session storage 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?

No annotations are provided, so the description must carry the transparency burden. 'Export' implies a non-mutating read, but the description does not explicitly confirm absence of side effects or explain cookie scope/sensitivity beyond the schema. It adds the session-transfer context, but falls short of full behavioral disclosure.

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 short sentences with no filler. Each sentence earns its place: the first defines what the tool returns and the second identifies the primary use case.

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 single-parameter, no-output-schema tool, the description is mostly complete: it defines the return as a JSON string and names the companion import tool. It could add a note on the exact return shape or limitations, but nothing critical is missing.

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 the domain parameter already documented as 'Filter by domain (empty = all)'. The description adds no extra meaning to the parameter, so a 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?

Clearly states the tool exports all cookies as a JSON string, with a specific verb and resource. The phrase 'as JSON string' and the pairing with cookie_import distinguish it from similar siblings like cookie_export_file and cookie_list.

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 says to use it with cookie_import to transfer session, giving a clear intended workflow. Does not state exclusions or compare with cookie_export_file, but the companion-tool 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 provided, the description carries the full behavioral burden. It usefully discloses that the output is all cookies in Playwright format, but it does not state whether an existing file is overwritten, whether cookies are removed from the session, or what path/permission requirements apply. These are moderate gaps, though not fatal for a straightforward file export.

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 with no filler: it front-loads the action, scope, destination, and format. The parenthetical about Playwright format adds essential information without bloating the text.

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 single-required-parameter tool with full schema coverage, the description plus schema is enough to invoke the tool correctly and understand the result: what it does, where it writes, and the file format. The lack of an output schema and overwrite/return behavior notes are minor for correct 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 description coverage is 100% and the only parameter is already described as 'Output JSON file path'. The description adds no additional parameter-level meaning beyond the Playwright format context, so it stays at the baseline for a fully documented 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 states a specific verb and resource ('Export all cookies'), a destination ('JSON file'), and a format ('Playwright format'). This clearly differentiates it from the sibling cookie_export tool, which would otherwise be the main source of confusion.

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 file destination implies this tool should be used when cookies need to be persisted to disk, but the description does not explicitly say when to prefer it over cookie_export or how it relates to cookie_import_file. The usage context is inferable rather than directly stated.

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

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

No annotations are provided, so the description carries the full burden. It does disclose a meaningful behavioral effect ('Restores session state') beyond merely saying 'import cookies'. However, it does not state whether imported cookies replace existing cookies or merge with them, nor does it mention potential side effects such as invalidation of the current session until a reload.

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

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

The description is two short sentences with no filler. The core action and input format are front-loaded, and the second sentence adds a meaningful behavioral consequence. Every word earns its place.

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

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

For a single-parameter tool with no output schema and no annotations, the description plus schema is mostly sufficient for basic invocation. However, it leaves open important practical details: whether the operation overwrites or merges cookies, whether a page reload is needed to see the restored session, and what happens if the JSON is malformed or refers to an invalid domain. More context would improve safe usage.

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

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

Schema description coverage is 100%, so the schema already documents that cookies_json is a JSON array of cookies. The description adds a small amount of value by indicating the JSON should come from cookie_export, but it does not compensate or expand beyond what the schema provides. 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 a specific verb ('Import'), a specific resource ('cookies'), and the input format ('JSON'), and explicitly ties the source to 'cookie_export'. It also communicates the intended outcome ('Restores session state'), which distinguishes it from related operations like cookie_export and cookie_import_file.

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 'from cookie_export' provides a clear context for when this tool should be used: after exporting cookies with the sibling cookie_export tool. It does not explicitly discuss alternatives such as cookie_import_file or storage_state_load, but for a one-parameter tool with a clear pairing, the implied usage 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether importing replaces existing cookies, merges with them, or requires an active browser context. This is a meaningful gap for a state-mutating operation.

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 filler. It front-loads the action and source, and the format qualifier is placed meaningfully at the end.

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 low complexity and single parameter, the description covers the essential input. However, without annotations or an output schema, it omits the overwrite/merge side effects and does not clarify how this tool relates to cookie_import, leaving moderate 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?

The schema already fully documents the path parameter at 100% coverage, so the baseline is 3. The description adds value by clarifying that the file content must be in Playwright cookie JSON format, which is important for correct invocation.

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

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

The description states a specific action ('Import cookies') and resource ('a JSON file'), and adds the Playwright format constraint. It is clear, though it does not explicitly differentiate itself from the sibling cookie_import 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 implies the tool should be used when cookies are available as a Playwright-format JSON file path. However, it provides no explicit guidance about when to prefer this over cookie_import or cookie_export_file, and no exclusions are stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'List cookies' implies a read-only operation but does not state scope, return format, default domain behavior, 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 short and free of fluff, but it is under-specified rather than appropriately concise. It restates the tool name without adding useful context, similar to a placeholder-level 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 tool with one optional parameter, no annotations, and no output schema, the description should clarify domain filtering, output shape, and relationship to the active browser context. It provides none of this, leaving the agent to guess invocation 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?

The only parameter, 'domain', is entirely undocumented in the description. With 0% schema description coverage, the description needed to compensate by explaining whether domain filters the results or is required, but it does not.

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 clear verb and resource ('List cookies') and is unambiguous about the core operation. However, it does not differentiate this tool from similar cookie-related siblings like cookie_export or http_session_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?

No guidance is provided about when to use cookie_list versus alternatives such as cookie_export or http_session_cookies. The description gives no context for selecting this tool over related ones.

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

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

No annotations are provided, so the description must disclose behavioral traits itself. It does so by revealing the non-obvious Firefox session-cookie behavior: expires_days=0 keeps the cookie in memory only and it is lost after browser_close even though the profile persists. This is valuable behavioral context beyond the basic action.

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 filler. The core action is front-loaded, and the important caveat is placed immediately after. Every sentence earns its place.

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

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

For a mutating cookie tool with no annotations and no output schema, the description provides the essential operational context: how to set a cookie and how to control its lifetime. It does not discuss overwriting behavior or domain/path constraints, but the critical persistence scenario is covered well enough for correct 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 only 38%, and the description compensates for the most subtle parameter by explaining what expires_days means in practice and giving an example value. The remaining parameters (name, value, domain, path, secure, same_site) are either self-explanatory or already described in 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 states a specific verb and resource: 'Set a cookie.' This immediately distinguishes it from sibling tools like cookie_delete, cookie_list, cookie_import, and cookie_export. An agent can understand the tool's core function without opening the schema.

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

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

The description provides clear, practical guidance on how to achieve a persistent login session ('Pass expires_days (e.g. 30)') and warns about the default session-cookie behavior. It does not explicitly name alternative cookie tools, but for a simple set operation 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?

With no annotations, the description carries the full burden and does disclose the essential behavior: it returns a compact summary plus an enumerated `intent` classification. It does not explicitly state that the page is not modified, but the read-only nature is strongly implied by 'describe' and 'summary'.

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 compact and front-loaded with the core value proposition. The intent enum is useful and earns its place, and the comparative cost note is one short clause. No filler exists.

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

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

For a zero-parameter read-only utility, the description explains what the tool returns, the key fields covered, the intent taxonomy, and how it fits into agent workflows. There is no output schema, so this fills the needed gap without requiring further documentation.

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

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

The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to add about arguments. The baseline of 4 applies because parameter semantics are simply not a concern for this tool.

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 opens with a specific outcome: 'Compact LLM-friendly page summary (title, heading, key buttons, forms)' and then identifies a unique differentiator, the classified `intent` field. This clearly distinguishes the tool from browser_snapshot and other snapshot-like siblings.

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

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

It explicitly positions the tool against browser_snapshot ('Cheaper than browser_snapshot for agent context') and explains when it is valuable ('agent can branch with one read'). It does not spell out exclusions or say when a full snapshot is necessary, so it falls just short of fully explicit when-not 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?

The word 'heuristic' usefully signals non-deterministic, inference-based results, and the vendor list clarifies detection scope. However, with no annotations provided, the description carries the full transparency burden and does not disclose return semantics (vendor name vs. null), whether analysis is passive, or failure 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?

A single 15-word sentence with zero filler. The scoping phrase 'on current page' is front-loaded, and the vendor examples are packed efficiently into the trailing parenthetical.

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?

Adequate for invocation — an agent knows there are no arguments and what the tool checks. But with no output schema and no annotations, the missing return-value semantics leaves the agent unable to interpret the result or act on it confidently.

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 takes zero parameters and schema coverage is 100%, so there is nothing for the description to add about inputs. The baseline 4 for zero-parameter tools applies; no param documentation gap exists.

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

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

The description states a specific action — 'detection of anti-bot vendor' — on a specific resource, 'current page', and names concrete target vendors (Cloudflare, DataDome, Akamai, PerimeterX, Imperva). This distinguishes it from siblings like detect_content_pattern and fingerprint_audit without needing to inspect their schemas.

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

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

No guidance on when to use this tool versus alternatives. It does not mention, for example, using it before choosing click_turnstile or to diagnose blocked navigation, nor does it name any sibling as a fallback or exclusion. An agent must infer the use case entirely.

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 full behavioral burden. It only says 'Auto-detect' and 'suggest CSS selectors', which is essentially the tool's purpose. It does not disclose whether the operation is read-only, what the returned output format is, whether the page is modified, or how the detection works.

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 core purpose and followed by an explicit usage directive. There is zero wasted wording, and each sentence earns its place.

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

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

The tool is simple with one optional parameter and no output schema, so the description need not be exhaustive. However, because there is no output schema and no annotations, the lack of any detail about the format or structure of the suggested selectors leaves an agent guessing about the return value.

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 min_items parameter is already documented in the schema. The description does not mention min_items or add any extra meaning beyond the schema, 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 states a specific verb ('detect'), resource ('repeated content patterns'), and outcome ('suggest CSS selectors'), with concrete examples (cards, listings, rows). It also names the related tool extract_structured, which distinguishes it from siblings.

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

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

The instruction 'Run this BEFORE extract_structured to find the right selectors' provides an explicit temporal condition and names the alternative tool. An agent can decide when to invoke this tool without further inference.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It covers persistence across tabs, one-shot versus persistent semantics, fire-time reading of the action, and removal behavior. This is unusually transparent for an install-style 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?

Three tight sentences with no wasted words. The most important distinguishing fact ('PERSISTENT') is front-loaded, and each sentence adds a distinct piece of information: persistence scope, dynamic action reads, and removal.

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 three simple parameters and no output schema, the description plus input schema fully covers how to install, configure, and remove the handler. There are no significant gaps that would prevent an agent from using it correctly.

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

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

Schema description coverage is only 33%, but the description adds meaningful semantics for enabled ('set enabled=false to remove it') and action ('reads its action at fire time'). The prompt_text parameter is already documented in the schema, though the description does not explain its interaction with the action 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 opens with a specific verb ('Install') and resource ('PERSISTENT dialog handler'), then immediately distinguishes it from the one-shot sibling dialog_handle. The scope ('every dialog and every tab') makes its purpose unmistakable.

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 explicitly contrasts with dialog_handle ('dialog_handle is one-shot') and explains when this persistent variant is appropriate. It also states exactly how to remove the handler with enabled=false, giving clear lifecycle 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 behavioral burden and discloses three important traits: it applies across tabs, only the first dialog is handled, and the handler clears itself afterward. This is strong transparency, though it stops short of explaining side effects on the page or how a successful handling is reported.

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

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

A single, front-loaded sentence packs the action, scope, and lifecycle behavior into the essential details with no filler. The parenthetical adds critical behavioral rules 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?

The tool has no output schema or annotations, and with 0% parameter coverage the description should make the two parameters and their semantics clear, which it does not. It describes the handler lifecycle well but leaves prompt_text undefined and says nothing about return values or invocation results, so an agent cannot fully predict the call.

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

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

Schema description coverage is 0%, so the description needed to explain action and prompt_text but does not mention either. The action enum and defaults are visible in the schema, but the meaning of prompt_text and when it applies (e.g., only when accepting a prompt) is left completely unspecified.

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 resource ('handler for the next alert/confirm/prompt') and adds global scope ('ANY open tab'), which clearly differentiates this one-shot manual handler concept from a generic auto-handler sibling. It tells an agent exactly what the tool does.

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

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

It gives clear context: this is for the next dialog on any open tab, so an agent knows when to call it before an action that might trigger a dialog. It does not explicitly name alternatives like dialog_auto_handle or provide when-not-to-use guidance, but there are no misleading exclusions.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'drag from one element to another' and does not reveal whether this simulates mouse events, dispatchs HTML5 drag/drop events, waits for animations, or has any side effects or failure modes.

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

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

The description is a single short sentence with no filler words. The action is front-loaded and every word earns its place.

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

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

For a simple two-parameter tool with fully documented schema, this is a minimum viable description. It is missing behavioral depth and usage guidance, but an agent familiar with drag-and-drop semantics can infer the basic call. It does not explain when to choose this over siblings or what event behavior 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 already documents both parameters with 100% coverage, so the descrioption does not need to compensate for missing schema information. It adds no extra meaning beyond the fact that the action moves between two elements, which is the baseline expected when schema is complete.

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

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

The description states a specific verb ('Drag') and the resources involved ('from one element to another'), which maps cleanly to source_ref and target_ref. It distinguishes the tool from sibling click/hover actions by the drag semantics, though it does not explicitly mention any sibling or edge case.

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 hover, click, mouse_move, or mouse_click_xy. There are no prerequisites, exclusions, or timing considerations, so an agent gets no help choosing this over the many sibling input-simulation 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?

Annotations are entirely absent, so the description carries the full burden of behavioral disclosure. It only states that JavaScript is executed, with no mention of return values, promise handling, side effects, navigation risks, or error behavior—critical gaps for an evaluation tool.

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

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

The description is a single, front-loaded sentence with no filler or repetition. It is concise, though the brevity does sacrifice some behavioral detail, which is better judged under completeness.

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?

Even though the tool has only one parameter, there is no output schema and no annotations, so the description must explain what the expression returns and warn about execution side effects. It provides neither, leaving an agent under-informed about the actual result and risks of invoking the tool.

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

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

Schema coverage is 100%, and the only parameter 'expression' already has a 'JS expression' description. The tool description adds no new parameter-level meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description states a specific action ('Execute JavaScript') and a clear resource/scope ('in page context'). This makes the tool's core function evident and subtly distinguishes it from sibling 'frame_evaluate', though it does not explicitly name or contrast with that alternative.

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

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

No guidance is given about when to prefer this tool over alternatives. The phrase 'in page context' hints at main-frame usage, but there is no explicit mention of when not to use it or when to use frame_evaluate or other scripting-related 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, the description carries the transparency burden and does disclose a real behavioral dependency: headers are only available if network_start(capture_bodies=true) was used. It also implies a non-mutating export action, though it leaves the exact return format and whether the command is executed implicit.

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 core action, and no filler. The prerequisite/clarification earns its place by preventing a common call failure.

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 3-optional-parameter, no-output-schema tool, the description explains the purpose and the one essential precondition. It could be more explicit about what the tool returns, but 'as a runnable curl command' plus full schema param docs makes correct instruction reasonably achievable.

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 3 applies. The description adds no parameter-level meaning beyond what the schema already provides for id, redact, and url_contains.

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+resource pair: 'Rebuild a captured request as a runnable curl command'. Its stated goal of replaying or sharing an API call 'without re-deriving its headers' makes the function distinct from siblings like network_get, export_har, and http_request even without naming them.

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

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

It gives a clear precondition and explicit when-to-use: 'Needs network_start(capture_bodies=true)' and replay/share scenario. However, it does not name any alternative tools or state when not to use it, so it stops short of full routing 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 behavioral disclosure burden. It discloses the dependency on network_start and the conditional inclusion of headers and bodies based on capture_bodies. This is meaningful context, though it does not describe what happens if network_start was not called or the exact output 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 compact sentence that front-loads the core purpose and immediately follows with the essential prerequisite and data-completeness caveat. Every clause adds value, and there is no redundant or filler 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?

The description covers the core workflow requirement and output format, which is good for a fairly simple tool. However, the path parameter is undocumented and the return value/file destination is not explained, which matters because path is optional with an empty default. This leaves an important gap for correct 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 description adds no parameter-level semantics. The limit parameter is documented in the schema, but the path parameter has no description in either the schema or the tool description, leaving the meaning of the default empty path ambiguous. With only 50% schema coverage, the description needed to compensate but did not.

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: exporting captured network traffic as a HAR 1.2 file, with the output being openable in DevTools and other HAR viewers. This is a specific verb plus resource, and the HAR format differentiates it from sibling tools like export_curl, though it does not explicitly name alternative 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 gives an explicit prerequisite: network_start must be called first. It also clarifies when bodies/headers will be present, tying usage to a specific capture configuration. It does not explicitly state when not to use this tool or mention alternatives, so it stops short of a 5.

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

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

With no annotations present, the description carries the behavioral burden, and it delivers: it discloses auto-deduplication, empty-item filtering, and direct-text-only extraction. These are meaningful behaviors beyond what the input schema alone implies, though it could still clarify what happens on zero matches or how the output is shaped.

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 filler: the core action is front-loaded, key behaviors are listed compactly, and the prerequisite tool usage is placed at the end. Every clause earns its place.

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

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

The rich schema covers all parameters, and the description adds the critical prerequisite (detect_content_pattern) plus key data-shaping behaviors. It does not explicitly describe the return format or no-match behavior, and there is no output schema, so it stops just short of fully complete.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters and their defaults. The description reinforces direct-text and deduplication behavior but does not add new parameter-level meaning beyond what the schema provides.

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

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

The description states a specific verb ('Extract'), a clear resource ('structured data from repeated elements'), and gives concrete examples ('cards, rows, listings'). This makes it easy to distinguish from generic scraping tools like scrape_page or extract_table without needing to inspect schemas.

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 tells the agent to run detect_content_pattern first to find the correct selectors, which is actionable guidance. It does not enumerate when to avoid this tool in favor of extract_table or scrape_page, but the scope ('repeated elements') provides enough context for most selection decisions.

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 the output format and gives no information about table selection behavior, how multiple tables are handled, how limit affects rows, whether headers are included, or what happens when no table matches.

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

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

The description is a single, efficient sentence that clearly front-loads the main purpose. It contains no wasted words, though it is so brief that it misses opportunities to convey important usage and behavior details.

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

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

Given no output schema and no annotations, the description leaves out important operational details such as how limit interacts with row extraction, whether it targets the first matching table, what the JSON array entries look like, and what error or empty behavior occurs when no table is found. More context is needed for reliable 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 schema already documents both parameters with descriptions and defaults: limit is 'Max rows' and selector is 'CSS selector for the table'. The description adds little beyond restating the HTML table context, so it meets the baseline for high schema coverage without adding significant semantic value.

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

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

The description states a specific action ('Extract data'), a specific resource ('HTML table'), and a clear output format ('JSON array'). It is distinguishable from broader siblings like get_text or get_html by focusing on structured table extraction, though it does not explicitly name any sibling 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 gives no guidance on when to use this tool versus alternatives such as query_selector_all, get_text, or extract_structured. It also does not clarify whether it operates on the current page, a URL, or a provided HTML source, leaving usage context ambiguous.

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 transparency burden and does well by disclosing the replace-always behavior and the Firefox-specific select-all workaround. It is a non-obvious behavioral detail that agents need to avoid surprising append 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?

Two tight sentences front-load the main purpose and then add a valuable edge-case detail. Every clause earns its place; there is no filler 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?

For a simple two-parameter mutation with no annotations or output schema, the description covers the critical behavior (replacement and the Firefox nuance). It leaves minor unknowns such as return value or event dispatch, but these are not essential for a straightforward fill 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?

Schema coverage is 100%, so a baseline of 3 applies. The description adds useful semantic context: ref is a ref ID targeting input/textarea elements, and value is used as replacement text, which goes beyond the schema's bare 'Element ref' and 'Text to fill'.

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

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

The description states a specific verb ('Fill') with a resource ('input/textarea') and a targeting method ('by ref ID'), making the core action clear. It does not explicitly differentiate from related siblings like type_text or smart_fill, so it falls short of a 5.

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

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

It conveys an important usage trait: the tool always replaces existing content rather than appending. However, it provides no explicit guidance on when to choose this tool over siblings such as type_text, smart_fill, or fill_form.

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 mentions that submission is optional, but does not explain that field refs come from a snapshot, what happens after submit (e.g., navigation or waiting), or whether filling triggers 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 a single, front-loaded sentence with no filler. Every word contributes to the core operation, which is appropriate for a relatively simple tool.

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

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

The description is too thin for a mutation tool with no annotations and no output schema. It omits necessary context such as obtaining refs from a snapshot, whether submission may cause navigation, and how this compares with other form-related tools.

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

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

The description adds modest context by saying 'multiple form fields' and 'optionally submit', which maps to the 'fields' and 'submit_ref' parameters. However, the schema already documents 'ref', 'value', and 'submit_ref', and the description does not meaningfully deepen the understanding of either 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 states a specific verb and resource: filling form fields, with an optional submit action. It is clear, but it does not explicitly differentiate itself from siblings such as 'fill', 'smart_fill', or 'form_introspect', relying on the word 'multiple' to imply 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?

No guidance is given about when to prefer this tool over alternatives like 'fill', 'smart_fill', or 'type_text'. The description only implies use for multiple fields, with no exclusions, prerequisites, or alternative-selection criteria.

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

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

No annotations are provided, so the description carries the disclosure burden. It does disclose that the operation returns both a ref and a match count, which is useful behavioral information. However, it omits what happens on zero matches (e.g., null ref vs. empty result) and gives no details on matching semantics (exact vs. partial, case sensitivity).

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

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

The description is a single sentence that front-loads the action and target, then states the return. Every element is informative with no redundancy or filler.

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

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

With no output schema, the description adequately states the return value ('ref + how many matched'). The schema covers both parameters. The main gaps are the lack of usage guidance and zero-match behavior, but for a simple find tool with one required parameter, the information is largely 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?

Schema description coverage is 100%, so the schema already documents both 'label' and 'within' with examples and allowed patterns. The description adds only a parenthetical mention of '<label>' to clarify the label type, which is a minor addition beyond the schema. No further parameter guidance is needed.

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 ('Find') and a clear resource ('input element') with an explicit matching mechanism ('by its label text (<label>)'). It also states the return value ('ref + how many matched'), which distinguishes it as a lookup rather than a mutation. While it doesn't name sibling tools, the label-text criterion is specific enough to distinguish from find_by_text and find_by_placeholder.

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

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

The description implies a use case (locating an input by its label) but provides no explicit guidance on when to choose this tool over alternatives like find_by_placeholder or find_by_text. No exclusions, prerequisites, or alternative recommendations are given, leaving the agent to infer routing from the name and label reference.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that it returns a ref and match count, but does not clarify whether the operation is read-only, how matching works (exact, partial, case-sensitive), or what happens when no matches or multiple matches are found.

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 streamlined sentence that front-loads the purpose and then specifies the return value. There is no filler, repetition, or unnecessary detail.

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

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

For a simple two-parameter lookup tool, the description covers the core function and return shape adequately, and the schema handles the within parameter. However, with no output schema and no annotation coverage, missing details such as no-match behavior and matching semantics leave minor but real 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 50%, with placeholder lacking a schema description and within having one. The description partially compensates for placeholder by identifying it as the search text, but adds no detail about matching behavior or formatting. The within parameter is already covered by 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 clearly states a specific action ('Find input by placeholder text') and resource, and briefly mentions the return value. It does not explicitly distinguish itself from sibling tools like find_by_text or find_by_label, but the placeholder-specific focus makes the purpose reasonably clear.

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

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

There is no guidance on when to use this tool versus alternatives such as find_by_text or find_by_label. The description implies it is for locating inputs via placeholder text, but it provides no exclusions, prerequisites, or alternative routing.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It reveals that the tool returns every match, a total count, and per-candidate refs/ancestor paths. It could clarify the relationship between 'every match' and the schema's limit parameter, but it does communicate the core 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?

Two tightly worded sentences with no filler. The main behavior is front-loaded, the return-value detail earns its place, and the usage guidance is appended efficiently.

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

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

The description compensates for the missing output schema by outlining the return shape, and the schema covers parameter details. However, the claim of returning 'EVERY match' conflicts with the limit parameter's 'Max candidates to describe,' leaving ambiguity about how many candidates are actually detailed.

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

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

The description adds little meaning for exact, limit, or within beyond what the input schema already provides. With 75% schema description coverage, the schema does most of the parameter-documentation work; the description mainly reinforces the text 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?

States a specific operation, 'Find elements by visible text,' and names the resource. The mention of returning total matches plus refs and ancestor paths clearly distinguishes it from generic get_text or browser_snapshot.

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?

'Skip browser_snapshot when you know the text' is an explicit routing rule to a sibling tool. It also implies the intended use case: verifying which matched element you would actually click. It does not enumerate other alternatives, but the guidance 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?

With no annotations, the description fully carries the behavioral burden, and it does so explicitly: 'Read-only: it inspects, it does not change anything.' It also discloses the inspection scope (site-observed rather than local) and that it actively flags contradictions, going beyond a minimal side-effect statement.

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 no filler: the core behavior leads, the detection rationale follows, and the read-only guarantee closes. Every clause earns its place.

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

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

For a parameterless read-only tool this is largely complete: an agent knows what to invoke and what to expect conceptually. However, there is no output schema and the description does not characterize the shape of the reported fingerprint or the flagged contradictions, leaving some interpretation to 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?

The input schema is empty, so there are no parameter meanings to clarify; baseline 4 applies. The description still adds context by clarifying the implicit subject ('this browser' and 'a site') even though there are no parameters.

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

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

The first sentence names a specific action ('Report') and a precise resource ('the fingerprint a site actually sees from this browser'), then adds a distinguishing behavior ('flag internal contradictions') that separates it from generic fingerprint or anti-bot tools. This is not a tautology and gives an agent a concrete target.

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

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

It gives clear context for when this tool is valuable: when the exposure is not a single fingerprint value but the inconsistencies across values that trigger bot detection. It does not name alternative tools or state when not to use it, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the behavioral burden. 'Analyse a form' and the list of read-only attributes (current value, validation state) make the non-destructive intent clear, and 'Tells you what to fill' explicitly stops short of filling. It does not explicitly state 'read-only' or document failure modes, but the behavioral profile is well conveyed.

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 no fluff: the first names the operation and all key output dimensions, the second gives the practical value. Every clause earns its place, and the structure is front-loaded with the core behavior.

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

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

For a single-parameter, no-output-schema tool, the description is complete: it specifies what the tool analyzes, what per-field results are returned, and when an agent should reach for it. The input schema handles the empty-selector edge case, so there are no significant gaps for correct selection and 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 fully documents the single form_selector parameter, including its default value and the empty-selector behavior. The description adds no additional parameter-specific syntax or constraints, so it does not need to compensate; 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 names the exact resource ('a form') and a specific inspection verb ('Analyse'), then enumerates the per-field data returned: label, type, current value, constraints, validation state, and framework. This clearly frames the tool as read-only form analysis, distinguishing it from snapshot tools and fill 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 gives two concrete use triggers: knowing what to fill and diagnosing why a submit is rejected. It also implies a when-not by contrasting with snapshot-based guessing. It does not explicitly name fill_form or smart_fill as the alternatives for actually filling, so it falls just short of fully explicit routing.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It only states the core action and does not disclose return values, side effects of executing arbitrary JavaScript, error behavior, or how frame selection resolves when frame_name is empty. This 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?

The description is a single sentence with no filler and is appropriately front-loaded. It communicates the core purpose immediately without redundant phrasing.

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 annotations and no output schema, so the description needs to compensate by explaining return behavior and side effects. It does not specify whether the result of the JavaScript expression is returned, how frame selection works beyond schema defaults, or any execution caveats.

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 67%, with frame_name and frame_index documented in the schema, but the required expression parameter has no schema description. The description adds that the operation targets a frame but does not explain what the expression should return or how it is evaluated.

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

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

The description states a clear verb and resource: 'Execute JavaScript' inside a 'specific frame/iframe.' This distinguishes it from the generic sibling 'evaluate' by narrowing scope to frames, though it does not explicitly name the alternative.

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

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

The description implies usage when a JavaScript expression must run in a frame rather than the main page, but it does not explicitly state when to use this tool versus 'evaluate' or how to decide between frame_name and frame_index. Usage context is present but not fully articulated.

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 says 'get a specific attribute value,' with no information about behavior when the attribute is missing, whether the element must exist, whether any waiting occurs, or what the return value looks like.

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

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

The description is a single sentence with no filler and the key action is front-loaded. Every word contributes to stating the tool's purpose.

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 two required string parameters, no annotations, no output schema, and a 0% schema description coverage, this description is too thin. An agent cannot confidently construct a valid call without knowing how to define ref or what to expect back for missing attributes.

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

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

Schema description coverage is 0%, so the description must compensate. It implicitly maps 'attribute' to an attribute name and 'ref' to an element, but it does not explain what form ref takes, what attribute names are expected, or any constraints on the values. This adds only minimal meaning beyond the bare 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 names a specific verb and resource: retrieve a specific attribute value from an element. The phrase 'attribute value' clearly distinguishes this from sibling getters like get_text, get_html, and get_url, so an agent can tell what it does.

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

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

No guidance is given about when to use this tool versus alternatives such as get_text, get_html, inspect_element, or evaluate. The description states what it does but not when it is the right choice or when it is not.

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?

There are no annotations, so the description carries the behavior disclosure burden. It communicates a read operation but does not describe what kind of HTML is returned, whether the selector targets the first or all matching elements, or what the 'outer' behavior affects. An agent lacks key behavioral context beyond the tool name.

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

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

The description is a single short sentence with no redundant wording or filler. It is front-loaded and easily parsed, though its brevity comes at the cost of detail covered by other dimensions.

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?

No output schema, no annotations, and 0% schema description coverage mean the tool requires a richer description. An agent cannot confidently determine what 'outer=false' returns, whether the default selector 'body' returns only the body element's HTML, or how this compares to related extraction tools.

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

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

Schema description coverage is 0%, and the description does not explain either parameter. 'outer' is particularly ambiguous without explanation, and the description adds no meaning to 'selector' beyond the property name.

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

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

The description states a clear action and resource: getting HTML content from either the page or a selected element. It is specific enough to understand the tool's basic function, though it does not distinguish it from similarly named siblings such as get_text or get_attribute.

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

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

No guidance is provided about when to use this tool instead of alternatives like browser_snapshot, get_text, inspect_element, or scrape_markdown. The description gives no context, prerequisites, or exclusions.

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

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

No annotations are present, so the description carries the full burden. It does disclose the scope and output shape ('all links' with 'URL and text'), which is helpful. However, it does not mention whether the operation is read-only, whether it waits for page load, how relative URLs are handled, or whether hidden/duplicate links are included.

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

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

The description is a single front-loaded sentence with no filler. Every phrase contributes to understanding the tool's purpose and expected output, and it is easy for an agent to parse 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?

For a simple getter with one optional, self-documented parameter, the description is mostly complete. The stated output ('URL and text') partially compensates for the lack of an output schema. Minor ambiguity remains around the exact matching syntax of the URL pattern and the precise return field names, preventing a perfect 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?

The schema covers 100% of the single parameter, including its meaning and default behavior ('Filter links by URL pattern (empty = all)'). The description itself adds no additional parameter semantics beyond what the schema already provides, 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 exact operation: 'Get all links on the page with URL and text.' The scope is explicit ('all links'), the resource is clear ('the page'), and the output content is specified ('URL and text'), distinguishing it from sibling tools like get_url or get_text.

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

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

The description implies when to use the tool: when you need all links on the current page. However, it provides no explicit guidance about when to prefer this over alternatives such as query_selector_all, extract_structured, or inspect_element, and it gives no exclusions or when-not-to-use conditions.

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

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

No annotations are provided, so the description carries the full disclosure burden and meets it: it reveals the capture mechanism ('hook installed at browser_launch'), the lifecycle behavior (buffer resets on every navigation), and the capacity limit (max 100 entries per page load). These are non-obvious behaviors an agent cannot infer from the name or schema.

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

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

Three sentences, each earning its place: what is returned, how and when it is captured with the reset caveat, and the entry cap. The main purpose is front-loaded with zero filler.

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

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

For a zero-parameter, no-output-schema diagnostic tool, this is complete. It states the payload, the capture mechanism, the reset pitfall, and the size limit—everything an agent needs to call it correctly and interpret results. No critical information is missing.

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 rubric baseline is 4. The description adds value by describing what the returned payload contains (uncaught errors, unhandled promise rejections, up to 100 entries), which helps an agent interpret results even in the absence of an output 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 states a specific verb and resource: 'Get uncaught JavaScript errors + unhandled promise rejections from the current page.' The content is precisely scoped ('current page') and the payload specificity (uncaught errors vs. console logs) distinguishes it from the closest sibling, console_get, even without naming it.

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?

Clear temporal guidance is given: 'buffer resets on every navigation (read it before navigating away),' which tells the agent exactly when to call the tool relative to navigation events. It stops short of a 5 because it does not explicitly name alternatives or state when not to use it.

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

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

With no annotations provided, the description must carry the behavioral disclosure burden, but it only describes the core operation. It does not explain whether hidden text is excluded, what happens when no element matches, whether it waits for content, or what the return value looks like.

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

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

The description is a single concise sentence with no filler. The core action and object are front-loaded, making it immediately scannable.

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 annotations and no output schema, the description is too thin to be fully actionable. An agent still needs to infer the return format, selector semantics, and behavior on missing elements. The simple interface reduces the burden slightly, but important operational details remain absent.

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

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

The schema has 0% description coverage for the 'selector' parameter, and the description only vaguely connects it to 'element'. It does not explain that the selector is likely a CSS selector, whether it targets the first match or all matches, or how the default 'body' maps to the whole page.

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

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

The description states a clear action and resource: retrieving visible text from either the whole page or a selected element. The phrase 'visible text' helps distinguish it from sibling tools like get_html and get_attribute, though it does not explicitly name those 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?

There is no guidance about when to prefer this tool over related tools such as get_html, evaluate, find_by_text, or scrape_page. The usage context is only implied by the action name and description.

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

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

With no annotations provided, the description carries the burden of explaining behavior, and it does state that the tool returns the current URL and title, clearly implying a read-only operation. However, it gives no details on output format, error conditions (e.g., no page loaded), or whether it operates on the active tab versus the whole browser context. This is adequate but lacks richer behavioral context.

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