adspower-browserスキルを使用すると、AIがMCPサーバーなしでCLI経由でAdsPowerを操作できるようになります。エディタに以下のように追加してください：
環境 | 追加方法 |
Cursor |
|
Claude Code |
|
GPT / Codex | add-skillがサポートされている場合: |
AdsPowerブラウザのLocalAPIを操作するためのModel Context Protocolサーバーです。このサーバーにより、LLMはv2 APIを使用してAdsPowerブラウザプロファイルと対話でき、プロファイルの作成、更新、削除、グループ管理、ブラウザ操作の自動化が可能になります。
LLMに話しかけてブラウザを作成: Create an Android UA browser using Chrome 134
LLMに話しかけてブラウザを作成: Help me with random UA, random fingerprint, random cookie generation, create 3 browsers, use 134 cores, and open them
Nodeバージョン18以上
一部のAPIはAdsPowerクライアントのバージョンアップに伴い段階的に導入されます。
特定のAPIを含むバージョンにクライアントがアップグレードされていない場合、リクエストが Not found を返すことがあります。
その場合は以下を行ってください：
まずAdsPowerクライアントを最新のパッチバージョンにアップグレードしてください。
その後、同じコマンド/APIを再試行してください。
Claude Desktopで使用するには、サーバー設定を追加します：
macOSの場合: ~/Library/Application Support/Claude/claude_desktop_config.json Windowsの場合: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"adspower-local-api": {
"command": "npx",
"args": ["-y", "local-api-mcp-typescript"]
}
}
}{
"mcpServers": {
"adspower-local-api": {
"command": "cmd",
"args": ["/c", "npx", "-y", "local-api-mcp-typescript"]
}
}
}MCPサーバーは、コマンドライン引数または環境変数による設定をサポートしています。
ポートパラメータはAdsPower Local APIのポートを指定します。デフォルトは 50325 です。
優先順位:
コマンドライン引数 --port (最高優先度)
環境変数 PORT (中優先度)
デフォルト値 50325 (最低優先度)
例:
コマンドライン引数を使用する場合:
{
"mcpServers": {
"adspower-local-api": {
"command": "npx",
"args": ["-y", "local-api-mcp-typescript", "--port", "50325"]
}
}
}環境変数を使用する場合:
{
"mcpServers": {
"adspower-local-api": {
"command": "npx",
"args": ["-y", "local-api-mcp-typescript"],
"env": {
"PORT": "50325"
}
}
}
}APIキーはAdsPower APIの認証に使用されます。リクエストの Authorization: Bearer <api-key> ヘッダーとして送信されます。
優先順位:
コマンドライン引数 --api-key (最高優先度)
環境変数 API_KEY (中優先度)
デフォルト値なし (指定がない場合、リクエストにAPIキーヘッダーは含まれません)
例:
コマンドライン引数を使用する場合:
{
"mcpServers": {
"adspower-local-api": {
"command": "npx",
"args": ["-y", "local-api-mcp-typescript", "--api-key", "your-api-key-here"]
}
}
}環境変数を使用する場合:
{
"mcpServers": {
"adspower-local-api": {
"command": "npx",
"args": ["-y", "local-api-mcp-typescript"],
"env": {
"API_KEY": "your-api-key-here"
}
}
}
}両方のパラメータを同時に使用できます。コマンドライン引数は環境変数を上書きします：
{
"mcpServers": {
"adspower-local-api": {
"command": "npx",
"args": ["-y", "local-api-mcp-typescript", "--port", "50326", "--api-key", "new-key"],
"env": {
"PORT": "50325",
"API_KEY": "old-key"
}
}
}
}この例では、サーバーは port: 50326 および apiKey: new-key を使用します（コマンドライン引数が環境変数を上書きするため）。
またはCursorで使用
Related MCP server: Puppeteer MCP Server
# clone
git clone https://github.com/AdsPower/adspower-browser.git
cd adspower-browser
# install (monorepo)
pnpm install
# build all packages
pnpm run buildローカルでのMCP開発については、Claude DesktopでMCPパッケージを指定してください：
"mcpServers": {
"adspower-local-api": {
"command": "node",
"args": ["<Replace Your Project Path>/adspower-browser/packages/local-api-mcp/build/index.js"]
}
}Click the element
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | The selector of the element to click, find from the page source code |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Close the browser
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | The browser id of the browser to stop, it is required when you want to stop the browser |
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation action with 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.
Does 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.
Does 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.
Does 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.
Connect the browser with the ws url
| Name | Required | Description | Default |
|---|---|---|---|
| userId | No | The browser id of the browser to connect | |
| serialNumber | No | The serial number of the browser to connect | |
| wsUrl | Yes | The ws url of the browser, get from the open-browser tool content `ws.puppeteer` |
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.
Is 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.
Given 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the three parameters. The description adds 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It 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.
Create a browser
| Name | Required | Description | Default |
|---|---|---|---|
| domainName | No | The domain name of the browser, eg: facebook.com | |
| openUrls | No | The open urls of the browser, eg: ["https://www.google.com"] | |
| cookie | No | The cookie of the browser, eg: "[{"domain":".baidu.com","expirationDate":"","name":"","path":"/","sameSite":"unspecified","secure":true,"value":"","id":1}]" | |
| username | No | The username of the browser, eg: "user" | |
| password | No | The password of the browser, eg: "password" | |
| groupId | Yes | The group id of the browser, must be a numeric string (e.g., "123"). You can use the get-group-list tool to get the group list or create a new group, or default is 0 | |
| name | No | The name of the browser, eg: "My Browser" | |
| country | No | The country of the browser, eg: "CN" | |
| sysAppCateId | No | The sys app cate id of the browser, you can use the get-application-list tool to get the application list | |
| userProxyConfig | Yes | The user proxy config of the browser | |
| fingerprintConfig | No | The fingerprint config of the browser, default is automatic_timezone: 0, timezone: "", language: [], flash: "", fonts: [], webrtc: disabled, browser_kernel_config: ua_auto, random_ua: ua_version: [], ua_system_version: [], tls_switch: 0, tls: "" | |
| storageStrategy | No | The storage strategy of the browser, default is 0 |
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.
Is 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.
Given 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents 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.
Does 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.
Does 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.
Create a browser group
| Name | Required | Description | Default |
|---|---|---|---|
| groupName | Yes | The name of the group to create | |
| remark | No | The remark of the group |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives 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.
Delete the browser
| Name | Required | Description | Default |
|---|---|---|---|
| userIds | Yes | The user ids of the browsers to delete, it is required when you want to delete the browser |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Drag the element
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | The selector of the element to drag, find from the page source code | |
| targetSelector | Yes | The selector of the element to drag to, find from the page source code |
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. 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.
Evaluate the script
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | The script to evaluate, eg: "document.querySelector('#username').value = 'test'" |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Fill the input
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | The selector of the input to fill, find from the page source code | |
| text | Yes | The text to fill in the input |
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 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.
Does 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.
Does 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.
Does 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.
Get the list of applications
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | The size of the page |
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 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.
Does 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.
Does 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.
Does 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.
Get the list of browsers
| Name | Required | Description | Default |
|---|---|---|---|
| groupId | No | The group id of the browser, must be a numeric string (e.g., "123"). You can use the get-group-list tool to get the group list | |
| size | No | The size of the page, max is 100, if get more than 100, you need to use the page to get the next page, default is 10 | |
| page | No | The page of the browser, default is 1 | |
| id | No | The id of the browser | |
| serialNumber | No | The serial number of the browser | |
| sort | No | The sort of the browser | |
| order | No | The order of the browser |
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.
Is 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.
Given 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents 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.
Does 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.
Does 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.
Get the list of groups
| Name | Required | Description | Default |
|---|---|---|---|
| groupName | No | The name of the group to search, use like to search, often used group name to find the group id, so eg: "test" will search "test" and "test1" | |
| size | No | The size of the page, max is 100, if get more than 100, you need to use the page to get the next page, default is 10 | |
| page | No | The page of the group, default is 1 |
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the three parameters (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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It 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.
Get the list of opened browsers
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and 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.
Does 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives 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.
Get the html content of the page
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description 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.
Does 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It 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.
Get the visible text content of the page
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives 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.
Hover the element
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | The selector of the element to hover, find from the page source code |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It 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.
Click the element in the iframe
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | The selector of the element to click, find from the page source code | |
| iframeSelector | Yes | The selector of the iframe to click, find from the page source code |
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation action with 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('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.
Does 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.
Does 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.
Move browsers to a group
| Name | Required | Description | Default |
|---|---|---|---|
| groupId | Yes | The target group id, must be a numeric string (e.g., "123"). You can use the get-group-list tool to get the group list | |
| userIds | Yes | The browser ids to move |
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation 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.
Does 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.
Does 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.
Does 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.
Open the browser, both environment and profile mean browser
| Name | Required | Description | Default |
|---|---|---|---|
| serialNumber | No | The serial number of the browser to open | |
| userId | No | The browser id of the browser to open | |
| ipTab | No | The ip tab of the browser, 0 is not use ip tab, 1 is use ip tab, default is 0 | |
| launchArgs | No | The launch args of the browser, use chrome launch args, eg: ["--blink-settings=imagesEnabled=false","--disable-notifications"], or vista url, eg: ["https://www.adspower.net"] | |
| clearCacheAfterClosing | No | The clear cache after closing of the browser, 0 is not clear cache after closing, 1 is clear cache after closing, default is 0 | |
| cdpMask | No | The cdp mask of the browser, 0 is not use cdp mask, 1 is use cdp mask, default is 0 |
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.
Is 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.
Given 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention 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.
Open a new page
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. 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.
Press the key
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The key to press, eg: "Enter" | |
| selector | No | The selector of the element to press the key, find from the page source code |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Get the screenshot of the page
| Name | Required | Description | Default |
|---|---|---|---|
| savePath | No | The path to save the screenshot | |
| isFullPage | No | The is full page of the screenshot |
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.
Is 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.
Given 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It 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.
Scroll the element
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | The selector of the element to scroll, find from the page source code, Simulates a user navigating page by scrolling, usually finding element in the bottom of the page |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It 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.
Select the option
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | The selector of the option to select, find from the page source code | |
| value | Yes | The value of the option to select |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It 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.
Update the browser
| Name | Required | Description | Default |
|---|---|---|---|
| domainName | No | The domain name of the browser, eg: facebook.com | |
| openUrls | No | The open urls of the browser, eg: ["https://www.google.com"] | |
| cookie | No | The cookie of the browser, eg: "[{"domain":".baidu.com","expirationDate":"","name":"","path":"/","sameSite":"unspecified","secure":true,"value":"","id":1}]" | |
| username | No | The username of the browser, eg: "user" | |
| password | No | The password of the browser, eg: "password" | |
| groupId | No | The group id of the browser, must be a numeric string (e.g., "123"). You can use the get-group-list tool to get the group list or create a new group | |
| name | No | The name of the browser, eg: "My Browser" | |
| country | No | The country of the browser, eg: "CN" | |
| sysAppCateId | No | The sys app cate id of the browser, you can use the get-application-list tool to get the application list | |
| userProxyConfig | No | The user proxy config of the browser | |
| fingerprintConfig | No | The fingerprint config of the browser, default is automatic_timezone: 0, timezone: "", language: [], flash: "", fonts: [], webrtc: disabled, browser_kernel_config: ua_auto, random_ua: ua_version: [], ua_system_version: [], tls_switch: 0, tls: "" | |
| storageStrategy | No | The storage strategy of the browser, default is 0 | |
| userId | Yes | The user id of the browser to update, it is required when you want to update the browser |
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.
Is 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.
Given 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 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.
Does 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.
Does 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.
Update the browser group
| Name | Required | Description | Default |
|---|---|---|---|
| groupId | Yes | The id of the group to update, must be a numeric string (e.g., "123"). You can use the get-group-list tool to get the group list | |
| groupName | Yes | The new name of the group | |
| remark | No | The new remark of the group |
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
click-elementclose-browserconnect-browser-with-wscreate-browsercreate-groupdelete-browserdrag-elementevaluate-scriptfill-inputget-application-listget-browser-listget-group-listget-opened-browserget-page-htmlget-page-visible-texthover-elementiframe-click-elementmove-browsernavigateopen-browseropen-new-pagepress-keyscreenshotscroll-elementselect-optionupdate-browserupdate-groupMost 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.
All 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.
With 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.
The 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
A Model Context Protocol server for Wix AI tools
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
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
