nexus-browser-mcp
Server Quality Checklist
Latest release: v0.2.3
- Disambiguation4/5
Tools are mostly distinct: navigation, interaction, reading, waiting, and session management are clearly separated. Some overlap exists between snapshot and read (both capture page state) and among the three wait variants, but descriptions clearly differentiate their purposes.
Naming Consistency3/5All tools share the 'browser_' prefix, but the pattern is mixed: most use verb_noun (navigate, click, type, read, evaluate), while several use noun-only (snapshot, console, errors, network, perf, tasks). This inconsistency makes it less predictable.
Tool Count3/5With 25 tools, this sits at the heavy end of the scale. Browser automation justifies many operations, but the count feels borderline; some tools (e.g., wait_ms, list_sessions) could potentially be consolidated.
Completeness4/5The tool surface covers core browser workflows well: navigation, interaction, state reading, waiting, debugging, and session management. Minor gaps exist (e.g., no explicit cookie handling or file upload), but agents can work around them.
Average 3.6/5 across 25 of 25 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 41 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is 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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully explain behavioral traits. It only mentions 'switch' without disclosing side effects (e.g., whether the current page context changes for subsequent tools), return behavior, index-base semantics, or error conditions. This is insufficient for a safe tool invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, making it concise. However, it is so brief that it borders on under-specification, yet for the purpose of conciseness, it earns a high score for avoiding irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description fails to provide adequate context. It does not explain how the index relates to the tab list from sibling tools, the impact on subsequent actions, or the role of task_id in multi-session scenarios. The absence of an output schema and any behavioral details leaves the tool incomplete for an agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters. The 'index' parameter is not explained (e.g., zero-based or one-based), and 'task_id' is ignored entirely. The description does not compensate for the bare schema, so the agent lacks critical parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: switching to the tab at a specified index. It distinguishes from siblings like browser_navigate (which navigates to a URL) and browser_list_pages (which lists pages). The verb 'switch' and resource 'tab page' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as browser_navigate or browser_list_pages. There is no mention of prerequisites, exclusions, or preferred contexts, 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?
No annotations exist, so the description carries the full burden. It discloses only the basic behavior (capture, save, return path) but omits side effects, file naming/overwrite behavior, or how parameters like full_page and task_id affect the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently states the core purpose with no fluff. However, it is under-specified, forgoing valuable details, so it is not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides minimal context beyond the basic action. With no output schema and three undocumented parameters, it falls short of what an agent needs to invoke the tool correctly, especially regarding what 'path' means and the effect of full_page.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters (path, task_id, full_page). The agent is left guessing their meanings and required formats, which is critical for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('截取页面截图' - capture page screenshot), the resource (page), and the outcome (save file and return path). This is a specific verb-resource-result structure that distinguishes it from sibling tools like browser_snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as browser_snapshot or browser_read. There are no exclusions, prerequisites, or mention of scenarios where this tool is preferred.
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 available, so the description carries the full burden of behavioral disclosure. It only states the action and the locator hierarchy, but omits side effects (e.g., page scroll position changes), failure behavior (e.g., missing element), and whether the scroll is smooth or instant. This is insufficient for a tool that mutates 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence that front-loads the purpose and includes a helpful locator chain. Every word contributes value, with no filler. It is appropriately concise, though it sacrifices detail needed for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 4 parameters with zero schema documentation, the description is incomplete. It does not explain parameter semantics for 'ref'/'selector'/'task_id', nor does it cover return values or error cases. The tool is simple but still underdescribed for reliable autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain all parameters. It defines 'landmark' as a semantic region and shows the fallback order, but 'ref' and 'selector' are not defined, and 'task_id' is completely omitted. The priority chain helps but leaves the agent guessing about the meaning of each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states an action ('scroll to specified element') and identifies the target as an element, which distinguishes it from the sibling 'browser_scroll' that likely scrolls the page itself. The locator priority chain (landmark→ref→selector) adds specificity about how the element is identified. However, it does not explicitly contrast with sibling tools, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prioritized parameter usage order (landmark→ref→selector), which implies which parameter to try first. It does not, however, state when to use this tool over alternatives like browser_scroll, nor does it mention any preconditions for scrolling to an element. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses the timeout behavior: '超时返回WARNING' (returns WARNING on timeout). However, it does not explain success return values, blocking behavior, or what happens if the element/text never appears, leaving the agent with limited insight into the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of only two short sentences. Both sentences carry essential information: the waiting purpose and the timeout warning. No redundant or irrelevant content is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite its conciseness, the description is incomplete for a 6-parameter tool with no annotations and no output schema. It fails to explain parameter roles, success behavior, error handling, or when to prefer sibling tools. The agent would need to rely on the schema alone, which itself lacks descriptions, making it highly challenging to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 6 parameters with 0% description coverage, and the description only mentions 'element or text' without mapping to specific parameters like ref, name, role, or text. It does not clarify the function of timeout or task_id, leaving the agent to guess parameter semantics from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: '等待元素或文本出现' (Wait for element or text to appear). This distinguishes from sibling tools like browser_wait_ms (timed wait) and browser_wait_navigation (navigation wait), though it does not explicitly name alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus sibling tools such as browser_wait_stable or browser_wait_ms. It only implies a general waiting scenario, without exclusions or alternative recommendations.
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, the description bears the transparency burden. It discloses return values (title, URL, readyState, page structure) and mentions multi-task isolation, providing useful behavioral context beyond a simple 'navigate' statement. However, it doesn't explain side effects like wait behavior or potential errors, preventing a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action and followed by return value and feature note. Every sentence earns its place with no redundancy, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters with no schema descriptions, no annotations, and no output schema, the description is insufficiently complete. It provides return values but misses parameter semantics, usage conditions, and behavioral side effects, making it hard for an agent to invoke correctly in nuanced contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero descriptions for url, task_id, and wait_until, and the description adds no parameter-level detail. It only implies the URL target but offers no explanation of task_id or wait_until, leaving the agent without essential parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool navigates the browser to a specified URL and returns title, URL, readyState, and page structure, making its primary function unambiguous. It doesn't explicitly differentiate from sibling navigation-related tools like browser_wait_navigation, but the verb+resource+output structure is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or when to prefer browser_snapshot or browser_wait_navigation. The only additional note about multi-task isolation is a feature description, not usage direction.
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 full responsibility for behavioral disclosure. It only says 'scroll page' and describes direction and amount. It does not explain what happens when scrolling reaches the edge, whether scrolling is relative to the viewport or an element, or how task_id affects behavior. This is minimal and 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: two short sentences deliver the core action and key parameter details. Every word earns its place, with no fluff or repetition of schema defaults.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the basics, but it omits crucial context: differentiation from sibling browser_scroll_to, the role of task_id, and any edge-case behavior. The lack of an output schema and annotations makes this minimal description less complete than it could be, but it is not wholly inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for 'direction' (up/down/left/right) and 'amount' (pixels, default 500), which the schema only provides as defaults without descriptions. However, the 'task_id' parameter is completely unexplained, and with schema description coverage at 0%, the description only partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrolls the page, with a verb and resource ('滚动页面' = scroll page). It explains the main parameters (direction, amount), but does not distinguish from the sibling tool browser_scroll_to, which likely scrolls to a specific element. This is clear but lacking sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like browser_scroll_to or browser_wait. The description merely states the action and parameters, leaving the agent to infer usage context. There is no mention of prerequisites or exclusions.
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 states the action ('close') but fails to mention side effects, irreversibility, prerequisites (e.g., task existence), or the impact on the session. For a destructive operation, this is insufficient behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with zero wasted words. It is concise and front-loaded with the core action and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description needs to provide more context. It lacks guidance on how to discover task IDs (sibling tool browser_tasks), whether the action affects the session, and what state changes occur. This is inadequate for a destructive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single parameter task_id. The description only says '指定task' (specified task), which barely adds meaning beyond the parameter name. It does not explain how to obtain a valid task_id (e.g., via browser_tasks) or any format expectations, so it fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool closes browser resources (page/context) for a specified task, using a specific verb ('关闭' = close) and resource. It distinguishes from siblings like browser_close_session (closes a session) and browser_list_sessions by focusing on task-scoped cleanup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to clean up a specific task's browser resources. However, it does not explicitly mention alternatives or exclusions (e.g., use browser_close_session for session-level cleanup), so guidance is only implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the scope (current task) but does not disclose return format, whether it affects browser state, or any side effects. The description is essentially a restatement of purpose without additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the action. It contains no unnecessary words and is immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not explain what information is returned for each tab (e.g., id, title, URL). It also does not clarify the relationship between task_id and the current task. Lacking these details, an agent might not know what to expect from the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (task_id) with no description (0% coverage). The description mentions 'current task' which hints at the parameter's role, but it does not explain how task_id is used, accepted values, or behavior for different inputs. The description does not fully compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all open tabs for the current task, using a specific verb ('列出') and a specific resource ('标签页'). It distinguishes from sibling tools like browser_list_sessions or browser_tasks by focusing on tabs/pages rather than sessions or tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to see open tabs for a task) but provides no explicit guidance on alternatives or when not to use it. It does not compare with sibling tools, so usage context is only inferred.
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 full responsibility for behavioral disclosure. It only says 'wait for navigation to complete' but does not mention timeout handling, what constitutes 'complete', return values, or side effects. This leaves significant 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are 3 parameters and no output schema, the description is insufficiently complete. It does not explain parameter semantics, return values, timeout behavior, or how url_contains affects waiting. A simple wait tool still needs to clarify these aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the parameters (task_id, timeout, url_contains). The schema also lacks descriptions (0% coverage), so the description must compensate but fails to explain any parameter's purpose or expected value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it waits for navigation triggered by click/submit to complete. This distinguishes it from sibling tools like browser_wait (generic wait), browser_wait_stable, and browser_wait_ms by specifying the trigger context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'click/submit触发的' implies it should be used after a click or submit action. This gives clear context on when to use it, though it does not explicitly name alternatives or exclusion 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 of disclosure. It states that it closes all task resources but does not explain the consequences: whether the session itself is closed, if tasks are permanently deleted, whether the operation is reversible, or any side effects on the browser context. This lack of detail is significant for a destructive-looking operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically complete sentence that gets straight to the point. It is concise, front-loaded, and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameters, the description is the only source of context. It clarifies that it closes all task resources, but it leaves ambiguity about whether the session itself is also terminated, what happens to ongoing operations, and how this relates to other session/task management tools. For a mutating operation, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is an empty object. The description adds no parameter information, but since there are no parameters, it does not need to. Per the baseline for 0 params, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (close) and the target (all task resources of the current session), making the tool's purpose unambiguous. It differentiates from sibling tools like browser_close_task, which closes a single task, by explicitly targeting all tasks in a session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as browser_close_task or browser_list_sessions. It does not mention prerequisites, context, or exclusions, leaving the agent to infer usage solely from the name.
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, the description carries the behavioral disclosure burden. It transparently explains the streaming behavior: buffering, incremental updates, and dropping of oldest content when overflow occurs. This goes beyond the basic purpose and gives useful operational details, though it omits the exact return format and edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose, then details streaming modes in a structured way. Each sentence adds meaningful operational content without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters, no output schema, and no annotations. The description covers core reading behavior and streaming modes but leaves many parameters unexplained and does not describe return values, error handling, or interaction with the broader tool set. It is incomplete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only explains wait_stable, follow, and selector implicitly. The remaining 6 parameters (ref, full, task_id, max_chars, stream_id, max_wait_ms) are not described at all, leaving significant meaning gaps for an agent trying to use the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads text content of page elements, with a default to the whole body. However, it does not explicitly distinguish itself from sibling tools like browser_snapshot or browser_evaluate, which also interact with page content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains different modes (wait_stable for one-time full read, follow for incremental tracking) and the default behavior when no selector is given. It implies when to use these options but does not explicitly state when to use this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It discloses the locator resolution priority and the wait_stable behavior, but it does not mention potential side effects (e.g., navigation, popups), conditions like element visibility, or what happens if multiple elements match. This is a significant gap for a click action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence. It front-loads the core action and then provides the priority order and a key behavioral flag in a compact and scannable form with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no annotations, and no output schema, the description is not complete. It provides locator guidance but leaves important parameters (confirmed, double_click) unexplained, and does not describe return values, error handling, or side effects. The tool is simple but the description gaps could lead to mis-invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains several parameters through the priority list: pos (coordinates), ref (snapshot handle), selector, role+name, and name. It also explains wait_stable. However, it omits the meaning of confirmed, double_click, and task_id, leaving these ambiguous. Since schema coverage is 0%, the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with '点击页面元素' (click page elements), clearly stating the action and target. The locator priority list further clarifies what the tool does, and it is distinct from sibling tools like browser_type, browser_read, or browser_screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on how to specify the element via a priority order (pos → ref → selector → role+name → name), which directly assists the agent in choosing the right parameter combination. However, it does not explicitly mention alternatives or when not to use the tool compared to other browser 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?
With no annotations present, the description carries the behavioral burden and discloses meaningful details: the locator priority order (pos → ref → selector → role+name), the automatic fallback to placeholder/label/common CSS, and the wait_stable=true behavior of waiting for DOM quiet. It does not cover failure behavior or default clearing, but adds substantial transparency beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—two sentences—and front-loads the core action before diving into locator mechanics. The use of arrows and parenthetical fallback notes is information-dense but not bloated, making it reasonably easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is an 11-parameter tool with no output schema and no annotations, yet the description only explains the main typing flow and one option (wait_stable). Missing are the effects of clear, press_enter, confirmed, task_id, return values, and failure scenarios, making the overall context incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate for 11 parameters. It explains pos, ref, selector, role, and wait_stable, but leaves clear, confirmed, press_enter, and task_id unexplained. This is insufficient for a tool with many optional parameters, especially since 'clear' has a non-obvious default of true.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '在输入框中键入文本' (type text in the input box), clearly stating the tool's verb and resource. It further distinguishes browser_type from sibling tools like browser_click or browser_read by focusing exclusively on text entry and specifying the locator priority.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for typing text into inputs but does not explicitly state when to prefer it over alternatives such as browser_evaluate or browser_click. No exclusion or comparison with sibling tools is provided, so usage guidance remains 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.
- 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 does disclose the default-disabled state and the need for manual confirmation—a key safety behavior. However, it does not describe what happens after execution (return value, errors, page state changes), leaving significant behavioral aspects unclear for a potentially destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense, front-loaded sentence that conveys the core action and both critical constraints (default disabled, confirmation required). It is concise with zero wasted words and achieves maximum informational density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex and high-risk (JavaScript execution), yet the description omits the return format, error behavior, and any explicit side-effect warnings. For an agent to safely and effectively use this tool, it needs more detail about what the tool returns or how it affects the page. The lack of output schema increases the burden, which this description does not meet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies the 'expression' parameter's purpose and explains the 'confirmed' flag's role. However, 'task_id' is entirely unaddressed, and there is no detail on expression syntax, limits, or evaluation context. This partial coverage is insufficient with three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '执行JavaScript表达式' (execute JavaScript expression), which is a specific verb + resource. This uniquely distinguishes it from all sibling browser tools (navigate, click, type, read, etc.) that perform other actions. The purpose is unambiguous and directly names the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: it is for executing JavaScript and comes with a default-disabled state and a human-confirmation requirement. While it doesn't explicitly name alternatives or when not to use it, the context makes the primary use case obvious. The operational prerequisite (enable + confirm) is stated, which is valuable 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 provided, the description alone must disclose behavioral traits. It usefully reveals the multi-step attempt sequence, which is a significant behavioral detail. However, it does not mention what happens if no popup is found, whether the action is destructive, or how it interacts with the task_id parameter. The potential for unintended clicks is also not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, highly efficient sentence that front-loads the tool's purpose and lists the fallback strategy in a compact arrow format. Every word contributes meaning with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is functionally clear for a simple popup-dismissal tool, but it lacks return behavior (no output schema), failure handling, and parameter explanation. An agent would not know whether the tool returns success/failure or what happens if no popup exists. While the description covers the core action, these gaps limit full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, task_id, is not described in the schema (0% coverage) and the tool description does not mention it or clarify its purpose. Since the schema provides no semantics beyond the name, the description carries the burden, but it fails to explain what task_id refers to. The name implies an identifier, but its role in targeting the popup is unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool automatically detects and closes popups, specifying three common types (login/cookie consent/ads) and an ordered strategy (close button → cancel → Escape). This is a specific verb+resource description that clearly distinguishes it from sibling browser interaction tools like browser_click or 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: when popups such as login, cookie consent, or ads appear. It implies the use case but does not explicitly name alternatives or state when not to use it. The strategy sequence hints at a self-contained fallback approach, but a direct 'use this instead of manual clicking' would be stronger.
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 states the core behavior (list active sessions) but adds no context about what constitutes an 'active' session, potential side effects, or return format. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the operation. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameter-less list operation, the description is mostly complete. However, it doesn't explain what sessions are or how they relate to sibling tools, which could cause minor confusion. Still, the core function is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per the rubric the baseline is 4. The description correctly avoids inventing parameter details; nothing more is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'list' and resource 'all active sessions', clearly distinguishing it from siblings like browser_list_pages (pages) and browser_close_session (close). It is unambiguous 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention differences from browser_list_pages or explain scenarios where listing sessions is appropriate, leaving the agent to infer usage.
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 full burden. It discloses the wait behavior and upper time limit, but does not mention return values or whether it checks page state. The use cases give some context, but for a 'pure wait' more could be said about non-interference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with a parenthetical, front-loaded with the core action and constraints. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple wait tool with no output schema, the description covers purpose, use cases, and a safety limit. It lacks explicit return behavior and task_id semantics, but given simplicity this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 0% of parameters. The description explains the ms parameter by referencing the specified milliseconds, but task_id is not addressed. Since ms is straightforward from the name, this is partially sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a pure wait for a specified number of milliseconds, with explicit use cases ('escape hatch' for animations/rate limiting/delayed rendering). This distinguishes it from sibling wait tools like browser_wait_stable or browser_wait_navigation, though it does not name alternatives directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance via the 'escape hatch' phrase, indicating this is for scenarios where animation, rate limiting, or delayed rendering need a fixed delay. It also mentions the upper bound (timeout - 5s), but does not explicitly contrast with conditional waits.
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, the description carries full transparency burden. It discloses key behaviors: returns structured elements with ref/box, waits for a DOM silent window, and marks offscreen elements in full mode. It does not explicitly state whether it is read-only or if it modifies page state, but the emphasis on snapshot and non-mutating language suggests safety. It could further explain determinism guarantees or side effects, but overall is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, tightly packed with essential information. It front-loads the core purpose, then provides behavioral details and mode distinctions without any fluff or redundancy. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no annotations and no output schema, the description does not fully compensate. It explains the return concept (structured list with ref/box) but provides no details about the structure, pagination, or error behavior. The presence of many parameters that remain undocumented makes the tool's full behavior unclear, leaving the agent to guess on important configuration options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains the 'mode' parameter (reading/interactive vs full) and mentions offscreen marking. It fails to explain the other six parameters (diff, scope, task_id, wait_stable, include_generic, include_offscreen), leaving the agent to infer their meanings from names and defaults. This is a significant gap for a tool with 7 configurable options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the page accessibility tree snapshot and returns a structured element list with ref/box. It uses a specific verb (获取/get) and identifies the resource (accessibility tree), distinguishing it from sibling tools like browser_screenshot or browser_evaluate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides usage context by explaining that reading/interactive modes only cover the viewport while mode=full includes the entire page, guiding when to choose each mode. It also mentions the event-driven deterministic snapshot that waits for DOM silence, which implies appropriate usage after page interactions. However, it does not explicitly compare against alternatives like browser_read or browser_wait_stable.
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 burden of disclosing behavior. It reveals that the tool monitors DOM mutations and uses an 800ms quiet period, giving the agent insight into the underlying mechanism. However, it does not state what happens on timeout, whether it returns any value, or if it is strictly read-only, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every phrase (DOM stop changing, 800ms, use cases) contributes to understanding, making it highly concise and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and no schema coverage, the description is not complete enough. It omits parameter semantics, timeout behavior, and clear differentiation from sibling wait tools beyond a narrow use case. The agent would need to infer too much for a confidently correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate but does not. It mentions the default 800ms silence window but fails to explain the meaning or role of task_id and timeout_ms, leaving the agent without necessary parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the action: waits for the page DOM to stop changing, with a specified silent window (default 800ms). It also explicitly names use cases (streaming reply completion, animation end), which effectively distinguishes it from sibling wait tools like browser_wait_ms and browser_wait_navigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context (when streaming or animations are finishing) but does not explicitly mention alternatives or when not to use it. The sibling context implies differentiation, yet the description stops short of explicit when-to-use vs. when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the action (list) and output (tasks and page counts), but does not mention read-only nature, potential prerequisites (e.g., active session), or any side effects. This leaves the agent without safety or behavior context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and object. It contains no redundant information and is appropriately sized for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool, the description is fairly complete: it states what is listed (tasks) and what information is returned (page counts). However, it does not clarify what constitutes a 'task' or what 'current session' means, which could be ambiguous without further context. Still, given the simplicity, it is nearly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. With no parameters, the baseline is 4, and the description appropriately does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all tasks for the current session along with their page counts. It uses a specific verb (list) and resource (tasks), and the 'current session' scope distinguishes it from siblings like browser_list_sessions and browser_list_pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying 'current session', implying it is used to inspect tasks in the active session. However, it does not explicitly mention when to use this tool over alternatives or any exclusions, but the purpose itself makes the usage fairly obvious.
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 provided, so description carries the burden. It discloses key behaviors: metadata only (no body), failed_only default true, url_pattern substring matching, and incremental cursor. But it leaves details like return order/format and meaning of '同上' unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently packs purpose, key filters, and cursor behavior. No redundancy, every clause adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-param tool with no annotations or output schema, the description covers main behaviors but lacks explicit info on limit/task_id, return format, and references an unclear 'same as above' context. Adequate but not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates partially: explains failed_only and url_pattern, and implies since via cursor. It does not explain limit or task_id, leaving gaps for two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb '读取' (read) and resource '网络请求元数据' (network request metadata), enumerating fields (method/url/status/resource type) and exclusion (no body). This clearly differentiates from sibling browser_network_body.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context about failed_only default and url_pattern filtering, and '增量游标同上' implies cursor usage. However, it doesn't explicitly name alternative tools or exclusions, though '不含 body' hints at browser_network_body.
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 provided, so the description carries the burden. It discloses an important behavioral detail: 'SPA 导航不重置计时' (SPA navigation does not reset timing) and notes the output source URL. This adds useful context beyond a simple 'read' operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first lists the metrics, the second gives usage context and a caveat. Every sentence adds value with no fluff or repetition. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (a read-only metrics collector), the description covers the key aspects: what metrics, when to use, and a behavioral caveat. However, the lack of clarity on the task_id parameter and the return value structure (no output schema) leaves minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'task_id' with 0% description coverage. The description does not mention or explain task_id at all, leaving the agent to infer its meaning from the name or sibling tools. The description should have clarified what task_id refers to (e.g., the browser task/session ID).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads page performance metrics and enumerates specific metrics (FCP/LCP/CLS/INP, TTFB, DOMContentLoaded, load, slowest 5 resources). This distinguishes it from sibling tools like browser_network or browser_snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear when-to-use scenario: '页面慢/加载异常时用它定位是后端慢(TTFB)还是资源重' (when page is slow/loading abnormal, use it to locate whether backend is slow or resources are heavy). It does not explicitly mention alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses the exact error types included, time-sorting, and cursor behavior. It does not explicitly state whether the operation is read-only or describe the return structure, which is a minor gap for a view tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core purpose, includes usage guidance, and contains no redundant wording. It is appropriately sized and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose and gives a clear usage trigger, but without an output schema or annotations, it does not describe the return format, pagination details, or potential side effects. For a troubleshooting tool, the missing output structure and read-only confirmation leave notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'limit' or 'task_id' parameters. Only a hint is given about the cursor ('增量游标同 browser_console'), which partially clarifies 'since'. The description fails to compensate for the complete lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool merges JS uncaught exceptions, console errors, and failed requests (network failures or HTTP>=400) into a time-sorted view. It uses the phrase '一站式排障' (one-stop troubleshooting) and differentiates itself from sibling tools like browser_console and browser_network by being a combined view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: '点了没反应/页面白屏时先调它' (call it first when clicks don't respond or page is blank). It also references the incremental cursor being the same as browser_console, giving a clear analogy for its usage pattern.
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 provided, so the description carries full responsibility for disclosing behavior. It clearly explains the incremental cursor semantics, filtering options, and limit continuation behavior, which are non-obvious traits. However, it does not mention potential side effects (e.g., whether reading clears the buffer) or edge cases like invalid level values, though these may be low risk for a read-only console reader.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact, information-dense single sentence with semicolon-separated clauses. Every part delivers value: purpose, filters, cursor mechanics, and limit behavior. No filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple console-reading tool with no annotations and no output schema, the description provides a solid understanding of what it does, its key parameters, and how to paginate. The main gap is the unexplained 'task_id' parameter, which might be relevant in multi-task contexts, and there's no mention of what happens when the console is empty or if it captures historical output. Overall, it's complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the meaning of 'since', 'level', 'pattern', and 'limit' with concrete usage details (regex, defaults, continuation). However, it omits 'task_id' entirely, and the list of valid level values is incomplete ('...' implies more but not enumerated), leaving some parameters under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: '读取页面 console 输出' (read page console output), and clarifies the output includes level/text/location. This distinguishes it from sibling tools like browser_errors (which would be error-specific) and browser_network (which focuses on network traffic).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the tool: incremental cursor behavior (since omitted vs since=0), level/pattern filtering, and limit cap with continuation advice. It doesn't explicitly compare with alternatives or state when not to use it, but the purpose is clear enough that context implies when to choose it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains text decoding vs. binary (only byte count), the per-item cap (BROWSER_NETWORK_BODY_CAP), and the confirmation requirement with reasoning. This is extensive and compensates for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core function, and every clause adds useful detail (prerequisite, binary behavior, cap, confirmation). No filler or repetition; highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description covers the purpose, prerequisites, behavioral outcomes (text vs. binary), size cap, and confirmation flow. It does not mention error cases (e.g., seq not found) or the exact return structure, but for a relatively simple read operation, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains 'seq' (used to identify the request) and 'confirmed' (requires true for confirmation), but does not mention 'task_id' at all. Two of three parameters are given meaning beyond the schema, but the gap for task_id prevents a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '按 seq 读取单个请求的响应体' (read the response body of a single request by seq). This is a specific verb+resource combination that distinguishes it from sibling tools like browser_network (which likely lists requests) and browser_read (which reads page content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides prerequisites (BROWSER_ALLOW_NETWORK_BODY=true) and a usage requirement (confirmed=true) with a rationale: the response body is page-controlled content and the URL should be shown to the user first. It does not explicitly name alternative tools, but the context implies when to use this tool over others. Lacks explicit exclusionary guidance but is overall clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/paipaipai666/nexus-browser-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server