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 describes the action but does not mention potential side effects, safety considerations, or error behaviors. The example only illustrates invocation, not what happens when the method is called or whether it mutates state. This is a significant gap for a tool that invokes arbitrary methods.

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: a clear definition and an illustrative example. It is concise, front-loaded, and contains no filler. Every word earns its place, making it efficient for an agent 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?

The tool is an arbitrary method call with multiple parameters, but the description is minimal and lacks details about how to structure arguments, what js_api entails, or error handling. While an output schema exists, it doesn't cover the invocation mechanics. The description is insufficient for an agent to confidently use the tool in varied scenarios.

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. The example implies 'method' is the name of the js_api method, but it does not explain how to use 'args' or 'kwargs'. The description adds minimal meaning beyond the schema, leaving the two optional parameters undocumented and unexplained.

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: 'Call a js_api method directly on the Python object exposed to the page.' It specifies the verb 'call' and the resource 'js_api method,' which distinguishes it from siblings like eval_python and eval_js. The example reinforces the intended use.

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 the app exposes a js_api method, with a concrete example. However, it does not explicitly state when not to use this tool or mention alternatives like trigger_action or eval_js. It gives contextual guidance but lacks exclusions or comparisons.

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 adds useful information about coordinate semantics (element center, offset within element, viewport coordinates), which is not inferable from the schema. However, it does not discuss failure behavior, button selection, or what happens when all parameters are null.

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 brief and well-structured, with a single opening sentence and three bullet points that clearly organize the usage modes. No redundant information is included.

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 and the presence of an output schema (which covers return values), the description covers the essential usage patterns and coordinate behavior. It omits discussion of the button parameter and edge cases (e.g., all parameters null), but these are relatively minor.

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 only types and defaults with 0% description coverage, so the description must compensate. It explains the meaning of element_id and x/y through the three usage modes, clarifying that x/y are relative offsets when combined with element_id and viewport coordinates otherwise. The button parameter is not mentioned, which is a minor 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 clearly states the tool's function: clicking an element or page coordinate. It uses a specific verb ('Click') and resource ('element or page coordinate'), and the three bullet points clarify the different modes of operation. It distinguishes itself from siblings like double_click by the action name.

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

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

The description explains how to use the tool based on parameter combinations (element_id, coordinates), but it does not provide explicit guidance on when to prefer this tool over alternatives such as double_click, type_text, or press_key. There are no stated 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?

With no annotations, the description carries the full burden of behavioral disclosure. It simply states the action without mentioning whether the element must be visible, whether coordinates are relative to the element, whether it dispatches a dblclick event, or any 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, concise sentence with no fluff. It is appropriately front-loaded and easy to parse, though it sacrifices substance for brevity.

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

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

Although the tool is simple and an output schema exists, the description omits crucial context: no mention of coordinate behavior, return values, or when to use this over 'click'. The lack of any explanatory detail makes it insufficiently complete for reliable agent selection.

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 provides no additional meaning for the parameters. The element_id target, x/y coordinates, and their relationship are left entirely to the schema's bare names, so the description does not compensate for the lack of schema 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 ('Double-click') and the resource ('an element'). It distinguishes itself from the sibling tool 'click' by specifying 'double-click', though it does not explicitly contrast them.

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

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 vs 'click' or other interaction tools. It does not describe prerequisites, typical scenarios, or situations where double-clicking is appropriate.

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

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

No annotations are provided, so the description carries full responsibility for disclosing behavior. It only mentions execution and returning a result, omitting potential side effects on the page, error handling, or the fact that arbitrary code can be run. This is a significant gap for a code 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 a single, front-loaded sentence with no redundant words. Every part contributes to the core purpose, making it highly concise and efficient.

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

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

Although the tool has only one parameter, the description lacks critical behavioral details for safe and effective use by an agent. It does not mention the need for a loaded webview, possible page mutations, or how the result is serialized. The presence of an output schema does not compensate for missing usage 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 input schema has a single parameter 'code' with no description, and schema description coverage is 0%. The description does not elaborate on what 'code' should contain, syntax expectations, or whether it accepts expressions vs. statements, so it adds no meaning beyond the schema.

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

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

The description clearly states the tool executes JavaScript in the webview page and returns the result. It uses a specific verb ("Execute") and resource ("JavaScript in the webview page"), and it distinguishes from the sibling eval_python by naming JavaScript explicitly.

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 over alternatives such as eval_python or other DOM interaction tools. It does not mention prerequisites, exclusions, or recommended 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, the description carries the full burden. It discloses that code runs in the app process, names the exposed context objects, and warns that it's debugging-only. However, it does not state the potential for arbitrary code execution side effects, state mutation, or crashes, which would be expected for a powerful eval 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 three short sentences, front-loaded with the core purpose, followed by useful context and a clear warning. Every sentence contributes meaningful information with no waste.

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 eval tool, the description is fairly complete: it states purpose, execution context, available objects, and a safety warning. The presence of an output schema covers return value expectations. It could be improved by noting whether the code is an expression or statement and whether execution is synchronous, but overall it is sufficient.

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

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

The input schema lists only 'code' with a type of string and zero description coverage. The description does not explicitly describe the code parameter, but the tool name and the context line ('window, webview, api') imply that the code should be a Python snippet with access to those objects, adding some semantic value beyond the raw 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 ('Evaluate Python') on a specific resource ('in the app process'), and the context line adds the available objects. This distinguishes it from siblings like eval_js (JavaScript) and call_api.

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 warning 'debugging only' provides an explicit when-not condition, and the context line indicates the execution environment. However, it does not explicitly mention alternatives such as eval_js for JavaScript evaluation, so it falls 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 burden of disclosing behavior. 'Search DOM elements' implies a read-only operation, but it does not state whether it returns a single element or list, what happens if no match is found, or whether it has side effects. The examples are illustrative but do not clarify behavioral details.

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

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

The description is concise and well-structured, with the core search criteria in the first line and three illustrative examples. Every sentence adds value and there is no redundant 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 tool with six optional parameters and no annotations, the description is incomplete. It does not cover return values, error handling, parameter combinations, or how this tool fits into the broader workflow with siblings like click or get_element_info. The examples are helpful but not sufficient for full contextual 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 description lists all parameter categories and provides examples for selector, text, and role, which adds practical meaning beyond the raw schema. However, it does not explain the 'visible' parameter, combination rules, or value formats for all parameters, leaving gaps.

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 searches DOM elements by multiple criteria (CSS selector, tag, id, role, text, visibility), which is specific and understandable. It does not explicitly differentiate from sibling tools like get_dom_tree or get_element_info, but the scope is clear enough for basic selection.

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 examples show how to use the tool with different parameters, implying usage scenarios, but there is no explicit guidance on when to use this tool versus alternatives or when not to use it. It lacks context about combining parameters or fallback behavior.

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 transparency burden. It discloses a key limitation (only for launch_app apps) and implies a read-only 'get' operation, but it does not describe behavior when no app is running, whether it blocks, or the role of the port parameter.

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

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

The description is exceptionally concise: two sentences, front-loaded with the core action and a useful constraint. Every word adds value, with no redundancy.

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

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

The tool is simple and has an output schema, so return values are covered. However, the port parameter is unexplained, and edge cases like a non-running app are not mentioned. The description covers the main purpose but leaves significant context 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 description explains 'n' as the number of lines, but leaves 'port' completely undocumented. With schema description coverage at 0%, the description fails to explain a parameter, offering only partial compensation.

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 retrieves the last n lines of the launched app's stdout/stderr, with a specific verb ('Get') and resource. It distinguishes itself from sibling log tools like get_logs by specifying app output rather than general logs.

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 a clear precondition: only works for apps started via launch_app. This gives context on when the tool is applicable, though it does not explicitly compare with alternatives such as get_logs 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 full burden of behavioral disclosure. It does enumerate the returned fields, which is helpful, but it does not mention any side effects, prerequisites (e.g., app must be ready), or error behavior. While a getter is presumably side-effect-free, the description alone provides limited behavioral context beyond the output 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?

The description is a single concise sentence, immediately front-loaded with the action and resource, followed by a compact list of output fields. Every word earns its place, 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?

Given the tool's simplicity (zero parameters, a clear output schema, and a flat structure), the description completely covers its purpose. The listed fields align with the output schema, and the context of app-level state is sufficient for an agent to invoke this tool correctly. No additional details are needed.

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 input schema is trivially complete. The description adds no parameter information, but this is unnecessary. The baseline for no parameters is 4, as the description correctly conveys that no input is required.

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

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

The description clearly states the tool's function with a specific verb ('Get') and a specific resource ('app-level state'), listing the key components (page title, URL, focus element, pywebview platform). This distinguishes it from sibling tools like get_element_info or get_dom_tree, as it focuses on app-wide state rather than element or DOM details.

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 is used when app-level state information is needed, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. Given that sibling tools like get_app_status could overlap, explicit guidance would improve clarity.

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 non-obvious behavior (detecting native dialog blocks) and suggests a read-only health report, but it does not explicitly state whether the tool has side effects, requires a running app, or behaves differently when the bridge is down. This is useful but incomplete 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 a single, concise sentence that is front-loaded with the core action. Every word contributes meaning, with no repetition or filler. It is an excellent example of minimal yet effective prose.

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 output schema exists, so return values are documented, and the simple one-parameter schema reduces complexity. However, the description lacks usage context, such as when to call this tool or what 'bridge health' entails in practice. It is adequate for a simple read-only tool but misses opportunities to fully inform 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 only parameter is 'port' with a default of 7891, but the description does not explain its purpose or how it relates to process and bridge health. Schema description coverage is 0%, and the description does not compensate, leaving the agent to guess what changing the port would do.

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 specific verbs: 'Report process + bridge health' and 'detect likely native dialog blocks.' It distinguishes this tool from siblings like get_app_state or get_dom_tree by focusing on health and dialog detection rather than app state or UI structure.

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 does not mention situations like 'when you suspect the app is unresponsive' or compare it to get_app_state, get_logs, or wait_until_ready. This leaves the agent without clear 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 full burden. It clearly discloses the return format and the per-element structure (id, tag, html_id, class, role, text, visible, bounds, children), indicating a pure read operation. It could add more details about dynamic content or performance, but it adequately describes the behavior.

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

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

The description is two concise sentences, front-loaded with the main purpose, then detailing the output structure and usage instruction. Every sentence adds value without redundancy.

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

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

Given the tool's simplicity (no parameters, output schema present), the description fully explains what the DOM tree contains and how to utilize it (element IDs for other tools). It provides sufficient context for an agent to decide when to invoke it.

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

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

The tool has zero parameters, so no parameter explanation is needed. The baseline for 0 parameters is 4, and the description appropriately focuses on the output structure rather than parameter semantics, which is consistent with the empty input schema.

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

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

The description uses a specific verb 'Get' with a clear resource 'DOM tree of the page as JSON.' It distinguishes itself from sibling actions like click or type_text by clearly indicating it is a read/introspection 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 states 'Use element IDs from this tree in other tools,' providing clear context for when to call it. It does not explicitly mention alternatives or exclusions, but the instruction implies its role as a prerequisite for other 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 carries the full burden. It does not disclose behavior for missing/invalid ids, error handling, or whether this is a read-only operation. While the name 'get' suggests read-only, the description doesn't explicitly confirm safety or 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?

A single, concise sentence that says exactly what the tool does with no filler or repetition. Every word is necessary 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?

The tool is simple (one parameter, no nested objects) and has an output schema, which covers return values. The description provides enough context to invoke it correctly for a basic getter, though it lacks detail on edge cases and usage guidance (already penalized separately).

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 element_id is documented only as a string in the schema (0% schema description coverage). The description adds meaning by specifying it's an 'MCP id', which clarifies the type and origin of the parameter beyond the raw 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 the action (Get), the resource (detailed properties of a specific DOM element), and the method (by MCP id). It distinguishes from siblings like get_dom_tree (which returns the whole tree) and find_element (which locates elements).

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

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

The description implies a clear use case: you need an MCP id for a specific element and want its properties. This distinguishes it from broader tools like get_dom_tree, though it doesn't explicitly name alternatives or provide exclusion 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?

With no annotations, the description carries the burden of behavioral disclosure. It clearly identifies the tool as an informational/read-only resource ('Return how to call launch_app') and adds context about the focus on the script parameter and timing (before launch_app). It does not explicitly state 'no side effects,' but the wording implies it, which is sufficient for a simple help tool.

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

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

The description is two sentences with no wasted words. The first sentence front-loads the primary purpose, and the second gives clear conditional usage. 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?

Given the tool's simplicity, zero parameters, and existing output schema, the description is complete. It tells the agent exactly what the tool does and when to call it. Since the output schema exists, the description need not explain return values.

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 0 parameters, so the baseline is 4. The description does not need to explain parameters, but it adds useful context by referencing the 'script parameter' of launch_app, which is the key uncertainty it resolves. Schema coverage is 100% (vacuously), and the description adds value beyond the empty 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 the tool's function: 'Return how to call launch_app — especially the script parameter.' It uses a specific verb 'Return' with a resource ('how to call launch_app') and distinguishes itself from sibling tools like launch_app itself by focusing on guidance rather than execution.

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

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

The description provides explicit when-to-use guidance: 'Call this before launch_app when you are unsure which entry .py to use or whether script should include a subfolder path.' This is clear context, but it does not mention alternatives or explicitly state when not to use it, so it stops short of the full 'when/when-not/alternatives' criterion.

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 burden of disclosing behavior. It only states a read operation ('Get') and the resource, but does not mention side effects, permissions, ordering guarantees, or whether it can block. The verb implies read-only, but crucial behavioral details are missing.

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

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

The description is a single sentence that is front-loaded with the verb and resource. It includes a meaningful qualifier ('from the app') and the parameter reference without any fluff. Every word earns its place.

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

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

The tool is simple (one optional parameter) and an output schema exists, so return values are likely covered elsewhere. However, the description lacks usage guidance and behavioral transparency, making it incomplete for an agent that needs to understand when to invoke this tool and what to expect beyond the returned data.

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 0% because the only parameter 'n' lacks a description in the schema. The description says 'last n', which clarifies that n controls the number of records to return. This provides semantic meaning beyond the schema's type/default, but does not explain constraints like minimum/maximum values or behavior with zero.

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 'Get' and clearly identifies the resource: 'Python logging records from the app'. This distinguishes it from sibling tools like get_app_output or get_app_state, which target other data. The scope ('last n') adds precision.

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 does not provide any explicit guidance on when to use this tool versus alternatives. There are no exclusions, prerequisites, or suggested contexts. The usage is only implied by the name and resource, falling short of even a clear contextual hint.

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 burden. It discloses two key behaviors: the MCP bridge is injected and the tool waits until UI readiness before returning. This is meaningful beyond what the name alone conveys. However, it does not mention process lifecycle details such as whether the app runs in the background, what happens on timeout (schema covers timeout but not the failure mode), or port conflict 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, front-loaded sentence. It states the action, the target, the key injection detail, and the completion condition with zero filler. Every word earns its place.

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

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

Given the rich input schema, the presence of an output schema, and the sibling tools context, the description is largely sufficient. It covers the essential launch-and-wait behavior. It could add a brief note about when not to use it or how it relates to wait_until_ready, but that gap is more about usage guidelines than completeness for a launch 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 description coverage is 100%, so the baseline is 3. The description itself adds no parameter information, but the input schema provides rich details for every parameter including cwd, script, timeout, and app_args. The description's lack of param info is acceptable because the schema already does the heavy lifting.

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 ('Launch') with a clear resource ('pywebview app') and adds meaningful qualifiers ('with MCP bridge injected, then wait until the UI is ready'). It clearly distinguishes launch_app from sibling tools like wait_until_ready, get_app_status, and stop_app, which perform different lifecycle phases.

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 launch_app is the entry point to start the app and includes a readiness wait, but it does not explicitly state when to use this tool versus alternatives. For example, it doesn't mention that wait_until_ready may be redundant after launch_app or what to do if the app is already running. The context is clear but exclusions and alternatives are not addressed.

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

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

No annotations are provided, so the description must carry the burden. The verb 'List' implies a read-only operation with no side effects, but it does not disclose specifics about element visibility, duplicate handling, or whether disabled elements are included. The output schema covers return format, so the gap is acceptable.

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

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

A single, well-structured sentence that is front-loaded with the action and object. No waste.

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 list action with no parameters and an output schema, the description adequately scopes the result set. Minor ambiguity remains about what qualifies as 'clickable,' but it is sufficient for most agents.

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?

With zero parameters, the input schema is complete and the description does not need to explain parameters. Baseline 4 for no-param tools.

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 resource ('clickable buttons, links, and role=button elements'), clearly distinguishing this from broader DOM tools like get_dom_tree and find_element.

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

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

The description implies usage when you want to enumerate interactive elements, but it does not explicitly contrast with sibling tools like get_dom_tree or find_element, 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. It discloses that the action targets the focused element and enumerates supported named keys, providing basic transparency. However, it does not mention modifiers, supported character keys, event details, or behavior when no element is focused.

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 first sentence states the action and target, the second provides the key vocabulary; both sentences earn their 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 one-parameter tool with an output schema, the description covers the core action and valid named keys. It lacks explicit notes about modifier support or behavior on unfocused elements, but the tool is simple enough that this is nearly 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 0%, so the description compensates by listing valid named key values (enter, escape, tab, etc.). This adds concrete meaning beyond the schema, though it does not fully disambiguate the key format or clarify if arbitrary single-character keys are supported.

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 clear verb 'Press' and specifies the target 'focused element'. It distinguishes itself from sibling tools like type_text (typing text) and click by focusing on discrete key presses, and lists supported named keys.

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 implicitly suggests use for special keys like enter, escape, arrows, and function keys, but it does not explicitly state when to use this tool versus type_text or click. No alternatives or exclusions are mentioned.

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 behavioral disclosure. It adds useful context by mentioning the underlying CDP mechanism and the 'orient yourself' purpose, but it does not describe the return format (e.g., base64, file path), pagination, or any side effects. For a screenshot tool, the core behavior is implied, but the lack of output details is a moderate gap.

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

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

The description is exceptionally concise: two sentences with no wasted words. The action is front-loaded, and the usage tip ('Call this first') is a valuable addition. 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 one optional parameter, the description covers the main purpose, the parameter's role, and a practical usage suggestion. The lack of return format is a minor omission, but given the simplicity and the absence of an output schema, the description provides sufficient context for an agent to use 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?

The schema has zero description coverage for the element_id parameter, but the description explicitly explains its purpose: capturing a specific element by ID when provided, and the full page when omitted. This compensates well for the schema's lack of detail.

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

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

The description clearly states the action ('Capture a screenshot') and the scope ('of the webview page (or a specific element by ID)'). It distinguishes the tool from siblings like get_dom_tree or get_element_info by focusing on visual capture. The verb-object pair 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?

The phrase 'Call this first to orient yourself' provides explicit guidance on when to use the tool, suggesting it is the initial step in a visual workflow. However, it does not mention alternatives or exclusions, such as using get_dom_tree for structural navigation, so it lacks full differentiation.

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 is the only source of behavioral context. It provides the dy direction semantics but fails to disclose how dx and element_id influence behavior, potential side effects, or what happens if the element is not found. This is minimal for a zero-annotation tool.

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

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

The description is two short sentences, front-loaded with the core action. No unnecessary words 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 3-parameter tool with no annotations, this description is incomplete. It explains only one parameter partially, omits dx semantics, and does not address element_id usage or edge cases. An output schema exists, which mitigates return-value explanations, but the parameter behavior remains under-specified.

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 no parameter descriptions (0% coverage). The description only explains dy's direction, leaving dx and element_id entirely unexplained. It does not compensate for the schema's lack of 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 tool scrolls the page or an element, which distinguishes it from sibling interaction tools like click, type, and press_key. The additional direction rule (dy > 0 scrolls down) reinforces the action.

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

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

The usage is implied by the tool's name and description, but there is no explicit guidance on when to choose this over alternatives. No exclusions or alternative recommendations are provided.

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

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

No annotations are provided, and the description does not disclose behavioral details such as the effect of the 'port' parameter, whether the operation is idempotent, or what happens if the app is not running. It only adds the scoping condition that it applies to apps started via launch_app.

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 is front-loaded with the verb and object.

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

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

For a simple tool with one optional parameter, the description conveys core purpose but fails to explain the 'port' parameter. Since an output schema exists, return values are presumably documented, but parameter semantics are 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 schema has one parameter ('port') with zero description coverage. The description does not mention 'port' at all, leaving the agent without any semantic understanding of how to use it.

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

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

The description clearly states the action ('stop'), the resource ('a previously launched app'), and the context ('started via launch_app'), distinguishing it from launch_app and other sibling tools.

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

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

The description implies when to use it (for apps started via launch_app) and establishes a precondition. It doesn't explicitly mention alternatives or when not to use, but the tool's scope is clear.

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

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

No annotations are provided, so the description carries the full burden. It discloses the selection method and lack of DOM traversal but does not mention side effects, error behavior, or prerequisites (e.g., element visibility, scrolling, event triggering). This is insufficient for a mutation tool.

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

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

The description is a single, front-loaded sentence that conveys the core action, target, and distinguishing feature with no redundant words. It is appropriately concise for a simple interaction 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?

With an output schema present, return values are covered. The description provides the essential invocation details but lacks usage context and behavioral specifics. It leaves ambiguity around parameter combination and side effects, relying on the agent to infer the rest. Adequate but with noticeable 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 has 0% description coverage, but the description compensates by mapping 'name' to an HTML id and 'text' to visible text. It clarifies both parameters meaningfully. However, it does not explain what happens if both are provided or that they are optional, missing some nuance.

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 clicks a button/link using either an HTML id ('name') or visible text ('text'). It also distinguishes itself from sibling tools by explicitly noting 'without DOM traversal', which differentiates it from other click-related 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 phrase 'by html id (name) or visible text' implies a specific use case, but it does not explicitly name alternatives or exclusion conditions. There is no direct guidance on when to use this tool versus siblings like click or find_element, leaving the agent to infer the appropriate context.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool focuses the element first, but does not clarify whether it replaces existing text, how element targeting works when element_id is null, or what events/side effects occur. Major behavioral ambiguities remain.

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-length statement with no filler. It front-loads the core action and parenthetically adds a behavioral detail, making efficient use of space.

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 two parameters and an output schema, the description is too brief to be complete. It lacks essential details about text replacement behavior, element targeting (including null semantics), and possible errors or return values. The output schema exists but does not compensate for missing usage 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 0%, so the description must explain parameters. It mentions 'text' indirectly but never explains element_id or the role of focus in parameter handling. The parameter names are somewhat self-explanatory, but the description adds no detail beyond the schema, leaving null/default semantics unclear.

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 ('Type text') and resource ('input element'), and adds the behavior that it focuses the element first. This distinguishes it from siblings like click, press_key, and scroll.

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 context (typing text into input elements) but does not explicitly contrast with alternatives such as press_key or click. No when-to-use or when-not-to-use guidance is provided.

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

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

The description explains the core waiting condition (no DOM mutations) but does not disclose what happens when the timeout is reached, whether the tool polls or passively listens, or how success/failure is signaled. Since no annotations are provided, the description carries the full burden but leaves these behaviors unclear.

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 efficiently conveys the purpose and core condition.

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 an output schema exists, so the description does not need to explain return values in detail. It captures the essential behavior well, though the missing timeout semantics are a notable gap for a complete 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 description clarifies the meaning of quiet_ms by tying it to the idle condition. However, the timeout parameter is not explained at all, and the schema provides no descriptions either, leaving its unit and behavior ambiguous for a 0% schema coverage case.

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: wait until the page has been quiet (no DOM mutations) for quiet_ms. This clearly identifies the resource (the page) and the condition, and distinguishes it from sibling tools like wait_until_ready.

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 is clear: use this tool when you need to wait for the page to stop mutating before proceeding. It does not explicitly mention alternatives or exclusions, but the intended use is obvious from the phrasing.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the waiting condition but does not explain what happens on timeout, whether it polls or blocks, if it returns a value, or how quiet_ms influences behavior. This leaves significant ambiguity for 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 a single, front-loaded sentence with no filler words. It conveys the core purpose efficiently, making it easy to parse, though it omits important context that would improve its informativeness.

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 annotations and minimal schema descriptions, the description is under-specified. It does not explain parameter semantics, return values, timeout behavior, or relationships to sibling tools, making it insufficient for reliable 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 defines timeout and quiet_ms with defaults but no descriptions. The tool description does not mention either parameter, leaving quiet_ms especially unclear. Since schema description coverage is 0%, the description needed to compensate but failed.

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 'Wait until' and clearly identifies the resources: 'DOM is ready' and 'pywebview API is available.' This distinguishes it from sibling tools like wait_for_idle, which targets a different condition.

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 wait_for_idle or get_app_status. No prerequisites, exclusions, or usage context are provided; the description only states what the tool does without explaining when it should be invoked.

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