mcp-electron-driver

by mesomya

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation4/5
Most tools have distinct purposes, but some overlap exists, such as keyboard_type and press_sequence being aliases, and drag having a complex fallback that could confuse its boundary with other interaction tools. However, descriptions are detailed enough to clarify differences.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with clear verb_noun structures, such as click, get_text, wait_for_selector, and accessibility_snapshot. There are no deviations in naming conventions.
Tool Count3/5
With 39 tools, the count is high for an Electron driver, bordering on heavy. While it covers many scenarios, it may overwhelm agents with its breadth, suggesting some tools could be consolidated or omitted for better focus.
Completeness5/5
The toolset provides comprehensive coverage for Electron app testing, including app lifecycle (start_app, stop_app), window management, UI interaction, evaluation, waiting, and debugging. No obvious gaps are present; it supports full CRUD-like operations for the domain.
Average 4/5 across 39 of 39 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it's a read operation, implying non-destructive behavior, but doesn't disclose other traits like error handling, performance implications, or dependencies (e.g., needing a snapshot for 'ref'). This is insufficient for a tool with potential complexity in web interactions.
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 a single, efficient sentence that front-loads the purpose and lists parameters, with no wasted words. It could be slightly more structured by separating usage hints, but it's appropriately sized for the tool's scope.
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?
Given no annotations, no output schema, and incomplete parameter documentation (50% coverage), the description is inadequate. It doesn't explain return values, error cases, or behavioral nuances, making it incomplete for a tool that interacts with dynamic web elements.
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 50% (only 'ref' has a description), and the description adds that parameters are 'selector' or 'ref', matching the schema. However, it doesn't explain the semantics beyond this, such as what 'selector' expects or how 'ref' relates to snapshots, so it partially compensates but not fully, aligning with the baseline.
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 the verb ('Read') and resource ('current value of a form input, textarea, or select'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_text' or 'get_attribute', which might retrieve similar content, so it doesn't reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'get_text' or 'get_attribute', nor does it mention any prerequisites or exclusions. It only lists parameter options ('selector' or 'ref') without contextual advice, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that it reads from the 'first matching element,' which implies a selection behavior, but doesn't disclose critical traits such as error handling (e.g., what happens if no element matches), performance considerations, or any side effects. This leaves significant gaps in understanding how the tool behaves in practice, especially for a read operation with potential failures.
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 and front-loaded, consisting of just two sentences that directly state the purpose and key parameter usage. Every word earns its place, with no redundant information or fluff, making it easy to parse quickly while conveying essential information efficiently.
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?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is partially complete. It covers the basic purpose and parameter hints but lacks details on behavioral aspects like error handling, return values, or integration with sibling tools. Without annotations or output schema, more context on what the tool returns or how it interacts with the system would improve completeness, leaving it as adequate but with clear 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?
The description adds meaningful context beyond the input schema. While the schema covers 67% of parameters (with descriptions for 'ref' and 'name'), the description clarifies that 'selector' or 'ref' are alternative ways to identify the element, which isn't explicitly stated in the schema. It also implies that 'name' is required (as per schema), but doesn't detail parameter interactions. This compensates well for the schema's partial coverage, though it could elaborate more on parameter usage.
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 the tool's purpose: 'Read an attribute from the first matching element.' It specifies the verb ('Read'), resource ('attribute'), and scope ('first matching element'), which is specific and actionable. However, it doesn't explicitly distinguish this tool from potential siblings like 'get_computed_style' or 'get_text', which might also retrieve element properties, leaving room for improvement in sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: 'Pass `selector` or `ref`.' This implies that either parameter can be used to identify the element, but it doesn't explain when to choose one over the other, nor does it mention alternatives or exclusions. For example, it doesn't clarify if this tool should be used instead of 'get_computed_style' for attribute retrieval, or what happens if no matching element is found, resulting in a lack of contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the action ('press') but doesn't disclose behavioral traits such as whether it simulates a real key press, if it works in specific contexts (e.g., focused window), error handling, or performance implications. The description is minimal and lacks necessary behavioral context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: it states the purpose in the first sentence and provides helpful examples in the second. Every sentence earns its place by adding clarity without waste, making it efficient and easy to understand.
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?
Given the tool's complexity (a mutation action with no annotations and no output schema), the description is incomplete. It doesn't cover what happens after pressing (e.g., response, errors), prerequisites (e.g., window focus), or detailed behavioral traits. For a tool that modifies state, more context is needed to ensure safe and correct usage.
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 1 parameter with 0% description coverage. The description adds meaning by explaining that the 'key' parameter accepts examples like 'Escape' or 'Control+S', which clarifies the expected string format. However, it doesn't fully compensate for the lack of schema documentation, such as listing all valid keys or constraints.
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 the tool's purpose: 'Press a keyboard key or chord in the window.' It specifies the verb ('press') and resource ('keyboard key or chord'), though it doesn't explicitly differentiate from sibling tools like 'keyboard_type' or 'press_sequence' beyond providing examples. The purpose is specific but lacks sibling distinction.
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 implies usage through examples (e.g., 'Escape', 'Control+S'), suggesting when to use this tool for key presses, but it doesn't explicitly state when to use it versus alternatives like 'keyboard_type' (for typing text) or 'press_sequence' (for multiple keys). Guidelines are implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the action as clearing values, which implies mutation, but lacks details on permissions, side effects (e.g., whether it triggers events), error handling, or response format. The analogy to 'selecting all and deleting' adds some behavioral context but is insufficient for a mutation tool with zero annotation coverage.
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 concise sentences with zero waste, front-loading the core action and providing a helpful analogy. Every word earns its place without redundancy or fluff.
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?
For a mutation tool with no annotations, no output schema, and incomplete parameter documentation (50% schema coverage), the description is inadequate. It lacks details on behavioral traits, error cases, return values, and full parameter meanings, leaving significant gaps for an AI agent to use it 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?
Schema description coverage is 50% (only 'timeoutMs' has a description). The description does not explain the 'selector' parameter beyond implying it targets inputs/textarea, nor does it clarify the 'timeoutMs' beyond the schema's default. It adds minimal value over the schema, resulting in a baseline score due to moderate coverage gap.
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 specific action ('Clear the value'), target resource ('input or textarea matching a selector'), and method ('Equivalent to selecting all and deleting'), which distinguishes it from siblings like 'type', 'get_value', or 'set_input_files' that involve different operations on similar elements.
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?
Usage is implied through the description of clearing values, but there is no explicit guidance on when to use this tool versus alternatives like 'type' (for setting new values) or 'get_value' (for reading values). The context suggests it's for resetting input fields, but no exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool returns a bounding box 'of the first matching element,' which implies it selects only one element and may ignore others. However, it doesn't disclose error handling (e.g., what happens if no element matches), performance characteristics, or side effects. The description adds some context but leaves significant gaps for a tool with no annotation coverage.
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 highly concise and front-loaded: the first sentence states the core purpose, the second explains parameters, and the third provides usage context. Every sentence earns its place with no redundant information, 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.
Completeness3/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 (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the purpose and parameters but lacks details on return values (e.g., bounding box format), error cases, or integration with sibling tools beyond a vague reference to 'snapshot.' For a tool with no output schema, more information on the return type would be beneficial.
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?
Schema description coverage is 50% (only 'ref' has a description). The description compensates by explaining the parameter semantics: 'Pass `selector` or `ref`' clarifies that these are alternative inputs, and it adds context that 'ref' is 'from snapshot,' linking to a sibling tool. This provides meaningful guidance beyond the schema, though it doesn't detail the format or constraints of 'selector'.
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 the tool's purpose: 'Get the bounding box of the first matching element in CSS pixels.' It specifies the verb ('Get'), resource ('bounding box'), and scope ('first matching element'), though it doesn't explicitly differentiate from siblings like 'elements_list' or 'snapshot' which might also retrieve element information. The mention of 'CSS pixels' adds useful specificity.
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 provides some usage context: 'Useful before drag operations' implies a specific scenario, and it mentions passing 'selector' or 'ref' as parameters. However, it doesn't explicitly state when to use this tool versus alternatives like 'elements_list' (which might list multiple elements) or 'snapshot' (which might capture broader state), nor does it provide exclusions or prerequisites.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully describes the 'force' parameter's purpose (skipping actionability checks for overlays), which adds context beyond the schema. However, it doesn't cover other important behaviors like error handling, what happens on failure, or interaction with the UI state, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences, front-loading the core purpose and efficiently covering key parameter usage. Every word earns its place with no redundancy or fluff, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a UI interaction tool with 7 parameters, no annotations, and no output schema, the description is somewhat incomplete. It covers the basic action and a key parameter nuance, but doesn't address potential side effects, error conditions, or what constitutes successful execution. Given the complexity and lack of structured data, more behavioral context would be helpful.
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 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by briefly mentioning 'selector' and 'ref' alternatives and the 'force' parameter's use case, but doesn't provide additional semantic context beyond what's in the schema. This meets the baseline for high schema coverage.
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 the action ('Click an element') and specifies the target resource ('element'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from similar sibling tools like 'press' or 'hover' that also interact with elements, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage guidance by mentioning when to use 'force: true' ('when an overlay is in the way'), but it doesn't explicitly state when to choose this tool over alternatives like 'press' for keyboard interactions or 'hover' for mouse hovering. No clear exclusions or sibling comparisons are provided.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by specifying 'Fast check' (implying low latency), 'Does not wait' (clarifying non-blocking behavior), and that it returns 'the count' (output detail). However, it doesn't cover aspects like error handling, performance limits, or what 'matches' entails (e.g., partial vs. exact), leaving gaps for a tool with potential UI interactions.
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 highly concise and well-structured: three short sentences that efficiently convey purpose, parameters, and a key behavioral trait ('Does not wait'). Every sentence adds value without redundancy, making it easy to parse and front-loaded with essential information.
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?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is partially complete. It covers the core purpose and a behavioral trait but lacks details on output format (beyond 'count'), error cases, or integration with siblings like 'snapshot' for 'ref'. For a UI testing tool, this leaves room for improvement in guiding effective 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 adds some meaning beyond the input schema: it explains that parameters are alternatives ('Pass `selector` or `ref`'), which isn't clear from the schema alone. However, with 50% schema description coverage (only 'ref' has a description), it doesn't fully compensate for the undocumented 'selector' parameter. The baseline is 3 since the schema provides partial coverage, and the description offers limited additional context.
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 the tool's purpose: 'Fast check for whether any element matches, plus the count.' It specifies the verb ('check'), resource ('element'), and outcome ('matches, plus the count'). However, it doesn't explicitly differentiate from siblings like 'check', 'wait_for_selector', or 'elements_list', which might offer similar functionality.
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 provides some implied usage guidance: 'Pass `selector` or `ref`' indicates parameter options, and 'Does not wait' suggests it's for immediate checks rather than waiting for conditions. However, it lacks explicit when-to-use vs. alternatives (e.g., compared to 'wait_for_selector' for delayed checks or 'elements_list' for listing elements), and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Pause') but lacks details on execution (e.g., blocking vs. non-blocking, error handling, or performance implications like CPU usage during the wait). This leaves gaps in understanding how the tool behaves beyond the basic pause function.
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 and front-loaded, consisting of just two sentences that directly convey the tool's function and usage advice. Every word earns its place, with no redundant or unnecessary information, making it efficient for quick comprehension.
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?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and offers usage guidance, but misses behavioral details (e.g., what happens during the pause) and parameter specifics, leaving the agent with some uncertainty in more complex scenarios.
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 0% description coverage, with one parameter 'ms' of type 'number'. The description adds minimal semantics by implying 'ms' represents milliseconds for the pause duration, but doesn't specify units, valid ranges, or formatting (e.g., integer vs. float). This provides some context but doesn't fully compensate for the schema's lack of details.
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 the tool's purpose with a specific verb ('Pause') and resource ('for N milliseconds'), making it immediately understandable. However, it doesn't explicitly differentiate from its sibling 'wait_for' or 'wait_for_selector' beyond suggesting preference, leaving some ambiguity about when this exact tool is uniquely appropriate.
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 by explicitly naming alternatives ('wait_for_selector or wait_for') and advising to 'prefer' them when possible. This helps the agent understand when to consider other tools, though it doesn't specify exact scenarios where this tool is the only or best choice, such as for fixed delays or low-level timing needs.
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?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it reads text content (not attributes), operates on the first matching element (not all), and 'Does not wait' (implying immediate execution without delays). However, it misses details like error handling (e.g., if no element matches), permissions needed, or output format, leaving gaps for a tool with potential 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 highly concise and front-loaded, with two sentences that directly address purpose and key usage notes. Every word earns its place, avoiding redundancy or fluff, making it efficient for quick comprehension by an AI agent.
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?
Given 3 parameters, no annotations, and no output schema, the description is minimally adequate. It covers the core action and parameter usage but lacks details on return values, error cases, or integration with siblings like snapshot (which provides refs). For a tool in a rich UI automation context, more context on output and failures would improve completeness.
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?
Schema description coverage is 67% (2 of 3 parameters have descriptions). The description adds value by clarifying that 'selector' or 'ref' are alternative inputs for element identification, which isn't explicit in the schema. It also implies 'trim' defaults to true via context, though not directly stated. This compensates well for the partial schema coverage.
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 the action ('Read the text content') and target ('first matching element'), distinguishing it from siblings like get_attribute or get_value. However, it doesn't explicitly differentiate from tools like elements_list or snapshot that also involve element interaction, leaving some ambiguity about its unique scope.
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 implies usage by specifying 'Pass selector or ref' and 'Does not wait', suggesting when to use parameters and a behavioral constraint. However, it lacks explicit guidance on when to choose this tool over alternatives like get_attribute (for non-text attributes) or wait_for_selector (for waiting), and doesn't mention prerequisites or exclusions.
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?
With no annotations provided, the description carries the full burden. It discloses that hovering can skip actionability checks with 'force: true' when overlays intercept, which is useful behavioral context. However, it lacks details on error handling, what happens if the element isn't found, or performance 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?
The description is front-loaded with the core action, followed by parameter guidance in two efficient sentences. Every word serves a purpose, with no wasted text, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is adequate but incomplete. It covers key parameter usage but lacks details on return values, error conditions, or integration with sibling tools, leaving gaps in contextual understanding.
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?
Schema description coverage is 75%, so the description adds value by explaining the purpose of 'selector' and 'ref' as alternatives, and clarifying 'force' for overlays. It doesn't cover 'timeoutMs', but compensates well for the partial schema coverage with practical usage insights.
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 the action ('hover the mouse over an element') and resource ('an element'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'click' or 'drag' beyond the hover action itself, which is why it doesn't reach a 5.
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 implies usage by mentioning 'when an overlay intercepts' for the force parameter, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'click' or 'wait_for_selector'. No exclusions or clear alternatives are stated.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the tool captures data (non-destructive read operation) and mentions the default behavior for 'interestingOnly' (matches Playwright default), but does not cover other aspects like performance implications, error handling, or output structure 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 efficiently structured in two sentences: the first states the core purpose and use cases, and the second provides a key parameter tip. Every sentence adds value without redundancy, making it easy to parse and front-loaded with essential information.
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?
Given the tool's moderate complexity (accessibility data capture), no annotations, and no output schema, the description is adequate but incomplete. It covers the purpose and basic usage but lacks details on output format, error conditions, or integration with other tools, leaving gaps for an AI agent to infer behavior.
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 100%, so the schema already fully documents both parameters. The description adds minimal value by mentioning 'interestingOnly: false' as an option to include every node, but does not provide additional semantic context beyond what the schema descriptions state.
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 specific action ('capture the accessibility tree') and resource ('current page'), with a precise output format ('as JSON'). It distinguishes this tool from siblings like 'screenshot' or 'snapshot' by focusing on accessibility data rather than visual or DOM snapshots.
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 ('useful for testing screen-reader behaviour, finding elements by role, or auditing for missing ARIA labels'), which helps differentiate it from other tools. However, it does not explicitly state when not to use it or name specific alternatives among siblings.
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?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: supports async/await, requires a function body with return, and exposes an arg variable. However, it misses details like error handling, execution time limits, or security implications, which are important for a JavaScript evaluation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: it starts with the core purpose, provides usage instructions, includes an example, and notes key features (async/await support, contract similarity). Every sentence adds value without redundancy, making it easy to parse.
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?
Given the tool's complexity (evaluating JavaScript in a renderer context) and no annotations or output schema, the description is moderately complete. It covers the basic operation and parameters but lacks details on return values, error cases, or performance considerations, which could be crucial for safe and effective 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?
Schema description coverage is 100%, so the schema already documents both parameters (js and arg) thoroughly. The description adds some semantic context by explaining that js is a 'FUNCTION BODY' and arg is 'JSON-serializable' and exposed as a local variable, but this mostly reinforces the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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: 'Evaluate JavaScript in the renderer (page) context.' It specifies the verb ('evaluate'), resource ('JavaScript'), and context ('renderer (page) context'), distinguishing it from sibling tools like eval_main by explicitly mentioning the execution context.
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 usage context by stating 'Pass a FUNCTION BODY — use `return` to yield a value' and 'Same contract as eval_main,' which implies when to use it (for renderer context evaluation) and references an alternative (eval_main). However, it lacks explicit exclusions or detailed comparisons with other siblings like check or wait_for.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that it 'Returns the absolute path' and allows filename control, which adds useful context about output and input behavior. However, it does not cover potential side effects, error conditions, or performance implications, leaving gaps in behavioral understanding.
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 highly concise and front-loaded, with two sentences that efficiently convey the tool's purpose, output, and key parameter usage. Every sentence earns its place without redundancy or unnecessary details.
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?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic functionality and output but lacks details on error handling, file storage location, or interaction with sibling tools. For a tool with no annotations, it should provide more behavioral context to be 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?
Schema description coverage is 100%, so the schema already documents both parameters ('name' and 'fullPage'). The description adds marginal value by explaining that 'name' controls the filename without extension, but does not provide additional semantics beyond what the schema offers. Baseline 3 is appropriate as the schema handles most of the parameter documentation.
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 specific action ('Capture a full-page PNG') and resource ('current window'), distinguishing it from sibling tools like 'snapshot' or 'accessibility_snapshot' by specifying the output format and scope. It explicitly mentions what the tool does without being vague or tautological.
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 implies usage for capturing full-page screenshots in PNG format, but does not explicitly state when to use this tool versus alternatives like 'snapshot' or other sibling tools. It provides clear context for its purpose but lacks explicit exclusions or named alternatives.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the safety aspect ('Safe to call even if the element is already visible'), which is useful, but lacks details on potential side effects, error handling, or performance implications. It does not contradict annotations, but could be more comprehensive for a tool with mutation-like 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 front-loaded with the core purpose in the first sentence and adds a helpful safety note in the second. Both sentences earn their place by providing essential information without redundancy, making it efficient and well-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?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is adequate but has gaps. It covers the basic purpose and safety, but lacks details on parameter usage, return values, or error conditions. It meets minimum viability but could be more complete for effective 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?
Schema description coverage is 50% (only 'timeoutMs' has a description), and the description does not add meaning beyond the schema. It mentions 'selector' but does not explain its format or usage, and 'timeoutMs' is only documented in the schema. With low coverage, the description fails to compensate, resulting in minimal added value over 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 specific action ('Scroll the first element matching a selector into view') and resource ('first element matching a selector'), distinguishing it from siblings like 'scroll' (general scrolling) or 'wait_for_selector' (waiting). It precisely defines the tool's function with a verb+resource combination.
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 usage ('if needed') and a safety note ('Safe to call even if the element is already visible'), which helps in decision-making. However, it does not explicitly mention when to use this tool over alternatives like 'scroll' or 'wait_for_selector', nor does it specify exclusions, leaving some guidance implicit.
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?
With no annotations provided, the description carries the full burden. It discloses that the tool returns recent messages from a buffer, includes specific sources (renderer and main-process), and mentions that 'clear: true' drains the buffer—important behavioral traits. However, it doesn't cover rate limits, permissions, or response format 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 front-loaded with the core purpose in the first sentence, followed by a concise note on the 'clear' parameter. Both sentences are essential—no wasted words—making it efficient and easy to parse for an AI agent.
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 no annotations and no output schema, the description adequately covers the tool's purpose and key behavior (buffer draining). However, it lacks details on return format (e.g., structure of log entries) and doesn't address potential complexities like pagination or error handling, leaving some gaps for a tool with 4 parameters.
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 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning the 'clear' parameter's effect ('drain the buffer after reading'), but doesn't provide additional context beyond what's in the schema, such as typical use cases for filters.
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 'return' and the resource 'recent console messages', specifying they are captured since app start and include both renderer console and main-process stdout/stderr. It distinguishes this tool from siblings like 'screenshot' or 'wait' by focusing on log retrieval rather than UI interaction or timing.
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 implies usage for accessing console logs, but provides no explicit guidance on when to use this tool versus alternatives like 'eval_main' or 'eval_renderer' for direct execution, or 'info' for general information. It mentions the 'clear' parameter functionality but doesn't specify scenarios where clearing is appropriate versus not.
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?
With no annotations provided, the description carries full burden. It discloses the return structure ({ exists, styles }) and that it reads from 'the first element matching a selector', which clarifies scope. However, it doesn't mention error handling, performance implications, or what happens if the selector matches multiple elements beyond the first.
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 sentences with zero waste: the first states purpose and return format, the second provides concrete examples. It's front-loaded with key information and appropriately sized for the tool's complexity.
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 2-parameter tool with no annotations and no output schema, the description is mostly complete: it explains purpose, parameters, and return structure. However, it lacks details on error cases (e.g., invalid selector) and doesn't fully document the 'exists' field in the return object.
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?
Schema description coverage is 50% (only 'properties' has a description). The description adds value by explaining 'selector' targets the first matching element and providing example properties ('background-color', 'font-family', 'display'), which clarifies usage beyond the schema's minimal parameter documentation.
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 ('Read'), resource ('computed CSS property values'), and target ('from the first element matching a selector'). It distinguishes from siblings like get_attribute (reads HTML attributes) or get_text (reads text content) by specifying CSS property retrieval.
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 implies usage for reading CSS values from DOM elements, but doesn't explicitly state when to use this vs. alternatives like get_attribute (for HTML attributes) or when not to use it (e.g., for non-CSS data). No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the no-op behavior (useful context) and implies mutation (checking), but does not cover permissions, error handling, or response format. It adds some behavioral insight but leaves gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and includes essential behavioral detail (no-op). Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is minimal but functional. It covers the basic action and a key behavioral trait (no-op), but lacks details on errors, side effects, or return values, leaving room for improvement given the complexity.
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?
Schema description coverage is 67% (2 of 3 parameters described). The description does not mention parameters directly, but it implies the 'selector' parameter's purpose. It adds no syntax details beyond the schema, but with moderate coverage and implied mapping, it compensates 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 the action ('Check a checkbox or radio button') and the target ('matching a selector'), distinguishing it from siblings like 'uncheck' (opposite action) and 'click' (general interaction). It also specifies the no-op behavior for already-checked elements, adding precision.
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 implies usage for checkboxes/radio buttons via selectors, with no-op guidance for already-checked states, but does not explicitly mention when to use alternatives like 'click' for non-checkable elements or 'uncheck' for toggling off. It provides clear context but lacks explicit exclusions.
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?
No annotations are provided, so the description carries the full burden. It discloses the destructive behavior ('Delete all screenshots'), which is critical for a mutation tool. However, it lacks details on permissions needed, whether deletions are reversible, error handling, or confirmation prompts. The description adds value but doesn't fully cover behavioral traits for a destructive operation.
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 sentences, front-loaded with the core action and followed by usage context. Every word earns its place with no redundancy or fluff, making it highly efficient and easy to parse for an AI agent.
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?
Given the tool's complexity (destructive operation with no parameters) and lack of annotations/output schema, the description is minimally adequate. It covers the purpose and basic usage but lacks details on behavioral implications (e.g., irreversible deletion, scope limitations). For a destructive tool, more context would improve completeness, but it meets the minimum viable threshold.
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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the absence of inputs. The description adds no parameter information, which is appropriate here. A baseline of 4 is applied for zero-parameter tools, as no additional semantics are needed beyond what the schema provides.
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 specific action ('Delete all screenshots') and target resource ('from the current session directory'), distinguishing it from sibling tools like 'screenshot' (which creates screenshots) and 'snapshot' (which likely captures snapshots). The purpose is unambiguous and well-defined.
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 the tool ('Useful between test phases to keep storage tidy'), indicating it's for maintenance during testing workflows. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings (e.g., whether 'clear_input' or other cleanup tools exist), which prevents a perfect score.
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?
With no annotations provided, the description carries full burden. It clearly describes what data is retrieved (window title, URL, viewport size from window.innerWidth/innerHeight, uptime, devicePixelRatio) and implies this is a read-only operation. However, it doesn't specify format of return values or potential limitations.
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?
Single sentence efficiently lists all retrieved data points with zero wasted words. The description is appropriately sized for a no-parameter tool that returns multiple metrics.
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?
For a no-parameter tool with no annotations and no output schema, the description adequately explains what data is retrieved. However, it doesn't specify the format/structure of return values or provide any error handling context, which would be helpful given the lack of output schema.
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 tool has 0 parameters with 100% schema coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on what the tool returns.
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 specific verb 'Get' and lists the exact resources retrieved: current window title, URL, viewport size, uptime, and devicePixelRatio. It clearly distinguishes from sibling tools by focusing on window/system information rather than interaction or element 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 implies usage for retrieving window/system metrics, but doesn't explicitly state when to use this tool versus alternatives like 'windows_list' or 'snapshot'. No guidance on prerequisites or exclusions is provided.
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?
With no annotations provided, the description carries the full burden. It discloses the core behavior (selecting dropdown options) and parameter requirements ('At least one must be provided'), but doesn't mention error handling, what happens if multiple options match, or whether the selection triggers page changes. It adds some context but lacks comprehensive 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 perfectly concise with two sentences that each earn their place: the first states the purpose, the second explains parameter usage. It's front-loaded with the core functionality and wastes no words on unnecessary details.
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?
For a 5-parameter tool with no annotations and no output schema, the description provides adequate basic information but lacks details about return values, error conditions, or the relationship between parameters. It covers the 'what' but not the 'what happens after' or edge cases, making it minimally 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?
With only 20% schema description coverage (only timeoutMs has a description), the description compensates well by explaining the semantics of three key parameters (value, label, index) and their relationship ('At least one must be provided'). However, it doesn't explain the 'selector' parameter which is required, leaving a gap in parameter understanding.
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 specific action ('Select an option') and resource ('in a <select> dropdown'), distinguishing it from sibling tools like 'click' or 'press' by specifying it's for dropdown selection. It precisely identifies the target UI element type.
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 about when to use this tool (for dropdown selection) but doesn't explicitly mention when not to use it or name specific alternatives among the many sibling tools. It implies usage for <select> elements but doesn't exclude other selection scenarios.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the action ('Uncheck a checkbox'), conditional behavior ('No-op if already unchecked'), and implies mutation (unchecking changes state). However, it doesn't cover error handling (e.g., if selector doesn't match), performance aspects, or side effects, leaving gaps for a mutation tool with zero annotation coverage.
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 concise sentences with zero waste: the first states the core action and target, and the second adds critical behavioral context. It's front-loaded with the main purpose and efficiently covers key information without redundancy or fluff.
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?
Given no annotations, no output schema, and 3 parameters with partial schema coverage, the description is adequate but has clear gaps. It covers the basic action and conditional behavior but lacks details on error cases, return values, or advanced usage (e.g., interaction with 'force' parameter). For a mutation tool in this context, it meets minimum viability but isn't fully 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?
Schema description coverage is 67% (2 of 3 parameters have descriptions: 'timeoutMs' and 'force'), with 'selector' lacking a description. The description adds value by explaining that 'selector' matches a checkbox and that the action is conditional ('No-op if already unchecked'), which compensates partially for the schema gap. However, it doesn't detail selector syntax or format, so it doesn't fully compensate for the 33% coverage gap.
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 specific action ('Uncheck a checkbox') and target ('matching a selector'), distinguishing it from sibling tools like 'check' (which would check a checkbox) and 'clear_input' (which clears text inputs). It also specifies the conditional behavior ('No-op if already unchecked'), making the purpose explicit and differentiated.
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 implies usage for unchecking checkboxes, with 'No-op if already unchecked' suggesting it's safe to call repeatedly. However, it doesn't explicitly state when to use this vs. alternatives like 'check' or 'clear_input', nor does it mention prerequisites (e.g., the checkbox must exist). This provides clear context but lacks explicit exclusions or named 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it auto-accepts or dismisses dialogs, handles different dialog types (alert/confirm/prompt/beforeunload), and includes auto-uninstall logic. However, it lacks details on error handling or permissions needed.
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 the main purpose and efficiently details parameters and behavior in two sentences. Every sentence adds value without redundancy, making it easy to understand quickly.
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 (handling multiple dialog types) and no annotations or output schema, the description is mostly complete. It covers the tool's function, parameters, and key behaviors, but could improve by mentioning potential side effects or integration with sibling 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 100%, so the schema already documents all parameters. The description adds some context by explaining the purpose of 'action' and 'text' in relation to dialogs, but it does not provide significant additional meaning beyond what the schema offers, such as examples or edge cases.
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 with specific verbs ('Install an auto-responder') and resources ('JavaScript dialogs'), distinguishing it from sibling tools that focus on UI interaction, accessibility, or evaluation. It precisely defines what the tool does without restating the name.
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 on when to use this tool ('for JavaScript dialogs') and mentions auto-uninstall behavior, but it does not explicitly state when not to use it or name alternatives among sibling tools like 'wait_for' or 'press' that might handle different dialog scenarios.
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?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it types into the 'currently focused element' (implying no element selection) and uses 'keyboard events' (suggesting simulated typing). However, it lacks details on error handling, performance implications, or what happens if no element is focused, leaving gaps in 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 highly concise and front-loaded: it states the tool's function, differentiation from sibling, and compatibility reason in two efficient sentences with zero wasted words, making it easy to parse quickly.
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 (2 parameters, no output schema, no annotations), the description is mostly complete: it covers purpose, usage, and key behavior. However, it lacks details on return values or error cases, which would be helpful since no output schema exists, leaving minor 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?
Schema description coverage is 50% (only 'delayMs' has a description). The description adds no parameter-specific semantics beyond implying 'text' is the string to type. It doesn't explain parameter interactions or constraints, so it provides minimal value over the schema, aligning with the baseline for moderate 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 tool's purpose: 'Types a literal string into the currently focused element as keyboard events.' It specifies the verb ('types'), resource ('currently focused element'), and mechanism ('keyboard events'), and explicitly distinguishes it from its sibling 'keyboard_type' by noting it's 'an alias... with no focus selector.'
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 usage guidance: it states this tool is 'kept for backwards compatibility' and is 'an alias for keyboard_type with no focus selector,' indicating when to use it (for compatibility) and how it differs from the alternative (lacks focus selector). This clearly defines its context relative to siblings.
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?
No annotations are provided, so the description carries the full burden. It describes the scrolling behavior (absolute vs. delta scrolling) and the selector logic, but doesn't mention potential side effects (e.g., page layout changes, event triggers), error conditions, or performance implications. It adds some context but lacks comprehensive behavioral disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and front-loaded: two sentences that directly address purpose, parameters, and sibling differentiation with zero wasted words. Every sentence earns its place by providing critical guidance 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 moderate complexity (scrolling with multiple parameter options), no annotations, and no output schema, the description does well by covering purpose, parameter logic, and sibling differentiation. However, it lacks details on return values or error handling, which would be helpful for a mutation tool without structured output documentation.
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 100%, so the schema already documents all 5 parameters thoroughly. The description adds minimal value by mentioning the selector logic and the x/y vs. dx/dy distinction, but doesn't provide additional syntax, format, or constraint details beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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 with specific verbs ('scroll an element or the window') and distinguishes it from a sibling tool ('use scroll_into_view instead if you just want to make an element visible'). It explicitly mentions the resource (element or window) and the action (scroll to absolute position or delta).
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: it specifies to use scroll_into_view instead for making an element visible, and clarifies the conditions for scrolling an element vs. the window (based on selector presence). This directly addresses sibling differentiation and usage context.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the polling mechanism, timeout, and poll interval behavior, which is helpful. However, it lacks details on error handling, what happens if the predicate never returns truthy, or performance implications of frequent polling, leaving some behavioral aspects unclear.
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: two sentences that efficiently explain the tool's purpose and provide a practical example. Every sentence adds value without redundancy, making it easy to understand quickly.
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 (polling with JavaScript) and no output schema, the description is mostly complete: it covers the main functionality and parameters. However, it could improve by mentioning return values or error cases, as there's no output schema to fill those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the 'js' parameter as a 'function body' with an example, clarifying its semantics beyond the schema's basic description. It also implies the purpose of polling and timeout parameters, though not explicitly detailing them.
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: 'Poll a JavaScript predicate in the renderer until it returns truthy, then return its value.' It specifies the verb ('poll'), resource ('JavaScript predicate'), and scope ('in the renderer'), distinguishing it from sibling tools like 'wait' or 'wait_for_selector' by focusing on custom JavaScript evaluation rather than element waiting.
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 usage: it's for polling a JavaScript predicate until truthy, with an example illustrating when to use it (e.g., checking for DOM elements). However, it does not explicitly state when not to use it or name alternatives like 'wait_for_selector' for simpler element-based waiting, leaving some room for improvement.
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?
With no annotations provided, the description carries full burden and discloses important behavioral traits: it wipes the screenshots directory on fresh start, detects single-instance-lock failure mode, and gives helpful hints. It doesn't cover all potential behaviors like error handling or performance characteristics, but provides substantial operational 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?
Four sentences with zero waste - each adds value: establishes purpose, prerequisite usage, parameter guidance, and behavioral details. Could be slightly more front-loaded by moving the 'Must be called before' clause earlier, 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 complex initialization tool with 7 parameters, no annotations, and no output schema, the description provides good context about prerequisites, behavioral side-effects, and failure modes. It doesn't explain return values or what constitutes successful launch, but covers most critical operational aspects.
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 100%, so the schema already documents all 7 parameters thoroughly. The description mentions the 'main' parameter requirement and screenshotsDir behavior, but doesn't add significant semantic value beyond what's in the schema. Baseline 3 is appropriate when schema does heavy lifting.
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 specific action ('Launch an Electron app via Playwright') and resource ('Electron app'), distinguishing it from sibling tools like 'stop_app' or 'accessibility_snapshot'. It specifies this is an initialization tool that must be called before other driving tools, establishing its unique role.
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 'Must be called before any other driving tool', providing clear when-to-use guidance. It also distinguishes from alternatives by mentioning this is for starting the app, unlike 'stop_app' or other interaction tools in the sibling list, though it doesn't name specific 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the tool's behavior: using trusted browser events via Playwright, generating PointerEvents, measuring movement delta with 'detectSelector', automatic fallback to React fiber-prop access if primary strategy fails, and including a 'strategy' field in results. It also notes coordinate units (CSS pixels) and the ability to disable fallback. This covers critical aspects like mutation effects, reliability mechanisms, and output details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose but becomes dense with technical details about fallback strategies and React handlers. While informative, some sentences could be more streamlined (e.g., the explanation of fallback and result fields is verbose). It efficiently covers key points but could benefit from clearer structuring to separate primary functionality from edge-case handling.
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 (5 parameters, nested objects, no output schema, no annotations), the description is largely complete. It explains the drag mechanism, parameter purposes, behavioral traits, and result details like 'strategy' field. However, it lacks explicit information on error handling, performance implications (e.g., rate limits), or prerequisites (e.g., browser state), which would enhance completeness for a low-level input simulation 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?
Schema description coverage is 60%, and the description adds significant meaning beyond the schema. It explains the purpose of 'detectSelector' (to measure element movement and handle clamps) and 'fiberFallback' (to invoke React handlers directly if primary drag fails), which are only briefly described in the schema. However, it does not elaborate on 'from' and 'to' coordinates or 'steps' beyond what the schema implies, leaving some parameter semantics reliant on 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 explicitly states the tool's purpose: 'Drag from one point to another using real Chromium input events.' It specifies the mechanism (Playwright's CDP mouse pipeline) and distinguishes it from simpler click tools by emphasizing trusted browser events that generate PointerEvents for React/native listeners, CSS states, and pointer consumers. This clearly differentiates it from sibling tools like 'click' or 'hover'.
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: for drag operations that need to simulate real user input events, especially to trigger PointerEvents and CSS states. It mentions using 'detectSelector' to verify movement and handle clamps, and a fallback strategy for React handlers. However, it does not explicitly state when to choose this over alternatives like manual mouse events or other drag methods, nor does it list specific sibling tools as 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?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it simulates drag/drop events, works with web APIs like FileReader, and has limitations regarding file.path and legacy systems. It doesn't mention error handling or performance aspects, but covers essential operational 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 the core purpose in the first sentence, followed by specific usage contexts and limitations. Every sentence earns its place by providing critical information without redundancy, making it efficient 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?
Given the tool's complexity (simulating drag/drop with file contents), no annotations, and no output schema, the description is mostly complete. It explains what the tool does, when to use it, and key limitations, but could benefit from mentioning potential side effects or error scenarios to be fully comprehensive.
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 100%, so the schema fully documents the three parameters. The description adds no additional parameter semantics beyond what's in the schema, such as examples or edge cases, meeting the baseline score of 3 for 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 specific action ('Simulate dropping a file onto a target element') and resource ('file contents'), distinguishing it from siblings like 'set_input_files' or 'drag' by specifying it's for drag/drop events with DataTransfer. It explicitly mentions the web API context and limitations.
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 ('Works for apps that read File via web APIs') and when not to use it ('Does NOT populate file.path — apps that rely on webUtils.getPathForFile() or legacy file.path must use eval_main'), naming an alternative tool ('eval_main') for specific cases.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so effectively. It reveals key traits: the tool returns basic info (tag, text snippet, id, etc.), has a default cap of 50 elements, and includes default attributes like 'aria-label' and 'role'. This covers output format, limits, and defaults, though it lacks details on error handling or performance 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?
The description is appropriately sized and front-loaded, with the core purpose stated first ('Enumerate elements matching a selector'), followed by return details and usage examples. Every sentence earns its place by adding value, such as the cap note and practical examples, without redundancy or 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 moderate complexity (3 parameters, no output schema, no annotations), the description is mostly complete. It covers purpose, behavior, and usage context well, but lacks details on output structure (e.g., format of returned info) and error cases, which would enhance completeness for a tool with no output schema.
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 schema description coverage is 67% (2 out of 3 parameters have descriptions), and the description adds meaningful context beyond the schema. It explains that 'selector' is for matching elements and implies 'limit' controls the cap mentioned, while the schema details defaults. However, it does not fully compensate for the lack of schema description on 'selector', leaving its exact syntax or examples unspecified.
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 with specific verbs ('enumerate elements matching a selector') and resources ('returning basic info about each'), distinguishing it from siblings like 'get_attribute' or 'get_text' by emphasizing bulk retrieval of multiple elements. It provides concrete examples ('what buttons are on this screen', 'give me all list items') that clarify its use case beyond just listing elements.
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 offers clear context for when to use this tool ('Great for "what buttons are on this screen" or "give me all list items"'), which implicitly suggests it's for exploratory or bulk queries rather than targeted single-element operations. However, it does not explicitly state when not to use it or name specific alternatives among the many sibling tools, such as 'get_attribute' for detailed single-element info.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains the tool's behavior: it returns detailed element information when something is focused, and returns { focused: false } when nothing meaningful has focus (document.body). This covers the key behavioral trait of handling the no-focus case.
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 perfectly concise and front-loaded: the first sentence states the core purpose and what's returned, and the second sentence explains the edge case behavior. Every sentence earns its place 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?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is quite complete. It explains what the tool does, what information it returns, and how it handles the no-focus case. The only minor gap is not explicitly mentioning the format of the bounding box or text snippet details.
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 tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on the tool's behavior and output.
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 with a specific verb ('Return') and resource ('currently focused element'), listing the exact information returned (tag, id, classes, text snippet, bounding box). It distinguishes from siblings like 'get_bbox' or 'get_text' by focusing specifically on the focused element rather than any element.
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: to get information about the currently focused element. It implicitly distinguishes from siblings by not mentioning alternatives, but the specificity of 'currently focused' naturally sets it apart from tools like 'get_bbox' or 'elements_list' that work on other elements.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the snapshot is based on the 'accessibility-tree,' it generates 'numbered refs' for interactive elements, and these refs are reusable across tools like click and type. However, it lacks details on potential limitations (e.g., performance impact, page state changes) or error handling, which prevents a perfect score.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by key benefits and usage instructions. Every sentence adds value, such as explaining ref usage and when to call the tool, with no redundant information. It efficiently conveys necessary details without verbosity.
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 (interaction with web pages) and lack of annotations or output schema, the description is largely complete. It explains what the tool does, how to use it, and its integration with sibling tools. However, it does not detail the output format (e.g., structure of the text representation) or error cases, which could be helpful for an agent, slightly 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 has 100% description coverage, with the single parameter 'selector' documented as 'Optional root selector. If given, only snapshot that subtree.' The description does not add any meaningful semantics beyond this, as it focuses on the tool's overall function rather than parameter details. According to the rules, with high schema coverage, the baseline is 3 when no extra param info 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's purpose: 'Return a structured text representation of the visible page with numbered refs.' It specifies the verb ('Return'), resource ('structured text representation'), and distinguishes from siblings by explaining that refs can be used with other tools like click and type instead of selectors. The mention of 'accessibility-tree-based representation similar to Playwright MCP's browser_snapshot' further clarifies its nature.
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 usage guidance: 'Call this FIRST before interacting with a page to see what is on screen.' It distinguishes from alternatives by noting that refs eliminate 'selector-guessing round-trips' and implies when not to use it (e.g., after initial snapshot, use other tools with refs). This directly addresses when to use this tool versus others in the sibling list.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior ('close cleanly') and safety characteristic ('safe to call even if no app is running'), which are crucial for understanding its operation. It doesn't cover potential side effects or error handling, but provides sufficient core 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 short sentences that are front-loaded with the primary purpose and follow with an important usage note. Every word earns its place with no redundancy or unnecessary elaboration.
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 (0 parameters, no output schema, no annotations), the description provides adequate context for understanding what the tool does and when to use it. It could potentially mention what 'cleanly' entails or confirm no return value, but for this complexity level, it's reasonably 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 input schema has 0 parameters with 100% coverage, so the baseline is 4. The description doesn't need to explain parameters, and it doesn't introduce any parameter-related confusion, maintaining the appropriate 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?
The description clearly states the specific action ('Close the running Electron app cleanly') and resource ('Electron app'), distinguishing it from siblings like 'start_app' which would initiate the app. It provides precise verb+resource pairing with no ambiguity.
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 'Safe to call even if no app is running,' which provides clear context on when it's appropriate to use this tool. However, it doesn't mention alternatives or explicitly differentiate from other shutdown-related tools (none are listed in siblings), so it falls short of a perfect 5.
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?
With no annotations provided, the description carries the full burden and does well by disclosing key behaviors: it returns element count and bounding box of the first match (avoiding follow-up eval), honors a timeout with default value, and supports multiple states. It covers mutation aspects (waiting for changes) and output behavior, though it could mention error handling or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by key behavioral details and parameter defaults in two efficient sentences. Every sentence adds critical information without redundancy, making it appropriately sized and well-structured for quick understanding.
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 3 parameters, no annotations, and no output schema, the description does a good job covering purpose, behavior, and parameter context. However, it could be more complete by explicitly detailing the return format (e.g., structure of bounding box) or error cases, leaving minor gaps in full contextual understanding.
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?
Schema description coverage is 67% (2 of 3 parameters have descriptions). The description adds value by explaining the 'state' parameter's purpose ('reaches a given state: attached/detached/visible/hidden') and clarifying 'timeoutMs' default, which compensates for the lack of schema description on 'selector'. It provides meaningful context beyond the schema's basic definitions.
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 ('wait until') and resource ('an element matching a selector appears'), specifying the exact action. It distinguishes from siblings like 'wait' and 'wait_for' by focusing on selector-based waiting with state conditions, making the purpose specific and differentiated.
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 implies usage for waiting on selector-based element states, but does not explicitly state when to use this vs. alternatives like 'wait' or 'wait_for'. It provides clear context for selector-based scenarios but lacks explicit exclusions or named alternatives, limiting full 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?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it lists windows with specific attributes, mentions the return format, and notes the edge case for single-window apps. It does not cover potential errors, performance, or side effects, but for a read-only tool with zero parameters, this is sufficient.
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 the core purpose in the first sentence and adds a helpful clarification in the second. Every sentence earns its place by providing essential information without redundancy, making it efficient and well-structured for quick understanding.
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 low complexity (0 parameters, no annotations, no output schema), the description is complete enough for a read-only listing operation. It explains what the tool does and what information is returned, covering the basics. However, without an output schema, it could benefit from more detail on the return structure or error handling, but this is minor.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, focusing instead on the tool's purpose and output. This meets the baseline for zero parameters, but a perfect score is reserved for cases where the description compensates for schema gaps, which isn't applicable here.
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 specific action ('List every BrowserWindow') and resource ('the app has open'), including what information is returned ('title, URL, id, and whether it is focused/minimized/maximized'). It also distinguishes from siblings by specifying this is about listing windows, unlike other tools that handle interactions, navigation, or app control.
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 on when to use it—to list open browser windows with their details—and includes a note about single-window apps returning one entry, which helps set expectations. However, it does not explicitly state when not to use it or name alternatives among the many sibling tools, such as 'switch_window' or 'start_app/stop_app' for window management.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool executes JavaScript in the main process, supports async/await, exposes 'electron' and 'arg' as locals, and requires a function body with a return statement. However, it lacks details on error handling, security implications, or performance impacts.
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 appropriately sized and front-loaded, with every sentence earning its place. It starts with the core purpose, details usage, and ends with practical examples, avoiding redundancy. The structure is efficient and easy to parse.
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?
Given the complexity of executing JavaScript in the main process, no annotations, and no output schema, the description is somewhat complete but has gaps. It covers purpose, usage, and parameters well, but lacks information on return values, error handling, or security considerations, which are critical for such a powerful 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?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema: it clarifies that 'js' is a 'FUNCTION BODY' (not just any string), emphasizes using 'return' to yield a value, and explains how 'electron' and 'arg' are used as locals. This enhances understanding but doesn't fully compensate for the lack of output schema details.
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 with specific verbs ('Evaluate JavaScript in the Electron main process') and distinguishes it from sibling tools like 'eval_renderer' by specifying the execution context. It identifies the resource (Electron main process) and the action (evaluating JavaScript).
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 versus alternatives: 'Use this to invoke IPC handlers, read paths, or drive windows the renderer cannot reach.' It distinguishes from 'eval_renderer' by targeting the main process for tasks inaccessible to the renderer, offering 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by explaining the low-level event dispatch mechanism, target compatibility, and optional focus behavior. It doesn't mention error handling, performance implications, or what happens if focusSelector fails, but provides substantial behavioral context beyond basic functionality.
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 sentences with zero waste - first establishes purpose and differentiation from sibling, second explains optional parameter behavior. Every phrase adds value: 'literal string', 'real keyboard events', 'per-character keydown/keypress/keyup events', specific target examples, and focus behavior.
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 4-parameter tool with no annotations and no output schema, the description provides excellent context about when to use it vs alternatives and behavioral characteristics. It could be more complete by mentioning what the tool returns (success/failure indication) or error scenarios, but given the sibling context and clear differentiation, it's quite comprehensive.
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?
Schema description coverage is 75% (3 of 4 parameters have descriptions), so baseline would be 3. The description adds value by explaining the 'focusSelector' parameter's purpose ('Optionally focus a selector first') and default behavior ('If omitted, types into whatever is currently focused'), which complements the schema's technical description. However, it doesn't add meaning for 'text' or 'delayMs' 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 action ('Type a literal string as real keyboard events') and distinguishes it from sibling 'type' by explaining the difference in implementation ('dispatches per-character keydown/keypress/keyup events' vs 'uses fill'). It also specifies the target contexts where it works best ('CodeMirror, contenteditables, editors, and anything that listens to keydown').
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 contrasts with sibling 'type' tool ('Unlike `type` (which uses fill)'), provides clear when-to-use guidance ('works with CodeMirror, contenteditables, editors, and anything that listens to keydown'), and mentions optional focus behavior. This gives the agent clear alternatives and context for 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: setting files without triggering the native file picker, requiring absolute file paths, and being designed for Electron testing. It doesn't mention error handling, permissions needed, or what happens if files don't exist, but covers the core behavioral traits well given the lack of 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 perfectly concise with three sentences that each earn their place: first states the core functionality, second provides critical context about Electron testing and comparison to alternatives, third gives parameter guidance. No wasted words, front-loaded with essential 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?
For a 3-parameter tool with no annotations and no output schema, the description provides good contextual completeness. It covers the tool's purpose, when to use it, behavioral characteristics, and parameter guidance. The main gap is lack of information about return values or error conditions, but given the testing context and parameter clarity, it's reasonably 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?
Schema description coverage is 67% (2 of 3 parameters have descriptions). The description adds valuable context beyond the schema: it clarifies that 'files' should be 'one or more absolute file paths' (reinforcing the schema's description) and implies the tool works on file input elements (context for 'selector'). While it doesn't detail 'timeoutMs' or 'selector' specifics, it compensates adequately for the partial 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 specific action ('Set files on an <input type="file">') and resource (file input element), distinguishing it from sibling tools like 'drop_file' by emphasizing it's the 'CORRECT way to test file upload UI in Electron' and 'more reliable than drop_file'. This provides 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('the CORRECT way to test file upload UI in Electron') and when not to use alternatives ('much more reliable than drop_file'). It provides clear context for usage in Electron testing scenarios with file uploads.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the core behavior ('REPLACING existing content') and implementation detail ('Uses Playwright's `fill`'), which gives important context about how the operation works. However, it doesn't mention error conditions, performance characteristics, or what happens with invalid selectors, leaving some behavioral aspects uncovered.
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 perfectly concise and well-structured: three sentences that each earn their place. The first states the core purpose, the second explains parameter alternatives, and the third provides crucial usage guidance. No wasted words, and the most important information (the replacement behavior) is 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?
For a 4-parameter mutation tool with no annotations and no output schema, the description does well but has minor gaps. It covers the core behavior, parameter relationships, and sibling differentiation effectively. However, it doesn't mention what the tool returns (success/failure indicators) or error handling, which would be helpful given the lack of output schema. The completeness is good but not perfect for this context.
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?
With 50% schema description coverage (only `ref` and `timeoutMs` have descriptions), the description adds significant value by explaining the relationship between `selector` and `ref` as alternatives ('Pass `selector` or `ref`'). This clarifies parameter semantics beyond what the schema provides. However, it doesn't explain the `text` parameter's purpose or format, which is a missed opportunity given it's the only required 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 tool's purpose with specific verbs ('Fill a text input, REPLACING existing content') and distinguishes it from sibling tools by explicitly naming an alternative ('use `keyboard_type` instead'). It identifies the exact resource (text input) and the replacement behavior, making it immediately distinguishable from similar tools like `clear_input` or `keyboard_type`.
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 versus alternatives: it specifies 'For keyboard-level typing (CodeMirror, contenteditables), use `keyboard_type` instead.' This clearly defines the exclusion case and names the alternative tool, helping the agent choose correctly between sibling tools in the Playwright automation 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?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it focuses the target window and routes future calls to it, implying state change and persistence. However, it doesn't mention error handling (e.g., if no window matches) or performance aspects, leaving some gaps.
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 the purpose, followed by parameter guidance and behavioral effects in two concise sentences. Every part adds value without redundancy, 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 moderate complexity (state-changing with 2 parameters), no annotations, and no output schema, the description is mostly complete. It covers purpose, usage, parameters, and effects, but lacks details on errors or edge cases, which could be helpful for robust agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 compensate. It adds crucial meaning: 'index' is from windows_list, and 'titleMatch' is a substring of the window title. This clarifies how to use the parameters effectively, going beyond the bare schema types.
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 ('Make... the current one') and resource ('BrowserWindow'), specifying that it changes which window subsequent tools will target. It distinguishes from siblings like 'windows_list' (which lists windows) and 'click' (which performs actions within the current window).
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?
It explicitly states when to use this tool: to switch the current window for driving subsequent actions. It provides alternatives by specifying two parameter options ('index' from windows_list or 'titleMatch'), guiding the agent on how to select the target window. This is clear and actionable.
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:

[![electron-driver MCP server](https://glama.ai/mcp/servers/mesomya/electron-driver/badges/card.svg)](https://glama.ai/mcp/servers/mesomya/electron-driver)

Score Badge

Copy to your README.md:

[![electron-driver MCP server](https://glama.ai/mcp/servers/mesomya/electron-driver/badges/score.svg)](https://glama.ai/mcp/servers/mesomya/electron-driver)

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/mesomya/electron-driver'

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