NexBrowser MCP Server

Official

by nex-browser

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v2026.8.20
Disambiguation4/5
Most tools have clear, distinct purposes (e.g., nex_browser_click vs nex_browser_type vs nex_browser_fill_form). Some potential overlap exists between nex_browser_run_code and nex_browser_evaluate, and between nex_proxy_create and nex_proxy_batch_create, but descriptions clarify the differences (permissions, batch vs single).
Naming Consistency4/5
Tools follow a consistent nex_<domain>_<verb> pattern (e.g., nex_browser_list, nex_proxy_create, nex_account_delete). Minor deviations like nex_browser_connection_info and nex_browser_network_requests use noun phrases instead of verb_noun, but the pattern is largely predictable.
Tool Count2/5
64 tools is excessive for a browser automation server, even with proxy and account management. Many tools are granular (e.g., key_down, key_up, check, uncheck, select_option) and could be consolidated. This exceeds the typical well-scoped range and risks agent confusion.
Completeness5/5
The tool surface covers the full lifecycle: window creation, opening, connecting, navigation, interaction, form filling, screenshots, network/console inspection, proxy management, account management, and group management. No obvious dead ends; workflows like create window -> bind proxy -> open -> connect -> interact -> close are fully supported.
Average 3.5/5 across 64 of 64 tools scored. Lowest: 1.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- Last stable release on August 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Navigated forward' only reports an outcome and provides no details about behavior, failure conditions, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It lacks sufficient content to be useful, so it cannot earn a higher score.
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?
This is a simple tool, yet the description fails to explain its purpose, behavior, or output. With no output schema, the description should provide more context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (pageId, sessionId) are already documented. The description adds no parameter information, but the schema covers all semantics, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Navigated forward' is a past-tense statement that merely restates the tool's name. It doesn't explicitly say the tool moves forward in browser history, and it fails to distinguish from the sibling tool go_back.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like go_back or navigate. There is no context about browser history or forward navigation applicability.
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 declare readOnlyHint=true, covering the safety profile, but the description adds no further behavioral context. It does not disclose return format, error behavior, or how the URL is resolved, though it does not contradict the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified, providing no actionable insight. Over-brevity at the expense of clarity is not effective conciseness.
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 no output schema and no meaningful description, the agent cannot determine what the tool returns (likely a URL string, but not stated) or how it fits among 50+ sibling tools. It is minimally viable at best.
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 100% with clear descriptions for both pageId and sessionId, so the description is not required to explain parameters. It adds no extra meaning, but the schema handles the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Page URL.' is essentially a restatement of the tool name, lacking a verb and any indication of what action it performs or what it returns. It does not distinguish from sibling tools like nex_browser_page_title or nex_browser_connection_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool vs alternatives, no mention of the default pageId/sessionId behavior, and no comparison with similar page-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but 'Navigated back' only states a result. It does not explain browser history interactions, what happens with empty history, or side effects on page state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but brevity here is under-specification rather than conciseness. A single vague phrase does not earn its place as a tool definition.
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?
As a navigation tool with no annotations or output schema, the description is critically incomplete. It provides no context about prerequisites, behavior with no history, or interaction with the current active page.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both optional parameters with defaults, so the description need not restate them. However, the description adds no semantic context about how pageId/sessionId affect the back navigation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Navigated back' is essentially a past-tense restatement of the tool name, not a clear purpose statement. It fails to specify that this goes to the previous page in browser history or to distinguish from nex_browser_go_forward and nex_browser_navigate.
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 usage guidance is provided. There is no indication of when to use this tool versus go_forward or navigate, nor any mention of history stack requirements or fallback behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, 'Page reloaded.' tells the agent nothing about what happens upon invocation—whether it reloads the current page, discards unsaved changes, requires network, or returns a confirmation. There is virtually no behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It lacks essential information and reads as a status message rather than a tool description. Front-loading is irrelevant when the content is nearly empty.
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?
For a simple reload action, a minimal description could still be complete if it clearly stated 'Reloads the page.' However, 'Page reloaded.' is a past-tense statement that does not even confirm the tool's action, nor does it explain behavior, return value, or any caveats. With no output schema and no annotations, this is grossly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (pageId and sessionId) with descriptions, and the schema description coverage is 100%. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Page reloaded.' is a statement of completion rather than a clear imperative describing what the tool does. It essentially restates the tool name (reload) in past tense, providing no detail on scope or effect, and does not distinguish from sibling navigation tools like go_back or navigate.
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?
There is no guidance on when to use this tool versus alternatives such as go_back, go_forward, or navigate. The description offers no context, prerequisites, or exclusions, leaving the agent without direction on selecting this tool appropriately.
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 annotation readOnlyHint=true already signals a safe read operation, but the description adds no behavioral context. It does not disclose what is returned, whether the page must be loaded, or any potential failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At two words, the description is under-specified rather than concise. It fails to convey necessary information and does not earn its place as a helpful tool description.
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 simple getter, the lack of an output schema and the absence of any explanation about the return value or behavioral constraints make the description incomplete. A minimal phrase like 'Gets the title of the specified page' would be needed.
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%, with both parameters (pageId, sessionId) clearly described in the input schema. The description itself adds no parameter information, but the schema carries the full burden, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Page title." is a noun phrase that essentially restates the tool name without a verb or action. It does not clearly state that it retrieves the page title, nor does it distinguish from siblings like nex_browser_get_text or nex_browser_page_url.
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. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer the tool's purpose purely from the name.
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 `destructiveHint: true` annotation is the only behavioral signal. The description adds no further context about what happens when an environment is closed—whether sessions are terminated, proxies unbound, or state lost. It merely restates the operation without revealing consequences beyond the annotation.
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?
A single, front-loaded sentence with no filler. It states the core purpose efficiently, though the brevity comes at the cost of behavioral and contextual details.
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 destructive tool with no output schema, the definition is under-specified. An agent is left without knowledge of return values, error behavior, or the precise effects of closing an environment. The unresolved `teamId` parameter and lack of alternative guidance further reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level information. The schema partially documents `ids` and `windowId` as aliases, but `teamId` remains undefined in both schema and description. The relationship between the three parameters is ambiguous, and the description doesn't clarify which should be used or how they interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Close') and the resource ('one or more NexBrowser environments'). It is specific enough to convey that this tool shuts down entire browser environments rather than individual tabs, though it doesn't explicitly differentiate itself from sibling `nex_browser_tab_close`.
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?
There is no guidance on when to use this tool versus alternatives like `nex_browser_tab_close` or `nex_browser_disconnect`. The description gives no context about scenarios where closing an environment is appropriate, nor does it mention prerequisites or side conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions the action and target scope but does not explain event dispatch, focus handling, modifier support, or side effects. This is a significant gap for a keyboard interaction tool.
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, making it efficient. However, it is under-specified; while brevity is good, the sentence could earn its place by including more operational detail without becoming verbose.
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 tool with 4 parameters and no output schema or annotations, this description is insufficient. It does not explain return values, prerequisites, or how to construct the 'key' value. The agent is left without critical contextual information needed for reliable invocation.
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 coverage is 75% (3 of 4 parameters documented), but the required 'key' parameter lacks a schema description and the tool description does not clarify it either. The description adds no extra meaning beyond what the schema already provides, failing to compensate for the undocumented key parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Press a key') and the target scope ('selected page or focused element'). However, it does not explicitly differentiate itself from sibling tools like nex_browser_key_down or nex_browser_key_up, which are equally plausible for keyboard interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as nex_browser_type or nex_browser_key_down/up. There are no explicit context cues or exclusions, leaving the agent to infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the core action. It does not reveal side effects, requirements (e.g., element visibility), failure behavior, or whether the action is reversible. This is a complete lack of behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that requires no extra words. It is appropriately sized for the simplicity of the operation, earning top marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple interaction with no output schema or annotations, the description should still offer more context about the operation's effects or limitations. It only states the action, leaving out whether it waits for actionability, modifies page state, or returns any confirmation. The context is incomplete.
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% parameter descriptions, so the schema already covers parameter semantics. The description adds no additional insight into parameters, keeping the score at the baseline of 3.
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 'Uncheck a checkbox or radio control' clearly identifies the action and target resource. However, it does not explicitly differentiate from the sibling tool `nex_browser_check`, which performs the opposite action, so it misses the full sibling differentiation criterion.
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. There is no mention of `nex_browser_check` or any other context, exclusions, or prerequisites, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not specify what happens on timeout (error vs. return), how multiple conditions (target, text, time) are combined, or whether the operation is read-only. This is a significant gap.
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, front-loaded sentence with no fluff. It is concise and easy to parse, though slightly under-specified. It earns its place but could include more detail without losing conciseness.
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 tool with six optional parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, failure behavior, condition precedence, or the relationship between 'time' and 'timeout'. An agent would have to infer important behavioral details.
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 50%, and the tool description does not compensate. It mentions 'target, text, or bounded duration' but does not disambiguate the 'time' vs 'timeout' parameters or explain the semantics of 'text' and 'target' in practical terms. The meaning of these parameters remains ambiguous.
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 uses a specific verb ('Wait') and names target, text, and bounded duration, clearly distinguishing it from sibling browser actions like click or navigate. It lacks a bit of specificity about what 'target' and 'text' refer to, but the core purpose is understandable.
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. It does not mention suitable scenarios (e.g., after navigation or before clicking) or exclude cases where other tools (such as explicit waits in code) are preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden. It discloses that permission must be enabled, but does not mention whether evaluation can mutate page state, what the return value looks like, or what happens if permission 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?
A single sentence with no filler. The permission qualifier adds relevant context and the statement is appropriately front-loaded and efficient.
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 tool that executes arbitrary JavaScript, the description is under-specified: it omits return behavior, side effects, and relationship to the similar run_code tool. The existing schema and absence of output schema leave too many unanswered questions for reliable invocation.
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 describes pageId and sessionId, but the required expression parameter has no description, and the tool description does not clarify its syntax or role beyond 'Evaluate JavaScript.' The minimal description adds little meaning beyond the schema fields.
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 identifies the action as evaluating JavaScript and notes a permission prerequisite. However, it does not specify that evaluation occurs in the browser page or distinguish this from the sibling nex_browser_run_code, which likely performs a similar action.
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 phrase 'when the dedicated evaluate permission is enabled' gives a precondition but offers no guidance on when to prefer this tool over nex_browser_run_code or when not to use it. No alternatives or contextual triggers are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'sequential key events', which hints at character-by-character typing, but does not disclose whether existing text is replaced, how delay affects behavior, potential side effects, or failure modes. This is a mutation with insufficient disclosure.
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 and resource. Every word is informative with no filler or 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?
For a 5-parameter tool with no output schema, the description is minimal. It does not explain return behavior, prerequisites, or how the target element is resolved. Given the many sibling tools, more context is needed to use it correctly.
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 covers 60% of parameters with descriptions, but the tool description adds no meaning beyond the schema. The 'text' and 'delay' parameters lack descriptions in the schema and are not clarified in the description, leaving their semantics ambiguous.
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 uses a specific verb 'Type' and names the resource 'element', plus the method 'sequential key events'. It clearly states the core action but does not distinguish from siblings like fill_form or press_key, which also involve entering text or keys.
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 such as fill_form, press_key, or fill_account. The description implies typing into an element but offers no exclusions or context on which scenario is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It states that the tool 'checks' a control, but it does not mention whether the action waits for element stability, what happens if the control is already checked, or whether it triggers events. This is minimal behavioral disclosure for a UI automation action.
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, front-loaded sentence with no wasted words. It is concise and readable, although it is terse enough that it may under-specify behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple action and full schema coverage, the description is minimally adequate but leaves out behavioral nuances that could matter for correct use, such as whether it only works on visible/enabled controls or how it reports errors. With no output schema and no annotations, a bit more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description adds no parameter-specific meaning beyond the schema; it does not clarify the 'target' format or default behavior of 'pageId' and 'sessionId', but the schema already covers those. Baseline 3 is appropriate.
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 uses a specific verb ('Check') and resource ('checkbox or radio control'), making the tool's purpose immediately clear. It does not explicitly distinguish from sibling tools like nex_browser_click or nex_browser_uncheck, but the resource constraint provides some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as nex_browser_click or nex_browser_uncheck. The description implies it is for checking checkbox/radio controls, but it does not state exclusions, prerequisites, or how to decide among similar interaction tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no additional behavioral details, the description does not disclose what 'drag' entails (e.g., simulated mouse events, prerequisites, side effects). The agent is left without information about the operation's mechanics or consequences.
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, focused sentence with no redundant words. It is highly concise and front-loaded with the action and key targets.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, no output schema, and the simplicity of the description, the tool lacks essential context such as how drag interacts with the page, what trigger conditions exist, or what the return value might be. The description is too sparse for a real-world browser drag operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 4 parameters with clear descriptions, providing 100% coverage. The tool description adds no extra semantic meaning beyond what the schema already states, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Drag') and the resources ('one snapshot ref or selector to another'), making the core purpose obvious. It distinguishes from click/hover/type tools, though it doesn't clarify its relationship with the sibling 'nex_browser_drop'.
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 nex_browser_drop or other interaction tools. The description only states what it does, not the contexts in which it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits on its own. It fails to explain what 'approved files' means, whether drop triggers native drag-and-drop events or just sets data, how MIME-typed data is formatted, or any side effects on the page. The agent cannot predict what happens after invoking this tool.
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, front-loaded sentence with no wasted words. It could have been structured to include examples or a brief usage scenario without becoming verbose. Still, it is concise and easy to read, though it sacrifices helpful detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, a nested object, and no output schema, this description is far too thin. It does not explain how the data/paths parameters interplay, what happens on success or failure, whether an element must be visible/enabled, or how to reference the target reliably. An agent operating on a live browser would need more context to use this tool correctly and safely.
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 covers 60% of parameters with descriptions, so the description's compensation requirement is moderate. The description adds some meaning: 'files' maps to 'paths' and 'MIME-typed text data' maps to the 'data' object, and 'target' is clearly the drop receiver. However, it does not explain how 'data' should be structured (property names, values) or how 'paths' are treated, leaving ambiguity for the two underlying payload parameters.
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 uses a specific verb 'drop' and identifies the resource ('target'), and mentions two distinct payload types (files, MIME-typed text data). It is clear enough to distinguish from siblings like nex_browser_file_upload (which likely uploads via a file picker) and nex_browser_drag (which drags UI elements). However, 'approved' is vague and could confuse an agent about whether some pre-authorization is required.
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 about when to use this tool compared to alternatives such as nex_browser_file_upload, nex_browser_drag, or nex_browser_fill_form. The description does not state whether it simulates native drag-and-drop events, whether it works on all selectable targets, or any prerequisites. The agent is left to infer usage from the verb and parameter names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only reveals that filling happens 'in order,' but does not state whether it replaces existing values, waits for visibility, or handles missing elements. This is insufficient for a mutation-oriented tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every word contributes meaning: 'one or more' establishes cardinality, 'form controls' specifies the resource, and 'in order' conveys behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and the presence of many similar sibling tools, this description is incomplete. It does not explain what happens after filling, how the tool behaves relative to other form-related tools, or any prerequisites. The description alone would not allow an agent to confidently invoke this tool without additional assumptions.
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 target, pageId, and sessionId (67% coverage), so the description does not need to explain those. However, the description adds that the order of the fields array matters ('in order'), which is beyond the schema. It does not elaborate on the 'value' parameter, but its meaning is obvious from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fill') and resource ('form controls'), and adds scope ('one or more') and sequencing ('in order'). This clearly distinguishes it from generic tools like nex_browser_type or nex_browser_click, though it could more explicitly contrast with fill_credentials or fill_account.
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. There is no mention of use cases, prerequisites, or exclusions. Given the sibling list includes several related form-action tools (type, fill_credentials, select_option, check), this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a permission requirement, but running JavaScript can be destructive and may have side effects; the description does not mention return values, whether the operation is safe/read-only, or potential risks. This is a significant gap for a code execution tool.
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 sentence with no wasted words. It is concise, but it is also under-specified in content. Still, for length and front-loading, it is effective.
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 3 parameters, no output schema, and no annotations. It executes arbitrary page JavaScript, a powerful operation. The description only notes the permission requirement and fails to explain return behavior, side effects, or prerequisites beyond the permission. This is incomplete for the importance and complexity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for pageId and sessionId, but the required 'code' parameter has no description. The description only says 'Run page JavaScript', which weakly implies the code is JavaScript but does not clarify format, size limits, or execution context. Schema coverage is 67%, but the description adds little meaningful parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run page JavaScript') and a specific condition (when the separate runCode permission is enabled). However, it does not differentiate from sibling tool 'nex_browser_evaluate', which likely also executes code, so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by requiring a specific permission ('when the separate runCode permission is enabled'), but it does not mention when not to use it or provide alternatives such as 'nex_browser_evaluate'. The usage context is partially clear but no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It doesn't disclose whether existing selections are overwritten, whether it triggers change events, or how it handles invalid values. With no side-effect details, behavioral transparency is low.
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 immediately communicates the tool's purpose. It is concise and well-structured with no wasted words.
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 description is insufficient for a browser automation tool. It doesn't mention behaviors like single-select vs multi-select handling, whether it clears previous selections, or what happens if the target isn't a select element. No output schema exists, so the description should compensate.
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% with detailed descriptions for target and values. The description adds minimal meaning beyond the schema, only clarifying that values are for a select control. Baseline 3 is appropriate since schema does the heavy lifting.
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 selects one or more values in a select control, which is a specific action and resource. It distinguishes from sibling tools like check/uncheck (checkboxes) and type (text inputs), though it doesn't explicitly mention the browser context.
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 provided on when to use this tool versus alternatives. It doesn't mention that this is for HTML select elements or how it differs from clicking or typing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavior. It states 'Read' suggesting read-only, but the 'clear' parameter hints at a destructive operation that is not disclosed. There is no mention of buffer consumption, pagination, or scope of requests captured.
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 filler, efficiently stating the core purpose. It is 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 tool with 3 parameters, no annotations, no output schema, and a sibling with a similar name, the description is too brief. It omits clarity on the clear parameter, return format, and how it differs from the singular variant.
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 already describes pageId and sessionId, but the 'clear' parameter has no description and the tool description does not explain it. The description adds no value to parameter understanding, failing to compensate for the undocumented clear parameter.
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 reads network requests buffered by the automation session, using a specific verb and resource. However, it does not differentiate from the sibling tool 'nex_browser_network_request' (singular), which could cause confusion.
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 viewing buffered network requests but provides no explicit guidance on when to prefer this over related tools like the singular network_request or console_messages. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'select a tab.' It does not state what selecting entails, whether it affects the active tab, what happens if the page ID is invalid, or whether it has side effects. The one-liner provides minimal behavioral 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 a single, concise sentence that is front-loaded with the operation and resource. It contains no wasted words and is easy to scan.
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 simple selection tool, the description is extremely minimal. It lacks context about the active session, return value, or relationship to other browser operations. Given the absence of an output schema and annotations, the description does not provide enough information for an agent to fully understand the tool's role and outcomes.
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 only describes sessionId, leaving pageId undocumented. The description adds the phrase 'stable page ID' but does not explain where to obtain a page ID or what makes it stable. With 50% schema coverage, the description compensates inadequately for the missing 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 action (select), the resource (tab), and the key identifier (stable page ID). It unambiguously distinguishes this from sibling tools like tab_list, tab_new, and tab_close by indicating selection as the specific operation.
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. It does not mention prerequisites (e.g., obtaining a page ID from tab_list) or indicate that selection is needed before other interactions. The lack of usage context forces the agent to infer the appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a non-destructive read, but the presence of a 'clear' parameter suggests a side effect that is not disclosed. There is also no information about buffer lifecycle, message types, or whether reading consumes messages.
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 concise and to the point. It conveys the core purpose without unnecessary words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool, the description is minimally viable but leaves gaps: it does not explain what 'console messages' includes (e.g., logs, errors, warnings), what happens when 'clear' is set, or the return format. These gaps are notable since there is no output schema and no annotations to fall back on.
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 documents pageId and sessionId with brief descriptions, but the 'clear' parameter has no description. The tool description does not compensate for this gap, leaving the semantics of the clear parameter unclear and the overall parameter guidance incomplete.
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 ('Read') and the resource ('console messages buffered by this automation session'), making it distinct from sibling tools like network_requests or page_title. It identifies both the verb and the object precisely.
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. There is no mention of exclusions, prerequisites, or situations where another tool (e.g., network_requests or evaluate) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the basic action and gives no information about permission checks, what 'approved' means, side effects, or return behavior. Significant gaps remain.
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 essential idea without wasted words. It is appropriately concise for a simple tool.
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 performs a mutating action with no annotations, no output schema, and incomplete explanation of key aspects like 'approved files' and file path semantics. The description is too sparse to fully guide correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so the schema already documents most parameters. The description adds no parameter-level detail beyond the schema, but the baseline of 3 is appropriate given high 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 action (Upload), the resource (approved local files), and the mechanism (through a file input target). It is specific enough to distinguish from all sibling browser automation tools, none of which mention file upload.
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 about when to use this tool versus alternatives. The description implies usage for file uploads but does not state preconditions, exclusions, or alternative tools. 'Approved local files' hints at a prerequisite but is vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states 'Hover over an element.' It provides no details on side effects, visibility requirements, or event triggering. This leaves the agent uninformed about hover behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant information, making it highly concise and front-loaded.
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 simple hover action, the description is extremely bare. It lacks any context about when to use this tool, what happens after hover, or how it relates to other interaction tools. The schema covers parameters well, but the description itself is insufficient for an agent to make an informed choice.
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 100% with descriptive parameter definitions for target, pageId, and sessionId. The description adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Hover over an element' uses a specific verb and resource, clearly indicating the action. It distinguishes itself from sibling tools like click, type, and drag since no other tool performs hover.
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 hover versus alternatives like click or wait_for. The description does not mention any prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects, safety, and persistence of the resize operation. It only restates the tool's purpose, offering no additional behavioral context such as whether the page reloads, whether the resize is temporary, or if it affects the session/profile.
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 unnecessary words. It immediately conveys the core action, making it highly efficient.
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, a one-liner might be sufficient, but with no output schema and no annotations, the description should at least hint at return behavior or error conditions. It is minimally adequate for a basic operation but leaves gaps about what the caller receives after invocation.
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 already describes pageId and sessionId (50% coverage), but width and height lack descriptions beyond numeric bounds. The tool description adds no meaning to these parameters, failing to clarify units (e.g., pixels), typical ranges, or how they relate to the viewport.
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 'Resize the active page viewport' clearly identifies the verb (resize) and resource (active page viewport). It is distinct from sibling tools like navigate, scroll, or tab management, leaving no ambiguity about its function.
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, nor any prerequisites such as requiring an active page or a valid viewport. The description only states what it does, not the conditions under which it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions the two primary actions (list vs. accept/dismiss) but leaves important details unclear, such as what happens if both accept and dismiss are set, whether id is required to target a specific dialog, how promptText is used, and what listing returns. This is a significant gap for a tool that can mutate browser state.
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 redundant words. It efficiently communicates the core functionality while remaining easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six parameters, no output schema, and no annotations, the description is too brief to support correct invocation. It omits how the list and accept/dismiss modes interact, what the list operation returns, and how parameters behave in edge cases. The description would be insufficient for an agent to confidently use the tool in real scenarios.
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. The property names (id, accept, dismiss, promptText) are somewhat intuitive, but the description does not explain their meaning, relationships, or defaults. An agent cannot determine safe combinations of parameters without additional information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs: 'list', 'accept', and 'dismiss' applied to 'dialogs'. It distinguishes itself from sibling tools by focusing on dialog handling, a unique capability among the listed browser control tools.
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 usage context is implied: it should be used when there are pending dialogs to handle. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or mention any related tools that might be better suited in certain scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose that the image content is returned only 'when it is small enough,' which is useful, but it does not specify the size threshold, what happens when the screenshot is too large (e.g., saved to file, error), or other 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?
A single sentence that is concise and front-loaded with the main action. Every word earns its place, including the important size-related caveat. No filler or 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?
For a tool with 6 optional parameters, no output schema, and no annotations, this description is too sparse. It leaves open critical details: what the returned MCP image content looks like, behavior when the screenshot is too large, how parameters like fullPage or quality affect results, and what filename is used. The caveat 'small enough' raises more questions than it answers.
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% (2 of 6 parameters have descriptions), and the tool description adds no parameter semantics. It does not explain 'type', 'quality', 'fullPage', or 'filename', nor how they affect the output. With such low coverage, 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?
The description uses the specific verb 'Capture' with the concrete resource 'screenshot', and explicitly states the return behavior ('return MCP image content when it is small enough'). This clearly distinguishes it from sibling tools like snapshot, page_url, or get_text.
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 gives no guidance on when to use this tool versus alternatives such as nex_browser_snapshot or other inspection tools. The caveat 'when it is small enough' implies a limitation but does not suggest what to use instead for large screenshots, nor any context like 'use for visual verification'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the action without detailing side effects (e.g., sends a keyup event), behavior when the key is not held, or scoping to a page/session. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of one concise sentence with no redundant information. It is front-loaded and every word earns its place, achieving maximum conciseness.
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 is simple, but given no annotations and no output schema, the description should cover prerequisites (must be preceded by key_down), relation to press_key, and state implications. The description only provides minimal context, leaving the agent to infer critical usage details.
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% (pageId and sessionId have descriptions), but the required 'key' parameter lacks a description. The tool's description adds minimal semantic meaning by implying the key is the one to release, but it does not clarify the expected format or consistency with key_down.
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 specifies the action ('Release') and the resource ('a keyboard key held by nex_browser_key_down'). It distinguishes itself from sibling tools by explicitly referencing its complementary counterpart, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after nex_browser_key_down but provides no explicit guidance on when to use this tool versus alternatives like nex_browser_press_key. It does not state exclusions or prerequisites, leaving the conditions for use implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: password and 2FA secret are write-only and never returned, which is important for an agent to know. However, with no annotations provided, the description carries the full burden and still does not explain return values, error behavior, whether changes are reversible, or what happens when the account does not exist.
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 core action and scope are front-loaded, and the write-only warning earns its place as essential behavioral information.
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?
This is a mutation tool with 9 parameters, no annotations, and no output schema, yet the description is quite sparse. It omits return value expectations, failure modes, and explanations for several parameters, leaving an agent with significant gaps when deciding how to invoke the tool correctly.
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 44%, and the description does not compensate for the undocumented parameters such as teamId, username, platformUrl, platformName, or remark. It repeats the write-only nature of password and key2fa already present in the schema, but adds no new meaning for the remaining parameters beyond the general instruction to pass only changed fields.
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 ('Update'), a specific resource ('one platform account'), and a scope ('workspace catalog'), which clearly distinguishes it from sibling tools like nex_account_create, nex_account_delete, and nex_account_list. The phrase 'Pass only the fields that must change' further clarifies the update semantics.
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 modifying an existing account rather than creating or deleting one, and it gives invocation guidance ('Pass only the fields that must change'). However, it never explicitly states when to prefer this tool over alternatives such as nex_account_create or nex_account_delete, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the full transparency burden. It discloses one key behavioral trait (does not close the environment) but omits details such as whether the session can be reconnected, what happens to running automation, or the effect of omitting sessionId. This is adequate but minimal.
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, well-structured sentence that front-loads the action and includes the key qualifier. No wasted words; every phrase adds value.
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 one optional parameter, no annotations, and no output schema, so the description is the sole source of guidance. It explains the core action but leaves out essential information about sessionId usage, preconditions, and post-disconnect state, making it incomplete for an agent to invoke confidently.
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%, yet the description does not mention the sessionId parameter at all. It provides no guidance on what sessionId refers to, whether it is required, or what happens if omitted. The description completely fails to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Disconnect') and resource ('automation session') and clearly distinguishes the tool from its sibling nex_close_browsers by stating it does not close the NexBrowser environment. This is a precise, non-tautological description.
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 phrase 'without closing the NexBrowser environment' provides clear context for when to use this tool relative to closing the environment, implying a distinction from nex_close_browsers. However, it does not explicitly name alternatives or state exclusions, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does disclose a key behavioral nuance ('optionally bringing a target into view first'), which adds value. However, it doesn't mention what happens when both target and delta values are supplied, whether the scroll is instant or animated, or any side effects. The description adds some transparency but remains thin for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the primary action ('Scroll the page'), and every word adds meaning. There is no fluff, repetition, or irrelevant detail. It is appropriately concise for a simple tool.
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 5 parameters, no annotations, and no output schema, so the description must compensate for these gaps. It doesn't explain how the parameters interact (e.g., whether target overrides delta, or if both can be used together), what the return value is, or what error conditions may arise (e.g., target not found). The description is too terse to fully contextualize the tool for an agent.
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 coverage is 60% (3 of 5 parameters have descriptions), and the description helps explain 'target' by linking it to the 'bring into view' behavior. However, the two core delta parameters (deltaX, deltaY) are completely undocumented in both the schema and the description. The description provides no insight into their semantics (e.g., pixels, relative vs absolute), so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Scroll') and resource ('the page'), and clearly distinguishes this from all sibling tools (none of which are scroll-focused). It also mentions the optional target-bringing behavior, which helps define its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/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 (whenever scrolling is needed) but provides no explicit guidance on when not to use it or alternatives. For example, it doesn't mention that intense scrolling could be done via evaluate/run_code, or that cursor-based actions like click/hover are unrelated. The usage context is clear but exclusions are not 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?
The annotation destructiveHint: true already signals that this operation is destructive. The description adds the qualifier 'stable' to page ID, which provides context about the nature of the identifier. However, it does not disclose any additional behavioral traits such as side effects on the browser session or what happens when closing the last tab. The description is consistent with annotations, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the essential action and required parameter without any wasted words. It is extremely concise 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?
For a destructive tool with no output schema, the description is minimally sufficient: it states the action and the primary parameter. However, it lacks context such as how to get a valid page ID, potential errors, or behavior when the tab is the last one. The presence of sibling tools like tab_list partially mitigates this, but the description itself does not reference them.
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 describes sessionId but leaves pageId undocumented (50% coverage). The description clarifies that pageId is a 'stable' identifier, adding meaning beyond the plain 'string' type. However, it doesn't explain where to obtain the page ID or the relationship between pageId and sessionId, so it only partially compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Close'), the target resource ('a tab'), and the method ('by stable page ID'). It distinguishes from sibling tools like nex_browser_close (which likely closes the entire browser) and tab management tools (tab_new, tab_select).
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 does not mention when to use nex_browser_close instead, nor any prerequisites like needing to obtain the page ID from tab_list. There is no implied context beyond the basic 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 provide readOnlyHint=true, so safety is known. The description adds the context of 'automation session' and the concept of an 'active stable page ID' as output, but does not disclose error behavior or session requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence with no fluff. It front-loads the verb and key outputs, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one optional parameter and no output schema, the description is adequate but not fully complete. It doesn't describe the structure of the returned tab list or what 'stable page ID' means, which could be important 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 coverage is 100% and the only parameter (sessionId) has a clear schema description. The tool description adds no additional parameter detail, so the baseline of 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 uses the specific verb 'List' and clearly identifies the resource: tabs and the active stable page ID for an automation session. It distinguishes from sibling tools like tab_new, tab_select, and tab_close, and also from nex_browser_list which appears more generic.
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 explicit guidance is given on when to use this tool versus alternatives. While it implies usage for inspecting tabs in a session, it does not mention exclusions or compare with sibling listing tools like nex_browser_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the core action without disclosing side effects such as whether the new tab becomes active, return values, or session prerequisites.
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 primary action, with no wasted 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 tool with two optional parameters and no output schema, the description conveys the core behavior but lacks details about return values or session interactions. It is minimally adequate given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents sessionId with a description, and the description adds meaning for the url parameter by indicating it is an optional navigation target. However, it does not specify URL format or behavior when omitted.
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 ('Open') and resource ('new tab'), and adds the optional navigation scope, clearly distinguishing it from navigation-only tools like nex_browser_navigate.
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 context is implied: use when you need a new tab. However, there is no explicit guidance on when to prefer this over alternatives like nex_browser_open or nex_browser_navigate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly mentions that secrets are write-only and never returned, which is a valuable behavioral disclosure. However, it does not mention other behaviors such as partial success handling (e.g., if one item fails, do others still create?), idempotency, or rate limits. Given the batch nature and no annotations, more behavioral detail would be expected.
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 only two sentences, both informative and front-loaded with the core action. The first sentence states the purpose, the second adds a critical security caveat. It is concise without being under-specified, though it could make better use of space to mention usage guidelines.
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 batch creation tool with no output schema, the description covers the essential inputs and the write-only secret behavior, which is enough for a basic call. But it lacks information on what the tool returns (e.g., the created account IDs), error handling for partial failures, and whether the operation is atomic. Given the complexity of a batch operation and the absence of annotations, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters with descriptions. The description adds the crucial note that each item needs platformUrl (reinforcing a required field) and clarifies the write-only nature of secrets. It also mentions that the array accepts 'accounts or accountList' aliases, which is additional semantic value beyond the schema's basic description. However, it does not explain the meaning of other fields like teamId or remark beyond what the schema says, so the baseline is 3 with a slight bump for the alias note.
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 the specific action ('Create multiple platform accounts') and the resource ('from an items array'), clearly distinguishing it from the sibling nex_account_create which is singular. It also highlights that secrets are write-only, which is important 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?
The description implies the batch use case ('multiple platform accounts') and contrasts with the singular nex_account_create by its name. However, it does not explicitly state when to prefer this tool over nex_account_create or provide exclusions or prerequisites. The presence of nex_account_create as a sibling suggests an alternative, but no direct comparison is offered.
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 the description's 'Inspect' verb is consistent with that. The description adds useful context beyond the annotation by scoping to 'running' environments and clarifying the list-all behavior when windowId is omitted. It does not disclose what fields 'status' contains or behavior for invalid/non-running window IDs, but the annotation lowers 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?
Two sentences with zero waste. The primary purpose is front-loaded in the first sentence, and the second sentence delivers the single most important invocation detail. 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 read-only inspection tool with three optional parameters all documented in the schema, the description is largely sufficient. The main gap is the absence of an output schema combined with no description of what 'status' information is returned, which leaves the agent guessing about the response shape. Still, the tool name and description convey the essential semantics.
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 three parameters (ids, teamId, windowId) are already documented in the schema. The description's 'Omit windowId to list every running window' largely restates the schema's windowId description rather than adding new meaning. Baseline 3 is appropriate since the schema carries the parameter documentation burden.
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 a specific verb ('Inspect') and resource ('status of running NexBrowser environments'), making the tool's core function clear. It does not explicitly differentiate from close siblings like nex_browser_list or nex_browser_tab_list, but the 'status of running environments' framing is specific enough to convey what it does.
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 gives invocation guidance ('Omit windowId to list every running window'), which helps the agent use the tool correctly. However, it provides no when-to-use vs. alternative guidance, no exclusions, and no mention of when a sibling like nex_browser_list would be more appropriate. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Because there are no annotations, the description correctly carries the behavioral burden. It discloses that auth fields are optional and write-only, that creating accounts does not fill a login form, and that items creates several accounts. It does not mention duplicate/conflict outcomes, but the main side-effect boundary is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences with no fluff. Each sentence earns its place: scope, optional fields and write-only constraints, and what the check tool is not doing. The content is easy to scan and act on.
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 write operation with one required parameter, the description is mostly complete and gives the key distinction from form-filling. But it lacks any indication of the return value, failure behavior, or relationship to the very close `nex_account_batch_create` sibling, making it not fully sufficient for reliable selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 75% schema coverage, the schema already documents most parameters. The description adds a useful interpretive layer: platformUrl is required, credentials are optional and write-only, and `items` enables one-call bulk creation. However, it does not explain `teamId`, `remark`, or `platformName`, so those remain unexplained for an agent.
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?
States a concrete action: 'Create one platform account in the workspace catalog...', which gives both verb and resource. It also clarifies it is not a form-filling tool. However, it never distinguishes itself from the similarly named sibling `nex_account_batch_create`, so sibling differentiation is incomplete.
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 makes the general use case clear: creating accounts in the catalog, and the login-form exclusion adds a small when-not signal. But it provides no explicit guidance about when to use `items` versus `nex_account_batch_create`, or how this differs from account modify/delete/fill tools, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action, offering no details about side effects (e.g., page state changes), waiting behavior, error handling if the element is not found, or whether it scrolls into view. For a browser automation click, these are important traits that remain undisclosed.
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 filler words. It is front-loaded with the action verb and immediately specifies the target. Every word earns its place, making it an excellent example of concise, effective description.
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 click tool with no output schema and no annotations, the description provides the essential purpose but lacks critical context such as return value, error behavior, or reactivity to page changes. It is minimally viable but leaves several behavioral questions unanswered, particularly about what happens after a click or if the element is not actionable.
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 60% (3 of 5 parameters described). The description adds some value by mentioning 'latest snapshot or CSS selector' which aligns with the target parameter, and 'Click or double-click' hints at the doubleClick parameter. However, it does not elaborate on button or pageId/sessionId beyond the schema, leaving those partially covered. It does not fully compensate for the gap but is not entirely silent.
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 ('Click or double-click') and the target resource ('an element from the latest snapshot or a CSS selector'). It uses a specific verb and resource, and it is distinct from sibling tools like hover, type, or drag. This is a textbook clear 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 provides clear context: use this tool when you need to click an element. It does not explicitly name alternatives or when-not scenarios, but the verb 'click' inherently signals the appropriate use case. There are no misleading or ambiguous instructions, so it earns credit for clear context even without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns a refreshed accessibility snapshot after navigating, which is useful. However, it does not clarify whether it waits for full page load, how it handles invalid URLs, or whether the current page context is preserved. The lack of such behavioral details prevents a higher score, but the description is not misleading.
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 filler words: 'Navigate the selected page and return its refreshed accessibility snapshot.' It front-loads the action and outcome, and every phrase earns its place. Excellent conciseness.
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, so the sole mention of 'accessibility snapshot' is the only return-value information. It does not describe the snapshot structure or mention loading behavior, but given the simplicity of the navigate action and the sibling tools context, it is minimally complete. More detail on return format or side effects would make it stronger.
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 pageId and sessionId described in the schema. The description does not add meaning to the url parameter beyond implying it is the destination URL. It does not explain URL format requirements or defaults, but the parameter names are self-explanatory. The description adds minimal value over the schema, so a mid-range score 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 uses the specific verb 'Navigate' with the resource 'selected page' and states the outcome 'return its refreshed accessibility snapshot.' This clearly distinguishes it from sibling tools like nex_browser_reload or nex_browser_go_back, which serve different navigation actions. The purpose 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 the tool is used when you need to point the current selected page at a new URL and get the updated snapshot, but it does not explicitly state when to use it versus alternatives such as nex_browser_open or nex_browser_tab_new. There are no exclusions or alternative suggestions, leaving the agent to infer usage from the tool name and position among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already covers safety. The description adds the fact that the request is 'buffered' and uses 1-based indexing, but it does not explain how the buffer is populated, whether requests are captured by default, or what happens for out-of-range indices.
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 immediately conveys the action, target, and indexing scheme. No filler words; every element 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 lack of an output schema, the description should hint at the return format, but it does not. It also omits any mention of prerequisites (e.g., whether the browser session must be in a network-recording state). For a simple read tool, this is a moderate gap.
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 explicitly states that the required 'index' is 1-based, which adds crucial meaning beyond the schema's minimum of 1 (which does not imply 1-based). The other parameters are already described in the schema, so this targeted addition is valuable.
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 ('Read') and resource ('buffered network request') and clarifies the access method ('by its 1-based index'). This clearly distinguishes it from the sibling tool 'nex_browser_network_requests' which lists all requests.
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 given on when to use this tool versus the plural 'nex_browser_network_requests'. The description does not mention that one might first list requests to get an index, which is a natural workflow and important for effective usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds that refs are 'short-lived'—a critical behavioral detail for agents to act promptly. It does not describe output format or other limitations, but the added ref-lifetime context earns credit.
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 conveys purpose and key behavior without redundancy. 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?
With no output schema, the description should explain what the snapshot contains and how to consume the refs. It implies an accessibility tree with actionable refs but does not specify return structure or integration with other tools, leaving the agent somewhat under-informed.
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 offers no parameter semantics. Schema coverage is only 60% (pageId, target, sessionId have descriptions; boxes and depth do not), and the description fails to compensate for the unexplained booleans/numeric 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 ('Capture') and clearly identifies the resource ('accessibility/ARIA snapshot') with a key differentiator ('actionable refs'). This distinguishes it from sibling tools like take_screenshot or get_text.
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 accessibility introspection and subsequent actions via refs, but does not explicitly state when to prefer this over alternatives or mention exclusions. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that credentials are never returned, which is a useful safety trait, but this is already stated in the schema for password and username. It does not mention partial failure behavior, validation errors, or whether creation is atomic. The added value beyond the schema is modest.
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 waste, front-loading the core action ('Create multiple custom proxy resources') and essential requirement ('host and port'). It is efficient and easy to scan.
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 batch operation with nested objects and no output schema, the description is incomplete. It does not explain what happens if some items are invalid, whether creation is all-or-nothing, or that the schema's items field description mentions it 'also accepts proxies or proxyList' (a behavioral nuance not reflected in the description). An agent would be left uncertain about error handling and alternative input shapes.
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 description coverage is 100% for the only parameter, and the schema provides full documentation for all sub-fields (host, port, protocol, etc.). The description's mention that each item needs host and port repeats the schema's required fields without adding new meaning. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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'), names the resource ('custom proxy resources'), and specifies the input ('items array') and the per-item requirement ('host and port'). This clearly distinguishes it from siblings like nex_proxy_create (single) and nex_proxy_import.
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 batch usage ('multiple') and that each item needs host and port, giving clear context. However, it does not explicitly state when to use this over nex_proxy_create (single) or nex_proxy_import, so it lacks an explicit when-not or alternative mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses that the tool creates an isolated automation session and defaults to the active team, but it does not describe side effects on existing connections, failure modes, or permission requirements. This provides some value but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with a clear purpose, and every word earns its place. No irrelevant 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 the main workflow and multi-window orchestration, but it does not mention return values, error conditions, or what happens if the window is not running. Since no output schema exists, the description should fill that gap to be more 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 covers teamId and startIfNeeded with descriptions, but windowId has no description and the description only mentions 'one window' indirectly. The multi-window workflow adds meaning to startIfNeeded, but the description does not significantly enhance parameter understanding 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 ('Connect to one NexBrowser window') and the outcome ('create an isolated automation session'). It distinguishes itself from sibling tools like nex_browser_open (which opens windows) and nex_browser_disconnect (which tears down sessions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use the active team by default and provides a precise multi-window procedure: call nex_browser_open once, then connect each window with startIfNeeded=false. This is concrete when-to-use guidance, though it does not mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds useful behavioral context beyond the bare action: names must be unique and the ungrouped bucket cannot be changed. However, it does not disclose response/return behavior, error conditions for duplicate names or invalid groupId, or whether workspace activation is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first sentence states the operation and scope, the second packs the critical constraints. Every clause earns its place and the action is 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?
This is adequate for a simple rename/reorder operation with a well-described schema, but it leaves gaps: no mention of return values or error behavior, no guidance on whether at least one of name/seq must be provided when groupId is given, and no explicit prerequisite about an active workspace beyond the phrase itself.
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 mainly echoes the schema's parameter descriptions (new unique name, new sort order, groupId 0 rejected) rather than adding new semantic meaning; it clarifies the ungrouped bucket but 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 states a specific action ('Rename or reorder') on a specific resource ('one custom window group'), with clear scope ('in the active NexBrowser workspace'). This distinguishes it from sibling tools like nex_browser_group_create/delete/move_to_group without needing to inspect schemas.
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 clearly frames when to use the tool: for renaming or reordering an existing custom window group. It also provides exclusions ('ungrouped bucket (groupId 0) cannot be changed') and a constraint ('names must stay unique'), but it does not explicitly name sibling alternatives or say when-not to use them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It states the tool 'Start[s] NexBrowser environments' and returns status, and reveal a batching/tiling behavior. However, it does not disclose prerequisites (e.g., whether target environments must already exist), side effects (e.g., whether existing sessions are affected), or error handling. The description is not contradictory but leaves significant 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 well-structured sentences with no fluff. The core purpose is front-loaded in the opening sentence, and the second sentence delivers a targeted usage guideline. Every word earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 params (one required), no output schema, and no annotations, the description is adequate but incomplete. It explains the main purpose and a key usage pattern, but fails to document the required teamId parameter, does not indicate where window IDs come from (e.g., from nex_browser_list), and lacks detail on the returned status format or failure behavior. These gaps are notable but not severe enough to render the description unusable.
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% (ids and windowId have descriptions; teamId does not). The description reinforces the windowId array usage and explains the benefit of batching, adding value beyond the schema's existing description. However, it entirely omits any explanation of the required teamId parameter, which the schema also lacks. The description does not fully compensate for the missing 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 states a clear action ('Start') and a specific resource ('NexBrowser environments'), and explicitly mentions the return of 'per-window status'. This distinguishes it from sibling tools like nex_browser_create (which likely creates new environments) and nex_browser_close (which stops them). The purpose 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance for multi-window tasks: 'pass every window ID in one windowId array so Desktop can batch-start and tile them before creating automation sessions.' This tells the agent how to batch requests effectively. However, it does not explicitly contrast with alternatives (e.g., calling individually, or when to use nex_browser_create), so it lacks full exclusionary 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 provide destructiveHint=true, so the agent already knows it is destructive. The description adds value by disclosing that bought channel proxies may be rejected by Desktop and that credentials are never returned. These are concrete behaviors beyond the annotation, improving 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 three concise sentences, each contributing distinct information: the core action, a caveat about bought proxies, and a note on credentials. It is front-loaded with the main purpose and avoids 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?
The description covers the primary function and adds a couple of cautions, but it omits details about return values, error handling, or whether deletion is permanent. With no output schema, agents may need to infer the response format. For a simple delete operation, this is adequate 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 100%, with each parameter described as an alias of proxyId. The tool description adds no additional parameter-specific meaning beyond the schema, which already explains that the parameters accept single IDs or lists. Baseline of 3 is appropriate given full 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 action (delete) and the resource (custom proxy resources) with a specific scope: 'Delete one or more custom proxy resources.' This distinguishes it from sibling tools like nex_proxy_create, nex_proxy_modify, and nex_proxy_list, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives or mention exclusions. Usage is implied by the delete intent, but there is no guidance on when not to use it or contextual conditions. The caution about 'Bought channel proxies may be rejected by Desktop' is a behavioral note, not usage 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?
With no annotations, the description carries the behavioral disclosure burden. It usefully states a PATCH-like update semantic and that credentials are never returned, which is valuable security behavior. It does not mention error behavior, idempotency, authorization requirements, or what happens if the resource does not exist.
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 filler. The action and resource are front-loaded, the partial-update behavior is stated next, and the credentials note provides value without 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?
The description covers the essential invocation semantics and a key security behavior. With 9 parameters and no output schema, more context could be given regarding expected return value, required identifier handling, and validation behavior. Nevertheless, the schema descriptions carry most of the parameter-level burden.
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 covers 78% of parameters with descriptions, but the description adds important update semantics by clarifying that only changed fields need to be passed. It does not, however, name individual parameters or explain the conceptual role of id/proxyId beyond the schema's field 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 states a clear verb ('Update'), a specific resource ('one existing custom proxy resource'), and a clear scope ('one'). This distinguishes it from the sibling tools that create, import, batch-create, delete, or detect proxies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit partial-update guidance: 'Pass only the fields that must change.' It also frames the target as 'existing,' implying this is not for creation. However, it does not explicitly list sibling alternatives or state when to choose this over create/delete.
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, so the safety profile is known. The description adds valuable context beyond that by explicitly stating it does not close windows or remove vault copies already stored in an open window. This gives the agent useful behavioral detail that annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant words. The primary action is front-loaded, and the clarifying caveat about side effects is essential and immediately follows. It earns its place without padding.
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 destructive operation, the description covers the scope (workspace catalog), explicit side-effect exclusions, and has a fully documented schema. No output schema exists, but for a deletion operation that is not a critical gap. The description is adequate for an agent to correctly invoke and understand the tool, though it does not mention return values or success indicators.
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 100% — every parameter is already described in the schema, including aliases like id, items, and accountIds. The description does not add meaningful detail beyond the schema; the phrase 'one or more platform accounts' aligns with the array support in the schema but adds little. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete'), a specific resource ('platform accounts from the workspace catalog'), and clearly distinguishes itself from sibling tools like create/modify/list. It also clarifies what the operation does NOT do, which further pins down 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it is to be used when deleting accounts from the workspace catalog. However, it does not explicitly mention when not to use it or point to alternatives. The note about not closing windows/vault copies is a side-effect clarification rather than usage guidance, so 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds a behavioral guarantee that 'Secrets are never returned.' It also clarifies the catalog vs. open-window vault distinction, which is a behavioral scoping. There is no contradiction with the annotation.
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 serving a distinct purpose: stating the primary action, routing away from a sibling, and reassuring about secrets. There is no fluff, and the key disambiguation is placed early.
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 sufficient for basic usage (calling with no parameters) and offers strong usage context, but it omits any explanation of how the parameters affect the result. Since there is no output schema, an agent cannot infer the return format beyond 'list of accounts with IDs.' This is a moderate gap for a tool with pagination and filtering options.
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 description contains zero information about any of the four parameters (page, size, teamId, keyword). Since schema coverage is 0%, the description must compensate for the missing parametric guidance, but it does not. An agent cannot know how to filter or paginate from this text.
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 starts with a clear verb and resource: 'List platform accounts in the workspace catalog.' It also states the intended usage ('so an accountId can be selected for window creation or later vault fill') and explicitly disambiguates from the sibling nex_browser_accounts, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance by contrasting with nex_browser_accounts: 'This is not the open-window vault; use nex_browser_accounts after a window is running.' This tells the agent exactly when to choose this tool over the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does convey the core stateful behavior: the key remains down until key_up is invoked. However, it lacks additional context such as whether the key repeat is enabled, how modifier keys are handled, or what happens if key_up is not called. This is minimal but not misleading.
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, clear sentence with no redundant wording. It immediately states the action and the end condition, making it easy to parse. 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?
For a simple stateful tool with three parameters and no output schema, the description is mostly complete. It explains the hold-until-release behavior and names the release tool. However, it omits any details about key naming conventions and potential errors, which would be useful for the agent, but given the simplicity, it remains 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%, meaning pageId and sessionId are documented in the schema, but the required 'key' parameter has no description. The tool description adds no information about what key values are accepted (e.g., 'A', 'Shift', 'ArrowUp'). Since the description does not compensate for the missing key semantics, the score stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: holding a keyboard key down. It explicitly links to the counterpart nex_browser_key_up, distinguishing it from press_key or type, which involve different key interactions. The verb 'hold' and the resource 'keyboard key' make 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 clearly implies when to use this tool: to press and hold a key until later released. It also references the complementary tool (nex_browser_key_up) that must be called to release the key, providing essential usage context. However, it does not explicitly mention alternatives like press_key for quick presses or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states credentials are never returned, but this is already repeated in the schema's 'Write-only; never returned' property descriptions. It does not mention permissions, reversibility, failure behavior, or return format. The credential warning adds no new information beyond the schema, leaving the description inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with the primary action front-loaded, followed by a routing hint. No fluff or repetition; every word earns its place.
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 8 parameters, two usage modes, and no output schema. The description omits what the tool returns on success (e.g., created proxy objects), any preconditions (authentication, API limits), and error behavior. Given the complexity and lack of annotations, this is a significant completeness gap. The description does not fully prepare an agent to call it safely and interpret results.
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 (88%), but the description clarifies the key relationship: single creation via protocol/host/port versus bulk creation via items. This adds semantic meaning beyond individual property descriptions by explaining how parameters combine, which is valuable for correct invocation.
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 creates one or multiple proxy resources from host/port and optional protocol. It explicitly names the sibling tool nex_proxy_import as the alternative for Desktop-compatible lines, making the purpose and scope 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?
Provides explicit when-to-use guidance: prefer nex_proxy_import for pasted Desktop-compatible lines, implying this tool is for custom/structured input. This distinction helps an agent choose correctly without extra inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It adds useful details like supported protocols and that credentials are never returned, but it does not explain whether the import persists, replaces existing proxies, or how malformed lines are handled. These are noticeable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the main action, and every sentence provides relevant information. There is no fluff or 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?
Combined with a very rich schema, the description covers the main purpose, source, supported protocols, and a key credential-safety behavior. It lacks a statement about persistence/failure effects, but the context is enough for an agent to understand when to invoke this 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 defines both parameters in detail. The tool description only reinforces the idea of importing text lines; it does not add additional semantic meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states a specific action ('Import custom proxy resources') with a precise source ('Desktop-compatible text lines the user supplied in the current request'). Supported protocols are named, and the tool is immediately distinguishable from siblings like nex_proxy_list and nex_browser_bind_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?
The description gives clear usage context: use it when the user supplies Desktop-compatible proxy lines in the current request. It does not explicitly mention alternatives or when not to use it, but the intended scenario is obvious enough to guide selection among the sibling tools.
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 meaningful behavioral context by specifying what the tool lists and what it explicitly never reports. This goes beyond the annotation, providing clarity on scope without contradicting the read-only hint.
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, efficiently front-loaded with the tool's preferred status and primary purpose, followed by necessary exclusions. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and a simple parameter set, the description clearly communicates what the tool does and what it excludes, which is sufficient for a list operation. It does not describe return format, but the core purpose and constraints are well covered.
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 20% (only groupId has a description), and the tool description adds no explanation of page, size, teamId, or keyword parameters. The description does not compensate for the schema's limited information, leaving agents 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 managed NexBrowser environments/profiles' and uses a specific verb 'lists' with a resource. It distinguishes itself from siblings by explicitly excluding other browser types and tabs, and positions itself as the preferred tool for showing/counting windows.
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 for when to use the tool ('Preferred NexBrowser OpenAPI tool for requests such as...') and outlines explicit exclusions (never reports Chrome, Edge, Codex in-app browser, OS windows, or tabs). It doesn't name alternative tools directly, but the behavioral scope suffices to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a non-mutating operation, and the description reinforces this with the visible safety note that 'Credentials are never returned'. It also clarifies the operation is scoped to the active Nex roser workspace, which is relevant context beyond the annotation alone.
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 core purpose is front-loaded, and the security-related caveat about credentials is added as a single clean second sentence.
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?
Because it is a read-only listing tool with no required parameters, the description is mostly sufficient for a correct invocation. Missing contextual detail includes what the returned proxy objects look like and how the filter parameters affect results, but the absence is mitigated by the clearly stated selection purpose and the readOnly annotation.
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 description coverage is only 20%, so the description should compensate by explaining the five parameters. It does not explain page, size, source, or keyword at all, and the only parameter given useful schema-level text is state. The description focuses on the tool purpose but leaves a low-coverage parameter surface essentially undocumented.
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 ('List'), a clear resource ('proxy resources available in the active NexBrowser workspace'), and the actionable purpose of selecting a proxyId for window creation or binding. This fee distinct from the proxy mutation tools like nex_proxy_import, nex_proxy_create, and nex_proxy_delete. An agent can instantly know what the tool returns and why it exists.
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 concrete use case: 'so a proxyId can be selected for window creation or binding'. It also implies that this is the place to look for existing proxyId candidates rather than creating or importing proxies. It does not formerly enumerate exclusions or alternatives, but's unthed expectations are clear.
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 annotations declare destructiveHint=true, and the description adds meaningful behavioral context beyond that: it explicitly states that running windows are rejected, that windows must be closed first, and that proxyId=0 removes the binding. This gives an agent the key operational constraints without over-explaining.
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 filler. The core action is front-loaded, the special removal case is stated, and the critical constraint about running windows is included. 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 simple bind operation with full schema coverage and a destructive annotation, the description covers the essential invocation details: what is bound, to what, the removal sentinel, and the closed-window precondition. It does not explain return values or error cases, but those are not critical for this tool's correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents proxyId, windowId, and windowIds. The description reinforces that proxyId=0 removes the binding and that multiple window IDs are supported, but it does not add substantial new parameter-level meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Bind'), a resource ('one proxy resource'), and a target ('one or more closed NexBrowser windows'), and it distinguishes itself from sibling tools like nex_browser_bind_account by specifying the proxy-to-window relationship. It also clarifies the special proxyId=0 removal behavior, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: bind a proxy to closed windows only, and running windows are rejected and must be closed first. It does not explicitly name alternative tools, but the sibling list makes the alternative bind operations obvious, and the closed-window constraint is a strong usage signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint already provided by annotations, the description adds key behavioral context by specifying 'visible text' (excluding hidden text) and the scoping between 'page' and 'target'. This goes beyond annotation-level safety info.
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, focused sentence with no filler. Every word earns its place and the core purpose 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 read tool with 3 optional params and no output schema, the description is sufficiently complete. It defines the action, scope, and optionality, though it does not detail return format or edge cases.
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 100%, so baseline is 3. The description adds meaning by explaining that reading can be from the whole page or a specific target, clarifying the optional semantics of the target parameter 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 verb 'Read' and the resource 'visible text from the page or one target', which distinguishes it from siblings like page_title or snapshot. It is specific and concise.
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 (reading visible text when needed) but does not explicitly contrast with alternatives like snapshot or page_title, nor provide 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that credentials are never returned and implies a non-destructive 'probe' operation, but 'credentials are never returned' is already in the schema for username/password, so it adds limited new behavioral depth. It does not explicitly state read-only or confirm no modification, though 'probe' suggests it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the action and resource, then add the credential safety note. Every word contributes, with no fluff or repetition of obvious 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?
The description covers the two input modes, key output fields (exit IP, location, timezone), and a security behavior. It lacks explicit mention of error/connectivity behavior and does not state read-only, but for a simple probe tool with 0 required parameters and no output schema, it is largely complete. Schema fills in protocol details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (86%), so the baseline is 3. The description compensates for the only undocumented parameter ('host') by framing it as part of an 'unsaved host:port', and it reinforces the proxyId vs host/port duality. This adds meaningful semantic context 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?
States a clear verb ('Probe') with a specific resource ('a proxy resource or an unsaved host:port') and the expected result ('exit IP, location, and timezone'). This immediately distinguishes it from sibling proxy tools like create/modify/delete/list, and the 'detect' suffix reinforces a diagnostic read 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 context on two usage modes: probing a saved proxy resource (via proxyId) or an unsaved host:port. The phrase 'unsaved host:port' explicitly signals a non-saved input scenario, but it does not explicitly compare against alternatives or state exclusions, so it falls just 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?
No annotations are present, so the description carries the full burden. It discloses that duplicate group names are rejected, which is a useful behavioral detail. However, it does not mention side effects (e.g., whether creation is idempotent), return values, or any prerequisites beyond 'active workspace'. The uniqueness rejection is the only behavioral trait beyond the schema, so a moderate score 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 exactly two sentences, with the core purpose stated first and the uniqueness constraint and alternatives appended. No wasted words; every sentence earns its place. It is appropriately front-loaded 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 create operation with fully documented parameters and no output schema, the description is sufficiently complete. It covers the core action, the uniqueness constraint, and routes to related operations. The only missing piece is a return value description, but the absence of an output schema suggests it is not critical. The context (active workspace) is stated, so an agent has what it needs to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully documents both parameters. The description repeats the uniqueness requirement for 'name' that is already in the schema ('must be unique inside the active team'), adding no new semantic detail. The 'seq' parameter is fully described in the schema. Thus, the description adds no value beyond the schema, fitting the baseline 3 for high 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 states a specific verb ('Create'), a concrete resource ('one window group'), and the scope ('in the active NexBrowser workspace'). It also clarifies the uniqueness constraint, distinguishing it from group modification and moving operations by naming sibling tools. This is unambiguous and clearly differentiates from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs the agent to use nex_browser_group_modify for renaming and nex_browser_move_to_group for placing windows, thereby defining when this tool is appropriate and providing alternatives. Though it doesn't state an explicit 'not for' case, the purpose is clear and the alternatives cover the main adjacent operations.
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 readOnlyHint annotation declares this is a safe read operation. The description adds meaningful behavioral context beyond that: it discloses that usernames are masked, secrets are never returned, and that the result provides accountId values intended for nex_browser_fill_account. This directly informs the agent about data safety and downstream usage, exceeding the annotation's coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler. The first sentence front-loads the verb and resource; the second provides security constraints and a pointer to the next step. Every clause adds value, and the structure is easy to scan.
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, so the description must convey what the tool returns. It does this adequately: it indicates the result includes bound platform accounts and user-saved passwords, masks usernames, omits secrets, and exposes accountId for use with nex_browser_fill_account. It lacks explicit pagination/return-format details, but for a simple list operation with two optional params, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes both parameters (windowId and windowIds alias) with 100% coverage, but the descriptions are minimal ('One window ID or a list' / 'Alias of windowId'). The tool description adds no parameter-level meaning. With complete schema coverage, baseline 3 applies; the schema already handles parameter clarity adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear, specific operation: listing autofill-capable credentials from the vault plugin. It identifies the resource scope ('vault plugin', 'bound platform accounts', 'user-saved passwords') and explicitly notes what is not returned (secrets). This distinguishes it from sibling tools like nex_account_list without needing to name them.
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: it lists credentials for use with nex_browser_fill_account. It implies the tool is a prerequisite for filling an account and warns that secrets are never returned, setting expectations. However, it does not explicitly state when NOT to use this tool or name alternative listing tools, so it lacks an explicit exclusion.
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?
No annotations are present, so the description carries the full behavioral disclosure burden. It reveals non-obvious behavior: unset fields use desktop defaults, each window gets an auto-generated fingerprint, and only differing fields need to be passed. This goes beyond the schema and helps the agent predict 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 sentences, front-loaded with the verb and resource, and every word adds value. It avoids redundant restatement of the schema and delivers key behavioral information efficiently.
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 (11 parameters, nested objects, no output schema), the description covers essential context: where creation happens, fallback behavior, and fingerprint generation. It lacks details about return values or interaction with other sibling tools, but these are partly covered by the schema and tool naming. Overall, adequate for an experienced 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 coverage is 73%, and the description adds meaningful parameter-level context by stating that unset fields fall back to defaults and specifying which types of fields (fingerprint, preferences, layout, startup page) are affected. This complements the schema and clarifies the semantics of optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create NexBrowser environments' and specifies the active workspace, making the tool's purpose unambiguous. It distinguishes itself from sibling tools like nex_browser_group_create by focusing on environment/window creation.
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 usage guidance: 'pass only the fields that must differ' and explains fallback behavior. While it doesn't explicitly contrast with alternatives, it implies when to use this tool (creating windows) and how to use it effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it discloses that values cross the model/MCP boundary, that they must never be stored or repeated, and explicitly states the tool never submits the form. It could add more about return values or errors, but the security-relevant behavior is well covered.
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 tight sentences, each earning its place: purpose, alternative/security rationale, and non-behavior. No fluff, information-dense, and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with no output schema, the description covers the critical aspects: what it does, when to use an alternative, and key security guarantees. It could mention what happens on success/failure or how it interacts with the visible page state, but overall it's quite complete for its purpose.
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 63% (5 of 8 params described); the description doesn't add parameter-specific detail beyond emphasizing the sensitivity of the literal values and their placement 'into visible fields.' The username/password/totpCode params lack descriptions in the schema, and the description doesn't elaborate on them either, so it doesn't fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource construction: 'Fill literal login credentials... into visible fields.' It clearly distinguishes itself from the sibling nex_browser_fill_account by contrasting literal vs. stored credentials, and it adds important scope with 'never submits the form.'
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 (nex_browser_fill_account) and gives the exact condition for preferring it ('when a stored vault credential is available'). This directly fulfills the when-to-use vs. alternatives guideline.
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 signals non-destructiveness, and the description adds valuable behavioral context—specifically that the first row is always the ungrouped bucket with groupId 0. This goes beyond the annotation by explaining what to expect in the list output.
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 the action and purpose front-loaded in the first sentence. The second sentence adds a critical detail (groupId 0) without any fluff. Every word is purposeful.
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 list tool with no parameters and no output schema, the description covers the core functionality: listing window groups with their counts in the active workspace, and the special ungrouped bucket. It could optionally detail the exact output format, but the phrase 'with the window count of each' conveys the essential return value.
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 takes zero parameters, and the schema is trivially complete. The description does not need to explain parameters, and the context signals confirm 100% schema coverage. This meets the baseline for a zero-parameter tool.
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', the target resource 'window groups of the active NexBrowser workspace', and the output detail 'with the window count of each'. It distinguishes this from sibling tools like tab_list or group_delete by specifically focusing on window groups and groupId selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the intended use: to select a groupId for window creation, moving, or deletion. It also highlights the special ungrouped bucket with groupId 0, which is important for using group-related tools. However, it does not explicitly mention alternative tools or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behavioral aspects: the operation is non-destructive (windows remain running) because groups are metadata. It does not mention potential side effects, error conditions, or whether the operation is synchronous, but the core behavior is transparently described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two sentences without fluff. It front-loads the main purpose and then provides essential context about the metadata nature and the groupId=0 case.
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 simple operation, the description covers the essential usage and behavior. It lacks explicit mention of what happens if no windowId is provided, but the phrase 'one or more' implies specification is required. The absence of an output schema makes return value explanation unnecessary.
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 already describes all parameters with 100% coverage, including the alias relationship between windowId and windowIds. The description reinforces the groupId=0 special case, though this is already in the schema. The semantics are clear and consistent.
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: moving one or more NexBrowser windows into a window group. It specifies the action (move), the resource (windows), and the target (group), distinguishing it from other window operations.
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 specific usage guidance by mentioning the groupId=0 condition for moving windows out of a group. It also explains that groups are metadata, so the move can happen without closing windows, which informs when this operation is appropriate. However, it does not explicitly compare to alternative tools or state 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint annotation is consistent with 'Delete', and the description goes beyond it by revealing that windows inside the group are not deleted but ungrouped, and that groupId 0 cannot be deleted. This gives the agent essential knowledge about side effects and invalid targets beyond what annotations alone convey.
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 contain the core action, the side effect, and the key exclusions. The main verb and object are front-loaded, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with a destructiveHint annotation and no output schema, the description covers the essential prerequisites: the operation applies to the active workspace, the group must be custom, and groupId 0 is forbidden. No critical calling information is missing.
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%, with both id and groupId already documented in the input schema. The description only restates the groupId=0 limitation ('ungrouped bucket (groupId 0) cannot be deleted') which is already in the schema, so no additional parameter meaning is provided. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Delete one custom window group from the active NexBrowser workspace.' It distinguishes this tool from sibling group operations by clarifying the side effect ('windows inside it are not deleted; they become ungrouped') and excluding groupId 0. This makes 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?
Clear context is provided: the tool operates on a custom window group in the active workspace, and the ungrouped bucket (groupId 0) is explicitly excluded. It does not explicitly name alternatives such as nex_browser_group_modify or nex_browser_move_to_group, but the behavioral notes make the tool's applicability apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden and succeeds richly. It discloses security boundaries ('keeps passwords and 2FA secrets outside MCP'), autonomy ('the plugin chooses the visible fields'), a critical non-action ('This tool never submits the form'), and the multi-step re-call behavior. This is genuinely valuable behavioral context beyond what structured data could convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, front-loaded with purpose, then prerequisite, repeat guidance, and a safety caveat. Every sentence earns its place; no filler. It is slightly long due to the workflow detail, but the structure flows logically from what→how→when→caveat.
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 3 optional params, no output schema, and no annotations, this description is remarkably complete: it covers the operation, the prerequisite sequencing, the security model, field-selection autonomy, repeated invocation across navigations, and the no-submit contract. The agent has everything needed to invoke it correctly without guessing.
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 100%, so baseline is 3, but the description adds real meaning: it constrains accountId to 'only an accountId returned for this open window,' telling the agent where the value must come from — something the schema alone does not state. It also clarifies the optional-single-credential case. This exceeds what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'autofill the current login page with a stored credential.' It clearly differentiates from siblings by emphasizing the vault-plugin aspect ('plugin chooses the visible fields') and by referencing the prerequisite nex_browser_accounts call, distinguishing it from manual fills like nex_browser_fill_form and nex_browser_fill_credentials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow guidance: 'Call nex_browser_accounts first and pass only an accountId returned for this open window' and 'Call again after each navigation in a multi-step sign-in.' It does not explicitly name alternatives to avoid (e.g., fill_form vs fill_credentials), but the context is clear enough for an agent to sequence correctly.
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?
While the destructiveHint annotation indicates destructive behavior, the description itself transparently mentions 'replaces the existing binding' and 'remove it', which are destructive actions. It also discloses the rejection of running windows. It does not explicitly label itself as destructive but provides enough behavioral detail about state changes and failure conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with each sentence delivering a distinct piece of information: core function, replacement behavior, removal method, precondition, and subsequent step. No extraneous verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers essential operational context: the need for closed windows, the removal option, and the recommended follow-up action. It does not describe potential error scenarios beyond the rejection, but this is sufficient for typical usage. The absence of an output schema reduces the need for return-value explanation.
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 fully covers all parameters, and the descriptions add important semantics: windowId/windowIds are aliases and must reference closed windows, while accountIds explains the replacement effect and special values ([] or 0) for clearing. This makes each parameter's role clear and actionable.
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 core action: binding workspace catalog platform accounts to NexBrowser windows. It specifies the resource, target, and the replace behavior, leaving no ambiguity about the tool's primary purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage instructions: how to remove bindings with an empty array, the requirement that windows must be closed first, and a pointer to the complementary tool (nex_browser_accounts) for post-opening steps. This gives clear when-to-use and when-not-to-use context.
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:

[![nexbrowser-mcp MCP server](https://glama.ai/mcp/servers/nex-browser/nexbrowser-mcp/badges/card.svg)](https://glama.ai/mcp/servers/nex-browser/nexbrowser-mcp)

Score Badge

Copy to your README.md:

[![nexbrowser-mcp MCP server](https://glama.ai/mcp/servers/nex-browser/nexbrowser-mcp/badges/score.svg)](https://glama.ai/mcp/servers/nex-browser/nexbrowser-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nex-browser/nexbrowser-mcp'

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