dolphin-anty-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Each tool targets a distinct resource/action, with detailed descriptions that clarify edge cases (e.g., list_profiles vs list_profiles_cursor, export_cookies vs export_cookies_local). The main risk is the sheer number of similarly named tools, but the descriptions resolve most ambiguity.
Naming Consistency4/5
The dominant pattern is verb_noun (list_, create_, update_, delete_, get_, start_, stop_, browser_), which is predictable. Minor deviations exist: plural forms (delete_profiles, create_profiles_bulk), the suffix in list_profiles_cursor, and the catch-all dolphin_request, but these do not obscure the convention.
Tool Count2/5
At 71 tools, this is far above the 25+ threshold for 'too many' and will be heavy for an agent to navigate. While the tools cover a wide range of the Dolphin{anty} product's features, the sheer volume makes the server feel like a kitchen sink rather than a focused toolset; splitting into modular servers would improve coherence.
Completeness5/5
The surface is remarkably complete: CRUD for profiles, proxies, folders, statuses, bookmarks, homepages, extensions, and team members, plus fingerprint generation, cookie sync, and browser automation. Minor gaps like a dedicated get_proxy are covered by list endpoints, so there are no functional dead ends.
Average 4.1/5 across 71 of 71 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and open-world behavior are covered. However, the description adds little beyond the action 'List' and the purpose. It does not disclose pagination, default limits, response format, or any constraints on what bookmarks are returned. For a simple read tool, the description adds minimal behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundancy. It is front-loaded with the action and resource. However, it lacks substance, which is penalized in other dimensions, but for structure and size it is appropriately short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 optional parameters and no output schema, the description should explain return values, filtering options, pagination, and how parameters interact. It provides none of this. The tool is a list operation, but there is no information on what data is returned, how to paginate, or what the 'query' and 'mainWebsites' parameters do. This is severely incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 4 parameters with zero description coverage, and the description does not mention any of them. With such low schema coverage, the description must compensate by explaining parameter meanings and usage, but it is completely silent. The agent has no guidance on what 'page', 'limit', 'query', or 'mainWebsites' control.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists bookmarks and specifies their purpose (available to assign to profiles). This distinguishes it from sibling tools like list_statuses or list_profiles by clearly identifying the resource (bookmarks) and the action (list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or scenarios where another list tool would be more appropriate. The context of 'available to assign to profiles' is a vague hint, not a clear usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutation but not destructive. The description adds the admin-only permission requirement, which is useful context beyond annotations. However, it doesn't disclose other behavioral traits like return values or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no fluff. 'Only admins can do this' earns its place as a key permission constraint, making it appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with 8 parameters and no output schema, the description is too sparse. It doesn't mention required fields, the role enum, or any expected response. The admin restriction helps but leaves many operational gaps that the moderate schema coverage cannot fully bridge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 63%, which is moderate but not high enough to rely on entirely. The tool description provides no parameter semantics whatsoever, leaving the undocumented parameters (role, password, displayName) without additional clarity. The description adds no value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a member to the team' – a specific verb and resource. It implies creation and differentiates from update/delete/list by the action word 'Add', but it doesn't explicitly name sibling alternatives or contrast with them, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like update_team_user or delete_team_user. The only additional context is 'Only admins can do this,' which is an authorization constraint, not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true. The description only restates the resource type without adding details about permanence, error handling, or effects on associated data. No additional behavioral context is provided beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler. Every word is meaningful, and the statement is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 1-param delete tool with no output schema, the description is thin. It omits essential context about the 'ids' parameter and any caveats like partial success, missing IDs, or whether deletion is permanent. The annotations cover safety but not operational semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'ids' parameter with 0% description coverage. The description does not clarify what the IDs represent (e.g., homepage entry IDs) or how they map to startup page entries, leaving the agent to guess based on the parameter name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Delete' and specifies the resource as 'startup page entries,' clearly distinguishing it from siblings like list_homepages, create_homepages, and update_homepage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention exclusions or alternative tools for deleting other resources, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey non-readOnly and openWorld traits, so the description's minimal disclosure is partially mitigated. It adds that a snapshot is returned, but does not mention side effects like changing the current tab or loading behavior. This is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no redundant wording, and the key actions are front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is minimally sufficient, but it lacks guidance relative to sibling tools and does not describe the snapshot output format or any prerequisites. Schema and annotations fill in many details, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (83%), so the parameters are already well-documented. The description adds no extra meaning beyond the schema, such as clarifying the behavior of `direction` or `tabIndex`. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: go to a URL or move through history, and returns a page snapshot. This is a specific verb+resource+outcome, but it does not explicitly distinguish from sibling tools like browser_snapshot or browser_tabs, though the navigation intent is evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Given many sibling browser tools exist, an agent would not know whether to use browser_navigate, browser_connect, or browser_tabs for a given task. The description solely states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-readonly, non-destructive operation, so the description does not need to repeat that. It adds 'up to 10' and 'startup pages', but these mostly mirror schema constraints (maxItems) and the resource type. No additional behavioral context such as side effects, auth needs, atomicity, or return behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It communicates the core action immediately ('Create') and includes the key batch limit. Every word earns its place, though this brevity sacrifices content completeness handled elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, zero schema descriptions, and no output schema, the description is too sparse. It provides the basic create action but leaves critical details about what constitutes a 'startup page', how 'mainWebsite' affects behavior, and what the response/return value will be. The tool is not fully usable from this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description names no parameters at all. The important parameters 'mainWebsite' and 'sharedToEntireTeam' are completely unexplained, leaving their meaning dependent on bare field names and enum values. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') with a clear resource ('startup pages') and a batch limit ('up to 10'), which distinguishes it from sibling tools like list_homepages, update_homepage, and delete_homepages. It directly states what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in one call' implies a batch usage context, but the description does not explicitly state when to prefer this tool over alternatives or mention any exclusions. No sibling tool comparison is provided, leaving usage guidance mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint, idempotentHint, and readOnlyHint=false. The description adds no additional behavioral context such as whether deletion is permanent, what happens to missing IDs, or any side effects. It merely restates the action without revealing new traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, 'Delete bookmarks from the workspace.' It is front-loaded with the verb and resource, contains no redundant words, and every word adds purpose or scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what the agent can expect (e.g., success response, error behavior). It also does not mention that deletion is batch-capable via the ids array or how missing IDs are handled. Given its simplicity, the description is too sparse to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'ids' with 0% coverage (no descriptions), and the tool description does not explain that 'ids' are bookmark IDs or that multiple IDs can be provided. The description names the action but fails to clarify parameter meaning, which is especially important given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'bookmarks', and adds scope 'from the workspace'. This distinguishes it from sibling tools like create_bookmark, update_bookmark, and list_bookmarks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and description: call this to delete bookmarks. However, there is no explicit guidance on when to use it versus alternatives, nor any noted exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive operation. The description adds minimal behavioral context beyond the creation act, and does not disclose potential uniqueness constraints, return values, or side effects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Create', and contains no filler. It is highly concise and structured for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple create operation, the description lacks essential contextual information such as return values, uniqueness constraints, or usage prerequisites. With no output schema and poor parameter coverage, the description should provide more context to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description does not compensate by explaining any of the parameters. The meaning of 'isPinned' remains ambiguous, and the agent must rely on property names alone. This is insufficient given the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' with the resource 'folder' and clarifies its purpose as 'grouping profiles'. This distinguishes it from sibling tools like update_folder, delete_folder, and list_folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is used when a folder is needed for grouping profiles, but it provides no explicit guidance on when to use it versus alternatives such as reorder_folders or move_profiles_to_folder. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the behavioral nuance that the bookmark 'can be pushed into browser profiles', which is useful context. However, it does not disclose return values, side effects, or permission requirements, so it only partially supplements the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the tool's core purpose without any unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool, the description is adequate but minimal. It does not explain what 'pushed into browser profiles' entails, what the response will be (no output schema exists), or how it relates to other bookmark/profile tools. The schema covers the parameter structure, but behavioral context is thin, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter explanations. While the schema reveals types, defaults, and enums (e.g., mainWebsite), the description does not clarify the meaning of parameters like 'mainWebsite' or 'sharedToEntireTeam' in relation to the 'pushed into browser profiles' behavior. The description fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Create a bookmark') and adds a distinguishing nuance ('can be pushed into browser profiles'), which clearly differentiates it from sibling tools like list_bookmarks, update_bookmark, and delete_bookmarks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating bookmarks, and the 'pushed into browser profiles' context hints at its purpose. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. This is implied usage rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds a note about the pages being 'available to assign to profiles,' but does not disclose behavioral details like pagination or response structure. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It effectively communicates the core action and resource in ten words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with read-only annotations, the description covers the basic purpose but omits any mention of filter/pagination parameters or return shape. Since there is no output schema and the parameters are undocumented, the description is minimally adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any of the four parameters (page, limit, query, mainWebsites). The agent receives no guidance on pagination, searching, or filtering, leaving the parameters semantically opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('startup pages') and clarifies the purpose ('available to assign to profiles'). This clearly distinguishes it from sibling list tools like list_statuses or list_proxies, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: startup pages are used for assignment to profiles, so this tool is appropriate when an agent needs to see available homepages for that purpose. However, it does not explicitly state when not to use it or name alternatives (e.g., create_homepages), so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds some context by explaining the key types and the ability to target an element, but does not disclose potential side effects like form submission or focus changes beyond the annotation hints. The annotations indicate non-read-only and non-destructive, which the description does not contradict, but it provides only marginal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately states the action, and provides relevant key examples without irrelevant information. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex schema with nested target object and annotations, the description is sufficient to convey the core action, but it lacks details on return values, error handling, and edge cases like invalid keys or missing targets. The schema covers parameter semantics but not behavioral outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description supplements the schema with additional Playwright key examples (ArrowDown, PageDown, Backspace) and notes that keys can be sent to the page or focused element, which aligns with the target parameter. However, the schema already covers key details and target descriptions, so the added value is limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send a keyboard key to the page or to a focused element', identifying the specific verb and resource. It also lists Playwright key names, which distinguishes it from sibling tools like browser_type (typing text) and browser_click (mouse click).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for keyboard actions but does not explicitly state when to use this tool over alternatives like browser_type or browser_click. There is no when/when-not guidance, only the action description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a mutating (non-readOnly) but non-destructive action. The description adds minimal behavioral context beyond that—it mentions matching options by label or value but does not disclose side effects like triggering change events or that the element must be visible/enabled. With annotations covering safety, the description is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the core function and key matching strategies. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested target object, multiple parameters, no output schema), the description is thin. It does not explain how to locate the select element via target, potential errors, or return behavior, but the rich schema compensates partially. The description is sufficient for a straightforward tool but leaves gaps for edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (83%), and the description summarizes the two key parameters (labels and values) as 'visible label or by value.' This adds slight clarity but largely mirrors existing schema descriptions, providing little extra value beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool selects one or more options in a <select>, using a specific verb ('Choose') and resource ('<select>'). It distinguishes itself from sibling tools like browser_click or browser_type by focusing specifically on dropdown option selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating its function, but does not explicitly say when to use it over alternatives. It lacks guidance on when not to use it or how it compares to related tools like browser_click for interacting with dropdowns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint and destructiveHint. The description adds explicit no-op behavior when the robot is not running, which reinforces idempotency. It does not disclose any other behavioral traits like side effects, auth requirements, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two brief sentences, front-loaded with the core action. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the main action and the no-op behavior. It does not mention return values, but the absence of an output schema makes that less critical. Could further clarify that it only stops the robot, not the profile, but it's sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required integer browserProfileId with no description. The description does not explain the parameter's meaning beyond the name, and schema description coverage is 0%. The description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action 'Stop a running cookie robot' with a specific resource. 'No-op if it is not running' adds scope. This distinguishes it from the sibling run_cookie_robot as the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you want to stop a cookie robot) but does not explicitly mention alternatives like stop_profile or prerequisites. The no-op note gives a behavioral guideline but no exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely lists the operations without disclosing behavioral details such as whether it performs a partial update (only changing specified fields), if there are constraints on duplicate names, or any side effects. Annotations already indicate it's not read-only and not destructive, but the description adds no extra context beyond this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently conveys all three operations without wasted words. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple update tool, covering the main operations. However, it lacks important contextual details such as the partial-update behavior (whether omitted fields remain unchanged) and any constraints, which are especially relevant for update tools. The presence of annotations and the simple schema reduce the burden, but the description could still be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by mapping 'rename' to name, 'change emoji' to emoji, and 'pin/unpin' to isPinned, providing meaningful semantics. The id parameter is implied as the identifier. However, it doesn't clarify whether at least one optional field must be provided, which is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states specific actions on a folder: renaming, changing emoji, and pinning/unpinning. This goes beyond the generic title and distinguishes it from other update tools for different resources like update_profile or update_proxy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for modifying folder metadata, and the resource is clear from the name. However, it gives no explicit guidance on when to use this versus sibling tools like move_profiles_to_folder or reorder_folders, nor does it state prerequisites such as the folder needing to exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate that the tool is not read-only and not destructive. The description adds valuable behavioral detail: existing profiles will adopt the new settings on next launch. This goes beyond what annotations provide and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and followed by a meaningful consequence. Every word serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no parameter descriptions, this description is far too sparse. It does not cover return values, partial update behavior, or the need for the id parameter, leaving the agent without enough information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It only says 'new settings' with no elaboration on id, host, port, type, login, password, or changeIpUrl. The agent has to infer meanings from property names alone, which is insufficient for parameters like changeIpUrl.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Change a saved proxy' precisely states the action (change) and the resource (a saved proxy), clearly distinguishing it from create_proxy and delete_proxy. The added profile note reinforces its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for modifying an existing proxy versus creating a new one, which differentiates from create_proxy. It also notes that profiles pick up changes on next launch, giving timing context. However, it does not explicitly mention alternatives or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, so the description's mention of 'Keys and values are Base64-encoded and are normally treated as an opaque blob' adds valuable behavioral detail beyond that flag. It tells the agent not to parse the contents and that the data is grouped by origin. However, it omits any auth or rate-limit context, which keeps it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that lead with the core purpose and add a key behavioral detail. Every word earns its place; there is no repetition of schema or annotation information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not specify the return format or how the export is delivered (e.g., file vs JSON). It also omits prerequisites like the desktop app needing to be running or the plan parameter's role. The description covers basic behavior but is not fully complete for an agent choosing to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only browserProfilePassword has a description), and the tool description does not explain any parameters. With low coverage, the description should compensate, but it does not mention browserProfileId, plan, or cloudSyncDisabled, leaving their semantics to be guessed from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'Export a profile's local storage through the desktop app, grouped by origin.' This clearly distinguishes the tool from siblings like import_local_storage and export_cookies by specifying the operation, resource, and scoping (by origin).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for exporting local storage in a migration/backup context, but it does not explicitly state when to use it instead of alternatives like import_local_storage or export_cookies. There are no exclusions or alternative mentions, so usage guidance is minimal and only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds the behavioral nuance that the user-agent should be consistent with the profile's fingerprint, which is useful context. However, it does not disclose additional behavioral traits such as randomness or the handling of the oldUseragent parameter beyond what the schema provides. Thus a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every sentence adds value. 'Sample a real user-agent matching a platform and major Chrome version' is the essential purpose, and 'Keep it consistent with the rest of the profile's fingerprint' provides important contextual guidance. No redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the main behavior and adds an important fingerprint-consistency hint. There is no output schema, but the return type (a user-agent string) is clear from the description. The optional oldUseragent parameter is explained in the schema, and the description does not need to repeat it. The main gap is the lack of any mention of what happens if the same user-agent is requested repeatedly, but the schema's description of oldUseragent partially addresses this. Overall, the tool is adequately contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, with descriptions for oldUseragent and browser_version, and platform has an enum. The description text reinforces the meaning of platform and browser_version ('matching a platform and major Chrome version') but does not add substantial new meaning beyond the schema. It does not mention the oldUseragent parameter, but the schema already explains it. The overall parameter meaning is sufficiently covered by the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Sample' and the resource 'a real user-agent', specifying the matching criteria (platform and major Chrome version). It clearly distinguishes this tool from siblings like get_fingerprint, which has a broader scope. The action and purpose are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied guidance ('Keep it consistent with the rest of the profile's fingerprint') suggesting it should be used in the context of building a profile fingerprint. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. The usage context is clear but not directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds that the operation occurs 'through the desktop app' and the data is from export_local_storage, but it does not disclose whether existing local storage is overwritten or merged. This is relevant behavioral context that is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It front-loads the core action and immediately clarifies the data source. Appropriate length for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate at a high level but lacks important operational details for a mutating tool with no output schema. It mentions the desktop app requirement but does not explain return behavior, prerequisites (e.g., profile must exist), or whether existing storage is replaced. These gaps make it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 33%—only localStorage has a description. The tool description adds context that the input is a dump from export_local_storage, but it does not clarify the purpose of the `plan` or `profileId` parameters. With such low schema coverage, the description should compensate by explaining these parameters, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Write a local storage dump ... into a profile'. It uses a specific verb and resource, and references the counterpart tool `export_local_storage`, which distinguishes it from other import tools like import_cookies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: to import a local storage dump produced by export_local_storage. However, it does not explicitly state when not to use it or name alternative tools beyond the producer reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral detail 'Only the fields you pass are modified', which is valuable for partial-update semantics. Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false), so the description complements rather than contradicts them. No mention of permissions or side effects, but the annotations lower the bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, conveying the core behavior without any redundancy. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavior (partial update) but is minimal. Given the lack of an output schema and low parameter explanation, an agent may need to infer what fields like 'data' or 'mainWebsite' represent. The field names and enum values provide some context, but the description does not fully compensate for the missing schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter meaning. It only says 'fields you pass are modified', which clarifies that parameters are optional fields for partial updates, but it does not explain the semantics of 'data', 'mainWebsite', or 'sharedToEntireTeam'. The parameter names are moderately self-explanatory, but the description does not help an agent understand their structure or purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Change a startup page entry' clearly identifies the action (change) and the resource (startup page entry), distinguishing it from sibling tools like create_homepages, delete_homepages, and list_homepages. The verb is specific and the resource is well-defined in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the verb 'change' and the tool name 'update_homepage', suggesting it is for modifying existing homepages. However, there is no explicit guidance on when to use this tool versus alternatives such as create_homepages or delete_homepages, nor any exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds the behavioral note about lazy-loaded content, but does not disclose other aspects like scroll behavior inside frames, error handling, or whether scrolling waits for content to appear. Some value beyond annotations, but limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, no unnecessary verbiage. The lazy-loading note is relevant and adds context without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 top-level parameters and a nested target object with many optional selectors, the two-sentence description is somewhat sparse. It explains the two main modes and one use case but does not guide on how to choose between direction and target or handle edge cases. The schema fills in parameter details, but for a tool of this complexity, more context would help an agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, with direction lacking a description. The tool description says 'Scroll the page' (for direction) and 'bring a specific element into view' (for target), which adds a slight semantic distinction, but the schema already provides descriptions for target and amount. The description adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Scroll') and resources ('the page, or bring a specific element into view'), distinguishing it from sibling browser tools like navigate, click, or wait_for. The purpose is immediately understandable and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a concrete use case: 'Useful for lazy-loaded content that is not in the DOM until it is scrolled to.' This implies when to use the tool, though it doesn't explicitly mention alternatives or exclusions. The context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint and readOnlyHint, but the description adds important behavioral context by explaining the downstream effect on profiles (they lose the extension on next launch). This goes beyond the structured fields without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is precise and front-loaded with the primary action. It contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool with robust annotations, the description covers the essential effect on profiles. It could mention return behavior or permanence, but these are not critical given the simplicity and existing annotation coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden for explaining parameter meaning. It does not mention 'ids' at all, leaving the agent to infer that they are extension identifiers. The schema itself only provides type and requiredness, so the description adds no value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Remove' and clearly identifies the resource 'extensions from the workspace.' It also adds a meaningful consequence ('Profiles using them lose them on next launch') that distinguishes it from sibling tools like add_extension and list_extensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for deleting extensions but does not explicitly state when to use this over alternatives or provide exclusions. The usage is clear from the name and context, but no explicit guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds the authorization constraint 'Admins only', which is not present in annotations, and clarifies the scope is removal from the team rather than account deletion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action, no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool with annotations covering the destructive nature and an absent output schema, the description provides essential information (action, scope, permission). It could add a note on what happens to the user's associated data, but overall it is near-complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name and type (integer userId) with no description, and the description does not elaborate on what userId refers to or how to obtain it. With 0% schema description coverage, the parameter semantics are left to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Remove' with the resource 'member from the team', clearly distinguishing it from create/update team user tools. The action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the action and includes the prerequisite 'Admins only', but does not explicitly mention when to use this tool versus alternatives like update_team_user or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds the 'attach to profiles' scope, which is useful context, but it does not disclose pagination or search behavior, which are only visible in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It clearly states the action and scope in a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a list tool with optional pagination parameters and no output schema, the description gives a clear purpose. However, it does not mention pagination, search, or return format, which would be helpful but is somewhat mitigated by the tool's straightforward nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explanation for the page, limit, or query parameters. With 0% schema description coverage, the description fails to compensate, leaving the meaning of these parameters to be inferred from their names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('browser extensions'), and adds a clear scope ('available to attach to profiles'). This makes it easily distinguishable from sibling tools like add_extension and delete_extensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool—when you need to see extensions that can be attached to profiles. It does not explicitly mention alternatives or exclusion criteria, but the context is clear enough for a list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, covering the safety profile. The description adds the scoping detail 'in the workspace' and clarifies the purpose of folders, but it does not disclose return format, sorting, or pagination. This is acceptable given the annotations, but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It front-loads the verb and resource, making it instantly scannable and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema), and the description conveys the core purpose. However, it lacks any mention of what the response contains (e.g., folder IDs, names) or any caveats, which would be expected given there is no output schema to clarify return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed since the schema is empty and coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'folders', specifying that they group browser profiles in the workspace. This unambiguously differentiates it from sibling tools like list_profiles or list_proxies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying what the tool does, but it does not explicitly state when to use it over alternatives (e.g., get_folder_profile_ids, list_profiles) or mention any prerequisites. No exclusions or contextual guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the basic safety profile is known. The description adds value by specifying the scope ('current team account') and the output content ('roles and profile limits'), which is particularly helpful given there is no output schema. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. It immediately states the action and resource, then adds a concise detail about returned data. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with strong annotations and no output schema, the description is mostly complete. It specifies what is returned and the scope. However, it does not mention pagination or filtering behavior, though these are inferable from the input schema parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'query' has a description). 'page' and 'limit' have no semantic explanation in the schema, and the tool description does not compensate by explaining pagination or the meaning of these parameters. The description adds no parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('members of the current team account'), and adds specific output details ('with their roles and profile limits'). This distinguishes it from sibling tools like list_profiles or list_statuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for listing team members in the current team account, but it does not explicitly state when to use it versus alternatives or what situations it is not for. Sibling tools include create_team_user/update_team_user, but no cross-referencing or exclusion guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, non-destructive, and open-world behavior. The description adds that the reordering affects the UI and defines the sort direction, providing useful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no redundant wording; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core behavior is covered, but the description omits important usage details such as whether partial reordering is supported, the fate of unlisted folders, and any return value, which is significant for a tool with no output schema and minimal parameter descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the meaning of the `order` property ('Higher order values sort higher'), which is absent from the schema descriptions. However, it does not clarify whether the `folders` array should include all folders or only a subset, leaving some parameter contract ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Reorder' with resource 'folders' and explains the ordering direction ('Higher order values sort higher in the list'), clearly distinguishing it from sibling folder tools like create_folder or update_folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for display ordering but does not explicitly address when to use this tool versus update_folder or move_profiles_to_folder, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and openWorldHint=true, so the description doesn't need to repeat that it's a mutation. It adds the admin-only permission context. However, it doesn't disclose any additional behavioral nuances (e.g., effect on existing sessions, whether partial updates are allowed, or response format), so it only partially goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and object, followed by a short permission note. No wasted words, perfectly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with many optional parameters and no output schema, the description is minimal. It gives the core purpose and an admin restriction, but lacks information about return values, error behavior, or preconditions (e.g., user must exist). It's adequate for basic invocation but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11%, so the description needs to compensate. It groups params into categories ('role, credentials, supervisors or profile limits') which adds some meaning, but it doesn't explain subtle relationships (e.g., between bpLimit and unlimitedBp) and omits canCreateBp and displayName. The grouping provides modest value, but not enough to reach a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Change') and the resource ('a team member'), and lists the specific aspects being modified (role, credentials, supervisors, profile limits). This clearly distinguishes it from sibling tools like create_team_user, delete_team_user, and list_team_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with 'Admins only', indicating a permission prerequisite. It doesn't explicitly mention alternatives, but the tool name and purpose make it obvious when to use it instead of create/delete/list team user tools. No exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds the behavior of creating a status on the fly when name+color are provided, which is a useful side-effect disclosure. However, it does not mention what happens when both statusId and name/color are supplied, or when the statusId does not exist, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main action, and then immediately gives the parameter usage pattern. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the schema/annotations provided, the description covers the core behavior and parameter modes well. It explains how to assign an existing status or create-and-apply a new one. It lacks only minor contextual details like error handling or return value, but these are not essential given the output schema is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies the relationship between parameters: statusId is for existing statuses, while name+color are for creating a new status. This adds meaning beyond the schema, which only notes name is used when statusId is omitted. The ids parameter is obvious from 'several profiles'. The description compensates for the schema's limited coverage (50%).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Set the status of several profiles at once', which names the specific verb (Set), the resource (status of profiles), and the scope (several at once). This clearly distinguishes it from sibling tools like create_status or update_status, which create or modify status objects themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two usage modes: pass statusId for an existing status, or pass name and color to create on the fly. This tells the user when to use each sub-path, but it does not explicitly state when to prefer assign_status over create_status+update_profile or other alternatives. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the safety profile is known. The description adds the important behavioral context that other tools act on the active tab, which influences how tab selections affect subsequent operations. It does not disclose details like what happens to unsaved state on close, but this is not required given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action verbs and followed by the scope-defining sentence. Every word adds value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and clear annotations, the description is mostly complete. It explains the tool's actions and its relationship to other browser tools. The only gaps are the `tabIndex` vs `index` naming inconsistency and the lack of explicit mention that `action` defaults to 'list', though that is in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (url, index, profileId described; action has enum and default but no description). The description maps 'open' and 'switch' to action values 'new' and 'select', adding some semantic clarity. However, it refers to 'tabIndex' while the schema uses 'index', creating a minor naming inconsistency that could confuse the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with specific verbs: 'List, open, switch or close tabs.' It also distinguishes the tool from siblings by noting that other browser tools operate on the active tab unless given an explicit `tabIndex`, which establishes its unique role in tab management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool—when managing tabs—and implicitly contrasts it with sibling tools by explaining that other tools act on the active tab. However, it does not explicitly list alternative tools or exclusions, such as using browser_navigate for navigation in the current tab, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, which the description does not contradict. It adds the context of 'page settling' and names the types of waits, but it does not disclose timeout behavior, what happens on failure, or side effects beyond the read-only nature already captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and a practical usage tip. No redundant terminology, every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all major wait modes and gives a concrete use case, which is sufficient for selecting the tool. It omits behavior on timeout (e.g., whether it throws or returns early) and does not describe the return value, but those are secondary given the schema's rich parameter explanations and the blocking nature implied by the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, leaving state and timeout without textual descriptions. The main description summarizes the parameter categories (text, element, load state, delay) but does not map them directly to individual schema properties or explain nuanced fields like the nested target object. It adds some grouping value but relies heavily on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'wait' and lists four distinct waitable resources (text, element, load state, fixed delay). It also explicitly differentiates from retrying a failed click, making it distinct from browser_click and similar browser tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance to use this tool instead of retrying a failed click when a page is settling, offering a clear alternative scenario. However, it does not compare with other waiting tools like browser_await_human or list any exclusions, so it stops short of full when/when-not coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world behavior, lowering the bar. The description adds useful context by mentioning the password-protected flag and folder scope. It does not describe return format or errors, but this is acceptable given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no filler, directly stating what the tool does and what it returns. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with open-world annotation, the description covers the main output. However, it lacks explicit parameter binding and any mention of edge cases like folder not existing. Overall adequate for the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'id' integer with no description. The description says 'inside a folder' but never explicitly states that the id parameter is the folder ID; this must be inferred from the tool name/title. With 0% schema coverage, more explicit binding would be better.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns profile IDs inside a folder plus a password-protected flag, using a specific verb ('Return') and resource ('profile ids inside a folder'). This distinguishes it from sibling tools like list_profiles, get_profile, and list_folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Usage is implied by the tool name and description but no exclusions or alternative tools are mentioned, so it falls short of clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world, so the description appropriately adds the behavioral trait that each item carries a full fingerprint, implying heavy payloads. This is useful context beyond the annotations, though it does not detail return structure or pagination specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose and then a practical caution. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters and no output schema, the description provides only a high-level overview. It mentions the fingerprint payload but not the return shape or which filtering options exist. It is adequate but incomplete for an agent to fully understand the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 42% schema description coverage, the description should compensate for the many undocumented parameters. It only broadly mentions pagination, search, and filters, and specifies the limit default. It does not explain filters like tags, folders, statuses, or sorting, leaving the agent to guess parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists browser profiles and mentions key capabilities (pagination, full-text search, filters). This distinguishes it from similar tools like list_profiles_cursor by implying page-based pagination, and the verb-resource pair is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: the tool supports pagination, search, and filters, and warns about the large payload of full fingerprints, advising a small limit. It does not explicitly mention when to use list_profiles_cursor as an alternative, so it falls short of a 5, but the guidance is pragmatic and clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it's safe. The description adds workspace scoping and optional search/pagination, but no other behavior details like return format or pagination semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 11 words, front-loaded with the action and resource, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with read-only annotation and schema displaying constraints, the description is sufficient to convey purpose and optional parameters, though it doesn't detail return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers only 33% of parameters with descriptions (query). The description mentions search and pagination, providing some context for parameters, but page and limit lack detailed descriptions beyond schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists proxies saved in the workspace, with a specific verb and resource. It distinguishes from sibling list tools for other resources (e.g., list_profiles, list_statuses).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage for retrieving proxies from the workspace. There are no alternatives for listing proxies among siblings, so context is clear, but it doesn't explicitly state when to use or not use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses partial-update semantics beyond what annotations provide: unspecified fields remain unchanged. Since readOnlyHint=false already signals mutation, this adds useful behavioral detail. It does not cover error cases or return values, but annotations are present and low-risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action and immediately adding the critical partial-update behavior. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, annotations, and no output schema, the description is mostly sufficient: it names the action and the partial-update behavior. The absence of return-value documentation is a minor gap but does not hinder selection or invocation for a straightforward update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that only passed fields are modified, which clarifies the role of each optional parameter. However, it does not detail individual parameters like mainWebsite or sharedToEntireTeam, though their names and schema types are self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's function clearly: 'Change a bookmark.' This identifies the verb and resource, distinguishing it from create/delete/list bookmark tools. It does not explicitly differentiate from sibling update tools, but the resource is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a key usage guideline: 'Only the fields you pass are modified,' which tells the agent how to perform a partial update. It does not name alternatives or when-not-to-use cases, but the context implies this is for modifying an existing bookmark by ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a non-read-only, non-destructive operation. The description adds valuable behavioral context: it's a partial patch ('Only the fields you pass change') and explains how `extra` passes unmodeled fields. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, then patch semantics and `extra` guidance. Every sentence earns its place with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters, nested objects, and no output schema, the description is too sparse. It lacks prerequisites (e.g., must profile be stopped?), side effects (openWorldHint suggests external effects), return value, and guidance for complex fields like proxy or fingerprint. The patch semantics are helpful but insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 46%; the description adds general patch semantics and clarifies `extra` as a catch-all. However, it doesn't compensate for undocumented parameters like fingerprint, platformVersion, or statusId. The value added is modest beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Patch an existing profile' with a specific verb and resource. It distinguishes from create_profile and delete_profiles by indicating this is for updating existing profiles. The partial-update semantics and `extra` field clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use this tool (to modify an existing profile) and when not (creation is for create_profile). It also gives direct guidance on using `extra` for unmodeled fields. No explicit exclusions but sufficient context for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only (readOnlyHint=false) and open-world (openWorldHint=true). The description adds useful context about attaching vs. starting and the origin of port/wsEndpoint, but does not disclose failure behavior, error cases, or what happens if the profile is not running. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose, each sentence earning its place. No unnecessary detail or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and usage well, but since it involves side effects (openWorld) and there is no output schema, it doesn't describe return values or error conditions. For a connection tool, this is a notable gap, though the broader tool suite context partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented. The tool description reinforces that port and wsEndpoint come from the start response and explains the start parameter's effect, adding some value beyond the schema. Baseline 3 is appropriate since the schema already carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool attaches the automation client to a running profile, using a specific verb+resource. It distinguishes itself from start_profile by noting this is usually unnecessary and providing a concrete use case (profiles started outside the server).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this when the profile was started outside this server' and notes the alternative that start_profile records the endpoint. Also explains the optional start:true to start the profile itself, providing clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates the safe read-only nature, so no need to repeat. The description adds value by disclosing that the result includes the full fingerprint, which is non-obvious and useful behavioral/return information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, eleven words, front-loaded with the verb and resource. Every word earns its place; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-fetch tool, the description covers the key points: what is fetched (profile by id) and a notable detail (full fingerprint). Given the annotations cover safety and there are no nested objects, this is sufficiently complete, though it could mention error cases or absence behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It only says 'by id', which essentially just repeats the parameter name 'id' without explaining the id's origin, format, or relationship to the profile. The schema states it's an integer, but the description adds little meaning beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (fetch), the resource (one browser profile by id), and specifies that it includes the full fingerprint. This distinguishes it from sibling tools like list_profiles (which fetch many) and get_fingerprint (which fetches only a fingerprint).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the use case: when you need a single profile identified by its id. It does not explicitly mention alternatives or when-not-to-use, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses that existing cookies with the same domain/path/name are replaced, which is a key behavioral trait. It also mentions the dependency on cloud sync and paid plan. This adds valuable context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each providing essential information: the core action, the replacement behavior, and the prerequisites. No filler or repetition. The information is front-loaded with the primary purpose first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, nested cookie structure) and no output schema, the description covers the key aspects: behavior, prerequisites, and replacement semantics. However, it omits mention of the optional browserProfilePassword and what the API returns. Still, it is largely complete for making an informed call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters, and the schema description coverage is 0%. The schema itself includes some nested descriptions for cookie fields, but the crucial browserProfilePassword parameter and the overall cookie array requirements are left unexplained. Since schema coverage is low, the description should compensate, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Write') and resource ('cookies into a profile'), and clarifies the mechanism ('via the remote sync API — no desktop app required'). This clearly distinguishes it from sibling tools like import_cookies_local and aligns with the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use: when you need to import cookies remotely via sync API without a desktop app. It also states prerequisites ('profile must have cloud sync enabled', 'paid-plan feature') that help the agent choose the right tool. However, it does not explicitly name alternatives like import_cookies_local.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses additional behavioral traits: it waits for the element to be actionable and returns a page snapshot. These are useful for agent planning and are not captured in the structured annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first sentence front-loading the core actions and the second adding key behavioral details (waiting and snapshot return). Every sentence earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, nested target object, no output schema), the description adequately covers the operation and return value. The schema handles parameter semantics, and the description explicitly notes the snapshot return, which is essential since there is no output schema. It could mention potential navigation side effects, but openWorldHint partly covers this, making the description sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents most parameters with descriptions (target selector strategies, modifiers, tabIndex, profileId), and the tool's description adds no parameter-level explanation beyond what the schema provides. At 67% schema coverage, the description does not compensate for the undocumented timeout parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with specific verbs (click, double-click, right-click, hover) and a resource (an element). It distinguishes itself from sibling tools like browser_navigate (navigation) and browser_type (keyboard input) by focusing on pointer actions, and it also mentions the waiting behavior and snapshot return, reinforcing its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for any element interaction involving clicks or hover, and the note about waiting for actionability suggests it is appropriate for dynamic pages. However, it does not explicitly name alternatives or exclusion criteria (e.g., 'for selecting a dropdown value, use browser_select_option'), so it provides clear context but no explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, which covers the safety profile. The description adds behavioral context by noting the optional immediate assignment to a profile, which is a side effect beyond simple creation. It does not disclose permissions, reversibility, or return format, but the annotations reduce the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 18 words, with the verb and resource placed upfront. Every word contributes to clarifying the tool's purpose and optional behavior, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema, annotations present), the description provides the core purpose and the optional assignment behavior, which is sufficient for an agent to select and invoke it. The schema fills in the remaining parameter details, so the combination is complete enough. It lacks explicit failure scenarios but that is not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (profile and password have descriptions). The description compensates for the un-described name and color parameters via the phrase 'coloured status label', which implies text and color choices. It also maps the 'optionally applying it to a profile' phrase to the profile parameter, offering meaningful conceptual coverage of all four parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and identifies the resource ('coloured status label') with a clear purpose ('for grouping and filtering profiles'). It distinguishes itself from sibling tools like list_statuses, update_status, assign_status, and delete_statuses by focusing on creation with optional immediate assignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use the tool: when a new status label is needed for grouping/filtering. It suggests an alternative path by saying 'optionally applying it to a profile straight away', implying that if the status already exists one might use assign_status. However, it does not explicitly name alternatives or exclusions, so it is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive, but the description adds valuable context beyond annotations: 'Profiles inside it are detached, not deleted.' This clarifies the non-recursive behavior, which is important for a delete operation. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The first sentence states the primary action, and the second adds a crucial side-effect. Minimal and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description covers the essential behavior and the important side-effect (detaching profiles). It is complete given the tool's low complexity and the annotations provide additional safety info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention the 'id' parameter or explain its meaning. Although the parameter is self-evident from the tool name, the description adds no semantic detail to compensate for the schema's lack of description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete a folder' with a specific resource, and adds a key qualifier that profiles inside are detached, not deleted. This distinguishes it from sibling tools like delete_profiles and move_profiles_to_folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool vs alternatives: it deletes a folder without deleting profiles, suggesting you'd use delete_profiles if you want to remove profiles too. However, it doesn't explicitly name alternatives or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds valuable context that profiles are not deleted but left with no status, clarifying the scope of destruction beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the verb and resource, and every word adds value. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter delete tool with annotations covering destructive and idempotent behavior, the description sufficiently conveys the essential behavioral outcome. The missing parameter detail is accounted for in the parameter semantics dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), so the description must compensate. It implies 'ids' are status label IDs via 'Delete status labels,' but it does not explicitly define the parameter semantics or format beyond the schema's array of integers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), the resource ('status labels'), and the downstream effect ('Profiles carrying them are left with no status'). This distinguishes it from sibling tools like list_statuses, create_status, update_status, and assign_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to remove status labels while preserving profiles. However, it does not explicitly mention alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the description aligns with a write operation. It adds behavioral context by specifying the write target ('on-disk data directory') and the dependency on the 'running desktop app'. It also implies that this method bypasses cloud sync, which is valuable. However, it does not detail potential side effects or failure modes, but the annotation coverage reduces that burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the core action, and the second provides guidance. No redundant or filler content. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and usage guidance, and the annotations provide safety-related context. However, with no output schema and low schema coverage, the description leaves gaps around parameter details and potential failure modes. It is adequate but not complete for an agent to fully understand the tool's behavior without further inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, with only domain and expirationDate described. The tool description does not elaborate on parameters like profileId, cookies structure, cloudSyncDisabled, or browserProfilePassword. While the mention of 'cloud sync disabled' hints at cloudSyncDisabled, it does not explain the parameter semantics. The description adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Write cookies into a profile's on-disk data directory through the running desktop app.' The verb is specific, the resource is identified, and the method distinguishes it from the sibling import_cookies tool. The title also emphasizes 'Local API', reinforcing the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Prefer import_cookies unless the profile has cloud sync disabled.' This tells the agent when to choose this tool over the sibling, and also implies the prerequisite that the desktop app must be running. This is direct and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by adding that the fonts 'genuinely exist on the given OS', implying an actual system query rather than a static list. It also discloses that each record contains a `font` property, giving insight into the return structure. No negative side effects are mentioned, but the readOnly annotation covers that, and the openWorldHint aligns with OS-dependent results. This is valuable additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. The first sentence front-loads the core purpose, and the second provides actionable usage instructions. It is concise and well-structured, earning a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one enum parameter and no output schema, the description is nearly complete. It explains the purpose and gives a practical usage example (how to configure profile fonts). It does not detail the entire return format, but the mention of 'each record' implies an array of objects, which is sufficient for an agent to understand the tool's output and use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines `platform` with an enum of windows/macos/linux, but the description does little to explain the parameter beyond saying 'given OS'. It implicitly maps platform to OS, but does not elaborate on each value or how the choice affects results. Since schema coverage is 0%, the description should compensate more, but the enum is self-explanatory and the parameter is simple, so the gap is minor.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List font families that genuinely exist on the given OS.' It specifies the resource (font families) and the scope (OS-dependent), distinguishing it from sibling list tools like list_statuses or list_profiles. The verb 'list' is specific and matches the tool name, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by explaining how to apply the results: 'extract just the `font` property... set that as `fonts`, and set `fontsMode` to `manual`.' This tells the agent when to use the tool (when configuring profile fonts) and how to process the output. It does not explicitly mention alternatives or when not to use it, but no direct alternative exists among siblings, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool modifies the running desktop app state by storing a JWT and validating it, going beyond annotations which only indicate a mutation. It also reveals the fallback-to-server-token behavior, providing useful context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that front-load the core action ('Store... and validate it') and add only the essential default behavior. Every word contributes, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter, no output schema, and straightforward behavior, the description covers the purpose, the side effect, and the parameter default. It could mention that this authentication is a prerequisite for some local operations, but the title and context make that reasonably clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the token parameter with its fallback behavior ('Falls back to the server's DOLPHIN_API_TOKEN'). The description reiterates this fallback but adds no new semantic detail, so it stays at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('store' and 'validate') and names the exact resource ('remote JWT inside the running Dolphin{anty} desktop app'). It clearly distinguishes this tool from all sibling tools, none of which perform authentication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear usage context by stating the default behavior ('Defaults to the token this server is configured with') and implies the tool is for authenticating the local API. It does not explicitly list exclusions or alternatives, but no sibling tool competes for this role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: it reveals the dual attach/detach behavior and that detaching removes from the current folder. It does not contradict annotations (readOnlyHint=false, destructiveHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that front-loads the core action ('Attach profiles to a folder') and then adds the detach exception. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema, the description and schema together cover the main operation, attach/detach logic, and the optional password. Missing details like error behavior or what happens if folderId is invalid but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (folderId and password have descriptions). The description adds 'Omit folderId to detach,' but this is already in the schema. profileIds lacks description, but its meaning is self-evident from the name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool attaches profiles to a folder or detaches them, with a specific verb+resource. It distinguishes from sibling folder tools by focusing on the move/attach/detach action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Omit folderId to detach' clarifies when to use the detach behavior. However, it does not name alternative tools or provide exclusion criteria beyond attach/detach.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide generic hints (readOnlyHint=false, openWorldHint=true, destructiveHint=false). The description adds useful context: it creates a fresh data directory, uses default fingerprint preferences, returns a profileId, and does not persist the session. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the key action and outcome, then adds the usage context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately simple and has no output schema, but the description adequately mentions the return value (profileId) and the core behavior. It could delve deeper into lifecycle details (e.g., whether the profile is automatically deleted), but overall it is sufficient for an agent to understand the tool's purpose and basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already includes descriptions for 3 of 5 parameters (dpr, headless, automation), covering 60%. The description itself adds no parameter-specific semantics, but the schema covers the majority. The remaining parameters (screenWidth/screenHeight) are self-explanatory from their names and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Launch a throwaway profile') and the resource (a temporary profile with a fresh data directory and default fingerprint preferences). It also distinguishes this from sibling tools like start_profile by emphasizing the temporary, non-persisted nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it is 'Useful for one-off sessions you do not want persisted in the workspace,' giving clear context on when to use it. However, it does not explicitly name alternatives or state when not to use it, so it falls just short of full guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the operation is graceful, syncs data, and reports success even if the browser already exited. This complements the annotations (idempotentHint=true, destructiveHint=false) by adding specific behavioral context about the stop process. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and clear scope. Every phrase adds value: 'gracefully', 'sync its data directory back to the cloud', and 'safe to call when the browser has already exited'. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and full annotation coverage, the description answers key questions: what it does, when it is safe, and what to expect. It could mention the hard-stop risk of retryToStop, but that is covered in the input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for all 4 parameters, so the description does not need to add parameter details. It adds no extra meaning beyond the schema, and the baseline for full schema coverage is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('stop') and identifies the resource ('running profile') plus a key side effect ('sync its data directory back to the cloud'). It clearly distinguishes from related tools (start_profile, stop_cookie_robot) by focusing on graceful profile termination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use the tool: to gracefully stop a profile and sync data, and it is safe even if the browser has already exited. However, it does not explicitly discuss alternatives or when not to use it (e.g., vs. hard stop via retryToStop), leaving some decision-making to the parameter descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a significant backend quirk: false success when the recipient email does not exist. It also adds the permission requirement. While destructiveHint is already in annotations, the quirk adds valuable behavioral context beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences: one for the action, one for the prerequisite, and one for the critical quirk. No filler, and the most important operational warning is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers permissions, the false-success quirk, and the transfer action. It does not describe the return value, but there is no output schema. Missing details about proxy movement behavior are already in the schema, so overall it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, so parameters are mostly described in the schema. The tool description mentions 'by email' which aligns with the username parameter, but it does not add new meaning to ids or withProxy beyond their existing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Move', the resource 'profiles', and the target 'another Dolphin{anty} account by email'. This distinguishes it from sibling tools like delete_profiles (delete) and share_profile_access (share, not transfer).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states a prerequisite: 'You must own the profiles or hold the `share` permission.' It does not explicitly mention alternatives or when not to use, but the purpose is clear enough that it is likely the correct tool for transferring ownership.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate that the tool is not read-only (readOnlyHint: false) and not destructive (destructiveHint: false). The description adds that it modifies the name and colour, but does not disclose side effects, required permissions, or behavior on invalid id. This is adequate given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action. There is no fluff or repetition, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with 3 parameters, no output schema, and existing annotations, the description is mostly complete. It clearly states what changes can be made. It could mention that 'id' is required or what happens if the status does not exist, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by mapping 'name' to 'rename' and 'color' to 'badge colour', which helps understand the intended use. However, it does not mention the required 'id' parameter or any constraints, but the schema provides types and enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Rename a status or change its badge colour.' This uses specific verbs and identifies the resource (status) and the attributes it modifies (name, badge colour). It distinguishes from siblings like list_statuses, create_status, and delete_statuses by specifying the update operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need to rename a status or change its badge colour. It does not explicitly state exclusions or alternatives, but the context of sibling tools makes it clear this is only for updating existing statuses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a critical non-obvious behavior: the connection is made by the Dolphin app on the client machine, not by this server. This goes beyond the annotations (readOnlyHint=false, destructiveHint=false) and tells the agent that no connectivity testing or external connection is performed here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: the first states the action and purpose, the second prevents a common misconception about server involvement. No verbose or redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core function and the most important behavioral caveat, making it sufficient for an agent to understand the tool's role. Some details such as return values, uniqueness behavior, and validation are not mentioned, but for a simple creation tool with a moderately detailed schema, this is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level information. Schema coverage is only 43%, and fields like login, password, port, and type lack descriptions in both the schema and the description. Since the description does not compensate for the low schema coverage, this dimension is weak.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Save') and resource ('a proxy') and explains the purpose ('so it can be attached to profiles'). This clearly distinguishes the tool from siblings like update_proxy or delete_proxy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by indicating the saved proxy is for later attachment to profiles, and explicitly clarifies that the server does not make the connection, setting expectations for when this tool is appropriate. It doesn't explicitly name alternatives like update_proxy, but the context is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive behavior and idempotency, but the description adds crucial context beyond that: profiles referencing the proxy are left without one. This discloses a concrete side effect that an agent must know, enhancing transparency beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that immediately state the purpose and the key side effect. Every word earns its place; there is no fluff or redundancy, and the action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter delete tool with strong annotations (destructive, idempotent), the description covers the essential purpose and an important consequence on profiles. It doesn't mention error behaviors or return values, but these are not required for such a straightforward operation, making it adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter (id) with 0% description coverage, and the tool description does not explain the parameter's meaning or format. While the parameter is implicitly the proxy identifier from the tool name, the description fails to compensate for the lack of schema documentation, leaving the agent to infer semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove a saved proxy') with a specific verb and resource, distinguishing it from sibling tools like create_proxy or update_proxy. It adds a valuable behavioral note that profiles referencing the proxy are left without one, clarifying the scope and impact beyond a simple deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool by indicating the consequence for profiles that reference the proxy. It does not explicitly mention alternatives or exclusions, but the context is sufficient for an agent to decide to use it when a proxy should be permanently removed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds the key behavioral trait of cursor pagination and tells how to carry the cursor, which goes beyond annotations. It does not disclose the full response shape or pagination edge cases, but the added cursor behavior is valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, with the main purpose front-loaded. Every word earns its place, and the usage instruction is packed into the second sentence without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and 9 parameters, the description provides the most critical context: when to use the tool and how to handle pagination via `cursor`. However, it does not mention how to use `prev_page_url`/`previous_page` for backward pagination, nor does it describe the response structure beyond `next_page_url`. It is adequate for the primary use case but leaves some edge cases unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 22% (cursor and previous_page have descriptions). The description clarifies that `cursor` comes from `next_page_url` and says to keep other parameters identical, which partially compensates for the cursor parameter. However, it does not explain the meaning of tags, limit, order, query, sortBy, folders, statuses, or previous_page beyond what the schema already provides, leaving the majority of parameters under-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cursor-paginated profile listing', which is a specific verb+resource combination. It explicitly distinguishes itself from `list_profiles` by saying to prefer it over that sibling when walking a large workspace, so it is well differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: prefer this tool over `list_profiles` for large workspaces, and instructs exactly how to paginate (pass the `cursor` from `next_page_url`, keep other parameters identical). This is clear when-to-use and how-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and open-world behavior, and the description adds valuable specifics: 'synthetic events dispatched from here behave differently from real input and some sites notice.' This goes beyond the generic annotation flags and provides a concrete behavioral caveat. It also frames the tool as an 'escape hatch,' implying it bypasses normal accessibility paths.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action, then usage alternatives, then a behavioral caveat. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, nested object, no output schema), the description covers purpose, alternatives, and a key behavioral risk. The return type is mentioned ('return the result as JSON'). It could potentially note error behavior or async support, but current coverage is strong for a browser automation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already explains all parameters including target, expression, tabIndex, and profileId. The description adds no new parameter-level semantics beyond what's in the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Evaluate an expression in page context and return the result as JSON.' It clearly establishes the tool as an escape hatch for reading values the accessibility tree does not expose, distinguishing it from sibling tools like browser_snapshot and browser_click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to prefer alternatives: 'Prefer browser_snapshot for reading structure and browser_click for interacting.' Also warns about the nuance of synthetic events, giving clear context for when this tool is appropriate versus when it is not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds valuable context by disclosing that this tool 'costs far more context' than browser_snapshot — a behavioral trait about resource usage not captured in annotations. While it doesn't detail return format, the cost disclosure and use-case framing add meaningful transparency beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence states the purpose, the second provides usage context and a cost warning. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a nested target object and no output schema, the description supplies strong selection guidance and cost context. It doesn't explain the return format, but the tool's purpose (screenshot as image) makes it inferable, and the rich schema covers invocation details. The description is complete enough for correct tool selection and basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents every parameter (format, target, quality, fullPage, tabIndex, profileId) with descriptions. The tool description itself adds no new parameter-level detail, so it meets the baseline but doesn't exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Capture the page as an image' — a specific verb and resource that unambiguously states the tool's function. It also distinguishes itself from the sibling browser_snapshot by emphasizing that it is for visual rendering when a text tree is insufficient, making its role clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with browser_snapshot and provides clear when-to-use guidance: use it only when visual rendering matters, with concrete examples (layout problems, canvas, captcha-like elements). It also warns about the cost, effectively telling the agent to prefer the cheaper alternative when possible.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds valuable behavioral context: the output is compact, text-only, and represents the accessibility tree with role/name pairs that directly feed into click/type targets. This goes beyond the annotations by clarifying the output format and integration with other tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action ('Read the page as an accessibility tree') and every phrase adds value—defining output, stating preference over screenshot, and noting compatibility with click/type. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description conveys the essential return type (accessibility tree text) and how it fits into the browser tool ecosystem. It doesn't mention the target parameter for subtree snapshots, but that is fully covered by the input schema, so overall completeness is good for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all parameters. The description adds minimal extra parameter meaning by linking role/name pairs to browser_click and browser_type targets, but it doesn't significantly expand beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the page as an accessibility tree with roles, accessible names, and structure. It distinguishes itself from browser_screenshot by being the primary text-only way to see a page, and the mention of role/name pairs for browser_click and browser_type adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives guidance to prefer this tool over browser_screenshot unless visual rendering is needed. It also explains that the output's role/name pairs are exactly what browser_click and browser_type take as targets, making the use case and alternatives clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the readOnlyHint annotation, including the requirement for cloud sync, paid plan status, and the empty array return behavior for never-synced profiles. It also clarifies that no desktop app is required, which is not disclosed by annotations. This is rich, useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and method. Every sentence adds value: the first explains what and how, the second covers prerequisites and an edge case. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two parameters and no output schema, the description covers the core purpose, prerequisites, and return behavior (empty array). It doesn't describe the cookie format, but for this type of tool that's not critical. The sibling context differentiates the tool adequately. A small gap is the lack of explicit error conditions (e.g., if cloud sync is disabled), but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, with only browserProfilePassword having a description. The tool description does not elaborate on the parameters. However, the parameter names are self-explanatory ('browserProfileId', 'browserProfilePassword'), and 'password only if profile is password-protected' is provided in the schema. The description adds no extra parameter semantics, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a profile's cookies via the remote sync API, which is a specific verb and resource. It distinguishes itself from sibling tools like export_cookies_local by explicitly mentioning 'remote sync API' and 'no desktop app required', making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear conditions for use: profile must have cloud sync enabled and it is a paid-plan feature. It also notes that an empty array is returned if the profile has never synced. While it doesn't explicitly name alternative tools like export_cookies_local, the 'remote sync API' implies when this tool is appropriate, and the prerequisites serve as usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a significant side effect—writing a dolphin-anty-cookies-<name>-<id>.txt file per profile to the Downloads folder—which goes beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false). It also notes the dependency on the running desktop app. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, side effect, and usage guidance. Each sentence adds essential information without redundancy or fluff, and the most important info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters (one enum) and no output schema, the description covers the core behavior, side effects, and alternative choice. It lacks explicit return value details, but given the straightforward 'export' purpose, it is sufficiently complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'browserProfiles' parameters by explaining that 'name' and 'id' are used in the output file name. However, the 'plan' parameter is not mentioned at all, and schema description coverage is 0%, so the description only partially compensates for the lack of parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: 'Export cookies for one or more profiles through the running desktop app.' It uses a specific verb ('Export') and resource ('cookies for profiles'), and immediately distinguishes itself from the sibling 'export_cookies' by noting the local API and the file side effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided in the final sentence: 'Prefer `export_cookies` unless you need that file or the profile is not cloud-synced.' This clearly tells the agent when to choose this tool over the alternative and under what conditions it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, but the description adds valuable non-obvious behavioral guidance about keeping WebGL1 and WebGL2 data in sync. This is exactly the kind of behavioral trait that goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with the first stating purpose and the second providing crucial usage guidance. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and key behavioral rule, and annotations handle safety. However, it omits explanation of browser_version and the return format (no output schema), which leaves some gaps for a 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for withMaximum (webgl2Maximum block) and implicitly for platform ('available for a platform'), but browser_version is entirely unexplained. With schema description coverage at only 33%, the description should compensate more for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states a specific verb ('List') and resource ('GPU adapter combinations') with scope ('for a platform'). It distinguishes from sibling list tools by focusing on WebGL vendor/renderer pairs, and the title reinforces this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context and a concrete usage rule: 'When swapping these into a fingerprint, always copy the vendor/renderer pair together...' This implies a fingerprint-customization use case. However, it does not mention alternatives or explicitly state when not to use this tool vs. get_fingerprint or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as a non-read-only, non-destructive, open-world operation. The description adds valuable behavioral detail beyond the annotations: the requirement that all permission flags must be true when action is 'remove'. This non-obvious API quirk is exactly the kind of transparency that helps agents avoid mistakes. It doesn't cover every side effect, but the openWorldHint is supplemented with a concrete caveat.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose, and the second sentence provides a necessary caveat without any fluff. Every word contributes to understanding, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and is a mutation, but the description covers the core behavior well, including the crucial action='remove' nuance. It lacks information about return values, whether calls are additive or replacing, or prerequisite permissions, but the openWorldHint and non-destructive annotation mitigate some of that. Given the tool's relative simplicity, this is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for 'ids' and 'users' (and 'usage' within the user object), yielding 67% coverage. The description enriches the 'action' parameter semantics by explaining the special meaning of 'remove' and the flag condition. This goes beyond the schema's enum to clarify real-world behavior, but it doesn't explain the individual permission flags (view/share/delete/update) beyond what the schema gives.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Grant or revoke') directly tied to a resource ('per-user permissions across one or more profiles'), making the tool's function immediately clear. It distinguishes itself from sibling profile tools by focusing on permission management rather than profile properties, creation, or transfer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool (when granting or revoking profile access) by stating its exact function, and it provides a critical usage rule for the 'remove' action. However, it does not explicitly mention alternatives or state when not to use this tool, so it stops short of the highest score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds that the browser continues running, which explains the non-destructive nature beyond annotations. It does not detail edge cases like in-flight automation, but the provided context is sufficient for the intended use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The main action is front-loaded, and the contrast with stop_profile adds critical context in the second sentence. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, side-effect-moderate tool with no output schema, the description is complete. It explains what the tool does, what it does not do, and how it differs from the sibling that closes the browser.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the parameter with a clear description ('Browser profile id, as passed to start_profile'). The tool description adds no further parameter information, but the schema already provides adequate meaning; baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb and resource: 'Release the automation connection.' It clearly differentiates from sibling stop_profile by noting the browser keeps running, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with stop_profile: 'use stop_profile to actually close it and sync its data directory back to the cloud.' This tells the agent exactly when to use this tool vs. the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (readOnlyHint=true, openWorldHint=true) and adds context that these are 'custom status labels for tagging profiles,' implying a lightweight read operation. It doesn't detail return format or ordering, but with no parameters and only a list, this is acceptable. The semantic distinction of 'custom' versus system statuses is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It uses parallel structure with the title and immediately communicates the action and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool, the description is sufficient. It explains both the resource (custom status labels) and purpose (tagging profiles), which is all the context needed. The lack of an output schema is acceptable since no parameter guidance is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description doesn't need to explain any. It clearly states the output is the list of status labels. Since there is no parameter schema to augment, the description fully conveys what the invocation entails.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clearly specifies the resource: 'custom status labels available for tagging profiles.' This differentiates it from sibling tools like create_status, update_status, and assign_status, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While no explicit exclusions or alternative tools are named, the description clearly implies a read-only lookup for statuses. The context of sibling tools (e.g., create_status, delete_statuses) establishes when this list is useful. No parameters are needed, so usage context is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses that the tool replaces the existing value by default, supports pressEnter, and explains the difference between fill and press modes (one-shot vs real per-key events). This adds behavioral depth beyond the annotations, which only indicate read/write/destructive hints. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and every phrase adds value (behavior, mode selection, specific use cases). No fluff or redundant repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 9 parameters and nested objects, the schema covers most details, and the description addresses the key behavioral variations. No output schema exists, but the description doesn't need to explain return values for an action like typing. Slightly missing explicit guidance on target selection, but the schema compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (89%), so the description doesn't need to explain every parameter. It adds valuable context for `mode` (when to use 'press') and `pressEnter`, augmenting the schema's definition. This justifies a score above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (enter text) and the resources (input, textarea, contenteditable), distinguishing it from sibling tools like browser_click or browser_press_key. It also mentions key behaviors like replacing existing value and optional submission via pressEnter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use press mode (pages that listen for keydown, autocompletes, search-as-you-type) and mentions pressEnter for submission. It does not explicitly name alternative tools or exclusion criteria, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the critical behavior that the backend ignores a nested 'fingerprint' object and requires flattened top-level keys, which is not apparent from the annotations or schema. It also explains the merging semantics between 'common' and per-item values. While it does not mention error handling or side effects, the disclosed behaviors are significant and exceed what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and immediately followed by the most important caveat. Every sentence earns its place, condensing significant detail (flattened key list, merge precedence, contrast with sibling) into a compact, scannable format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a bulk creation tool with open-ended schemas (additionalProperties: true) and no output schema, the description is fairly complete: it explains the main gotcha (flattened fingerprint keys), the 'common' merge mechanism, and provides a partial list of valid keys. It lacks information about request limits, validation errors, or response format, but these are partially covered by the absence of output schema and the open-world hint, making the description adequate for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 100% of parameters, providing baseline meaning for 'items' and 'common'. The description adds semantic value by elaborating on the 'common' merge behavior and specifying that fingerprint data must be flattened top-level keys, which is beyond the schema's generic 'additionalProperties' allowance. This helps the agent understand the intended structure more precisely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create many profiles in one call' which clearly identifies the action (create), the resource (profiles), and the bulk nature. It explicitly contrasts with 'create_profile' by highlighting the fingerprint nesting difference, thus distinguishing it from the sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names the alternative tool (create_profile) and explains a critical difference in how fingerprint data must be supplied, guiding the user to this tool for bulk creation. It also provides usage guidance on using 'common' for shared values and the precedence rule, which helps decide when to use this tool and how to structure input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the call is 'unvalidated' and lacks the safety of typed tools, adding behavioral context beyond the annotations (readOnlyHint: false, openWorldHint: true). It also explains query serialization style and target-specific URL hosts, which are useful non-obvious behaviors. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose statement, a bullet list for target selection, and a concise note on query style. Every sentence earns its place, and the most important guidance is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic raw API tool, it covers the essential context: what it does, when to use it, how to choose targets, and query serialization behavior. It does not explicitly mention return format or error handling, but given no output schema and the raw call nature, the description is sufficiently complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (40%), but the description compensates by explaining the critical `target` parameter (host mapping) and clarifying `query` array joining with commas. These details add meaning beyond the schema's enum and object definitions, though body and path remain generic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'raw, unvalidated call to the Dolphin{anty} API' and contrasts with dedicated typed tools, making its purpose and distinctiveness from siblings unambiguous. The specific verb 'call' plus the resource 'API' defines the action precisely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to 'Use this only when no dedicated tool fits' and explains that typed tools carry validation and API-specific guidance. It also provides a clear mapping of target values to hosts, so an agent knows exactly when and how to select the correct endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only (readOnlyHint=false) and has open-world side effects (openWorldHint=true). The description adds valuable behavior: it only accepts public extensions, rejects private/unpublished ones, and enforces specific URL prefixes. It doesn't detail side effects or error behavior, but given the simple create action and existing annotations, this is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the primary purpose, then constraints, then the alternative. Every sentence adds essential information without fluff. Structure is easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, no output schema), the description covers the essential usage context: what it does, what inputs are valid, and what other tool to use for alternative input formats. It is a complete, self-contained guide for this operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 67% of parameters, with only 'url' lacking a description. The description compensates by specifying valid URL patterns and rejection criteria for the url parameter, adding meaning beyond the schema's 'format: uri'. The other parameters (mainWebsite, sharedToEntireTeam) are already described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Add'), the resource ('public Chrome Web Store extension'), and the purpose ('so it can be attached to profiles'). It distinguishes from sibling tools like list_extensions and delete_extensions by specifying the action and the source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use this tool vs. alternatives: 'To add a packed .zip instead, use dolphin_request against /extensions/upload-zipped (multipart).' It also gives usage constraints (URL must be a public Chrome Web Store link, private/unpublished are rejected), which helps the agent decide if this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses that the tool brings the browser to the front, tells the operator what to do, blocks until the challenge clears or timeoutSeconds elapses, returns a fresh snapshot, and requires headed mode. It also warns about profile flagging. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core purpose, followed by use cases, a critical warning, mechanics, and a prerequisite. Every sentence adds unique information, and there is no padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description covers the essential operational context: when to invoke it, what it does, how it behaves, what the operator sees, return behavior, and prerequisites. Schema fills the remaining param details. The description is fully sufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds contextual meaning to timeoutSeconds and reason (operator message) but does not deeply elaborate each parameter. It meets the baseline without adding substantial value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb+resource ('Hand control to a person and wait') and immediately enumerates concrete use cases (CAPTCHA, Cloudflare check, login wall, 2FA/OTP, SMS, payment). It distinguishes itself from the sibling browser_wait_for by explicitly stating it is for human-required actions and warns against attempting to solve CAPTCHAs automatically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance with a concrete list of scenarios, and when-not-to-use by instructing not to try solving CAPTCHAs automatically. It also clarifies the headless requirement, giving clear exclusions and prerequisites. This is exemplary usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses nuanced deletion behavior: paid plans default to moving to the Basket, forceDelete makes it permanent, and Free plans require forceDelete. This goes beyond the annotations' destructiveHint and adds significant context about reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences, front-loaded with the core purpose followed by key conditions. No redundant wording or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and moderate complexity, the description covers the critical behaviors (Basket, forceDelete, password constraint) and the annotations cover safety. It might have mentioned prerequisites like stopping running profiles, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only documents forceDelete, leaving ids and browserProfilePassword undescribed. The description compensates by explaining the 'one or more' semantic for ids and the password constraint, plus reinforcing forceDelete's permanence and plan requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Delete one or more profiles,' using a specific verb and resource that clearly distinguishes it from sibling delete tools like delete_proxy or delete_folder. It also clarifies the plural nature of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear conditional guidance: forceDelete is mandatory on Free plans, and browserProfilePassword is only accepted for a single password-protected profile. However, it does not explicitly compare with alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behavioral details: visits URLs in a short-lived browser, saves cookies, runs sequentially, and importantly that progress is reported via Socket.IO but the server does not subscribe, so the call returns immediately after starting. This goes significantly beyond the annotations (readOnlyHint=false, openWorldHint=true) by explaining the async fire-and-forget nature and requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences with no fluff. Each sentence earns its place: purpose, execution order, and async/requirements. The format is highly scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with this complexity, it covers purpose, execution model, prerequisites (paid plans, desktop app), and return behavior (returns immediately). The lack of an output schema is compensated by clarifying that progress is not tracked by this server, so the agent knows not to expect completion status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 60% of parameters. The description adds context for browserProfileId ('that profile') and data ('a list of URLs'), reinforcing their roles. It does not add new information for browserProfilePassword or headless/imageless beyond what the schema already states, but the overall meaning is clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: warming up a profile by visiting URLs and saving resulting cookies. It distinguishes this from related cookie tools (export_cookies, import_cookies) and browser automation tools by specifying 'short-lived browser' and 'saving every resulting cookie to that profile'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: 'Warm up a profile' and notes sequential execution, paid plans, and desktop app requirement. However, it doesn't explicitly compare with alternatives like export_cookies or start_profile, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals several critical behaviors beyond annotations: default auto-fetching of a coherent Dolphin fingerprint, refusal of duplicate names unless allowDuplicateName is true, and the serious pitfall that a nested fingerprint object produces a profile that cannot be read or started. This is valuable context that prevents misuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place. It is front-loaded with purpose, then differences from siblings, then critical warnings and implementation details. Nothing is redundant and the structure flows logically.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's core purpose, sibling differentiation, duplicate-name handling, and the fingerprint shape trap in depth. It does not explicitly mention return values or that the created profile is not automatically started, but given the detailed schema and the presence of separate start tools, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds deep meaning for key parameters: fingerprint must be flattened into the profile's field shape, browserVersion only matters when auto-fetching, and allowDuplicateName prevents unintended duplicates. Schema coverage is 79% and these insights go beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a NEW browser profile' with a specific verb and resource. It also explicitly distinguishes itself from start_profile, which opens/runs an existing profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-not guidance: if the user wants to open/run/spin up a named profile, that is start_profile, not this tool. It also warns about data loss when creating a lookalike and suggests alternatives like passing a fingerprint from get_fingerprint or setting autoFingerprint to false.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description discloses a key edge case: empty object with HTTP 200 when no match. It also explains the behavioral requirement of internal consistency and the anti-fraud consequence of editing, adding valuable non-obvious context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The first states the core action, the second provides usage and edge-case info. Every sentence is informative and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description effectively covers the tool's main purpose, the critical usage instruction (verbatim pass-through), and the failure mode. The read-only nature is already in annotations, and the edge case is explicitly noted, making the description complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, with screen and browser_version already described. The description adds that the params act as filters, clarifying the role of the optional inputs. While it doesn't detail each param, it provides enough context to understand the filtering behavior, adding modest value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool samples a real-world fingerprint from the Dolphin dataset, using a specific verb and resource. It also differentiates from siblings like get_useragent and list_webgl by explicitly tying the output to create_profile, making its purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance: pass the returned object verbatim as create_profile's fingerprint. It also warns against editing values piecemeal, which instructs on proper usage and what to avoid. This directly tells the agent how to use the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations already signaling mutation (readOnlyHint false), the description adds significant operational context: it requires a running desktop app, automation is unavailable on the Free plan with HTTP 402, and stop_profile syncs the data directory back to cloud. It also warns that a new profile lacks the original's cookies, logins, or history.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and organized into three dense paragraphs. Every sentence earns its place: purpose, exclusion, workflow, and prerequisite. There is no filler or repetition of schema-only details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 11 parameters and no output schema, the description provides enough context for correct invocation: what the tool does, when to use it, how to avoid confusion with create_profile, how to chain automation/stop_profile, and the required runtime environment. This is highly complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents 82% of parameters, so the baseline is 3. The description adds cross-parameter guidance on choosing between `name` and `browserProfileId` and clarifies that `name` is resolved to an id while warning against creating a new profile for a user-given name. This is useful semantics beyond the individual schema entries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Launch an EXISTING browser profile' and explicitly maps the tool to natural-language requests like 'open/run/spin up <profile>'. It differentiates itself from create_profile by warning 'Never route a named profile to create_profile', making the tool's unique role clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance ('the tool for open/run/spin up <profile>'), an explicit exclusion ('Never route a named profile to create_profile'), and a workflow ('Pass automation: true ... then stop_profile'). It also states the prerequisite that the Dolphin{anty} desktop app must be running.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![DolphinMCP MCP server](https://glama.ai/mcp/servers/someorgyouwontcareabout/DolphinMCP/badges/card.svg)](https://glama.ai/mcp/servers/someorgyouwontcareabout/DolphinMCP)

Score Badge

Copy to your README.md:

[![DolphinMCP MCP server](https://glama.ai/mcp/servers/someorgyouwontcareabout/DolphinMCP/badges/score.svg)](https://glama.ai/mcp/servers/someorgyouwontcareabout/DolphinMCP)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/someorgyouwontcareabout/DolphinMCP'

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