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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the action and selector, omitting important behavior such as clickability checks, default index behavior, potential navigation, 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?

A single, front-loaded sentence communicates the core purpose without extraneous words. Every word earns its place.

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

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

The tool is low-complexity with two well-documented parameters, but with no annotations or output schema, the description omits return value and behavioral details. It is minimally adequate but has clear 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 100%, so parameters are already well-documented. The description adds no additional semantics beyond aligning 'CSS selector' with the selector parameter, so 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 uses a specific verb ('Click') and resource ('DOM element') with a clear identification method ('CSS selector'), clearly distinguishing it from siblings like type_text or execute_javascript.

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

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

The description implies usage for clicking elements but provides no explicit guidance on when to choose this tool over alternatives, no prerequisites, and no exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and purpose, but does not disclose whether connect establishes a session state, whether it replaces a previous connection, or any side effects. This is a significant gap for a tool that likely changes the target for subsequent operations.

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

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

The description is a single concise sentence that is front-loaded with the verb 'Attach' and contains no wasted words. It immediately conveys the core action and 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?

Given the simple input schema, the description is minimal, but it does not explain the workflow—such as that subsequent tools operate on the connected page—or what happens on success. Since there is no output schema or annotations, this missing context hampers an agent's ability to use the tool effectively.

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 the only parameter (page_id) with a description referencing list_inspectable_pages, so schema coverage is 100%. The tool description adds no parameter-specific information, but this is acceptable since the schema is already clear, warranting the baseline score of 3.

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

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

The description uses a specific verb ('attach') and a resource ('specific inspectable page') with a clear purpose ('for observation and automation'). It clearly distinguishes from siblings like list_inspectable_pages, which lists pages, while connect targets one for interaction.

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

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

The description implies that connect is a prerequisite for observing/automating a page, but it does not explicitly state when to use it over alternatives or mention exclusions. It could benefit from saying 'use this before get_dom, screenshot, navigate, etc.' so the context is only implied, not clarified.

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 side effects and operational behavior. It fails to mention that the log accumulates and is not cleared unless the 'clear' parameter is set, nor does it hint at the output format or whether dumping is a one-shot or continuous 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 that immediately conveys the core purpose. It is front-loaded with the action and resource, and contains no 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 tool is simple with a single optional parameter and no output schema, so the description does not need to explain complex return values. However, it omits any mention of the log's lifecycle or the effect of the 'clear' parameter, leaving the agent with incomplete operational context.

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

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

The schema has full description coverage for the single 'clear' parameter, which reads 'Clear the debug log after reading'. The tool description adds no additional parameter semantics beyond this, so the baseline score of 3 applies.

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

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

The description clearly states the tool's action ('Dump') and resource ('raw WebKit Inspector Protocol messages exchanged'), distinguishing it from sibling tools like get_console_log and get_network_log, which deal with higher-level logs. The debugging context is also apparent.

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

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

The phrase 'for debugging' implies use when troubleshooting protocol-level issues, but the description does not explicitly compare this tool to alternatives (e.g., get_console_log) or state when not to use it. Guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action. It fails to mention side effects (e.g., page modifications), error behavior, return value format, security implications, or that script execution can navigate or alter the page. This is a significant transparency gap for arbitrary code execution.

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

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

A single sentence that is front-loaded with the verb and resource, containing no filler or redundancy. It earns its place by stating the primary function immediately, maximizing conciseness and readability.

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

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

Despite having only 2 parameters and no output schema, the tool is inherently powerful (arbitrary JS execution) and requires warnings about side effects, return values, and error handling. The description offers no such context, making it inadequate for safe and effective use. The absence of output schema further amplifies this gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema; it neither clarifies parameter usage nor provides examples. The schema's own descriptions ('JS code to evaluate', 'Await the result if it's a Promise') are adequate, and the description does not need to compensate.

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

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

The description uses a specific verb 'Evaluate' and a clear resource 'JavaScript expression in the page context', making the tool's purpose unambiguous and distinct from sibling tools like navigate or click_element. It accurately communicates the core action without ambiguity.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention situations where direct JS execution is preferred over debug_protocol or get_dom, nor does it state any exclusions or prerequisites, leaving the agent to infer usage from context alone.

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

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

With no annotations, the description carries the transparency burden. It usefully discloses that the log is buffered 'since connection or last clear', but it does not mention potential side effects of the 'clear' parameter, whether the operation is read-only, or the return format.

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, tightly worded sentence that front-loads the verb and resource with no 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 low-complexity read tool with two self-describing parameters and no output schema, the description covers the essential scope and statefulness. It does not describe the output structure, but that is a minor gap.

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

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

Both parameters (clear and level) are fully described in the schema, so the description adds no additional semantic value. Baseline 3 is appropriate given 100% schema description 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 clearly states the action ('Retrieve') and the resource ('JavaScript console messages'), and adds temporal scope ('since connection or last clear') that distinguishes it from related tools like get_network_log.

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 wording implies the tool is for reading console messages, and the temporal scope is clear, but there is no explicit guidance on when to prefer this over alternatives such as get_network_log, nor any 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 provided, the description carries the burden of disclosing behavior. 'Read' implies a non-destructive operation and 'as HTML' indicates the return format, but it does not mention any side effects, performance implications, or that the DOM is a snapshot. It is minimal but not misleading, earning a mid-range score.

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, direct sentence with no redundancy. Every word contributes to the meaning, making it highly concise and 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 simple read tool with two well-documented parameters and no output schema, the description is mostly adequate. However, it lacks usage guidance and any behavioral caveats relative to sibling tools, making it not fully complete for an agent to make informed decisions.

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

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

The input schema provides 100% coverage with clear descriptions for both parameters (selector and outer_html), so the description does not need to add parameter details. The schema already explains the defaults and behavior, giving the agent sufficient information. 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 'Read the page's DOM as HTML' clearly states the verb (read), resource (page's DOM), and output format (HTML). It is distinct from sibling tools like get_url (reads URL) and get_console_log (reads console logs), so it unambiguously describes its function.

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

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

The description provides no guidance on when to use this tool versus alternatives. It implies usage for reading the DOM but does not mention exclusions or compare with execute_javascript, which can also access the DOM. This leaves the agent without decision support.

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

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

No annotations are provided, so the description carries full responsibility for disclosing side effects. It says 'Retrieve' (read) but does not disclose that the 'clear' parameter can delete the log after reading, nor that filter_url is a regex. It also doesn't mention default behavior (clear defaults to false) or whether reading affects the 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, concise sentence that front-loads the verb and resource. No wasted words or redundant 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?

The description covers the core purpose but lacks important context: it doesn't mention that the log can be cleared via the 'clear' parameter, how filters interact, or any output format. Given no output schema and no annotations, the description leaves some gaps for an agent to infer behavior.

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

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

The input schema provides 100% coverage with descriptions for each parameter (clear, filter_url, filter_status). The tool description adds no additional parameter semantics or examples, 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 ('Retrieve') and resource ('captured network requests'), with scope ('since connection or last clear'). This clearly distinguishes it from sibling tools like get_console_log and get_dom.

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

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

The description implies usage for inspecting network traffic but does not explicitly state when to use this tool versus alternatives (e.g., get_console_log for console messages). The phrase 'since connection or last clear' provides context on the log's lifecycle but no exclusions or 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 full burden of behavioral transparency. It states the action but does not disclose what happens if no page is connected, whether the URL is returned as a string, or any edge cases. This is a minimal 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?

The description is a single, clear sentence that is front-loaded with the action and completes the thought efficiently. 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 tool with no parameters and no output schema, the description is mostly complete in naming the return value implicitly, but it omits any information about failure modes or the need for an active connection. It's adequate but not fully comprehensive.

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, which per the rubric earns a baseline of 4. The description adds context about what 'current URL' means in relation to the connected page, which is sufficient given the lack of 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 clearly states the tool's purpose with a specific verb ('Get') and resource ('the current URL'), and it distinguishes itself from sibling tools like 'navigate' and 'get_dom' by focusing on retrieving the page 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 usage via 'connected page' but does not explicitly state when to use this tool versus alternatives or mention any preconditions (e.g., must be connected). It's a simple getter, so the implied usage is somewhat obvious, but explicit guidance is missing.

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

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

With no annotations, the description carries the full burden. It implies a read-only operation (listing) but does not disclose potential failure modes, whether the list is sorted, or any device-specific filtering beyond the 'Web Inspector enabled' condition (already part of the purpose). It is a safe read but lacks depth.

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. It states the verb and resource directly, making it maximally concise while preserving clarity.

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

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

The description is adequate for a zero-parameter list operation, but the absence of an output schema leaves the agent without knowledge of the return shape (e.g., array of device objects or just UDIDs). It also does not address edge cases like 'no devices connected'.

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, so schema coverage is fully complete. Per the baseline for 0 params, the description does not need to add parameter detail; it is appropriately silent.

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

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

The description uses a specific verb ('list') and specifies the exact resource ('connected iOS devices with Web Inspector enabled'), clearly distinguishing it from sibling 'list_inspectable_pages' which operates at the page level. The scope is unambiguous and immediately understandable.

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 versus alternatives like 'list_inspectable_pages' or 'connect'. It does not mention whether it should be called first, if any device pairing is required, or how it fits into the overall workflow.

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

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

With no annotations, the description carries the full burden. It conveys that the operation is a non-destructive enumeration and scopes to connected devices, but it does not disclose return format, behavior when no devices are connected, or whether a prior connection is required. Some behavioral context is added, but not comprehensive.

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

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

The description is a single, clear sentence with no redundant words. It front-loads the action and object, making it immediately understandable.

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: one optional parameter, no output schema, no annotations. The description states core purpose but omits what the enumeration returns (e.g., page titles, URLs) and when to use it in a workflow. Given the low complexity, the description is adequate but leaves these gaps.

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

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

Schema coverage is 100% for the only parameter (device_udid), and its description clearly states 'Filter to a specific device.' The tool description adds no additional parameter semantics, so the schema does the heavy lifting, earning the baseline score of 3.

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

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

The description uses the specific verb 'enumerate' and identifies the resource as 'inspectable WKWebViews' across connected devices. This clearly distinguishes it from siblings like list_devices, which lists devices, not webviews.

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

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

No explicit guidance is given about when to use this tool versus alternatives, nor any prerequisites or exclusions. The intended use is implied: to obtain available webviews before inspecting a specific one. There is no direct alternative for this purpose, so context is mildly implicit.

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

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

There are no annotations, so the description must disclose behavior. It only says 'load a URL' without mentioning side effects, asynchrony, return values, or prerequisites beyond the implied connection. This leaves significant behavioral uncertainty.

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

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

A single sentence with no fluff, front-loaded with the core action. Highly concise and well-structured.

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

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

A simple tool with one parameter, but no output schema and no behavior details. The description lacks information about what happens after loading (e.g., whether it waits, returns success, or if the webview must be connected first). This is insufficient for an agent to invoke it with full understanding.

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 describes the url parameter, achieving 100% coverage. The description does not add additional parameter semantics, so it meets 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 clearly states the tool's function: loading a URL in the connected webview. It distinguishes from siblings like get_url (which likely retrieves the current URL) and connect (which establishes a connection).

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 indicates the tool operates on the connected webview, implying a prerequisite. It does not explicitly mention when to use it over alternatives, but the action is distinct from siblings like get_url and execute_javascript, providing clear 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 and no output schema, the description must disclose behavioral traits, but it only states the action. It omits critical details such as whether the screenshot is saved to a file, returned as base64, or captured as a full page vs viewport, leaving the agent uncertain about the tool's output.

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

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

The description is a single, tightly worded sentence that conveys the core purpose without any filler. It is optimally concise and front-loaded.

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

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

Given that there is no output schema or annotations, the description should explain what the tool returns or where the screenshot goes. It does not, leaving an important gap for a tool that produces a visual artifact. The low parameter complexity and simple purpose do not compensate for the missing output 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 tool has zero parameters, so the schema fully covers parameter semantics. The baseline for 0 params is 4, and the description adds nothing else 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 tool's action ('Capture') and object ('screenshot of the webview content'), making it distinct from sibling tools that handle navigation, DOM, or logs. It is specific and unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives like get_dom or navigate. There is no mention of prerequisites, context, or exclusion scenarios.

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

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

With no annotations provided, the description carries full behavioral disclosure burden. It mentions the focusing behavior for the selector, but does not disclose whether text is appended or replaced, how special keys are handled, or what happens if the element is not found. This is a significant gap for a tool that writes to the page.

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

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

The description is a single, front-loaded sentence that conveys the core purpose without waste. Every word adds value, making it highly concise and well-structured.

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

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

For a simple two-parameter tool with full schema coverage, the description is adequate but incomplete. It omits expected return values and edge-case behavior (e.g., empty text, unfocused element). It does not need to explain return values since no output schema exists, but more behavioral 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?

Schema description coverage is 100% and each parameter has a description. The tool description adds the 'specified element' context but does not provide additional meaning beyond what the schema already states (e.g., selector focuses first). Baseline 3 is appropriate since the schema handles parameter documentation.

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

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

The description clearly states the action ('Type text'), target ('element'), and scope ('currently focused or specified'). This differentiates it from sibling tools like click_element and navigate, making its purpose unambiguous.

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

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

The description implies when to use it (typing text into elements) but provides no explicit when/when-not guidance or references to alternatives. The 'Focus this element first' hint gives usage context but no 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 full behavioral disclosure burden, but it only restates the action. It does not disclose timeout resolutions, polling behavior, error conditions, or side effects. The schema mentions timeout_ms, but the description itself fails to communicate how the wait behaves.

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 wasted words, and it is front-loaded with the core action. It is concise, though perhaps too concise to be fully informative. Still, it demonstrates good structure for a minimal statement.

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

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

Given that the tool has four parameters, no annotations, and no output schema, the description leaves too much unspecified. It does not explain when the wait completes, what the return value is, or how the different conditions interact. The schema helps with parameters, but the description alone is insufficient for an agent to invoke the tool correctly in 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 description coverage is 100%, so the parameters (selector, timeout_ms, network_idle, url_contains) are already well documented. The description adds no extra meaning beyond the generic 'condition', 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 the verb 'wait' and an outcome ('before proceeding'), giving a clear but generic sense of the tool's purpose. However, it says 'a condition' without specifying what kinds of conditions (DOM, network, URL), so it remains vague and relies on the schema to define actual use cases.

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 offers no guidance on when to use this tool versus alternatives. It does not mention typical scenarios, prerequisites, or how it fits with sibling tools like click_element or navigate. The phrase 'before proceeding' implies sequencing but is too indirect to serve as actionable usage guidance.

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