AdsPower LocalAPI MCP Server
OfficialServer Quality Checklist
Latest release: v1.0.0
- Disambiguation4/5
Most tools have distinct purposes, such as create-browser vs. open-browser, but some overlap exists, like get-browser-list and get-opened-browser, which could cause confusion. The descriptions help clarify, but the boundaries between these list tools are not perfectly clear.
Naming Consistency5/5All tool names follow a consistent verb-noun pattern with hyphens, such as create-browser, get-browser-list, and navigate. There are no deviations in style or convention, making the naming highly predictable and readable throughout the set.
Tool Count3/5With 27 tools, the count is borderline high for a browser automation server, as it may feel heavy and complex for agents to navigate. However, given the domain's scope covering browser management, groups, and page interactions, it is not extreme but could benefit from consolidation.
Completeness5/5The tool set provides comprehensive coverage for browser automation, including CRUD operations for browsers and groups, navigation, element interactions, and page content retrieval. There are no obvious gaps, and the surface supports full lifecycle management and interaction workflows.
Average 2.4/5 across 27 of 27 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 3 community issues answered or closed in the last 6 months
- 18 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.jsonto 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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers none. It doesn't mention whether this is a read or write operation, what visual feedback occurs, whether it requires specific browser states, potential side effects, or error conditions. The description provides no behavioral context beyond the basic action name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three words, this is under-specification rather than effective conciseness. The description doesn't front-load important information and fails to use its limited space to provide any meaningful guidance. Every word should earn its place, but this description provides almost no value beyond the tool name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given 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 completely inadequate. It doesn't explain what 'drag' means in this context, what visual or state changes occur, whether this simulates user interaction or programmatically moves elements, or what happens if selectors are invalid. The description fails to provide the minimal context needed 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/5Does 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 no additional meaning about what 'selector' and 'targetSelector' represent beyond what's in the schema descriptions. This meets the baseline of 3 when the schema does the heavy lifting, but the description doesn't compensate with any extra context about selector syntax or drag behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Drag the element' is a tautology that essentially restates the tool name 'drag-element' without adding meaningful context. While it does specify the action (drag), it doesn't clarify what resource is being manipulated or distinguish this tool from sibling tools like 'hover-element' or 'click-element' beyond the basic verb difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. There are no indications about prerequisites (e.g., needing an open browser), appropriate contexts, or comparisons to similar sibling tools like 'hover-element' or 'click-element' that might be used for different interaction types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides none. It doesn't indicate whether this is a read or write operation, what side effects might occur, what permissions are needed, or what the evaluation context is. For a tool that likely executes code in a browser environment, this lack of behavioral information is critically inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three words, this is under-specification rather than effective conciseness. The description fails to provide essential information that would help an agent understand and use the tool correctly. Every sentence should earn its place, but this description doesn't provide enough substance to justify even its minimal length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of script evaluation (potentially executing arbitrary code in a browser context), no annotations, no output schema, and sibling tools suggesting browser automation, this description is completely inadequate. It doesn't explain what gets evaluated, in what context, what the return values might be, or any safety considerations. The description fails to provide the contextual completeness needed for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'script' well-documented in the schema. The description adds no additional parameter information beyond what the schema already provides. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Evaluate the script' is a tautology that essentially restates the tool name. It doesn't specify what kind of script (JavaScript, browser automation, etc.), what context it runs in, or what 'evaluate' means in practical terms. While sibling tools suggest a browser automation context, the description itself provides no specific verb+resource combination or differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or relationships with sibling tools like 'execute-script' (if such existed) or other browser automation tools. The agent receives no usage direction from this description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Hover the element' gives no information about what the tool actually does behaviorally—does it simulate a mouse hover event, trigger hover CSS effects, wait for hover state changes, or something else? It also doesn't mention side effects, error conditions, or what happens if the selector doesn't exist. This is inadequate for a tool that presumably interacts with browser elements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise at three words, it's under-specified rather than efficiently informative. It fails to provide necessary context that would help an AI agent understand and use the tool correctly. Conciseness should not come at the expense of essential information, making this score low despite the brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of browser interaction tools and the absence of both annotations and an output schema, the description is completely inadequate. It doesn't explain what the tool does, when to use it, what behavior to expect, or what results it produces. For a tool that likely simulates user interactions in a browser environment, this minimal description leaves critical gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'selector' parameter fully documented in the schema itself. The description adds no additional parameter semantics beyond what's in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Hover the element' is essentially a tautology that restates the tool name 'hover-element' with minimal additional meaning. While it does specify the action (hover) and target (element), it lacks specificity about what 'hover' means in this context (e.g., mouse hover simulation) and doesn't distinguish it from sibling tools like 'click-element' or 'drag-element' beyond the basic verb difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open browser page), appropriate contexts (e.g., for UI testing or interaction simulation), or when not to use it (e.g., for non-interactive elements). With many sibling tools available for browser interaction, this lack of differentiation is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to do so. It does not explain what 'open' means operationally (e.g., whether it launches a process, requires authentication, has side effects like resource consumption, or involves rate limits). The phrase 'both environment and profile mean browser' is confusing and adds no clarity, making the tool's behavior opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, poorly structured sentence that is both under-specified and confusing ('both environment and profile mean browser'). It wastes space on unclear phrasing rather than conveying useful information, failing to be appropriately concise or front-loaded with actionable details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a browser automation tool with 6 parameters and no annotations or output schema, the description is severely incomplete. It does not cover what the tool does operationally, when to use it, behavioral traits, or expected outcomes, leaving critical gaps for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 6 parameters (e.g., serialNumber, userId, ipTab). The description adds no additional meaning or context beyond what the schema provides, such as explaining how parameters interact or their practical implications. However, since the schema is comprehensive, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Open the browser, both environment and profile mean browser' is tautological—it essentially restates the tool name 'open-browser' without specifying what 'open' entails (e.g., launching a browser instance, connecting to an existing one, or initializing a session). It fails to distinguish this tool from siblings like 'create-browser' or 'connect-browser-with-ws', leaving the purpose vague and unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing an existing browser profile), exclusions, or comparisons to sibling tools like 'create-browser' (for new instances) or 'connect-browser-with-ws' (for WebSocket connections), leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Select the option' vaguely implies a UI interaction but doesn't specify whether this is a read-only or mutating operation, what happens after selection (e.g., form submission, page change), error conditions, or performance characteristics. This is inadequate for a tool that likely modifies UI state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with only three words, the description is under-specified rather than efficiently informative. It fails to front-load critical information about the tool's purpose and context, wasting its minimal content on a tautological restatement of the name rather than earning its place with useful details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, plus the presence of many sibling UI interaction tools, this description is severely incomplete. It doesn't explain what 'selecting an option' entails behaviorally, what the tool returns, how it differs from similar tools, or what context it operates in (browser automation based on sibling tools). This leaves too many gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both 'selector' and 'value' parameters. The description adds no additional semantic context beyond what's in the schema (e.g., examples of selectors, format of values, or how they interact). This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Select the option' is a tautology that merely restates the tool name 'select-option' without adding meaningful context. It doesn't specify what type of option (e.g., dropdown, radio button, checkbox) or in what context (e.g., web page, application UI), nor does it distinguish this tool from sibling tools like 'click-element' or 'fill-input' that might perform similar UI interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open browser), context (e.g., interacting with form elements), or exclusions (e.g., not for clicking buttons). With sibling tools like 'click-element' and 'fill-input' available, this lack of differentiation leaves the agent guessing about appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Update the browser' implies a mutation operation but reveals nothing about permissions required, whether updates are partial or complete, what happens to unspecified fields, error conditions, or side effects. For a complex 13-parameter mutation tool, this complete lack of behavioral context is severely inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of just three words - 'Update the browser' - making it extremely concise. There's no wasted language or unnecessary elaboration. While the content is inadequate, the form is maximally efficient with every word serving the core message (however limited that message may be).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters including nested objects), lack of annotations, and absence of an output schema, the description is completely inadequate. It fails to explain what 'updating a browser' means in this context, what the operation affects, what permissions are needed, or what the expected outcome is. The description provides essentially no useful context for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 13 parameters thoroughly with descriptions, examples, and constraints. The description adds zero parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update the browser' is a tautology that merely restates the tool name 'update-browser'. It provides no specific information about what aspects of a browser are updated, what resources are involved, or how this differs from sibling tools like 'create-browser' or 'update-group'. This minimal description fails to communicate the tool's actual function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing a browser ID), when this tool is appropriate versus creating a new browser, or how it relates to sibling tools like 'update-group'. The agent receives zero contextual usage information from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Press the key' implies a mutation action but offers no details on effects, permissions, or side effects (e.g., whether it triggers page navigation or requires focus). This is inadequate for a tool that likely interacts with browser elements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly concise to the point of under-specification. 'Press the key' is a single phrase that fails to provide necessary context or structure, making it inefficient rather than appropriately brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'pressing a key' entails in this context (e.g., browser automation), what happens after execution, or how it differs from similar tools, leaving significant gaps for an agent to understand its use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters ('key' and 'selector'). The description adds no additional meaning beyond the schema, but the schema itself is well-documented, justifying a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Press the key' is a tautology that restates the tool name without adding meaningful context. It specifies the action (press) but doesn't clarify what resource or context this applies to (e.g., a browser element), making it vague compared to more specific sibling tools like 'click-element' or 'fill-input'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention context, prerequisites, or exclusions, leaving the agent to guess its application relative to siblings like 'click-element' or 'fill-input' in browser automation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails entirely. It doesn't indicate that this is a mutation operation, what permissions are required, whether it's idempotent, what happens on success/failure, or any side effects. The agent has no behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two words, this is under-specification rather than effective brevity. The description fails to provide any meaningful information that would help an agent understand or use the tool, making it inefficient despite its short length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with 12 parameters, nested objects, no annotations, and no output schema, the description is completely inadequate. It provides no behavioral context, no usage guidance, and relies entirely on the schema for parameter documentation, leaving critical gaps in understanding how to properly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 12 parameters with detailed descriptions and examples. The description adds no parameter information beyond what's in the schema, meeting the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a browser' is a tautology that restates the tool name without specifying what kind of browser is being created or its purpose. It doesn't distinguish this from sibling tools like 'open-browser' or 'update-browser', leaving the agent to infer details from the parameter schema alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'open-browser' or 'update-browser'. The description lacks context about prerequisites, such as needing a group ID from 'get-group-list', or when this creation tool is appropriate over other browser-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden but fails to disclose behavioral traits. It doesn't mention whether this requires an active browser session, what happens on errors (e.g., if selector is invalid), or any side effects like page changes. This leaves critical operational context unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loading the core action. However, it is under-specified rather than efficiently informative, as it lacks necessary details that would earn its place, slightly reducing its effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain the tool's role in browser automation (implied by sibling tools) or what 'fill' entails (e.g., typing, setting value), leaving gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema (e.g., 'selector' as from page source code, 'text' as content to fill). The tool description adds no additional meaning beyond the schema, so it meets the baseline of 3 without compensating or detracting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fill the input' is a tautology that restates the tool name without adding meaningful context. It specifies the verb 'fill' and resource 'input' but lacks specificity about what kind of input (e.g., web page form field) or how it operates, making it vague compared to more descriptive alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'select-option' or 'press-key' for similar input interactions. The description offers no context, prerequisites, or exclusions, leaving the agent without direction for appropriate tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Scroll the element' fails to disclose critical traits: it doesn't specify if this simulates user scrolling (implied by the schema but not stated), what happens if the element isn't scrollable, whether it requires a browser session, or any side effects like page reloads. The description is minimal and lacks behavioral context, making it inadequate for a tool with potential interaction effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, which is front-loaded and wastes no space. However, this conciseness comes at the cost of under-specification—it's too brief to be helpful. While efficient, it lacks necessary detail, but since every sentence (in this case, the phrase) technically 'earns its place' by stating the action, it avoids redundancy and is structurally sound.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a browser interaction tool with no annotations and no output schema, the description is incomplete. It doesn't explain what scrolling entails (e.g., smooth vs. instant, direction), expected outcomes, error conditions, or how it integrates with sibling tools like 'get-page-html'. For a tool that likely involves user simulation and page manipulation, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'selector' parameter well-documented in the schema itself. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't clarify selector syntax, scrolling behavior, or examples). According to the rules, with high schema coverage (>80%), the baseline score is 3, as the description doesn't need to compensate but also doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Scroll the element' is a tautology that essentially restates the tool name without adding meaningful specificity. While it indicates the action (scroll) and target (element), it doesn't distinguish this tool from sibling tools like 'hover-element' or 'drag-element' in terms of what scrolling accomplishes (e.g., bringing content into view, simulating user interaction). The purpose is vague and lacks 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention context such as scrolling to view hidden content, interacting with dynamic pages, or prerequisites like needing an element selector. With sibling tools like 'navigate' or 'hover-element', there's no explicit or implied distinction for usage scenarios, leaving the agent without clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Click the element' implies a mutation action (interacting with a UI), but it doesn't describe effects (e.g., page navigation, form submission), error handling, or requirements (e.g., element must be visible). This is inadequate 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with 'Click the element', a single sentence that directly states the action. It's front-loaded with no wasted words, making it efficient and easy to parse, though this conciseness contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a UI interaction tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects, return values, or context needed for effective use. Sibling tools suggest a browser automation context, but this isn't explained, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 100% description coverage, detailing 'selector' as 'The selector of the element to click, find from the page source code'. The description adds no additional meaning beyond this, but with high schema coverage, the baseline is 3 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.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Click the element' states a clear verb ('click') and resource ('the element'), but it's vague about what type of element or context. It doesn't distinguish from sibling tools like 'iframe-click-element' or 'hover-element', which perform similar actions on elements. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open browser or page), exclusions, or comparisons to siblings like 'iframe-click-element' for iframes or 'hover-element' for hovering. Usage is implied but not explicitly 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't explain what 'connect' means—whether it establishes a new session, reconnects an existing one, requires authentication, has side effects, or what happens on failure. This leaves critical operational traits undefined for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function. It's front-loaded with the core action and includes a helpful note about parameter sourcing, though it could be slightly more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a browser connection tool with no annotations and no output schema, the description is insufficient. It doesn't cover what the tool returns, error conditions, or how it integrates with sibling tools, leaving the agent with incomplete context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 minimal value by referencing the wsUrl source from 'open-browser', which provides some context but doesn't elaborate on parameter interactions or usage beyond what's in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as connecting a browser with a WebSocket URL, which is a clear action but lacks specificity about what 'connect' entails operationally. It doesn't distinguish itself from sibling tools like 'open-browser' or 'get-opened-browser', leaving ambiguity about its unique role in the browser management workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions getting the wsUrl from 'open-browser', implying a sequence, but doesn't clarify if this is a prerequisite or alternative to other tools like 'create-browser' or 'update-browser', leaving the agent to infer usage context.
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 full burden for behavioral disclosure. 'Delete the browser' implies a destructive mutation, but it doesn't specify permanence, side effects, permissions required, or error handling. This is inadequate for a tool with clear destructive potential.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Delete the browser') with zero wasted words, making it front-loaded and easy to parse. However, this brevity comes at the cost of completeness for a destructive operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'delete' entails operationally, what happens to associated resources, or what the return value might be, leaving critical gaps for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'userIds' clearly documented as required user IDs for deletion. The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete the browser' states a clear verb ('Delete') and resource ('the browser'), but it's vague about scope and lacks differentiation from siblings like 'close-browser' or 'update-browser'. It doesn't specify whether this deletes browser instances, configurations, or user data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'close-browser' or 'update-browser'. The description doesn't mention prerequisites, exclusions, or contextual factors for choosing this deletion operation.
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 full burden. It only states the action ('Get') without disclosing behavioral traits like whether it's read-only, requires authentication, has rate limits, returns paginated results, or what format the list is in. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Get the list of applications') with no wasted words. It's appropriately sized for a simple tool, though it could be more front-loaded with key details. It earns a 4 for conciseness but loses a point for not structuring essential info upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't cover what the tool returns, behavioral aspects, or usage context, leaving gaps for an AI agent. For a tool with minimal structured data, more descriptive detail is needed to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 100% description coverage ('size' as 'The size of the page'), so the schema does the heavy lifting. The description adds no meaning beyond this, as it doesn't explain parameter usage or context. Baseline 3 is appropriate when schema coverage is high and description adds no extra param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the list of applications' clearly states the verb ('Get') and resource ('list of applications'), but it's vague about scope (e.g., all applications vs. filtered) and doesn't differentiate from sibling tools like 'get-browser-list' or 'get-group-list' that also retrieve lists. It provides basic purpose but lacks specificity for 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention context, prerequisites, or exclusions, such as whether it's for all applications or requires specific conditions. With sibling tools like 'get-browser-list' available, this omission leaves 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?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose whether closing is reversible, if it requires specific permissions, what happens to open pages or data, or any side effects like session termination. This leaves critical behavioral traits unaddressed 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Close the browser' is extremely concise—three words that directly convey the core action. It's front-loaded with no unnecessary elaboration, making it efficient for quick understanding without wasting space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 one parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'close' means in practice, potential outcomes, or error conditions, leaving gaps that could hinder correct agent invocation in a browser management context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'userId' documented as 'The browser id of the browser to stop, it is required when you want to stop the browser'. The description adds no parameter semantics beyond this, as it doesn't mention parameters at all. Baseline score of 3 is appropriate since the schema fully covers the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Close the browser' clearly states the action (close) and resource (browser), but it's vague about scope—it doesn't specify whether this closes a specific browser instance or all browsers. It distinguishes from siblings like 'delete-browser' (which likely removes it permanently) and 'open-browser', but lacks precision on what 'close' entails operationally.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't clarify if this should be used after completing tasks versus 'delete-browser' for cleanup, or if it's for stopping a specific browser session. The description alone offers no context for selection among sibling tools like 'get-browser-list' or 'update-browser'.
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 full burden but lacks behavioral details. It doesn't disclose that this is a read-only operation (implied by 'get'), pagination behavior (beyond schema hints), rate limits, authentication needs, or what the return format looks like (no output schema). The description adds no meaningful context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a simple tool and front-loaded with the core action, though it lacks depth due to under-specification rather than verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, pagination, filtering), no annotations, and no output schema, the description is incomplete. It fails to explain key behaviors like pagination mechanics, filtering logic, or return structure, leaving significant gaps for an AI agent to infer usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 7 parameters. The description adds no parameter semantics beyond what's in the schema (e.g., it doesn't explain relationships like 'groupId' filtering or 'size/page' pagination). 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.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the list of browsers' states the basic action (get) and resource (browsers), but it's vague about scope and functionality. It doesn't specify whether this retrieves all browsers, filtered browsers, or paginated results, nor does it differentiate from sibling tools like 'get-opened-browser' or 'get-application-list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a group ID from 'get-group-list'), exclusions, or contextual cues for selection among sibling tools like 'get-opened-browser' or 'get-application-list'.
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 clicking but doesn't disclose behavioral traits like whether it waits for the element to be clickable, handles errors, requires specific page states, or has side effects (e.g., page navigation). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what happens after clicking (e.g., return values, success/failure states) or address potential issues like iframe loading. For a tool that interacts with web elements, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 ('selector' and 'iframeSelector') with descriptions. The description adds no additional meaning beyond implying these selectors are used for clicking, which is redundant. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('click') and target ('element in the iframe'), which is clear but vague. It doesn't specify what type of element or distinguish it from sibling tools like 'click-element' (which presumably clicks elements outside iframes). The purpose is understandable but lacks specificity about the tool's 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open browser or iframe context) or compare it to 'click-element', which is a direct sibling tool. The description implies usage only for iframe elements but doesn't explicitly state when to choose this over other clicking methods.
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, the description carries the full burden of behavioral disclosure. It implies a navigation action but doesn't specify if it requires an existing browser, what happens on failure (e.g., invalid URL), or any side effects like page loading. This leaves significant gaps in understanding the tool's 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, direct sentence that front-loads the core action. There is no wasted verbiage, making it efficient and easy to parse, though this conciseness contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of browser navigation tools, lack of annotations, and no output schema, the description is incomplete. It fails to address key aspects like prerequisites, error handling, or return values, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'url' parameter clearly documented. The description adds no additional meaning beyond what the schema provides, such as URL format examples or constraints, so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Navigate to the url' states the action (navigate) and target (url), but is vague about the context (e.g., browser navigation) and doesn't distinguish it from sibling tools like 'open-browser' or 'open-new-page'. It provides a basic purpose but lacks specificity and 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'open-browser' or 'open-new-page', nor does it mention prerequisites like needing an active browser session. The description offers no context for usage decisions.
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 full burden for behavioral disclosure. While 'Create' implies a write/mutation operation, the description doesn't specify permissions required, whether the operation is idempotent, what happens on duplicate group names, or what the response looks like (e.g., success confirmation or group ID). This is a significant gap for a creation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple creation tool, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a write operation with no output schema) and lack of annotations, the description is insufficiently complete. It doesn't explain what 'browser group' means in this context, what the creation entails, or what to expect upon success/failure. For a mutation tool with no structured output information, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('groupName' and 'remark') clearly documented in the schema. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting but doesn't compensate with extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a browser group' clearly states the action (create) and resource (browser group), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'update-group' or 'get-group-list', which would require mentioning it's specifically for initial creation rather than modification or retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'update-group' or 'get-group-list'. It doesn't mention prerequisites (e.g., whether a browser must be connected first) or exclusions, leaving the agent to infer usage context from the tool name alone.
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. 'Get the list of groups' implies a read-only operation, but it doesn't mention pagination behavior (implied by parameters), rate limits, authentication needs, or what the return format looks like. The description is too minimal to adequately inform the agent about how this tool behaves beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose, though it could benefit from additional context to improve other dimensions without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 is incomplete for a tool with three parameters and pagination behavior. It doesn't explain what the output looks like (e.g., list structure, fields), how errors are handled, or usage nuances, leaving significant gaps for the agent to navigate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 (groupName, size, page) with details on usage, defaults, and constraints. The description adds no parameter semantics beyond what's in the schema, meeting the baseline for high coverage but not enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the list of groups' clearly states the verb ('Get') and resource ('list of groups'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get-application-list' or 'get-browser-list' beyond the resource type, nor does it specify if this retrieves all groups or filtered results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'create-group' or 'update-group' for related operations, nor does it specify prerequisites or contexts for usage, leaving the agent to infer based on the name alone.
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 a mutation action ('Move') but doesn't clarify permissions needed, whether the operation is reversible, what happens to browsers in transit (e.g., if they're active), error conditions, or side effects. This is a significant gap for a tool that modifies state without any structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It front-loads the core action and resource, making it immediately understandable. No extraneous details or repetition are present, which is ideal for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is insufficient. It lacks critical context: no information on return values, error handling, prerequisites, or behavioral traits. For a tool that moves resources between groups, this leaves the agent with significant gaps in understanding how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for both parameters (groupId and userIds). The description adds no additional semantic context beyond what the schema provides, such as explaining what 'browser ids' represent or constraints on group selection. Baseline 3 is appropriate since the schema adequately covers parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move') and resource ('browsers to a group'), making the purpose understandable. It distinguishes from siblings like 'create-group' or 'update-group' by focusing on relocation rather than creation/modification. However, it doesn't specify what 'browsers' refer to (e.g., browser instances/sessions) or the system context, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., browsers must exist, group must exist), exclusions (e.g., cannot move to non-existent groups), or related tools like 'get-group-list' for obtaining group IDs. The description alone offers no usage context beyond the basic action.
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. 'Open a new page' implies a creation/mutation action, but it doesn't disclose behavioral traits such as whether this requires an existing browser context, what happens if no browser is open, or if it returns a page identifier. For a tool with zero annotation coverage, this leaves critical operational details unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loading the core action. Every word earns its place by specifying the verb and object without any fluff or redundant information. It's appropriately sized for a simple tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent complexity (likely interacting with a browser to open pages) and lack of annotations or output schema, the description is incomplete. It doesn't explain prerequisites (e.g., needing an open browser), return values, or error conditions. For a tool in a browser automation context with many siblings, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it correctly doesn't mention any. A baseline of 4 is appropriate since no parameter information is required, and the description doesn't mislead about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Open a new page' clearly states the action (open) and resource (new page), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'navigate' or 'open-browser', leaving ambiguity about whether this opens a new tab/window or navigates within an existing page. It's not tautological but remains somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With siblings like 'navigate' (for changing URLs) and 'open-browser' (for launching browsers), it's unclear if this tool is for opening new tabs, windows, or something else. No explicit when/when-not or alternative recommendations are included.
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 full burden. It states the action ('Get the screenshot') but lacks behavioral details like whether it captures the current viewport or requires specific permissions, what happens if no page is open, or if there are rate limits. This is inadequate for a tool with potential side effects like file saving.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it easy to parse and front-loaded. It directly conveys the core action without unnecessary elaboration, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (involving browser interaction and file operations), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, error conditions, or return values, leaving significant gaps for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 two parameters ('savePath' and 'isFullPage'). The description adds no additional meaning beyond implying screenshot capture, resulting in a baseline score of 3 as it doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the screenshot of the page' clearly states the verb ('Get') and resource ('screenshot of the page'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-page-html' or 'get-page-visible-text', which also retrieve page content but in different formats, so it misses full 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like needing visual capture versus text/HTML extraction, or prerequisites such as requiring an open browser page, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Update' implies mutation, but it doesn't specify what happens to existing data not mentioned (like other group properties), whether changes are reversible, permission requirements, or error conditions. This is inadequate 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded with the core action, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 insufficient. It doesn't explain what the tool returns, error handling, side effects, or how it interacts with other tools (like get-group-list for obtaining groupId). The 100% schema coverage helps, but doesn't compensate for missing behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 three parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline of 3 when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'browser group', making the purpose understandable. It distinguishes from siblings like 'create-group' (creation) and 'get-group-list' (read), but doesn't explicitly differentiate from 'update-browser' which updates a browser rather than a group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a group ID from get-group-list), when not to use it, or how it differs from similar tools like update-browser.
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 full burden for behavioral disclosure. While 'Get' implies a read operation, it doesn't specify whether this returns only currently active browsers, includes browser metadata, shows real-time status, or has any performance considerations. The description is minimal and lacks important 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what format the browser list returns, what information each browser entry contains, whether the list is filtered or comprehensive, or how this differs from similar sibling tools. The minimal description leaves too many questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema coverage, so the schema fully documents the input requirements. The description doesn't need to add parameter information, and it appropriately doesn't mention any parameters. This meets the baseline expectation for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('list of opened browsers'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling 'get-browser-list' - both appear to retrieve browser information, creating potential confusion about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'get-browser-list' or 'get-application-list'. There's no mention of prerequisites, timing considerations, or what distinguishes this from similar sibling tools.
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 full burden but offers minimal behavioral insight. It implies a read operation but doesn't disclose whether this requires specific page states (e.g., loaded page), authentication, rate limits, or what happens with errors. The description is too vague for a mutation-free 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 is minimally adequate but lacks completeness. It doesn't address behavioral aspects like what 'page' refers to (current page? specified page?), potential errors, or output format details, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline of 4 reflects that the description doesn't need to compensate for any parameter gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('html content of the page'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get-page-visible-text' or 'screenshot' that also retrieve page content in different formats, preventing 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requiring an open browser/page), exclusions, or comparisons to siblings like 'get-page-visible-text' for text-only retrieval or 'screenshot' for visual capture.
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 full burden but only states what the tool does, not how it behaves. It doesn't disclose whether this is a read-only operation, if it requires specific page states, potential latency, or error conditions. For a tool with zero annotation coverage, this leaves significant behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose with zero wasted words. It's appropriately sized for a simple tool and earns its place by clearly conveying the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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), the description is minimally adequate but lacks depth. It doesn't explain what 'visible text' entails (e.g., excludes hidden elements) or the return format, leaving the agent to infer behavior. With no annotations, it should provide more context for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 fully documents the lack of inputs. The description doesn't need to add parameter details, and it appropriately avoids mentioning any. Baseline for 0 parameters is 4, as it doesn't mislead about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('visible text content of the page'), making the purpose immediately understandable. It distinguishes from siblings like 'get-page-html' by specifying 'visible text' rather than HTML markup. However, it doesn't explicitly contrast with all siblings, keeping it at a 4 rather than 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/5Does 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 like 'get-page-html' or 'evaluate-script'. It lacks context about prerequisites (e.g., needing an open browser page) or exclusions, offering minimal usage direction beyond the basic purpose.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/AdsPower/adspower-browser'
If you have feedback or need assistance with the MCP directory API, please join our Discord server