WaveXisMCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.6.24
Disambiguation4/5
Most tools have clearly distinct purposes, e.g., separate tools for click, double-click, right-click, tap. However, there is overlap between `wavexis_act` and `wavexis_nl_click`/`wavexis_nl_fill`, and between the dual cookie APIs (`cookies_*` vs. `cookie_*`), which may confuse agents.
Naming Consistency4/5
All tools follow the `wavexis_` prefix with snake_case. Most use verb_noun or verb structure, but there are deviations like `find_by_text`, `nl_click`, `new_tab`, and `get_config`. The pattern is generally predictable but not perfectly uniform.
Tool Count1/5
72 tools far exceeds the typical 3-15 well-scoped range. While browser automation is complex, many tools are redundant or overly granular (e.g., six cookie tools, separate key_up/down/press), making the surface bloated and hard to navigate.
Completeness5/5
The tool set covers virtually every aspect of browser automation: sessions, navigation, DOM interaction, forms, keyboard, mouse, cookies, tabs, iframes, shadow DOM, screenshots, PDF, and more. Agents can accomplish nearly any browser task without resorting to escape hatches like `wavexis_invoke`.
Average 4.3/5 across 70 of 72 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 154 commits in the last 12 weeks
- Last stable release on July 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 2 times in the last 30 days.
This repository includes a glama.json configuration file.
This server has been verified by its author.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Side effects: Arbitrary; executes user-supplied JavaScript', which contradicts the annotation readOnlyHint: true that suggests no side effects. This is a serious inconsistency that misleads the agent about safety and write potential.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, starting with the main purpose. It is well-structured and easy to parse, though slightly more structure could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return format (JSON string with status and result) and mentions side effects. However, it could include more details on error handling, security implications, or limitations. Overall, it is sufficiently complete for a read-heavy tool with annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has descriptions for all four parameters (selectors, expression, session_id, await_promise), providing high coverage. The tool description does not add extra meaning beyond the schema, so it meets the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates a JavaScript expression inside a shadow DOM tree, using a selector chain. It differentiates from sibling tools by recommending wavexis_shadow_click or wavexis_shadow_fill for standard interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear when-to-use vs when-not-to by advising to use specialized shadow interaction tools for standard actions instead of raw JS. However, it does not exhaustively list all alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Side effects: Arbitrary; executes user-supplied JavaScript within the iframe context,' which implies potential mutations. However, annotations set readOnlyHint: true, idempotentHint: true, and destructiveHint: false, directly contradicting the described behavior. This is a serious inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, no wasted words. It front-loads the primary purpose, provides usage guidance, and lists side effects and return format efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite clear purpose and guidelines, the tool is complex (executes arbitrary JS) and has several parameters. The annotation contradiction leaves ambiguity about safety and idempotency. The description fails to resolve this, reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions, achieving 100% coverage. The description adds no additional parameter meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Evaluate a JavaScript expression inside an iframe,' specifying the verb (evaluate), resource (JavaScript expression), and context (inside an iframe). It also distinguishes from sibling tools by recommending wavexis_iframe_click or wavexis_iframe_fill for standard interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when not to use this tool: 'Use wavexis_iframe_click or wavexis_iframe_fill for standard interactions instead of raw JS.' This provides clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior1/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the action is destructive and irreversible, which aligns with annotations. It also adds useful context that the session remains active for other tabs. This goes beyond the annotations by clarifying 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and includes side effects and return value efficiently. Slightly verbose but generally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, side effects, and return format. While it omits prerequisites (e.g., session must exist), the required session_id parameter implies that. Complete enough for a simple resource-freeing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is listed as 0%, the description explains the tab_id parameter's behavior (optional, default current page). It does not elaborate on session_id, but the schema's required field and title suffice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it closes a browser page/tab by target id or current page, which is specific and actionable. However, it does not differentiate from the sibling tool 'wavexis_close_tab', which may cause confusion about when to use which.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions using it to free resources and notes compatibility with Playwright's API, but fails to provide explicit guidance on when to use versus alternatives (e.g., wavexis_close_tab) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts annotations: annotations mark readOnlyHint=true and destructiveHint=false, but description reports side effects like writing to output_path, launching browser, and navigating. This is a clear contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with clear sections, no redundant text, and immediately states the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core behavior, side effects, and return format. Lacks session management context, but annotations and schema partially fill gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions key parameters (url, js, output_path) and their roles, but does not cover all parameters (e.g., media, paper, margin). Given schema description coverage is 0% (contradicted by actual schema), description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a PDF from a web page, and distinguishes between 'wavexis_screenshot' and 'wavexis_page_pdf' for image capture or pixel-level control.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use alternatives ('wavexis_screenshot' for images, 'wavexis_page_pdf' for pixel-level control) and lists side effects, guiding appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists side effects (launching browser backend, navigating to URL, writing frames) which contradict the readOnlyHint annotation (true). The annotation implies no side effects, but the description explicitly states them. This is an annotation contradiction, warranting a score of 1 per guidelines.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is remarkably concise: one sentence for purpose, one for usage guidance, and one for side effects/return value. It is front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action, side effects, and return format. With an output schema available, it does not need to detail the return structure beyond the key names. It is complete for a tool with many parameters and a nested input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already contains detailed descriptions for each parameter, so schema coverage is effectively high. The description adds minimal extra meaning (e.g., that frames are written to output_dir when given), which is also in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as capturing a frame-by-frame screenshot sequence over a duration. It uses a specific verb ('capture') and contrasts with the sibling tool wavexis_screenshot, leaving no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 versus wavexis_screenshot ('use wavexis_screenshot for a single still image, or wavexis_screencast when animation or time-series capture is needed'), providing clear alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects (resets in-memory buffer) and return format. Matches annotations (destructiveHint=true) and adds 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise three-paragraph structure, front-loaded with purpose. No fluff, each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists (not shown but declared), and description specifies return format. Adequate for a simple clearing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description does not mention the only parameter (session_id). Leaves agent to infer its purpose; fails to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('clear all buffered console messages for the session'). Distinguishes from siblings by specifying console messages, unlike cookies_clear or other clear tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use before capturing fresh logs to avoid stale entries. Provides context on when to use, though no explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes side effects (dispatches mouse events, may trigger page interactions) beyond what annotations provide. Also mentions return format. Adds useful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with front-loaded purpose, usage note, side effects, and return. Efficient use of space, though could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, side effects, and return, but lacks detail on parameter semantics and does not differentiate from wavexis_drag. With output schema present, return is less critical, but more context on usage scenarios would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain individual parameters (e.g., steps, button) beyond coordinates. With 0% schema description coverage, more detail is needed to help agents use parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool drags mouse via CDP events from one screen coordinate to another. It uses a specific verb and resource, and distinguishes from sibling tools like wavexis_act.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions when to use this tool (programmatic coordinate drag) vs. alternatives: wavexis_act for natural-language drag. This provides clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds 'Side effects: None; reads cookie state from the browser session' and details the 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose with filters, alternative tool, side effects and return format. All information is essential and front-loaded, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations and the simple nature of the tool, the description adequately covers its behavior, return format, and alternatives. Minor omission: does not explicitly state that a session must be open, but this is inferable from the required session_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'name, domain, and path filters' but does not cover the 'limit' or 'session_id' parameters. With schema description coverage at 0%, the description partially compensates but lacks complete parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List browser cookies' with optional filters, distinguishing it from the sibling 'wavexis_cookie_get' for a single cookie.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions when to use 'wavexis_cookie_get' instead, providing clear alternative guidance. However, it does not mention the prerequisite of an open session, though this is implied by the required session_id parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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 context by stating 'fetches and searches the a11y tree read-only' and specifies the return format (JSON with status, matches, count). This adds value beyond annotations 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, with the first sentence stating the purpose. Every sentence adds value: purpose, usage alternative, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return format is not required in description, but it's provided anyway. However, parameter descriptions are lacking, and the tool's context (e.g., what an accessibility snapshot is) is assumed. Given the complexity (search tool with limited parameters), completeness is adequate but not excellent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. Only the 'text' parameter is hinted at ('text or regex pattern'). The 'limit' and 'session_id' parameters are not described, leaving the agent to infer their purpose. This is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search the accessibility snapshot for nodes matching text or a regex pattern', specifying a specific verb and resource. It distinguishes itself from the sibling tool wavexis_act by noting that wavexis_act is for natural-language interaction, 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use `wavexis_act` instead for natural-language element interaction; this tool mirrors Playwright's snapshot search for compatibility.' This tells when to use this tool versus alternatives. Additionally, it mentions 'Side effects: None', reinforcing safe usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (all false), so the description carries the burden. It states side effect (sends key-down event) and return format (JSON with status). No contradiction with annotations. Could be improved by noting if the event is dispatched synchronously or any error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 4 sentences: purpose, usage context, side effect, return format. No redundant phrases, front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (keyboard events), the description covers purpose, alternatives, side effects, and return. It references CDP and Playwright for context. Lacks mention of prerequisites (session must be open) or error states, but the output schema helps. Nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not detail any parameters; schema description coverage is 0%. However, the input schema itself has property descriptions (e.g., key). The description compensates by saying 'raw keyDown event' and 'mirrors Playwright's API,' but does not add parameter-specific guidance. Baseline 3 is appropriate since the schema already documents parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it dispatches a raw keyDown event via CDP, using a specific verb and resource. It distinguishes from siblings by recommending wavexis_press_keys for typing and wavexis_act for 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.
Usage Guidelines4/5
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 alternatives (press_keys, act), but does not mention other related siblings like wavexis_key_up. The context is clear enough for an agent to make a correct choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds beyond that: 'Side effects: launches/acquires a browser backend, navigates to each URL sequentially, evaluates expression in every page context.' It also describes the return JSON structure, providing useful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs, first sentence defines purpose, second provides usage guidance and side effects. Every sentence adds value, no fluff. Well-structured and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (multiple URLs, browser backend) and rich input schema with 9 parameters, the description covers the overall behavior, return format, and side effects. It lacks explanation of some parameters like backend or selector, but those are described in the schema. It is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% according to context, but actually the schema has descriptions for each parameter. The tool description does not add any additional parameter-level detail beyond what's already in the schema. Baseline is 3 due to schema coverage, and description adds no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Scrape data from multiple URLs by evaluating a JS expression on each.' It uses specific verb (scrape) and resource (data from URLs), and distinguishes from sibling wavexis_eval by noting it's for single-page evaluation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool vs wavexis_eval: 'Use wavexis_eval for single-page evaluation, or wavexis_scrape when the same expression must run across many pages with pagination.' It provides clear context but does not mention when not to use it beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive and non-readonly, but description adds side effects (firing events) and return format. It goes beyond annotations but could mention prerequisites like element visibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: purpose, usage guidance, side effects, return. Concise but not overly terse. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage alternatives, side effects, return format. Missing prerequisites (element visibility, focus) but overall sufficient for a typing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description does not explain parameters like selector, text, delay, etc. Schema has detailed property descriptions but description adds no parameter-level detail, despite low schema description coverage (0%) signal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it types text character by character with optional delay. It distinguishes itself from siblings by explicitly mentioning alternatives: wavexis_fill for instant value and wavexis_fill_form for multiple fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use wavexis_fill instead when you want to set a field's value instantly without per-keystroke delays, or wavexis_fill_form for multiple fields.' This tells the agent when to choose alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two sentences plus bullet points for side effects and return values. Every sentence adds value; there is no wasted text. The structure is clear and front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of sibling tools and rich schema, the description covers purpose, usage guidelines, side effects, and return format (JSON structure with keys). Annotations provide additional safety info, making this complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema has detailed descriptions for each property, the tool description only mentions 'url' and 'output_path' in the side effects. With 0% schema description coverage from the tool description, it adds minimal value beyond the schema. However, the schema itself provides good parameter documentation, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Capture the page as MHTML or a plain text document', specifying the verb 'capture' and resource 'page' with formats. It distinguishes from sibling wavexis_scrape by noting its use for structured data extraction, establishing a clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly guides when to use this tool vs wavexis_scrape: 'Use wavexis_scrape for structured data extraction, or this tool when a full page archive (MHTML) or text dump is required.' This provides clear context, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: describes side effects (mutates input, may trigger events) and return format. No contradiction with annotations (destructive hint true matches mutation). Could mention permission requirements or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, usage hint, side effects/return. No wasted words; front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given schema provides parameter descriptions, description covers purpose, side effects, return format, and a sibling usage hint. Output schema exists so return details not needed. Complete for a focused tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% so description must compensate. It gives context for selectors ('pierces shadow boundaries') and value ('fill...with a value'), but does not elaborate on session_id or precise selector format. Adequate but not thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Fill', resource 'input element inside a shadow DOM tree', and distinguishes from siblings like wavexis_fill and wavexis_shadow_click. It also mentions piercing shadow boundaries, specifying the unique capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to use wavexis_shadow_click after filling for submission/activation. Implies context of shadow DOM but lacks explicit when-not-to-use or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true and destructiveHint false. Description adds that side effects are none and reads cookie state, aligning with annotations. It also describes return format, which provides extra 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with bullet-like side effects and returns. Front-loaded with action 'Retrieve a single cookie'. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations covering safety and output schema for return, description is mostly complete. Minor gap: session_id parameter not explained, but it is likely a common context parameter across tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description clarifies name as main identifier and mentions optional path/domain, adding meaning over schema. However, it does not explain the session_id parameter, which is required. Baseline 3 with partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Retrieve a single cookie by name (and optional domain/path)', clearly identifying the tool's specific verb and resource. It distinguishes from the sibling wavexis_cookie_list, which is for multiple cookies or broad filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description proactively directs to wavexis_cookie_list when multiple cookies or broad filtering are needed, providing clear when-to-use and 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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description discloses side effects: launches/acquires browser backend, navigates to URL, executes arbitrary JS (may trigger network requests or DOM mutations). This adds valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise paragraphs. First sentence gives clear purpose. Second covers usage and side effects. Third describes return format. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description covers return format. However, it lacks guidance on session management (session_id) and detailed parameter behavior. Still adequate for most use cases given good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description should compensate. Only mentions url briefly (navigates to if provided) and return format. Does not describe other parameters like expression, session_id, wait_timeout, etc. Inadequate for a tool with 7 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Evaluate' and the resource 'JavaScript expression in the browser context'. It also distinguishes from sibling tools like wavexis_scrape and wavexis_act, which are for different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use wavexis_scrape (same expression across many pages) and wavexis_act (natural language interaction) instead, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false), and description acknowledges side effect ('Sends a key-up input event'). No contradiction. Could be improved by noting session requirement or potential impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise—three sentences plus a side effects/returns note. Every sentence adds value, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple dispatch tool with output schema, the description covers what the tool does, its side effects, and return format. No gaps given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds no parameter details. Parameters like 'key', 'code', modifier keys are left for the schema to explain, which is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Dispatch a raw keyUp event to the active page via CDP') and distinguishes itself from siblings by mentioning pairing with wavexis_key_down and suggesting wavexis_press_keys for simple text entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use this tool versus alternatives: pair with wavexis_key_down for low-level control, or use wavexis_press_keys for simple text entry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (which are minimal), the description discloses side effects: dispatches keyDown/keyUp pairs, no network requests, and return format. This adds value, but could mention more about focus requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four short lines, uses bullet points for side effects and returns, and front-loads the primary action. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of a rich schema and output schema, the description covers behavior, side effects, return format, and alternatives. Slight gap: it doesn't mention that the page must be focused, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has detailed descriptions for each parameter (text, delay, session_id). The description adds no further parameter-level details, so it meets the baseline but does not exceed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Type' and the resource 'a sequence of characters at the page level without targeting an element.' It distinguishes from sibling tools like wavexis_key_down/up 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides alternatives: 'Use wavexis_key_down/wavexis_key_up instead for individual modifier-key control, or wavexis_act for natural-language typing.' This guides 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false and destructiveHint=true, indicating the tool modifies state. The description adds valuable behavioral details: 'Side effects: Fires a contextmenu event on the element, typically opening a context menu in the browser.' and outlines the return format. However, it doesn't specify if the tool waits for the context menu to appear or any other post-action behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loaded: it starts with the purpose, immediately gives alternatives, then side effects, and finally return format. Every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage alternatives, side effects, and return format. Given the tool has multiple parameters and an output schema, it provides sufficient context for an agent to decide when and how to use it. However, it could briefly mention that it operates on the current page or session context, which is implied but not explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only mentions the 'CSS selector' parameter, which is already described in the input schema. Other parameters (url, backend, headless, etc.) are not elaborated in the description. Since the input schema itself contains descriptions for each property, the description adds minimal value to parameter understanding, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Right-click an element matching a CSS selector.' It distinguishes itself from siblings by explicitly mentioning alternatives: 'Use wavexis_click for standard left clicks or wavexis_double_click for double clicks.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 alternatives ('Use wavexis_click for standard left clicks or wavexis_double_click for double clicks.') and mentions side effects, giving clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses side effects ('Changes the selected option, firing change and input events') and the return format (JSON with status/error keys), which complements the destructiveHint annotation, adding value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 3 sentences, front-loaded with the core action, and includes essential usage guidance and side effects without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity with a nested input schema, the description covers core functionality, side effects, and output format well. It misses explaining some parameters (backend, session_id) but the schema already covers them, making it largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description bears full burden but only hints at the 'value' parameter ('by value'). It does not explain other parameters like selector, backend, session_id, or wait_timeout, which are only documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Select an option in a ``<select>`` element by value,' specifying the verb, resource, and method. It distinguishes between native `<select>` elements and alternatives like wavexis_fill or wavexis_click, which differentiates it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 (for native `<select>` elements) and when to use others (wavexis_fill for text inputs, wavexis_click for custom dropdowns), providing clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects: re-issues network requests and discards in-memory page state. Annotations provide no hints, so description adds value. Could mention if it's safe but not required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded, no wasted words. Purpose, usage, side effects, and return value are all covered efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple reload tool with two parameters and known output format, the description is complete. Side effects and return type are specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover both parameters; description adds minimal extra meaning ('optionally bypassing the cache' for ignore_cache). Baseline 3 as schema coverage is high in the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Reload the current page' with a specific verb and resource, and distinguishes from wavexis_navigate for going to a different URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (refresh stale content, retry failed load) and when not (use wavexis_navigate), with clear side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnly and idempotent. The description adds value by stating 'Side effects: None — read-only; queries in-memory session state and the browser's current URL', providing behavioral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds value: purpose, usage, side effects, and return format. Front-loaded with the core action, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: purpose, usage, side effects, and return values. Output schema is described with keys. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the session_id parameter with its origin. Although description does not repeat parameter info, schema coverage is sufficient, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query metadata and current URL of an active browser session', using a specific verb and resource. It distinguishes from sibling tool wavexis_list_tabs by explicitly mentioning that tab-level details are handled by that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use to inspect session health or retrieve the current page URL; use wavexis_list_tabs for tab-level details instead', providing clear guidance on when to use and when to use an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses side effects: triggers click handlers and may navigate or mutate the shadow DOM. It also specifies the return format (JSON with 'status' key). This adds significant value beyond annotations, which already indicated destructiveHint=true and readOnlyHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct with only three sentences, no unnecessary details, and front-loaded with the core action. Every sentence provides distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For its complexity, the description covers key aspects: shadow DOM piercing, side effects, return format, and a usage alternative. Combined with annotations (destructive, open world) and output schema (present), it provides a complete understanding for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions for both parameters (selectors and session_id) are already present and clear. The tool description does not add additional parameter meaning beyond what the schema provides. Hence baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool clicks an element inside a shadow DOM tree by piercing shadow boundaries. It specifies the action (click), target (shadow DOM element), and method (selector chain), effectively differentiating it from siblings like wavexis_click (regular click) and wavexis_shadow_fill (fill instead of click).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using wavexis_shadow_eval for custom JS that click/fill cannot express, providing a clear alternative. However, it lacks explicit when-to-use guidance compared to other click tools (e.g., wavexis_click), though the shadow DOM context intrinsically narrows usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects: launches browser process, allocates server-side state, may open network connections. This adds value beyond annotations (openWorldHint, destructiveHint) and matches them. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with one sentence each for purpose, usage, side effects, and return. Every sentence is informative and front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (14 parameters, many siblings, annotations, no output schema but described), the description covers purpose, usage, side effects, and return format adequately. The parameter details are in the schema, so completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description does not describe any of the 14 parameters; schema descriptions are present but the context signal shows 0% schema_description_coverage in the description. With low coverage, the description should compensate, but it does not. Only a basic mention of the return structure is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool launches a persistent browser session, using the verb 'Launch' and the resource 'browser session'. It distinguishes from sibling `wavexis_navigate` by specifying that `wavexis_navigate` with session_id omitted is for one-off fetches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call once at task start and reuse the session_id, and contrasts with `wavexis_navigate` for one-off page fetches. Provides clear when-to-use and 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects (sets selected files, fires change events) and explains return structure with error keys. Annotations already indicate destructive and not read-only; description adds 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (few sentences), front-loaded with purpose, then usage guidance, side effects, and return format. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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. Lacks explicit prerequisites like needing a session or page, but optional session_id and url parameters address that partially. Siblings are many but the tool is well-differentiated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all parameters (e.g., files, selector). The main description adds minimal extra detail beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool uploads files to a file input element. Distinguishes from wavexis_drop for drag-and-drop. Specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (for file input elements) and when to use the alternative wavexis_drop. Also describes side effects like triggering change events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and non-destructive behavior. The description adds specific side effects: dispatches a touch tap, may toggle controls or trigger navigation on mobile-optimised pages. It also details the return format including error keys. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and well-structured: first sentence defines the action, second gives usage guidance, third covers side effects and return format. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers purpose, usage, side effects, and return format. Output schema is implied by the description of the JSON return. While prerequisites (e.g., needing a page) are not explicitly stated, the session parameter handles this implicitly. Overall, it is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 additional parameter information beyond what the input schema provides. However, the schema itself has clear descriptions for all parameters (e.g., 'CSS selector for element to tap'), so the agent can understand parameters from there. The tool description does not add extra meaning, scoring at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool taps an element using a CSS selector with touch emulation, and explicitly distinguishes it from sibling tools wavexis_click (mouse-based) and wavexis_nl_click (natural language). The verb 'tap' is specific and action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 (touch-emulated click) versus alternatives (wavexis_click for desktop, wavexis_nl_click for NL description). This direct comparison leaves no ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds side effects ('Clicks the target checkbox to toggle it to unchecked, firing change events') beyond annotations, and does not contradict the destructiveHint or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with clear front-loading: purpose, usage guidelines, then side effects and return value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, side effects, return format, and distinguishes from siblings. The output schema exists, but the description still provides helpful details. 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 0% of parameters, but the tool description does not mention parameters or add meaning beyond the schema's own parameter descriptions. No additional value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Uncheck a checkbox matching a CSS selector by clicking it.' Verb and resource are specific, and the description distinguishes this from sibling tools like wavexis_check 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use wavexis_check for checking and wavexis_click for generic clicks, providing clear when-to-use and 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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses side effects (launches browser, navigates, evaluates JS, writes to disk) beyond annotations. Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, and description adds specifics. Return format is also described. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise—three short paragraphs covering purpose, alternatives, side effects, and return format. No wasted words, front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, many sibling tools), the description provides complete context: purpose, usage guidelines, side effects, return structure. Output schema exists, so return values need not be detailed further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has comprehensive descriptions for all properties, so the description does not add additional meaning. Schema coverage is 0% per context, but the actual schema includes parameter descriptions. Leading to baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool captures a screenshot of a web page or matched element. It distinguishes from sibling tools wavexis_pdf (print-ready document) and wavexis_annotated_screenshot (labelled element markers). Verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use alternatives: 'Use wavexis_pdf when a print-ready document is needed, or wavexis_annotated_screenshot when labelled element markers are required.' Also lists side effects, which helps the agent decide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant detail beyond annotations: explains side effects (terminates browser process, frees session state, unsaved data lost). Consistent with destructiveHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds value. Front-loaded purpose, then usage, side effects, return. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with annotations and output schema, description covers purpose, when to use, side effects, and return format. Fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one required parameter, schema provides a description. Description adds no extra param info, but schema coverage is sufficient; baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it closes a browser session and releases resources. It distinguishes from sibling tool wavexis_close_tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (session no longer needed) and when not to (use wavexis_close_tab for tabs). Provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false, and the description adds valuable behavioral context: 'Side effects: Aborts in-flight network requests and pending navigations; the page is left in its current partial state.' 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences with no fluff: purpose, usage guidance, side effects, and return format. Well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 all needed aspects: purpose, when to use, side effects, and return format. The output schema is mentioned implicitly by describing the return format. Fully complete for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the session_id parameter, but the input schema provides a description ('Active session ID'). With 0% schema coverage reported, the description could have added value, but the schema compensates. Score is baseline as schema covers the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop all pending navigations and resource loads in the session') using a specific verb and resource, and distinguishes itself from the sibling tool wavexis_wait.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool ('when a page load is hanging or no longer needed') and when not to (use wavexis_wait instead), providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses side effects: 'None — read-only polling with no page mutations; blocks the tool call up to the configured timeout.' This adds context beyond annotations (readOnlyHint, idempotentHint) by detailing the blocking behavior and polling nature. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single sentence for purpose, followed by usage notes, side effects, and return format. Every sentence adds value and is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (one required parameter, five optional with enums) and the presence of thorough schema descriptions, the description covers all necessary aspects: purpose, when to use, side effects, and return format. It is sufficient for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not elaborate on individual parameters; however, the input schema already provides detailed descriptions for each parameter (timeout, selector, strategy, url_pattern). Since schema coverage of descriptions is high, the description adds minimal value beyond restating the purpose and return format. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'block until' and the resource 'a page condition', listing specific conditions (load, selector, URL, network idle). It distinguishes itself from sibling tools like wavexis_navigate and wavexis_stop by providing context on 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'after wavexis_navigate when the wait strategy was none' or 'for dynamic content'. Also provides an alternative: 'use wavexis_stop to cancel a load instead'. This gives clear guidance on usage versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![wavexis-mcp MCP server](https://glama.ai/mcp/servers/MathiasPaulenko/wavexis-mcp/badges/card.svg)](https://glama.ai/mcp/servers/MathiasPaulenko/wavexis-mcp)

Score Badge

Copy to your README.md:

[![wavexis-mcp MCP server](https://glama.ai/mcp/servers/MathiasPaulenko/wavexis-mcp/badges/score.svg)](https://glama.ai/mcp/servers/MathiasPaulenko/wavexis-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MathiasPaulenko/wavexis-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server