WaveXisMCP

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

The description discloses the tool's behavior: it takes a snapshot, matches instruction, and performs the action. It lists possible actions and the return format. Annotations indicate it is not read-only (readOnlyHint=false) and not idempotent, and not destructive. However, there is no mention of what happens if the instruction cannot be matched, or if the action fails, or any side effects like page navigation. The transparency is adequate but could be improved with more 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 very concise: two sentences for purpose, then a bulleted list of args and returns. No fluff. It immediately states the purpose and action detection mechanism.

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 explains the tool's mechanism, inputs, and output format. With an output schema described in the text, the agent has sufficient information to use the tool. However, it lacks examples of natural language instructions or usage patterns, which could enhance completeness. Still, it covers core contextual needs.

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 includes descriptions for each parameter, such as 'Natural language instruction' and 'Active session ID'. The description only lists the parameter names without adding new semantics. Given the schema's comprehensive descriptions, the tool description does not provide additional value for parameter understanding. Hence score 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 clearly states the tool's purpose: executing natural language instructions on the current page using a11y snapshot and action detection. It explicitly lists the actions it can perform (click, type, fill, hover), which distinguishes it from sibling tools that are more specific (e.g., wavexis_click, wavexis_fill) or those that require explicit selectors.

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 explicitly provide usage guidelines or mention when to use this tool over alternatives like wavexis_nl_click or wavexis_nl_fill. It implies use for general natural language instructions but lacks direction on when not to use it or how it differs from other natural language tools. The required session_id parameter is documented, but no broader 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?

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds valuable context: side effect of changing active tab and that subsequent calls operate on the new tab, plus return format. No contradiction with annotations.

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?

Description is short, well-structured, and front-loaded. Each sentence serves a clear purpose: purpose, usage hint, side effects, and return value. No 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?

Covers purpose, prerequisites, side effects, and return format. Though it doesn't explicitly reiterate the required session_id from schema, the overall information is sufficient for correct usage with the input schema present.

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?

Input schema already provides descriptions for both parameters ('Tab ID to operate on', 'Active session ID from wavexis_session_open'). The tool description does not add further parameter semantics, making it adequate but not enhanced.

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?

Description clearly states 'Focus (bring to front) a browser tab by its ID', specifying the verb and resource. It distinguishes from sibling tools like wavexis_list_tabs (listing) and wavexis_new_tab (creating) by focusing on activation.

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

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

Explicitly says to use before navigation/interaction tools and to obtain tab IDs via wavexis_list_tabs first. This provides clear context and a prerequisite, though no explicit when-not-to-use advice is given.

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

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

Annotations indicate read-only and non-destructive. Description adds specifics: injects/removes overlays, writes to output_path. Provides more context than annotations alone.

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

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

Two paragraphs: first explains process, second gives usage guidance and side effects. Well-structured, though could be slightly more concise.

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?

Covers purpose, process, side effects, return values. Output schema exists but description still provides necessary context. Complete for a tool of this complexity.

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

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

Schema description coverage is 0% per context, but schema itself has descriptions for each parameter. Description mentions selectors and output_path but not session_id. Adds some value but not comprehensive.

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

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

Clearly states the tool captures a screenshot with numbered labels on elements. Distinguishes from sibling wavexis_screenshot by specifying it is for visual element identification.

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

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

Explicitly says when to use this tool vs wavexis_screenshot: 'Use wavexis_screenshot for plain captures, or this tool when visual element identification is needed for follow-up actions.'

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?

Beyond the annotations (which are all false), the description discloses side effects: 'Changes the active page to the previous history entry; may trigger network requests if that page was not cached.' This adds valuable behavioral context.

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

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

The description is concise with four sentences, each serving a distinct purpose: purpose, usage guidelines, side effects, and return format. No unnecessary words.

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

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

Given the simple tool (one parameter, output schema exists), the description covers purpose, usage, side effects, and return format. It is complete for effective decision-making.

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% (context), meaning the description must compensate. However, the tool description does not mention the session_id parameter or its meaning, leaving the agent without any additional semantics beyond the schema's minimal description.

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

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

The description explicitly states the action: 'Navigate backward one step in the browser history.' It clearly identifies the verb (navigate backward) and resource (browser history), and distinguishes from siblings like wavexis_navigate and wavexis_forward.

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

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

The description provides explicit guidance: 'Use for history navigation instead of wavexis_navigate when the target is the previous page.' This clearly indicates when to use this tool versus alternatives.

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?

Beyond annotations (readOnlyHint, destructiveHint, idempotentHint), description adds 'Side effects: None; queries the local filesystem only' and 'without launching a browser', giving rich behavioral context that matches annotations.

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

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

Three sentences, each earning its place: purpose, alternative usage, side effects/return. Front-loaded, no wasted words.

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

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

Given zero parameters, rich annotations, and output schema, description covers purpose, alternative, side effects, and return format. No 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?

No parameters, so schema coverage is 100%. Description adds value by explaining the return format (JSON with keys), which is not required due to output schema existence but is helpful. Baseline 4 appropriate.

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

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

The description clearly states the tool lists installed browser backends and their versions, using specific verb 'list' and resource 'backends'. It distinguishes from sibling tool 'wavexis_browser_version' by clarifying that sibling is for running sessions.

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

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

Explicitly provides context for when to use this tool versus wavexis_browser_version, saying 'Use wavexis_browser_version instead when you need the version of a specific running session's backend'. No exclusion needed.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating no destructive side effects. The description adds critical behavior beyond annotations: 'Side effects: Acquires (and may launch) a browser backend, then releases it.' This discloses a launch-and-release cycle that is not captured by annotations. It also specifies the return format as a JSON string with keys, which is helpful.

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

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

The description is extremely concise: two short paragraphs and one line for returns. The first sentence immediately states the purpose, the second places it relative to an alternative, and the third lists side effects and return format. Every sentence adds unique value, and there is no redundant or wasteful 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?

Given the tool's simplicity, the description is complete. It covers purpose, usage alternative, side effects, and return format. An output schema is present, so no need to detail return values. Annotations cover safety. The description does not miss any essential contextual information for an agent to invoke this tool correctly.

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

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

The input schema already provides descriptions for both parameters (backend with enum and default, session_id with nullability and behavior). The description does not add any additional meaning beyond what the schema provides. Since schema description coverage is effectively high (each parameter has a description), a baseline score of 3 is appropriate.

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

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

The description clearly states 'Query the active browser's version string via the selected backend.' This specifies a verb ('query') and a resource ('browser version string'). It also implicitly distinguishes from the sibling tool 'wavexis_backends' by mentioning that the latter lists backends without launching a browser.

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

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

The description explicitly tells when not to use this tool: 'Use wavexis_backends instead when you need a list of all installed backends without launching a browser.' It clearly indicates that this tool acquires (and may launch) a browser backend, which is a key context. However, it does not explicitly state when to use this tool, though it is implied when you need the browser version.

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?

Description states toggling behavior which contradicts annotations idempotentHint=true (toggling is not idempotent). Per guidelines, score 1 for description contradicting annotations.

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?

Four focused sentences: purpose, alternatives, side effects, return format. No redundancy, front-loaded with key action.

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 output schema and annotations, description covers purpose, side effects, return values. Missing explanation of idempotency discrepancy, but otherwise complete for a simple 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?

Description adds context that selector targets checkbox/radio, but does not elaborate on session_id or format beyond schema. Schema descriptions are minimal, so baseline is 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 clearly states 'Check a checkbox or radio button matching a CSS selector' and explicitly distinguishes from siblings wavexis_uncheck and wavexis_click.

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

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

Provides explicit guidance: 'Use wavexis_uncheck to uncheck a checkbox or wavexis_click for generic element activation', defining when to use this tool vs alternatives.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=false. The description adds specific side effects (triggers click, may submit forms, toggle controls, navigate page) and details the return format, providing useful context beyond the structured annotations.

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

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

The description is extremely concise: three sentences covering purpose, alternatives, side effects, and return format. Every sentence earns its place, with no fluff. Front-loaded with the core action.

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 complexity and the presence of an output schema (not shown but indicated), the description adequately covers the core behavior, side effects, and return structure. It distinguishes itself among many siblings. Minor gap: no parameter constraints (e.g., selector must exist) beyond side effects.

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 mentions 'CSS selector' but does not elaborate on other parameters like url, button, backend, or click_count. The schema itself provides descriptions for all parameters, so the description adds marginal value. Baseline score of 3 is appropriate given schema coverage.

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

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

The description opens with a clear verb-resource pair: 'Click an element matching a CSS selector.' It immediately distinguishes from siblings by naming alternative tools for double-click, right-click, and text-based clicking, making the purpose unambiguous.

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

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

The description explicitly states when to use alternative tools (wavexis_double_click, wavexis_right_click, wavexis_nl_click), providing clear context for selection. It lacks an explicit 'when not to use' but the alternatives cover the main 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?

This is far stronger than the annotations alone. It explicitly says the operation is destructive and irreversible, explains that the session stays alive, and documents the exact JSON return shape with 'status' and 'closed' keys. An agent knows both the side effects and the observable response.

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

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

The description is compact and well organized: purpose, usage context, side effects, and return value are each covered in a few short sentences. Every sentence carries necessary information, with no filler.

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

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

For a destructive tool with a simple input shape and an output schema, this description covers the critical behavioral contract thoroughly. The only notable gap is that it does not clarify how to choose between this and wavexis_close_tab, which is important given the sibling list.

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 prose explains that tab_id is optional and that omitting it closes the current page, which matches the schema. It does not add much semantic detail about session_id, but the schema already describes it as the active session ID from wavexis_session_open, so the minimum needed to invoke the tool correctly is available.

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 immediately identifies the action: 'Close a browser page/tab by target id' and clarifies the default behavior when no target is given. It is concrete and understandable, but it does not explicitly differentiate itself from the sibling tool wavexis_close_tab, which likely has a very similar purpose.

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

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

The description gives a clear use context: free resources while keeping the session active for other tabs. It does not explicitly list alternatives or state 'when not to use', but the practical intent is clear enough for an agent to select the tool.

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

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

The description adds context beyond annotations: it states side effects ('Closes the specified tab and discards its page state') and notes data loss ('unsaved data in that tab is lost'). While annotations already indicate destructiveHint=true, the description enriches this with specific implications, though it omits details like authentication requirements or rate limits.

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: it starts with the main action, follows with usage context, side effects, and return format, all in a few sentences 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?

For a simple close action, the description covers enough: it mentions the return format, side effects, and relationship to sibling tools. However, it could note that the tab ID comes from wavexis_list_tabs or similar, but the schema hints at the source. Overall sufficient given the tool's simplicity.

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?

Even though the context indicates 0% schema description coverage, the input schema actually provides clear descriptions for both parameters (tab_id and session_id). The tool description adds no further parameter meaning, so baseline 3 applies as the schema already does the job.

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 and resource: 'Close a browser tab by its ID.' It distinguishes from the sibling tool wavexis_session_close by noting that the latter terminates the entire session, making the purpose 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 description explicitly advises when to use this tool ('clean up tabs created with wavexis_new_tab') and provides an alternative tool ('use wavexis_session_close to terminate the entire session instead'), offering clear guidance on usage context.

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

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

The description explicitly discloses the wholesale buffer reset ('Resets the session's in-memory console message buffer') and the exact return format ('JSON string with keys: status ('ok'/'error')'). This complements the annotations by clarifying what the destructive hint means in practice and what the caller will receive. No contradiction with the annotations exists.

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

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

The description is four precise sentences, each with a distinct role: operation, usage placement, side-effect disclosure, and return value. It is front-loaded with the action and contains no filler or redundant phrasing.

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

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

For a single-parameter utility with helpful annotations and a schema description for the parameter, the description fully covers the intended effect, the recommended timing, the session-scoped nature, and the expected response shape. An agent has everything needed to invoke it correctly and understand its impact.

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

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

The sole parameter, session_id, is already described in the schema as 'Active session ID from wavexis_session_open.' The tool's text does not mention the parameter, but the schema provides sufficient meaning and provenance. Given schema coverage exists, the description need not repeat 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 uses a specific verb and resource: 'Clear all buffered console messages for the session.' It clearly defines the operation's scope and distinguishes it from cookie- or tab-related tools in the sibling list. There is no ambiguity about what the tool does.

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

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

The description provides a direct usage trigger: 'use it before capturing a fresh set of console logs to avoid stale entries.' This gives the agent a concrete scenario for when to call the tool without requiring inference. It does not explicitly name alternatives or exclusions, but none are needed for this focused utility.

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

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

Annotations already signal readOnlyHint, idempotentHint, and destructiveHint=false. The description reinforces this with 'Side effects: None; reads cookie state' and adds useful behavioral detail about the return shape (status and cookie keys). No annotation contradictions are present.

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

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

The description is compact and front-loaded: purpose first, usage routing second, then side effects and return format. Every sentence adds value, and there is no redundant or filler phrase.

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-only cookie getter, the description explains behavior, return shape, and sibling routing. The only notable gap is the lack of explicit mention that a valid session_id is required, but the schema covers this, so the context remains sufficient for correct invocation.

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

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

The schema already includes helpful descriptions for name, path, domain, and session_id. The description only adds a high-level notion of optional domain/path filtering and does not explain the required session_id dependency. It is adequate but does not meaningfully improve on the schema's 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 uses a specific verb 'Retrieve' with a concrete resource ('a single cookie by name') and clearly defines the scope ('from the browser', optional domain/path). It also distinguishes this from wavexis_cookie_list, so an agent can tell them apart without opening the schemas.

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

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

It explicitly states when to use a sibling tool instead: 'Use wavexis_cookie_list instead when you need multiple cookies or broad filtering.' This gives a clear when-to-use and when-not-to-use condition, leaving little to inference.

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

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

The description explicitly states that there are no side effects and that it reads cookie state from the browser session, which aligns with and meaningfully supports the readOnlyHint and destructiveHint annotations. It also previews the JSON return keys, though, since an output schema is present, the return-shape detail provides only modest added value.

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

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

The description is compact and well front-loaded: action first, then the alternative tool, then side effects and return shape. Every sentence earns its place, with no filler or repetitive 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 cookie-listing tool, the definition is solid: it specifies filters, gives a safe alternative, states the lack of side effects, and covers the output shape. Remaining details such as limit defaults and session_id sourcing are present in the schema, so the description is not critically incomplete, though it does not define filter matching semantics.

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 prose names three optional filters (name, domain, path) but does not describe the limit parameter or clarify how multiple filters are combined. With the stated schema description coverage at 0%, the description carries a heavier burden, but it only partially compensates; the nested schema provides the missing details.

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

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

The description opens with a precise action-resource statement ('List browser cookies') and names the optional filters: name, domain, and path. It also explicitly differentiates this tool from wavexis_cookie_get, which is the closest sibling, by saying the latter is for a single named cookie.

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

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

The description makes the intended usage clear: use this tool to list browser cookies, optionally filtered. It also gives an explicit when-not condition, directing the agent to wavexis_cookie_get when a single named cookie is needed, which removes ambiguity among the cookie-related siblings.

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

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

Annotations already indicate destructiveHint: true and idempotentHint: true. The description adds context about using an existing session backend and the return format (JSON with status). It does not contradict annotations and provides supplementary 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, with 4 sentences front-loaded with the main action. Every sentence adds value: purpose, alternatives, side effects, and return format, with no wasted words.

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

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

The tool has a single parameter and an output schema. The description covers purpose, alternatives, side effects, and return format. It could mention that a valid session is required, but overall it is fairly complete given the simplicity of 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?

With schema description coverage at 0%, the description does not add any meaning about the session_id parameter. The schema provides a basic description ('Active session ID from wavexis_session_open'), but the description misses an opportunity to compensate, leaving the parameter's role and prerequisites 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 'Clear all cookies from the browser session' with a specific verb and resource. It distinguishes itself from siblings wavexis_cookies_delete (specific cookie) and wavexis_cookies_get (inspect), fulfilling the criteria for a score of 5.

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

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

The description explicitly provides usage context: when to clear all cookies, and when to use alternatives (wavexis_cookies_delete for a specific cookie, wavexis_cookies_get to inspect first). This offers clear guidance on when to use this tool versus alternatives.

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?

Discloses side effects: launches/acquires browser backend, navigates if URL provided, destructively removes cookies. Annotations provide destructiveHint, but description adds valuable context about backend and navigation, fully aligning with annotations.

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?

Four sentences, front-loaded with purpose, then alternatives, side effects, and return. Every sentence earns its place with no redundancy.

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

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

Comprehensive for a deletion tool: covers purpose, side effects, return format, and distinguishes from siblings. Output schema exists for return details, so no gap.

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

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

The input schema already describes all parameters (name, domain, etc.). The tool description adds no new semantic info beyond mentioning 'matching a name and domain', which is covered by schema. Baseline 3 is appropriate given schema descriptions exist.

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 deletes cookies matching a name and domain, with specific verb and resource. It distinguishes from siblings like wavexis_cookies_clear and wavexis_cookies_set, making the purpose unambiguous.

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

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

Explicitly tells when to use this tool vs alternatives: use wavexis_cookies_clear to remove all cookies, or wavexis_cookies_set to add. Provides clear context and exclusion 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?

Describes side effects: launches browser backend, navigates if url provided, and declares read-only with respect to browser state. This aligns with annotations (readOnlyHint, idempotentHint, destructiveHint false) and adds useful 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 front-loaded with purpose, then alternative tools, side effects, and return format. Each sentence is efficient and necessary, with no fluff.

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

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

Given the tool's complexity and presence of annotations and output description, the description is mostly complete. It covers purpose, alternatives, side effects, and return format. However, it does not explain parameters like backend, headless, session_id, but these are documented in the schema.

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 has 0% description coverage, but the description mentions the url parameter's effect ('navigates to url if provided') and implies session context. However, it does not add significant meaning beyond the schema's existing parameter descriptions.

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

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

The description clearly states 'Retrieve all cookies for the current page context' with a specific verb and resource. It distinguishes from siblings by mentioning wavexis_cookies_set and wavexis_cookies_clear for different operations.

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

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

Explicitly states when to use alternatives: 'Use wavexis_cookies_set to add a cookie, or wavexis_cookies_clear to remove all cookies'. Provides clear context for when not to use this tool.

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

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

Beyond annotations (readOnlyHint=false, etc.), the description details side effects: launches/acquires browser backend, navigates to url if provided, mutates cookie state. Return format is also specified.

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

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

Three concise sentences with front-loaded purpose, minimal waste. Every sentence adds value.

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

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

Covers purpose, side effects, return, and sibling tools. Could mention session_id or prerequisites, but given the tool's simplicity and sibling context, it is sufficiently complete.

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

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

The description does not repeat parameter details, but the schema already has descriptions for all parameters (high coverage). It adds value by noting that 'url' triggers navigation, which complements 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 it sets a single cookie for the current page, distinguishes from sibling tools (get and delete), and mentions side effects like navigation and mutation.

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

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

The description explicitly mentions alternative tools for reading and deleting cookies, providing clear when-to-use guidance. It could be stronger by adding when not to use or prerequisites.

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?

Beyond annotations (idempotentHint=true, destructiveHint=false), the description discloses that the tool mutates DOM focus state and may trigger focus event handlers. This adds valuable behavioral context not captured by annotations.

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

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

Three sentences with no unnecessary words. First sentence states purpose, second provides usage guidance, third covers side effects and return format. Efficient 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?

Covers purpose, usage differentiation, side effects, and return. Could mention that focusing may scroll the element into view, but that's a common behavior. Overall quite complete for the tool's complexity.

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

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

The input schema already describes both parameters (selector and session_id) with clear descriptions. The tool description does not add additional meaning beyond mentioning 'CSS selector' implicitly. Schema coverage by the description is minimal, but the schema itself is well-documented, 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 clearly states the tool focuses an element via CSS selector. It explicitly distinguishes from wavexis_dom_click by advising use of that tool for activation rather than focus.

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

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

The description provides clear guidance on when to use this tool (focusing) versus the alternative (clicking for activation). It does not address other potential alternatives like direct focus via evaluation, but the main distinction is covered.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds that the tool is read-only and may navigate to a URL, and specifies the return format (JSON with status, html, selector). This adds useful behavioral context beyond what annotations provide.

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 with 3 sentences plus a returns line. It is well-structured, front-loaded with the purpose, and 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 has a well-described schema, annotations, and an output schema mentioned in the description, the description covers purpose, usage distinction, side effects, and return format. It is complete for the complexity of 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 input schema has detailed descriptions for all parameters, so schema coverage is effectively high. The tool description does not add additional parameter information beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states 'Retrieve the HTML of an element matching a CSS selector,' which is a specific verb+resource combination. It explicitly distinguishes from the sibling tool 'wavexis_dom_query' by noting that tool is for metadata. This meets the highest standard for purpose clarity.

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

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

The description explicitly tells when to use this tool vs. 'wavexis_dom_query' (raw HTML vs metadata). It mentions side effects are none and that it may navigate to a URL if provided, providing clear context for when to invoke.

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?

Description states 'Side effects: None; read-only' which aligns with annotations. It also details the return format (JSON string with keys), adding value beyond the readOnlyHint and idempotentHint annotations.

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: three sentences covering purpose, sibling, and behavior/return. It is front-loaded and contains no 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 presence of an output schema, the description's return format detail is sufficient. It covers side effects and key parameters. Missing error handling details, but overall adequate for a simple read 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?

With 0% schema description coverage, the description must compensate. It mentions 'CSS selector' and 'attribute value' but does not clarify that the 'name' parameter is the attribute name. The schema does provide some descriptions for nested parameters, but the description adds minimal extra meaning.

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 reads an attribute value from an element using a CSS selector. It distinguishes from sibling wavexis_dom_set_attr (write) and implies difference from wavexis_dom_get (which likely gets text).

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

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

The description explicitly mentions the write alternative (wavexis_dom_set_attr). It could improve by noting when to use this over other read tools like wavexis_dom_get, but it provides clear usage context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by explicitly stating 'Side effects: None; read-only. May navigate to url if provided.' This informs the agent about potential navigation side effects beyond the DOM query, which is not captured in annotations. It also mentions the return format structure (JSON keys).

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

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

The description is extremely concise: three sentences that front-load the purpose, provide a usage guideline, and summarize side effects and return format. Every sentence serves a clear purpose with no redundancy or wasted words.

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

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

Given the tool's complexity (multiple parameters, nested input) and the presence of an output schema, the description provides essential context: it explains the return keys (status, elements, count, total), notes pagination (offset/limit), and mentions potential navigation. It does not detail each element's fields, but that is covered by the output schema. It could improve by clarifying the relationship between session_id and url, but overall it is sufficiently complete.

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

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

The input schema already provides comprehensive descriptions for each parameter (e.g., 'Return all matches (True) or first only (False)' for 'all', 'URL to navigate to' for 'url'). The description itself adds little beyond mentioning 'CSS selector' and 'paginated metadata'. Since the schema covers the parameter semantics thoroughly, the description's contribution is minimal, warranting a 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 clearly states the tool's purpose: 'Query elements by CSS selector and return paginated metadata.' It also distinguishes itself from the sibling tool wavexis_dom_get, which is for retrieving raw HTML of a single element. This provides a specific verb+resource and explicit differentiation.

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

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

The description explicitly tells the agent when to use an alternative: 'Use wavexis_dom_get instead when you only need the raw HTML of a single element.' It also notes that the tool may navigate to a URL if provided, implying it can also be used for navigation-based queries. However, it does not provide exclusions for when not to use this tool beyond that single sibling.

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

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

Annotations indicate destructiveHint true; description adds 'permanently removes' and 'Destructive' side effects, plus return format. No contradiction.

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

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

Three efficient sentences, front-loaded purpose, no 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?

Covers purpose, alternative usage, side effects, and return format. Complete for a simple destructive DOM removal tool.

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

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

Schema provides descriptions for both parameters (selector, session_id), so baseline 3. Description does not add extra semantics 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?

Clearly states verb 'remove' and resource 'element matching CSS selector'. Distinguishes from sibling wavexis_dom_set_attr for hiding instead of deleting.

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

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

Explicitly advises using wavexis_dom_set_attr for hiding instead of this tool, providing clear when-not-to-use guidance.

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

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

Beyond annotations (destructiveHint=true), description explicitly states 'Mutates the DOM by deleting the attribute' and specifies return format ('JSON string with keys: status'). Adds value by detailing the exact mutation and response structure.

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

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

Three concise sentences: purpose, alternative usage, and side effects/return. Key information is front-loaded with zero wasted words.

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

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

For a simple attribute removal tool, description covers purpose, alternative, side effects, and return. Output schema exists and annotations provide safety hints. Could mention idempotency or error handling, but overall sufficient.

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

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

Schema has 0% description coverage, but parameter names are self-explanatory (name, selector, session_id) and schema provides types and minLength. The tool description does not add extra parameter details, leaving schema as the sole source. Adequate but not enhanced.

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

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

Clearly states the action ('remove an attribute') and the target ('element matching a CSS selector'). Explicitly distinguishes from sibling wavexis_dom_set_attr, providing a precise purpose.

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

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

Mentions when to use the alternative tool (wavexis_dom_set_attr) for restoring or changing attributes, giving clear guidance. Could additionally note prerequisites like having a valid session, but schema covers required parameters.

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

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

Annotations already provide idempotentHint=true, destructiveHint=false. The description adds useful behavioral context: 'Changes the page scroll position; may trigger scroll event listeners' and return format. This goes beyond annotations.

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

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

Three well-structured sentences, front-loaded with the core action, efficient use of words, 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?

Given the presence of annotations, output schema, and siblings, the description covers side effects, return format, and a usage hint. Lacks explicit precedence when both selector and offsets are provided, but overall complete enough.

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%, but the schema itself provides parameter descriptions. The description only repeats the 'element or offset' choice without detailing parameter interplay or edge cases. Adds modest value.

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

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

The description clearly states 'Scroll to an element or by a pixel offset', using a specific verb and resource. It distinguishes from siblings like wavexis_dom_get by suggesting use of that tool for inspection.

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 advises using wavexis_dom_get to inspect positions, which provides some context, but lacks explicit when-to-use vs alternatives or exclusions. No guidance on when not to use.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false. The description adds value by explicitly stating 'Mutates the DOM by writing the attribute on the matched element' and outlining the return format as a JSON string with status keys. It clarifies the mutation behavior beyond annotations.

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 concise sentences. The first sentence front-loads the primary action, the second provides a usage hint, and the third covers side effects and return. No redundant or unnecessary 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 simple set-attribute operation, the description covers the operation, side effects, and return format. It does not explain error conditions or prerequisites, but the schema covers the session_id requirement. The output schema is described adequately. Overall, it is complete for the tool's complexity.

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

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

The schema already provides descriptions for all four parameters (name, value, selector, session_id). The description does not add new information about the parameters beyond implying the selector is a CSS selector, which is already in the schema. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the verb 'Set', the resource 'attribute on an element', and the method 'CSS selector'. It explicitly distinguishes from the sibling tool 'wavexis_dom_get_attr' by recommending its use for reading before setting.

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 advises using 'wavexis_dom_get_attr' to read the current value before setting, providing clear context for when to use this tool and a direct alternative. It does not explicitly list when not to use it, but the guidance is sufficient for an AI agent.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's mention of 'Side effects: None; read-only' is consistent but redundant. However, it adds value by describing return format (JSON string with keys 'status', 'snapshot', 'documents') and the scope of including iframes and shadow roots, which annotations do not cover.

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

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

The description is extremely concise: four short sentences covering purpose, alternative, side effects, and return format. Every sentence adds value, and the purpose is front-loaded. No redundant or vague statements.

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 (one parameter, read-only operation) and the presence of annotations and an output schema (mentioned in description), the description covers all essential aspects: functionality, alternative usage, safety, and return structure. It is fully adequate for an agent to use correctly.

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

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

The input schema already describes the single parameter 'session_id' as 'Active session ID from wavexis_session_open'. The tool description does not add any further semantic information about this parameter. With full schema coverage for the parameter, a baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Capture'), resource ('full DOM snapshot'), and scope ('including iframes and shadow roots'). It distinguishes from sibling wavexis_dom_query, which is a lightweight alternative. The purpose is unambiguous and specific.

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

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

The description provides explicit guidance on when to use this tool vs. an alternative: 'Use wavexis_dom_query for lightweight element metadata instead of a full snapshot.' While it only mentions one alternative, it is highly relevant and helps the agent choose appropriately.

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

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

Annotations already indicate destructiveHint=true and openWorldHint=true. The description adds concrete side effects ('Fires two rapid click events... may open files, edit cells') and return format, enhancing transparency. However, it does not mention session or browser state implications.

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?

Every sentence adds value: purpose, alternatives, side effects, and return format. Front-loaded with the core action. No unnecessary words.

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

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

Given the tool's complexity and that output schema exists, the description covers purpose, usage guidance, side effects, and return structure. It lacks mention of session management but overall is adequate for 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?

The input schema has descriptions for all parameters (100% coverage), so baseline is 3. The tool description adds no additional meaning beyond what the schema already provides, so it meets baseline without adding extra value.

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

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

The description states 'Double-click an element matching a CSS selector', using a specific verb and resource. It clearly distinguishes itself from siblings by explicitly mentioning alternatives (wavexis_click for single clicks, wavexis_nl_click for natural language).

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?

Provides explicit context on when to use alternatives and describes side effects. However, it does not explicitly state when not to use this tool or mention prerequisites (e.g., needing a session), leaving minor gaps.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds context by listing side effects ('fires drag/dragstart/dragend and drop events') and the return format, which goes beyond annotations. No contradiction.

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 sentences long, front-loading the main purpose. Every sentence adds value (action, alternative, side effects/return). No wasted words.

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

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

The description covers purpose, alternative, side effects, and return format. It does not explain input parameters, but the schema handles that. Given the tool's complexity and sibling context, it is nearly complete; a minor gap is the lack of mention of session requirements.

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 detailed descriptions for all parameters (high coverage), so baseline is 3. The description does not add any parameter-specific information, but it is not necessary given the schema's thoroughness.

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: 'Drag an element from a source selector to a target selector.' It uses a specific verb and resource, and distinguishes itself from the sibling tool wavexis_drop by explaining when to use the alternative.

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

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

The description explicitly provides an alternative: 'Use wavexis_drop when you need to drop arbitrary MIME data or files onto an element rather than dragging an existing DOM element.' This gives clear guidance on when to use this tool versus a sibling.

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

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

Annotations indicate destructiveHint=true, which the description aligns with. Beyond annotations, it details side effects (dispatches dragEnter, dragOver, drop events) and return format, adding useful context. No contradictions.

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

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

The description is well-structured: purpose first, then alternatives, side effects, return. It is informative but slightly long; could be trimmed without losing value.

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

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

Given the tool's complexity (many parameters, side effects), the description covers purpose, alternatives, behavior, and return format. With an output schema present, it is sufficiently complete.

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

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

The description does not elaborate on individual parameters; the schema (with 0% coverage from the description) already has detailed descriptions for each property. The description adds no extra parameter guidance, so a baseline 3 is appropriate.

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

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

The description clearly states it drops files or MIME-typed data onto an element via drag events. It explicitly distinguishes from sibling tools wavexis_set_files (for file inputs) and wavexis_drag (for dragging DOM 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 provides explicit guidance: 'Use wavexis_set_files for standard <input type="file"> uploads or wavexis_drag for dragging an existing DOM element to another element.' This clearly indicates when to use alternatives.

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

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

Annotations only provide generic flags, so the description carries the burden of explaining side effects. It does this well: it discloses browser backend acquisition, optional navigation, and the fact that arbitrary JS may trigger network requests or DOM mutations. This goes beyond the annotations without contradicting them.

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

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

The description is compact and front-loaded: the first sentence states purpose, the second gives routing guidance, the third discloses side effects, and the final line documents the JSON return shape. No sentence is wasted.

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 an eval tool with multiple configuration params and strong side effects, the description covers the key behavioral boundaries (browser, network, mutations), alternative tool selection, and the return contract. It stops short of describing the parameter wiring, but the nested schema contains descriptions for those fields, so the gap is acceptable. Overall it is nearly complete for a custom browser-eval tool.

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

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

Schema description coverage for the top-level parameter is reported as 0%, so the description should compensate for undeclared parameter semantics. It clarifies only the `url` side effect and the result format, but it does not explain `session_id`, `backend`, `headless`, `wait_timeout`, or `await_promise`. These are meaningful choices an agent must correctly interpret to invoke the tool well.

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

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

The description opens with a specific verb ('Evaluate') and resource ('JavaScript expression in the browser context'), and states that it returns the result. It also names two sibling tools it is not, which differentiates it clearly from wavexis_scrape and wavexis_act.

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

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

The description explicitly tells the agent when to use wavexis_scrape ('when the same expression must run across many pages') and wavexis_act ('for natural-language interaction instead of raw JS'). This gives a clear decision rule for choosing this tool versus alternatives.

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

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

Annotations indicate destructiveHint=true; description adds specific side effects: clears target, sets value, fires single input event. Also documents return format with status and error details. No contradictions.

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?

Concise, well-structured: purpose first, then usage guidelines, side effects, and return format. 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 sibling tools, annotations, and schema descriptions, the description fully covers behavior, side effects, and return format. Output schema exists but description still documents return format explicitly.

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?

Input schema includes detailed descriptions for all parameters (e.g., selector, value). Description does not add additional parameter info but maintains baseline. Context signal indicates schema description coverage 0% but schema clearly has descriptions; if coverage were actually 0%, would 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?

Clearly states 'Fill an input element with a value, replacing existing content.' Explicitly contrasts with sibling tools wavexis_type and wavexis_fill_form, specifying unique verb-resource-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?

Provides explicit guidance: 'Use wavexis_type for character-by-character typing with key events, or wavexis_fill_form when filling multiple fields in one call.' This clearly differentiates usage 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?

The description discloses side effects beyond annotations: 'Clears and sets the value of each field, firing input events on every targeted element.' It also details the return JSON structure, including error keys. This adds significant value given the tool has destructiveHint and no idempotentHint.

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 (4 sentences) and well-structured: purpose first, usage guidance, side effects, return format. No extraneous 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?

Given the tool's complexity (multiple parameters, nested objects, no output schema in structured format), the description covers purpose, alternatives, side effects, and return values comprehensively. The return format is fully described.

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?

Despite a reported 0% schema description coverage, the actual input schema contains detailed descriptions for all parameters (e.g., 'CSS selector for the input element', 'Value to fill'). The description does not add further parameter-level information, so a baseline of 3 is appropriate.

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

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

The description clearly states the tool fills multiple form fields in one call, identifies itself as a convenience composite tool, and distinguishes its purpose from sibling tools like wavexis_fill (single field) and wavexis_type (per-keystroke).

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

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

The description explicitly guides when to use this tool vs alternatives: 'Use wavexis_fill for a single field or wavexis_type when per-keystroke events are required.' This provides clear 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?

Beyond the annotations, the description clarifies that this tool read-only fetches and searches the a11y tree and exposes the exact return shape ('status', 'matches', 'count'), including that results are returned as a JSON string. It does not discuss regex syntax limits or how 'limit' affects results, but it provides substantial operational detail without contradicted annotations.

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

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

The description is compact and logically ordered: the core functionality, the main alternative, side effects, and return schema are each mentioned in separate, crisp sentences. No unnecessary words or filler distract from the message.

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-only search tool, the description covers operation, safety, alternative routing, side effects, and return format. Together with rich annotations and a schema that explains required fields, an agent has enough context to select and invoke the tool correctly.

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

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

The input schema already documents each parameter: text or regex to search, maximum number of matches, and the active session ID. The tool description does not add substantial parameter-level meaning beyond that, so the baseline score is appropriate.

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

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

The description clearly states a specific action: searching the accessibility snapshot for nodes matching text or regex. It differentiates from wavexis_act by calling out that tool for natural-language interaction, but does not distinguish itself from the similarly named wavexis_find_by_text sibling, which keeps it from a perfect score.

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

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

It explicitly directs users to wavexis_act for natural-language element interaction, and the Playwright-compatibility note gives useful context for expected behavior. However, it does not explain when to choose waveaxis_find over wavexis_find_by_text or other snapshot/DOM search tools, so only one alternative is fully covered.

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

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

The description adds details beyond annotations: it states no side effects, that it is read-only, and does not interact. It also describes the return format and error structure. Annotations already indicate readOnlyHint=true, but the description reinforces and expands on behavioral traits.

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

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

The description is concise: three short paragraphs with clear separation of purpose, usage context, and return format. 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?

The tool is simple with few parameters. Annotations are present, and the description covers purpose, usage, side effects, and return format. No gaps remain, making it fully complete for an AI agent.

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

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

The input schema provides descriptions for all three parameters (query, all, session_id). The tool description does not add new parameter information beyond what the schema already covers. With schema_description_coverage effectively high, the baseline of 3 is appropriate.

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

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

The description clearly states it finds element selectors by visible text content. The verb 'find' and resource 'element selector(s)' are specific. It is distinct from siblings like wavexis_dom_query or wavexis_find because it specifies 'by visible text content' and 'without interacting'.

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

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

The description explicitly advises using this tool before wavexis_click or wavexis_fill when the visible text is known but the CSS selector is not. This provides clear context and ties to sibling tools, though it does not explicitly mention when not to use it or alternative tools.

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

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

Annotations are all false, so the description adds valuable context: side effects (changes active page, may trigger network requests) and the return format (JSON with status). It does not cover error cases explicitly, but the return format implies errors.

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

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

The description is very concise: four sentences each serving a distinct purpose (action, usage, side effects, return). No unnecessary words; front-loaded with the core action.

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 navigation tool, the description covers purpose, usage guidelines, side effects, and return format. It lacks explicit mention of prerequisites (e.g., session must exist, forward history), but the side effects and return error status imply these. With annotations lacking transparency, this is adequate.

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 does not add meaning beyond the input schema. The only parameter, session_id, is described in the schema as 'Active session ID', and the tool description does not elaborate on its context or relationship to other tools. With 0% schema description coverage, more parameter context would be beneficial.

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 'Navigate forward one step in the browser history' with a specific verb and resource. It distinguishes from wavexis_back and wavexis_navigate by mentioning their appropriate 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 explicitly says to use this after wavexis_back to restore a page and suggests wavexis_navigate for direct URL navigation. It does not mention when not to use (e.g., no forward history), but the guidance is clear enough.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond annotations: 'Side effects: None; queries the local filesystem only.' This provides transparency about side effects and scope, which is not captured in the annotations. No contradiction found.

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

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

The description is concise with three short paragraphs. It front-loads the main purpose, then provides usage alternatives, and finally lists side effects and return format. Every sentence adds distinct value with no redundancy, making it highly efficient for an AI agent.

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, read-only, idempotent), the description covers all essential aspects: purpose, sibling differentiation, side effects, and return type. An output schema exists (as per context signals), but the description still lists the expected keys in the return JSON, which is helpful. No gaps remain.

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 'input' of type object with no properties, effectively making the tool parameterless. The schema description coverage is 0% because the inner object has no description. However, the description does not discuss parameters, and since the tool takes no meaningful arguments, the omission is acceptable. The description could have explicitly stated 'takes no arguments' but the schema already conveys this. Score 4 for not adding value 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 returns wavexis-mcp server configuration and available browser backends. It distinguishes itself from the sibling tool wavexis_backends by noting that this tool additionally exposes the server name for introspection, while wavexis_backends only returns the backend list. This provides a specific verb and resource with clear differentiation.

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

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

The description explicitly provides usage guidance: 'Use ``wavexis_backends`` instead when you only need the backend list', which tells the agent when to use an alternative. It also implies this tool is for full configuration introspection, giving clear context for when to invoke 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?

Annotations indicate readOnlyHint false and destructiveHint false, which are consistent with a hover operation. The description adds value by detailing side effects: moving the mouse cursor and firing mouseover/mouseenter events that may reveal tooltips. No contradictions or missing critical behaviors.

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

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

The description is extremely concise, with no wasted words. It front-loads the purpose, then distinguishes from sibling, lists side effects, and specifies return format. Every sentence serves a clear 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 simplicity of the hover operation, the description is sufficiently complete. It covers purpose, comparison to click, side effects, and return format. However, it does not explain session management implications, but that is partially covered by sibling tools and schema. Overall, very good.

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

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

The input schema provides descriptions for each parameter, so the schema already handles parameter meaning. The tool description only mentions the CSS selector and does not add additional context for other parameters (url, backend, etc.). Baseline score of 3 is appropriate.

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

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

The description clearly states 'Hover over an element matching a CSS selector' and explicitly distinguishes from wavexis_click by noting that hover only moves the cursor without clicking. This differentiates it from its sibling tool effectively.

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

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

The description explicitly references wavexis_click as the alternative for activating an element, providing clear when-to-use guidance. It does not explicitly list when not to use, but the context is sufficient for decision-making.

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

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

Annotations only indicate destructiveHint=true and readOnlyHint=false. The description adds specific side effects: 'Triggers click handlers and may navigate or mutate the iframe DOM' and describes return format, going well beyond annotations. No contradiction.

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

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

Three concise sentences: purpose, usage guidance, side effects and return. No fluff, well-structured and front-loaded with the action.

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 a simple click action, annotations present, and output schema defined, the description covers purpose, when-not-to-use, side effects, and return format. Complete for effective tool selection and invocation.

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

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

The tool description does not discuss parameters, but the input schema provides descriptions for all three properties ('CSS selector inside the iframe', etc.), resulting in high schema description coverage. Thus baseline 3 is appropriate; the description adds no extra semantic value.

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

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

The description clearly states 'Click an element inside an iframe' with a specific verb and resource. This distinguishes it from sibling tools like wavexis_click (click in main frame) and wavexis_iframe_fill (fill inside iframe).

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 advises to use wavexis_iframe_eval only when actions cannot be expressed by click/fill, providing a clear when-not-to-use. It does not exhaustively list all alternatives but gives effective 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?

Explicitly discloses that side effects are arbitrary because user-supplied JavaScript is executed in the iframe, which goes beyond what annotations alone convey. It also documents the return shape as a JSON string with 'status' and 'result' keys, giving the agent a clear outcome expectation.

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?

Every sentence earns its place: the operation is stated first, sensible alternatives are given, and the side effects and return contract are compactly summarized. There is no fluff or redundant boilerplate.

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

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

The description covers what the tool does, when to avoid it, what side effects to expect, and what the response looks like. It does not mention error cases or promise-await behavior, but the schema covers await_promise and the side-effect warning compensates for the risk that raw JS evaluation entails.

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

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

The description adds little beyond what the schema already provides: it tells the agent that an expression is evaluated in an iframe, but does not explain session_id, iframe_selector, or await_promise semantics. However, the input schema itself contains descriptive property documentation, so the baseline coverage is adequate and the tool description does not need to fully repeat 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?

States a specific, unambiguous action: evaluate a JavaScript expression inside an iframe. It is clearly distinguished from sibling tools like wavexis_iframe_click and wavexis_iframe_fill by emphasizing that this is the raw JS path rather than a standard 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?

Directly tells the agent to prefer wavexis_iframe_click or wavexis_iframe_fill for standard interactions instead of raw JS, which is an explicit when-not-to-use signal. It does not mention a specific alternative for non-iframe evaluation (wavexis_eval), but the iframe-specific name and context make the intended scope 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?

The description details side effects: 'Mutates the input value within the iframe; may trigger input/change events.' This adds specific behavioral context beyond the annotations (destructiveHint=true) and clarifies that the tool can trigger events, aiding in agent decision-making.

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 with four sentences covering purpose, usage guidance, side effects, and return format. Each sentence serves a distinct purpose and is front-loaded with the primary action, making it efficient 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?

Given the tool's four parameters and existing annotations, the description covers the key behavioral aspects (purpose, side effects, return format, and guidance). It could be improved by mentioning prerequisites like an active session or error conditions, but overall it sufficiently equips an agent to understand the tool's 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 already provides clear descriptions for all nested parameters (session_id, iframe_selector, selector, value). The tool description does not add extra parameter information, and the top-level 'input' parameter lacks a description. However, the schema coverage is effectively high for the nested fields, so the description adds minimal value 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 states 'Fill an input element inside an iframe with a value,' using a specific verb (fill) and resource (iframe input element). It clearly differentiates from sibling tools like wavexis_fill (main page) and wavexis_iframe_click (clicking), making the tool's purpose unambiguous.

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

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

The description advises 'Use wavexis_iframe_click to submit or activate the field after filling,' providing explicit context on when to use this tool and a follow-up action. It implies not to use this tool for clicking or submission, though it lacks explicit 'when not to use' statements.

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

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

Annotations already convey destructiveHint=true and openWorldHint=true. The description adds valuable context: it may launch an ephemeral browser, navigate to URLs, and execute arbitrary backend methods, which is potentially destructive and clarifies the open-world nature. It also specifies the return format. This goes beyond the annotations without contradicting them.

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

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

The description is well-structured in three concise paragraphs: purpose/escape hatch, usage guidelines, and behavioral notes (side effects, return format). Every sentence contributes value with no redundancy or excessive length.

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 complexity (generic escape hatch with many parameters) and the presence of a detailed input schema and output description, the description covers purpose, when to use, side effects, and return format. It does not list all possible backend methods but provides sufficient examples, making it largely complete for agent use.

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 does not elaborate on any parameters beyond mentioning the method name. However, the input schema provides detailed descriptions for all properties (e.g., url, proxy, timeout). Since schema coverage is high, the baseline is 3, and the description adds no extra parameter-level meaning.

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

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

The description clearly identifies the tool as an escape hatch for invoking any wavexis backend method by name. It distinguishes itself from dedicated sibling tools (e.g., wavexis_act, wavexis_navigate) by stating to use those instead when available, making the purpose unambiguous.

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

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

Explicitly states when to use this tool (for methods without a dedicated MCP wrapper) and when to use alternatives (dedicated tools like wavexis_act). Provides concrete examples of methods that lack wrappers, offering clear guidance for the agent.

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

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

The description adds a behavioral disclosure beyond the annotations: 'Side effects: Sends a key-down input event to the browser page' and states the return format as a JSON status string. It could go slightly further by noting that a raw keyDown may need to be paired with wavexis_key_up, but the main runtime behavior is clear.

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

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

The description is compact and front-loaded: first sentence says exactly what the tool does, second sentence gives routing guidance, and the final lines state side effects and return format. No sentence is wasted or redundant.

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-level event-dispatch tool, the description covers the core invocation context: what it sends, where it sends it, how it should be positioned relative to higher-level typing tools, and what response shape to expect. It could be marginally more complete by noting the active page requirement or the key-up pairing, but the essential context is present.

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 description contains no parameter-level guidance and does not mention the required session_id, the key parameter, or the modifier toggles. Context reports 0% schema description coverage, and this description does not compensate by explaining the input contract that an agent must satisfy.

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?

Opens with a precise verb and resource: 'Dispatch a raw keyDown event to the active page via CDP.' This clearly identifies what the tool executes and at what level. It also distinguishes itself from sibling tools by directing typing flows to wavexis_press_keys and natural-language flows to wavexis_act.

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

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

Explicitly states when to use this tool vs alternatives: 'use wavexis_press_keys for typing text and wavexis_act for natural-language interaction.' This gives the agent concrete routing criteria and keeps the raw keyDown tool scoped to low-level CDP 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?

Annotations are present but provide minimal info (no readOnly, destructive, idempotent hints). The description adds valuable detail: side effects ('Dispatches a keydown/keypress/keyup sequence') and return format. It complements annotations well, though could mention requirement for active session.

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 (5 sentences), front-loaded with purpose, and structured logically: purpose, usage guidelines, side effects, return type. No 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?

Given the tool's simplicity, the description covers purpose, usage, side effects, and output. It could explicitly state that the key is pressed on the currently focused element (implied but not explicit). Output schema exists, so return values are documented. 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?

The input schema already provides clear descriptions for both parameters ('key' and 'session_id'). The tool description does not add extra parameter information beyond the schema, so baseline score of 3 is appropriate given schema coverage.

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

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

The description clearly states 'Press a single keyboard key on the focused element' with a specific verb and resource. It also distinguishes from siblings wavexis_type and wavexis_fill, which are for typing strings or setting field values without individual key events.

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

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

The description explicitly instructs when to use alternatives: 'Use wavexis_type for typing full strings or wavexis_fill for setting field values without individual key events.' This provides clear context for tool selection.

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 meaningful annotation hints (all false), the description carries the disclosure burden. It explicitly states the side effect — sending a key-up input event to the browser page — and describes the return value. It does not mention failure behavior or session-state requirements, but the core behavioral impact is transparent.

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

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

The description is compact and well-structured: behavior first, then guidance/alternatives, then side effects and return value. Each sentence adds distinct information 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 availability of an output schema, the description covers the important contextual gaps: it defines the low-level purpose, pairs it with key_down, provides alternatives, and states side effects. It could be more complete by explicitly noting the need for an active session or that keyUp should follow keyDown, but it is largely sufficient.

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

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

Schema description coverage is 0%, and the description does not compensate by explaining the required key or session_id fields, the modifier flags, or the meaning of 'raw'. The nested schema does contain property descriptions, but the tool description itself contributes almost no parameter semantics beyond saying a keyUp event is dispatched.

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 — dispatching a raw keyUp event to the active page via CDP. It clearly distinguishes itself by naming wavexis_key_down as its pairing counterpart and wavexis_press_keys as the higher-level alternative, so the agent knows what this tool uniquely provides.

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

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

The description gives explicit routing guidance: use wavexis_key_down for low-level key control and wavexis_press_keys for simple text entry. This tells the agent when to choose this tool rather than siblings and when to choose an alternative.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds 'Side effects: None — read-only query' and details on return format, providing useful context beyond annotations.

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: starts with action, then usage, side effects, and return. Every sentence 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?

Given the tool's simplicity, annotations, and output schema, the description is complete. It covers purpose, usage, side effects, and return format, leaving no gaps for an agent.

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

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

The input schema includes a description for session_id ('Active session ID from wavexis_session_open'). The tool description does not add further parameter details, but the schema already covers it adequately.

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 it lists all open browser tabs, with a specific verb and resource. It distinguishes from siblings like wavexis_session_info and tools that need tab IDs.

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 (before wavexis_activate_tab or wavexis_close_tab) and when-not-to-use (use wavexis_session_info for session metadata), along with alternatives.

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?

It discloses the exact CDP events dispatched (mouseMoved, mousePressed, mouseReleased), states that page interactions may be triggered, and gives the return shape. This meaningfully supplements the annotations, which already hint at non-read-only, destructive 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?

Three short, focused segments: the operation, the alternative tool, and side effects/returns. Every sentence earns its place, and the key purpose is 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?

For a drag tool with a rich input schema and explicit annotations, the description adequately covers side effects, the compatibility context, the natural-language alternative, and the response format. An agent can correctly select and invoke the tool without further inference.

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 itself adds only the general 'screen coordinate' semantics. However, the nested input schema documents all parameters in detail (start/end coordinates in CSS pixels, steps range, button enum, session_id source), so the schema carries most of the parameter documentation burden.

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

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

The description opens with a specific verb and resource: 'Drag the mouse from one screen coordinate to another via CDP mouse events.' It clearly distinguishes this raw coordinate-based drag tool from higher-level alternatives and states it is for Playwright-compatible drag operations.

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

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

The description explicitly tells the agent to use wavexis_act instead for natural-language drag interactions, naming the alternative and the condition under which it should be chosen. This leaves no ambiguity about when this tool 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?

Discloses side effects (network request, replaces page content) and auto-creation of session if session_id is omitted. This adds value beyond annotations (readOnlyHint=false, destructiveHint=false) and is consistent with them.

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

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

Three sentences front-loaded with main action, usage guidelines, and side effects. No wasted words, clearly 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?

Covers main purpose, usage guidelines, side effects, and return value (status, url). Missing details on wait strategy options, but schema descriptions (if present) would fill the gap. Output schema exists and is referenced.

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 schema description coverage at 0%, the description should compensate but only mentions 'configurable wait strategy' without detailing parameters or explaining their meanings. The schema itself has descriptions, but per context coverage is 0%.

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 specific verb 'navigate' and resource 'browser to a URL', clearly distinguishing from sibling tools like wavexis_back/wavexis_forward (history navigation) and wavexis_act (natural-language 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?

Explicitly states when to use (direct URL navigation) and when to use alternatives (history or NL), providing clear context for tool selection.

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?

Disclosed side effects: opens a new tab and optionally issues a network request. This aligns with annotations (readOnlyHint=false, openWorldHint=true). No contradictions. Could elaborate on whether the URL must be valid or if any tab limits apply.

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

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

The description is compact and front-loaded with purpose and usage distinction. It includes side effects and return format in separate sentences. Slight improvement could be grouping related info, but overall efficient.

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

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

For a simple tab-creation tool, the description covers purpose, usage, side effects, and return. It doesn't mention limitations or prerequisites beyond what the schema provides, but given the presence of output schema and annotations, it is sufficiently complete.

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

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

Schema description coverage is low (0%). The description only mentions 'URL' indirectly; it does not explain 'session_id' or that the URL defaults to 'about:blank'. The schema itself provides descriptions, but the tool description adds little 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 action ('Create a new browser tab') and the optional parameter 'URL'. It distinguishes itself from the sibling tool 'wavexis_navigate' by explaining when to use each.

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

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

Explicitly tells when to use (open parallel page) and when not to (use wavexis_navigate for current tab). It doesn't mention prerequisites like an active session, but the schema indicates 'session_id' is required and its source.

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

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

Annotations indicate destructive hint is true but no read-only hint. The description adds side effects: 'Locates the best-matching element via text/semantic matching and triggers a click event.' This clarifies behavior but could elaborate on error cases or matching 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?

Three short paragraphs: purpose, usage guidelines, and side effects/returns. Every sentence adds value, no fluff.

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

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

Covers purpose, usage, side effects, and return format. Given the tool's simplicity and the presence of schema annotations, it is fairly complete. Could mention potential failure modes or limitations.

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 already provides descriptions for all three parameters (query, auto_wait, session_id), so baseline is 3. The description adds nothing extra about parameters, only about return format.

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 'Click an element described in natural language', specifying a verb and resource. It distinguishes from siblings by noting alternatives: wavexis_click for known CSS selectors and wavexis_nl_fill for filling fields.

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

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

Explicitly tells when to use this tool vs alternatives: 'Use wavexis_click when you already know the CSS selector, or wavexis_nl_fill to fill a field described in natural language.' No ambiguity.

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

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

Description adds context beyond annotations: explains side effects (locates via text/semantic matching, clears element, sets value) and return format. Annotations already indicate destructive and open-world behavior, so description complements them without contradiction.

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?

Description is compact (two short paragraphs), front-loaded with purpose and alternatives, then side effects and return. Every sentence adds value without unnecessary fluff.

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

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

Given the tool's complexity (4 parameters, destructive nature, output schema exists), the description adequately covers purpose, side effects, and return format. It does not repeat schema info but provides enough context for basic usage.

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

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

Schema description coverage is 0%, meaning the tool description adds no detail about parameters. It implicitly covers 'query' and 'value' but omits 'auto_wait' and 'session_id'. The description does not elaborate on parameter semantics beyond what can be inferred from names.

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?

Description clearly states 'Fill an element described in natural language with a value', which is a specific verb+resource. It distinguishes from sibling tools wavexis_fill (CSS selector) and wavexis_nl_click (click instead of fill).

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

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

Explicitly tells when to use alternatives: 'Use wavexis_fill when you already know the CSS selector, or wavexis_nl_click to click an element described in natural language.' This provides clear context for tool selection.

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 mentions side effects like launching a browser, navigating, and writing to output_path, which contradicts the readOnlyHint annotation (true). According to scoring guidelines, a score of 1 is assigned for contradiction, as it may confuse an AI agent about the tool's 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 concise with two sentences covering purpose and differentiation, plus a clear listing of side effects and return format. Every sentence earns its place with no redundancy.

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

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

Given the complex schema and output schema, the description covers key behavioral aspects: side effects, return format, and comparison to sibling. It lacks explicit mention of session_id reuse but that is implied. Overall, fairly 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?

The input schema has high description coverage (all parameters have descriptions), so the baseline is 3. The description adds only general context about pixel-level control over paper size and margins, not specific parameter details. Thus, no additional value 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 it generates a PDF via the low-level Page.printToPDF CDP method and distinguishes from the sibling tool wavexis_pdf by emphasizing pixel-level control. It explicitly directs users to wavexis_pdf for simpler high-level generation, making the purpose unambiguous.

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

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

The description provides clear context for when to use this tool versus wavexis_pdf, but does not explicitly state prerequisites (e.g., session_id or url requirement). However, the schema covers that detail, so the guidance is adequate without being exhaustive.

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?

Description goes beyond annotations by stating side effects: 'launches/acquires a browser backend, navigates to url if provided; writes to output_path when given.' Annotations indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, which the description complements without contradiction.

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