BrowserMesh

Server Quality Checklist

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

Latest release: v0.2.1
Disambiguation5/5
Every tool is scoped to a distinct resource-action pair: sessions, pages, navigation, state, observation, and individual input actions are clearly separated. The repeated reminders about explicit sessionId/pageId and no global context eliminate most cross-tool selection risk.
Naming Consistency4/5
Names consistently share the browser_ prefix and mostly follow a predictable resource+action pattern like session_create, page_list, and state_save. Minor deviations such as browser_runtime_info, browser_snapshot, and browser_visible_text add a slightly noun-oriented style, but the naming remains highly readable.
Tool Count2/5
At 35 tools, this is a heavy tool surface for even a full browser-automation server. The tools are individually useful and non-overlapping, but the count pushes past the reasonable threshold and puts a significant selection burden on agents.
Completeness4/5
The toolkit covers the main browser lifecycle thoroughly: session and page management, navigation, state save/restore, element interaction, waiting, screenshots, and event observation. It lacks low-level escapes like arbitrary JavaScript execution, direct cookie/storage inspection, or file uploads, but those appear intentionally excluded and core workflows remain unblocked.
Average 4.1/5 across 35 of 35 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 66 commits in the last 12 weeks
- Last stable release on August 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds that BrowserMesh preserves same-session accepted order, which is a behavioral trait not covered by annotations. However, it doesn't disclose potential side effects (e.g., triggering JavaScript events, changing page state) beyond the hover action. With annotations providing some safety profile, the description adds some value but could be more transparent about what happens after hover.
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 two sentences, concise and front-loaded with the action. It includes a practical hint about same-session order. No wasted words, but it could be slightly more structured with explicit parameter guidance. Overall, it's 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?
Given the complexity of the input schema (nested locator definitions, frame chains, multiple strategies) and the lack of schema description coverage, the description is insufficient. It doesn't explain how to specify iframe contexts, the role-based locator structure, or the meaning of 'ref'. The output schema exists but the description doesn't clarify what the tool returns. For a tool with such a complex schema, the description should provide more guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. The description mentions 'semantic or CSS locator' and 'explicitly addressed page', which hints at locator and pageId parameters, but it doesn't explain the 'ref' parameter, 'timeoutMs', or the 'frame' structure. The schema is complex with nested definitions, and the description provides minimal guidance on how to construct the locator object. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: moving the pointer over a semantic or CSS locator on an explicitly addressed page. It distinguishes from siblings like browser_click and browser_focus by specifying the hover action and its use case (revealing hover-driven controls). However, it doesn't explicitly differentiate from other hover-related tools (none exist in siblings), so it's clear but not fully distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool: 'Use this to reveal hover-driven controls or state before inspecting or interacting.' It implies usage before other actions, but doesn't explicitly state when not to use it or mention alternatives. The sibling list includes browser_click, browser_focus, etc., but no explicit comparison is made. This is clear context but lacks 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?
Annotations already declare destructiveHint=true, so the description does not need to repeat that. The description adds a key behavioral nuance: it clarifies that removing state does not close or alter live sessions, which is valuable beyond the annotation. However, it does not detail what happens to the state data or if any confirmation is needed, but given the annotation coverage, this is adequate. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action ('Delete persisted browser state') and includes a crucial clarification. Every word earns its place; no redundancy or fluff. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity is low (single parameter, clear destructive intent), the description provides the essential context: what it deletes and that it does not affect live sessions. The output schema exists, so return details are not needed. However, the lack of parameter semantics (as noted) leaves a gap for an agent to correctly construct the stateId, and the description could have mentioned the need to list states or save state to get valid stateIds.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter (stateId) with basic type and length constraints, and schema description coverage is 0%. The description mentions 'safe logical stateId' but does not explain what 'safe' means or how to obtain a valid stateId, nor does it clarify if it is a UUID or an opaque identifier. With no parameter documentation in the schema, the description fails to provide sufficient semantics beyond listing the parameter name.
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 (delete persisted browser state) and the resource (by stateId), and distinguishes it from related state operations like browser_state_save and browser_state_list. However, it could have been more explicit about when to remove state versus other lifecycle operations, but the core purpose is clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by stating the condition for deletion ('when it should no longer be restorable'), which implies it is for cleanup of obsolete states. It also clarifies that it does not affect live sessions, which is a useful exclusion. However, it does not explicitly mention alternative tools for managing sessions or when NOT to use this tool, leaving the usage guidance somewhat implicit rather than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so no contradiction. The description adds a clarifying note about session names being workflow labels rather than internal agents, which is useful context but not behavioral detail beyond what annotations cover. It does not describe output or side effects, but those are trivial for a read-only 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 two sentences with no fluff. The first sentence states the core purpose, and the second adds a semantic clarification. Each sentence earns its place, and it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema that likely defines return format. The description fails to provide guidance on obtaining sessionId or connections to other session tools, but given low complexity and existing output schema, it is not critically incomplete. However, it could mention using browser_session_list to discover valid IDs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate for the undocumented sessionId parameter. It only indicates 'explicitly addressed' without explaining what sessionId is, its format, or how to obtain it. This adds minimal meaning beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states specifically that the tool inspects one explicitly addressed browser session, with the verb 'Inspect' and a clear resource. It distinguishes from sibling tools like browser_session_list (which lists all) and create/close tools by emphasizing 'explicitly addressed'.
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 explicit guidance on when to use this tool versus alternatives. It does not mention browser_session_list for finding session IDs or any prerequisites. The 'explicitly addressed' phrase implies an ID is needed but does not direct the agent on how to obtain it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish mutability and non-idempotency, so the description correctly carries no repetitive safety claims. The session/identity isolation disclosure adds genuine behavioral context beyond annotations: it tells the agent that the write is scoped to a session and that identity isolation requires separate sessions, which is operationally important for an openWorldHint=true tool. Slightly more detail (e.g., overwrite behavior on re-fill) would push it higher.
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?
Exactly two front-loaded sentences: the first delivers the core action with scope, the second adds the critical usage constraint. Zero filler words; every element serves purpose and usage communication.
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 genuine complexity (nested iframe selectors, multiple locator strategies, 6 params, 0% schema coverage), two sentences feel thin. The description covers page and session addressing well, but omits any mention of the iframe-chain capability, behavior on locator timeout (timeoutMs exists), or what happens when the field can't be found. The presence of an output schema and annotations mitigates some burden, landing this at minimum viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage and a highly complex polymorphic locator parameter (role/text/label/placeholder/testId/css strategies, iframe chains up to 5 deep, exact-match flags), the description should compensate significantly. It only loosely maps to two of six params ('form field'→value/locator, 'explicitly addressed page'→pageId, 'session'→sessionId) while ignoring the locator complexity, ref-slot, and timeout semantics. The description's contribution is limited to the session-scoping nuance.
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+resource ('Fill a form field') with a clear scope qualifier ('located on one explicitly addressed page') that establishes a page-addressability constraint. It clearly differentiates the tool's scope from page-level operations, though it doesn't explicitly distinguish itself from close form-related siblings like browser_check or browser_select_option (e.g., it doesn't say 'for text inputs, use fill; for checkboxes, use check').
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 session-scoping rule ('value is entered only in that session') provides clear context for when this tool applies, and 'use separate sessions for different identities' is a genuine usage directive. However, it never explicitly names alternatives among the 35 siblings or states when NOT to use this tool in favor of browser_press, browser_check, or browser_select_option.
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?
The description claims the stateId is 'safe,' directly contradicting the annotations' destructiveHint=true. It does not disclose what destructive action might occur (e.g., overwriting existing state, clearing storage). This is a clear annotation contradiction and a significant transparency failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately states the core action, and includes the critical usage condition. Every word contributes value with no 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 tool's purpose and ideal usage, but omits important context such as what 'supported storage' includes, behavior when a stateId already exists, error conditions, and the destructive implications flagged by annotations. It is adequate but leaves gaps for a complex save/restore 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?
With schema description coverage at 0%, the description adds valuable meaning by referring to 'explicitly addressed session' (mapping to sessionId) and 'logical stateId' (mapping to stateId). However, it does not provide detailed syntax, constraints, or potential values beyond what the schema's type and length limits already offer.
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 'Save' and clearly states the resource: 'cookies and supported storage from one explicitly addressed session under a safe logical stateId.' This distinguishes it from sibling tools like browser_state_list and browser_state_remove, which perform different actions.
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 usage context: 'Use this only when a later new isolated session should restore that authentication state.' This clearly indicates when the tool should be used, and the 'only when' phrasing implies when not to use it, though no alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate that the tool is not read-only (readOnlyHint: false), not idempotent, and not destructive, but the description adds that it affects only the specified page and not other sessions, which is useful context. However, it does not disclose details like what happens if there is no forward history, or if any errors are expected. The description does not contradict annotations, but the added value is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence that conveys the essential purpose and a key constraint. It is front-loaded and has no wasted words, making it easy for an agent 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?
The tool is relatively simple with a clear purpose, but it lacks information about error handling (e.g., what happens when there is no forward history) and potential edge cases. The presence of an output schema might clarify return values, but the description does not mention them. Given the simplicity, a 3 is appropriate as it meets basic needs but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the schema description coverage is 0%, the description must compensate, but it does not explicitly explain the parameters. However, the parameters are self-explanatory: sessionId and pageId are required to identify the page, and timeoutMs is optional and likely for controlling the wait time. The description's statement about addressing one page implicitly covers the need for sessionId and pageId, and the timeoutMs is optional as per the schema. Overall, the semantics are clear from the 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 clearly states the tool navigates forward in browser history, using a specific verb and resource. It distinguishes itself from the sibling tool browser_back by explicitly mentioning 'forward', and it also notes the operation is scoped to a specific page without affecting other sessions. However, it does not explicitly mention the sibling tool browser_navigate for direct URL navigation, which could be considered an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool should be used when you need to go forward in history on a specific page, but it does not explicitly state when to use it versus alternatives like browser_back or browser_navigate. It provides some context by mentioning 'explicitly addressed page' but lacks clear guidance on when not to use it or which other tools to consider.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-idempotent behavior. The description adds value beyond that by mentioning that the action is serialized with all browser work in that session and that an ambiguous locator returns LOCATOR_AMBIGUOUS. This provides useful behavioral context not captured in structured metadata.
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 in length, front-loaded with the core purpose, and contains no redundant or vague phrasing. Every sentence adds meaningful information: the first defines the action, the second gives usage and behavioral caveats.
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 with zero schema descriptions and is a mutation action, the description is incomplete. It lacks parameter explanations, prerequisites (e.g., page must be open), and return format details (though an output schema exists). The description covers usage guidance and some behavior but does not sufficiently compensate for the lack of schema details.
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%, so the description must compensate for undocumented parameters. However, it only mentions 'semantic or CSS locator' (giving some hint about the locator parameter) but says nothing about sessionId, pageId, ref, or timeoutMs. The description fails to explain the purpose or format of these parameters, leaving the agent without adequate guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: double-click a semantic or CSS locator on a specifically addressed page. It differentiates from siblings like browser_click by specifying 'only when the application assigns distinct double-click behavior' and 'one explicitly addressed page,' making the scope precise and distinguishing it from other browser interaction tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly conditions when to use the tool ('only when the application assigns distinct double-click behavior'), which tells the agent not to use it for simple clicks. It also implies the need for a page context via 'explicitly addressed page,' but it does not explicitly name alternative tools like browser_click, leaving some room for inference.
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 show readOnlyHint=false and destructiveHint=false, but the description adds that a missing or unsuitable select returns OPERATION_TIMEOUT within timeoutMs and that the session remains usable. This provides behavioral context beyond annotations, such as error behavior and session safety, which is valuable for an agent.
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 includes key information: the action, the target, the locator types, and error behavior. It is front-loaded and every phrase adds value, with no 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 tool is relatively complex with 6 parameters and a nested locator schema. The description covers the basic purpose and error behavior but lacks details on return values (though output schema exists), prerequisites for session/page existence, and specific examples of locator usage. With an output schema present, return values are covered, but the description still misses important context like how to construct locators or handle multiple selects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 6 parameters with 0% description coverage, so the description should compensate. While the description mentions using 'semantic or CSS locator' and 'timeoutMs', it does not explain specific parameters like sessionId, pageId, value, or the locator structure. The description adds minimal meaning beyond what the schema already defines, so it bears some responsibility for parameter clarity. Since schema coverage is 0%, the description should have done more, but it at least hints at the locator and timeout.
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 an option on a page using a semantic or CSS locator. It specifies the target resource (explicitly addressed page) and the action (selecting an option), which differentiates it from other browser interaction tools like click, fill, and check.
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 selecting options from dropdowns but does not explicitly contrast with alternatives like click or check. It mentions 'explicitly addressed page' implying a prerequisite, but does not provide detailed when-to-use/when-not-to-use guidance relative to sibling tools.
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 communicate readOnly, idempotent, non-destructive behavior. The description adds that the page is explicitly addressed and tied to an isolated session, but does not disclose failure behavior or what happens when no title exists. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that is front-loaded with the action and resource. There is no filler or redundancy; every phrase adds useful scoping information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, strong annotations, and presence of an output schema, the description is mostly sufficient. It identifies the target resource and required session context, though it omits optional timeout semantics and alternative-tool guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It loosely maps pageId to 'explicitly addressed page' and sessionId to 'owning isolated session', but it does not explain timeoutMs or provide any additional format/meaning for the parameters beyond their names.
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 ('title of one explicitly addressed page'), and clarifies the required session context. This distinguishes it from sibling tools like browser_get_url or browser_visible_text while stating exactly what value is returned.
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 the tool is for reading a page's title when you have an explicit page and session. However, it does not explicitly state when to prefer this tool over alternatives, nor does it mention any exclusions or prerequisites beyond the required IDs.
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 mark destructiveHint:true and readOnlyHint:false, so the description only adds the context that there is no global session/page. This is helpful but does not disclose other behavioral details like side effects on the session if it's the last page. With annotations provided, this is adequate.
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 action and purpose, and adds no unnecessary 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?
For a simple close operation with annotations covering destructive behavior and an output schema present, the description provides the essential context about why both IDs are needed. It is concise and adequate, though it could note potential side effects if the last page is closed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, so the description must compensate. It explains that both IDs are needed to unambiguously address a page, but does not individually describe what each ID refers to. It adds some context but leaves the distinction between sessionId and pageId implied
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: 'Close one explicitly addressed page in its owning session.' It specifies the resource (page) and context (session), and distinguishes from siblings like browser_session_close and browser_page_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that both IDs are required because 'BrowserMesh has no global current session or page,' but it does not explicitly state when to use this tool over alternatives, nor provide exclusion criteria. It lacks explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations by stating that the operation is 'typed', 'exposes no arbitrary JavaScript', and 'remains serialized within the session.' This reassures the agent about safety and execution ordering, though it does not mention side effects like scroll-triggered lazy loading or clamped deltas. No contradiction with annotations is present.
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 efficient sentence that front-loads the core action and then adds parameter guidance and a safety note. Every clause contributes useful information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a straightforward pixel-scroll operation, covering purpose, main parameters, and safety characteristics, and an output schema exists. However, it does not mention timeout behavior, how the scroll is clamped, or how this tool differs from browser_scroll_into_view, leaving some contextual gaps for an agent selecting among similar browser tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description is responsible for explaining parameters, but it only covers deltaX and deltaY briefly. It does not explain sessionId, pageId, or timeoutMs semantics beyond the phrase 'explicitly addressed page', leaving required parameters partially unexplained.
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 scrolls a page by deltaX/deltaY pixel values, distinguishing it from sibling tools like browser_scroll_into_view by specifying bounded integer deltas rather than element-based scrolling. The verb 'Scroll' plus the explicit resource ('an explicitly addressed page') and mechanism ('by bounded integer pixel deltas') make the purpose precise and differentiated.
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 precise pixel-based scrolling and provides guidance on which delta parameter controls which axis, but it does not explicitly state when to prefer this tool over browser_scroll_into_view or other browsing tools. No exclusions or alternative tool references are given, leaving the when-to-use decision mostly inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnlyHint=false, idempotentHint=true, and openWorldHint=true, and the description adds the useful scoping detail that 'the locator remains scoped to the supplied sessionId and pageId.' However, it does not disclose potential side effects implied by the open-world hint (e.g., whether focus changes page state or fires events), so it adds only moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences with zero waste. The first sentence states the action and its key qualifier ('without entering a value'), and the second provides usage context and scoping. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (frame chains, multiple locator strategies, exact-match options) and the presence of an output schema, the description is functionally adequate. However, the openWorldHint suggests behavioral side effects that go undisclosed, and edge cases like missing elements or visibility requirements are unaddressed, leaving meaningful gaps for a complex 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?
With 0% schema description coverage, the description is expected to compensate, and it partially does by naming sessionId and pageId and clarifying that 'locator' can be semantic or CSS. However, timeoutMs and ref are completely unaddressed, and the locator's frame/strategy options are left to the schema enums, so compensation is meaningful but 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 uses a specific verb+resource: 'Focus a semantic or CSS locator on one explicitly addressed page without entering a value.' The qualifier 'without entering a value' clearly distinguishes it from sibling actions like browser_fill or browser_press, and the scoping to sessionId/pageId adds precision. It clearly differentiates from the sibling list where fill/click/observe exist.
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 'Use this for focus-driven UI state or before a separate key action' provides an explicit when-to-use trigger. However, it does not name specific alternatives or give when-not-to-use exclusions for cases where focus is unnecessary, resulting in good but not fully explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the core behavioral profile is covered. The description adds the key context that it operates within an existing session and preserves authentication state, which is useful. However, it does not mention potential side effects like unsaved form loss or network requests, so it adds only moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the action and key constraints without unnecessary words. It is concise and 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 reload action, the description covers the essential context: it must target an existing page in an isolated session and preserves authentication. The output schema exists, so return values need not be described. It could mention waiting for load or error conditions, but given the tool's simplicity and annotation coverage, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It mentions 'explicitly addressed page' but does not explain sessionId, pageId, or timeoutMs. The parameter names are self-explanatory, but the description adds no additional meaning about how to use them or what timeoutMs controls, making it insufficient for a tool with undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reloads a specific page within an existing session and auth state. The verb 'reload' is specific, and it distinguishes from navigation tools like 'navigate', 'back', and 'forward' by focusing on refreshing the current page.
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 usage by requiring an 'explicitly addressed page' in an 'existing isolated session', which tells the agent it needs a session and page already open. It provides clear context but does not explicitly name alternatives or when-not scenarios, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that it lists pages 'belonging only to the addressed session', which clarifies scope but does not add much beyond annotations. It does not describe return format or pagination, but with annotations covering safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and every word adds value. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema exists, so the description need not explain return values. The description covers the purpose and usage context adequately. It could mention that it returns a list of page IDs, but the output schema likely covers that. Given the simplicity and annotations, the description is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but there is only one parameter (sessionId) with a clear name and type. The description mentions 'addressed session' which implies the sessionId parameter, but does not add detailed semantics beyond what the schema provides. Since the parameter is self-explanatory and the description references it, a 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 clearly states the tool lists pages belonging to a specific session, using the verb 'List' and specifying the resource 'pages' and scope 'session'. It distinguishes from siblings like browser_session_list (which lists sessions) and browser_page_create (which creates 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is used to rediscover or inspect all pages in a session, and notes that session creation already returns the initial pageId. It implies when to use this tool (when you need to see all pages in a session) but does not explicitly mention alternatives or when not to use it, though the sibling list makes alternatives apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds valuable behavioral details: error handling (returns OPERATION_TIMEOUT) and that it does not close MCP or browser sessions on failure. This goes beyond the annotations and provides actionable information for an agent. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both directly relevant. The first states the action and a key behavioral constraint (deterministic ordering). The second covers error handling and session preservation. No clutter or redundant phrasing.
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 action and error behavior, and an output schema exists (so return format is handled elsewhere). However, with six parameters and zero schema descriptions, the description does not fully compensate for parameter ambiguity. It is adequate but not thorough for a mutation tool with destructive annotations.
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 0%, so the description must compensate. The description only mentions timeoutMs ('within timeoutMs (10 seconds by default)') and implies 'locator' but does not explain sessionId, pageId, key, ref, or the locator structure. This is a significant gap; the agent cannot infer parameters from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Press a key on a locator within one explicitly addressed page'. It also distinguishes this from siblings like browser_click (mouse action) and browser_fill (text input) by focusing on keyboard key presses. The verb and resource are specific, and the phrase 'within one explicitly addressed page' adds scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context about usage: it operates on a specific page and preserves deterministic ordering with other operations. However, it does not explicitly mention alternatives or when not to use this tool (e.g., when to use browser_fill or browser_click instead). The context is clear but lacks explicit exclusions or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: idempotency (already in annotations), timeout bounding, and session isolation. Also notes that the locator can be semantic or CSS, giving insight into how the tool locates elements.
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, two sentences, and front-loaded with the core action. No redundant information or fluff.
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?
Provides sufficient context for a simple action but does not elaborate on the complex locator schema, potential failure modes, or prerequisites. Given the complexity of the input schema, it could be more explanatory, but it is adequate for an experienced user.
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 0% and the description does not explain the meaning of key parameters (ref, pageId, locator, sessionId) nor the locator structure. It only indirectly hints at timeoutMs and sessionId. This falls short of compensating for the lack of parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (uncheck a checkbox) and the resource (checkbox), with explicit mention of locator strategies (semantic or CSS) and page targeting. It distinguishes from sibling tools like browser_check.
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?
Clearly implies when to use (to uncheck a checkbox) and provides operational context (idempotent, bounded by timeout, session-isolated). However, it does not explicitly contrast with alternatives like browser_check or mention 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations by stating that only the specified page is affected, and other roles' pages/sessions remain untouched. This is valuable because the tool is a navigation action that mutates history position but is scoped. It does not contradict the annotations and provides useful isolation semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that states the action, scope, and isolation guarantee without unnecessary filler. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 simple nature, the presence of an output schema, and annotations, the description covers the essential behavior and scope. It does not cover edge cases such as behavior when there is no history, but that is likely acceptable for a low-complexity tool. The description is complete enough for basic invocation and role isolation.
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's parameter descriptions are absent (schema_description_coverage is 0%), so the description must compensate. It mentions page and session concepts indirectly, but it never explains the meaning of sessionId, pageId, or timeoutMs. The description alone is insufficient for an agent to know how to correctly populate the 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 the tool's function: 'Navigate backward in the history of one explicitly addressed page.' It uses a specific verb ('navigate backward') and resource ('history of a page'), and the phrase 'one explicitly addressed page' differentiates it from broader navigation or session-level tools. It is also distinct from sibling tools like browser_forward and 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context: the action applies to exactly one page and does not affect pages/sessions used by other roles. This clarifies the scope but does not explicitly state 'use this instead of browser_forward when...' or list exclusions. Thus context is clear, but explicit when/when-not alternatives are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description doesn't need to restate that. It adds valuable context beyond annotations by mentioning bounded timeout and strict ambiguity errors, which inform error handling. It also clarifies that source and target must be on the same explicitly addressed page, a behavioral constraint not present in annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise two-sentence statement that leads with the core action and immediately provides essential scope and behavior details. Every phrase earns its place, with no fluff or redundant information. It front-loads the purpose and adds constraints 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 (drag and drop across frames, multiple locator strategies), the description provides a solid high-level overview: it covers the operation type, page scoping, session binding, timeout behavior, and ambiguity handling. It doesn't mention iframe support or the details of source/target resolution, but those are captured in the schema, and with an output schema present, return values needn't be described. The description is adequately complete for orientation, though a mention of iframe capability would improve 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?
Schema description coverage is 0%, so the description carries full responsibility for parameter explanation, but it only vaguely references 'semantic or CSS-located' elements. It doesn't mention sessionId, pageId, timeoutMs, or the structure of source/target. The schema itself is rich, but the description fails to bridge that gap for an agent that might not parse the JSON schema deeply. This falls short of compensating for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: dragging a semantically or CSS-located element onto another, which directly distinguishes it from other browser interaction tools like click, hover, or fill. It also specifies the scope (one explicitly addressed page) and adds useful qualifiers (same page/session, bounded timeout, strict ambiguity errors), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use this tool (when dragging is required) and sets expectations about resolution (same page/session, timeout, ambiguity). It doesn't explicitly mention alternatives or when not to use it, but the context is clear enough for an agent to infer that this is the drag-and-drop operation among the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that there is no global current page, a behavioral trait not covered by annotations. It also reinforces the read-only nature implied by the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, consisting of two clear sentences that directly convey the necessary information 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 does not specify the return value or potential error conditions, but for a simple read operation with readOnly and idempotent annotations, it may be sufficiently complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description hints at the need for sessionId and pageId by mentioning 'IDs returned for the intended session', but it does not explain timeoutMs. Since the schema provides no parameter descriptions, the description only partially compensates.
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 that the tool reads the current URL of a specific page and explicitly requires addressing. It distinguishes itself from any global current page concept, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides guidance that IDs are necessary because there is no global current page, but it does not explicitly contrast with alternative tools or specify when to choose this over other navigation or read operations.
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, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context by stating the screenshot is bounded in-memory, uses measured CSS-pixel clips, performs encoded-byte validation, and does not write to caller-controlled paths or inspect other sessions. This adds meaning beyond the annotations, justifying a 4.
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 paragraph of about three sentences, front-loaded with the core action and then detailing constraints. It is compact with no filler, but it could be more structured (e.g., bullet points) to separate capture modes. Still, it is efficient and earns a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with several capture modes and iframe support, but the schema and output schema provide substantial detail. The description covers scope, bounds, and safety without needing to explain return values. It misses some edge-case guidance (e.g., what happens on invalid locators), but given the richness of the schema, it is complete enough for an agent to act 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 0% according to context, so the description must carry the load. The description mentions 'explicitly addressed page' and 'bounded iframe chain,' which clarifies the frame parameter and element selection, but it does not explain the semantics of sessionId, pageId, or timeoutMs exhaustively. Since the schema itself is rich with enums and descriptions for those fields, the description adds only marginal value, so a 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 clearly states the tool captures a bounded screenshot of a single page or element, with specific modes (viewport, full page, element) and constraints. It distinguishes itself from siblings like observe or snapshot by focusing on image capture, and the description's specificity (e.g., 'bounded in-memory PNG') makes the 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying capture modes and options like iframe chains, and states a key limitation: it does not write to caller-controlled paths. It does not explicitly mention alternatives or when not to use it (e.g., for text extraction), but the context is clear enough for an agent to infer appropriate use cases, so it earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate idempotence and non-destructiveness, and the description adds important behavioral constraints: it only accepts locators, never arbitrary JavaScript or coordinates. It does not discuss failure modes or visibility guarantees in detail, but the annotations reduce the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and contains no redundant filler. The usage guidance and constraint are expressed in the same concise description.
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 annotations, output schema, and reasonably self-describing sibling tool names, the description is mostly complete for a focused scrolling tool. It could improve by mentioning the element ref parameter or timeout behavior, but the core workflow is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning, but it only explains the locator concept and the 'explicitly addressed page' idea. It does not explain optional parameters such as ref or timeoutMs, nor does it clarify how sessionId and pageId combine to address the page.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: scroll a semantic or CSS locator into the viewport of a specific page. It also differentiates the tool from siblings by emphasizing that the target is a locator and that arbitrary JavaScript and coordinates are never accepted.
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 context: use before inspection or interaction when an off-screen target must become visible. It does not explicitly name or contrast alternative browsing tools such as browser_scroll, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), the description discloses many behaviors: rejection of oversized DOM, cursor expiration and staleness, password redaction, partial content as aria-yaml-fragment, and separate short-lived element refs. These add rich context not present in annotations and align with them.
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 dense but well-structured, front-loading the purpose first, then constraints and parameter-specific behaviors. Each sentence contributes unique information, though it is longer than necessary and could be more succinct while preserving value.
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 complexity and richness of the schema (13 parameters) and the presence of an output schema, the description covers many operational aspects: cursor semantics, truncation, redaction, and ref limitations. However, it still does not fully explain all parameter interactions or the exact output format, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter explanations. It mentions interactiveOnly, maxChildren, nextCursor, and refs, but omits many parameters like maxDepth, maxBytes, maxChars, includeBoundingBoxes, and scope details. The vague statement 'Semantic scope, depth, boxes...' does not suffice for a 13-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 tool inspects a bounded accessibility-oriented snapshot of one explicitly addressed page, with options for scoping via a locator and iframe chain. It uses specific verbs and resources ('inspect', 'accessibility-oriented snapshot') and distinguishes from sibling tools like browser_observe by emphasizing accessibility and boundedness.
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 that this is for accessibility-oriented inspection, and mentions parameter usage like interactiveOnly and maxChildren. However, it does not explicitly state when to use this tool over alternatives (e.g., browser_observe) or list exclusion criteria — only implicit contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and openWorldHint=true, so the description needn't repeat those. It adds the crucial nuance about not changing the global active page, which is beyond the schema/annotations. 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?
Two sentences, front-loaded with action, no fluff. Adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations and schema, description covers the key behavior and the global active page nuance. Lacks mention of timeoutMs, but that's in schema. Sufficient for a simple navigation 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 coverage is 0%, so description should compensate. It mentions absolute HTTP(S) URL and the sessionId/pageId pair, but doesn't clarify timeoutMs or beyond what schema says. Partial 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: 'Navigate an explicitly addressed page to an absolute HTTP(S) URL.' It identifies the specific resource (page) and action (navigate), and distinguishes from siblings like browser_reload or browser_back by emphasizing the explicit address and URL.
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 instructs to use the sessionId/pageId pair and clarifies that navigation never changes the global active page, which guides selection. It doesn't explicitly list alternatives (e.g., browser_get_url) but the context implies when to use this vs siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, establishing the safety profile. The description adds that the tool operates on visible text and remains within a page/session, providing additional scoping context beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action ('Read visible text') and packs essential details (locator types, iframe chain, page/session confinement) without waste. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the locator (with iframe chains) and the presence of an output schema, the description covers the core purpose and scoping adequately. It does not explain return values, but that's covered by the output schema. It is sufficiently complete for a read-only tool with safety annotations, though it could mention timeout behavior or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the burden. It explains the locator concept ('semantic or CSS locator' and 'iframe chain'), adding meaning for the complex locator parameter. However, it does not explicitly address sessionId, pageId, or timeoutMs, leaving some parameters only schema-defined. The value added is partial, not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads visible text from a semantic or CSS locator on a specific page. It distinguishes itself from sibling tools like browser_snapshot or browser_get_title by specifying the locator-based extraction and page confinement.
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 identifies the scope: 'one explicitly addressed page' and 'the lookup remains confined to that page and session.' This gives clear context for when to use the tool, but it does not name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: it explicitly states idempotency, timeout bound (timeoutMs), and session isolation. It also clarifies the locator strategy (semantic or CSS). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no excessive detail. The description is well-structured and directly conveys the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action and key constraints (idempotent, timeout, session). It does not delve into edge cases like element not found, but since an output schema exists (though not shown), return values are not required. Overall, it is sufficiently complete for typical use.
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 only mentions timeoutMs and session indirectly. It does not explain the meaning of ref, pageId, or locator structure. Given the schema has 5 parameters with 0% description coverage, the description adds limited parameter meaning.
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 (ensure a checkbox or radio is checked) and specifies the target type and how it is located (semantically or by CSS). It also distinguishes from similar tools like uncheck by focusing on checking.
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 usage for checking checkbox/radio elements and mentions authentication via session, but it does not explicitly contrast with alternatives like browser_click or browser_uncheck. However, the purpose is clear enough to infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint, idempotentHint), the description adds that closing a session releases all of its pages and isolated browser context, which is a useful behavioral detail. This enriches the agent's understanding without contradicting the provided hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences that pack in the action, its effect, and a usage tip. No word is wasted, and the most critical information appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with clear semantics and adequate annotations, the description covers the necessary aspects: what it does, what gets released, and when to use it. The presence of an output schema ensures return values are documented elsewhere, so the description need not address 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 description does not explain the sessionId parameter in detail; it only refers to an 'explicitly addressed session.' With 0% schema description coverage, more parameter-level guidance would have been helpful, though the tool name and parameter name are intuitive.
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 'close' with a clear resource 'explicitly addressed session' and explains the effect of releasing all pages and isolated browser context. It distinguishes itself from siblings like browser_page_close by focusing on the session-level scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Close each role/account session when its workflow is complete' provides direct guidance on when to call this tool. While it doesn't name specific alternatives, the context makes the use case clear, and the per-session scope is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors beyond annotations: LOCATOR_AMBIGUOUS for ambiguous locators, STALE_ELEMENT_REFERENCE for stale or cross-page refs, exact resolution requirements for iframe chains, and role locator name exactness. These error semantics and constraint details are valuable and not present in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: main behavior, locator/iframe constraints, and durability advice. Highly front-loaded and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex locator schema and an output schema, so return values need not be described. The description covers the dominant complexities—locator types, iframe chains, exact matching, and error cases—but omits timeout semantics and the required session/page addressing parameters, leaving a small gap given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for locator strategies, iframe chains, snapshot refs, and exact matching, but it does not explain sessionId, pageId, timeoutMs, or the ref pattern format beyond calling it 'short-lived.' This is partial but incomplete compensation.
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 specifies a precise action: 'Click exactly one semantic/CSS locator or short-lived snapshot ref on one explicitly addressed page.' It clearly differentiates from sibling tools like browser_double_click, browser_hover, and browser_focus by emphasizing exactly one click and explicit page addressing.
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 locator types, iframe constraints, and exact-match behavior. The final advice 'Prefer semantic locators for durable workflows' gives actionable guidance, though it does not explicitly name alternatives or state when not to use this tool versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only (readOnlyHint: false). The description adds valuable behavioral context about cookie/storage sharing with the session and advises when isolation is needed. It does not disclose all potential side effects (e.g., that a new tab might appear visibly), but it goes beyond annotations by explaining the sharing semantics, which is useful for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences with no redundancy. The first sentence gives the core action, the second provides usage context. Every word contributes to the meaning, and it is front-loaded with the essential purpose.
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 tool with one parameter, the description fully covers the main use case and contrasts it with an alternative. It does not detail what the created page looks like or how it behaves initially, but an output schema is present (context signal shows), which likely covers return values. The sharing/isolation guidance makes the tool's context clear enough for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for parameter explanation. It mentions 'explicitly addressed session,' which implies the single parameter sessionId identifies the target session, but it does not explicitly state that sessionId is the unique identifier for the session. This is implicit rather than direct, so it only partially compensates 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create an additional page inside one explicitly addressed session.' This uses a specific verb (create) and resource (page), scoped to a session, and distinguishes it from sibling tools like browser_session_create (which creates sessions) and browser_page_close (which closes pages). 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use it for another tab that must share that session's cookies and storage; use a separate session instead when identity or authentication must be isolated.' This clearly states when to use this tool versus when to use a separate session, offering a concrete alternative and exclusion condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavior beyond the annotations: popup pages receive a new pageId with isDefault=false, may be closed on page-limit excess, dialogs must be handled atomically because they cannot be inspected later, and returned dialog text is bounded. This complements the binary readOnly/destructive/idempotent flags without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded: the first sentence captures the core purpose and mechanism, and subsequent sentences cover popup behavior, dialog behavior, and usage. Every sentence adds information; there is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with nested wait/action/iframe schemas and no property descriptions, the description covers the key decision points: what can be waited on, what actions can be performed, iframe handling, popup semantics, dialog atomicity, and when to prefer this tool. Output semantics are also partially covered, and an output schema exists to handle return 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?
With schema description coverage at 0%, the description compensates substantially by explaining the wait variants (navigation, response, popup, dialog), dialog accept/dismiss semantics, prompt text bounding, and iframe-chain locators. It does not explicitly walk through sessionId/pageId/timeoutMs, but those are structurally covered by the schema and names are self-explanatory.
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 that the tool atomically registers a waiter (navigation, response, popup, or dialog) and then performs a click or press on a specifically addressed page. It also distinguishes itself from sibling tools by saying to use it instead of parallel same-session calls when an action triggers an event.
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 explicit usage context: use this when an action triggers a waitable event (navigation, response, popup, dialog) and when coordination matters. It names the alternative pattern (parallel same-session calls) but does not explicitly state when to fall back to simpler sibling tools like browser_click or browser_wait.
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, idempotentHint, and destructiveHint, covering safety. The description adds behavioral context beyond annotations: it lists all sessions, specifies the fields returned, and reveals the important fact that there is no global active session. This adds value without 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 two sentences, front-loaded with the core action and output, and then provides targeted usage context. Every word earns its place with no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no params, read-only), the description fully covers purpose, usage, and a key system nuance. The output schema exists, so return value details need not be explained. The mention of 'neutral workflow metadata' is slightly vague but the overall context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 as per guidelines. The description correctly adds no parameter details since none exist, and the schema is fully covered with no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('browser sessions'), and specifies exactly what is returned: sessionId, lifecycle status, name, and workflow metadata. It distinguishes itself from siblings like browser_session_get by emphasizing 'every' session and the lack of a global active session.
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 explicitly instructs to use this tool to recover the correct session for roles/accounts, and highlights that there is no global active session. However, it does not explicitly name alternatives like browser_session_get for when a specific sessionId is already known, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the readOnly/idempotent annotations by detailing privacy and completeness limitations: credentials and fragments are removed, headers/cookies/bodies/storage/WebSockets/service workers/data URLs are never captured, console stacks are omitted, text is best-effort redacted, and sinceEventId use is explicitly non-destructive. It also warns that results may be incomplete and to inspect gap and droppedCount.
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 front-loaded with the core purpose and packs substantial behavioral detail into a compact paragraph without filler or redundant schema repetition. It is dense and somewhat long, but the complexity of the tool justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, 7 parameters, and output schema, the description is very complete. It documents source semantics, text retrieval behavior, exclusions, redaction, checkpoint usage, and completion caveats. The rendered output schema covers the remaining response structure, so the description does not need to explain return values itself.
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?
Although the schema has 0% description coverage, the tool description compensates strongly for the most important parameters: 'source' receives detailed enum semantics, 'includeText' is explained with its restrictions, 'sinceEventId' is described as a non-destructive checkpoint, and sessionId/pageId map to 'one explicitly addressed page.' Less direct attention is given to limit, timeoutMs, and their defaults, so it stops short of a full score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'Read bounded observations recorded for one explicitly addressed page.' It then distinguishes the four source types, making it clear the tool is for observing console, page-error, network, and request-failed events, which separates it from the snapshot/visible-text/state siblings.
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 explicit guidance on when to use each source, notably distinguishing network responses from requestFailed events and explaining when includeText is meaningful. It does not explicitly mention alternatives among the sibling tools, but it provides strong within-tool selection guidance and advises inspecting gap and droppedCount before treating evidence as complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the mutating nature is clear. The description adds valuable behavior: sessions have isolated cookies/storage/pages, contextSettings are validated, geolocation is the only supported permission, and the response returns sessionId, initial pageId, and normalized effective settings. It could mention lifecycle/cleanup implications, but overall it gives meaningful transparency beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized, with the core action and key behavior front-loaded. Every sentence adds value, particularly around isolation, permissions, and return values. It is slightly long due to the contextSettings enumeration and redundancy with the schema, but no sentence is wasted.
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 nested schema, zero schema descriptions, and many siblings, this description is comprehensive. It explains the session-creation semantics, isolation requirements, permission constraints, supported settings, restoration via stateId, and the deterministic initial pageId in the response. It is complete enough 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It names the contextSettings fields in prose (viewport, scale, locale, timezone, color scheme, reduced motion, user agent, geolocation) and explains stateId's restore purpose. However, it does not explain the 'name' or 'metadata' parameters, and the mapping between 'scale' and deviceScaleFactor is not explicit. Still, it covers the critical parameter semantics well.
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 and resource: 'Create a new isolated browser session with its own cookies, storage, pages, and optional validated contextSettings.' It clearly distinguishes the tool from siblings like browser_session_get/list/close and browser_page_create by emphasizing isolation and session creation. This is unambiguous and context-rich.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Create a separate session whenever a task involves a different user, account, role, authentication state, device profile, accessibility preference, permission profile, or independent parallel workflow.' It also states a clear exclusion: 'never reuse one session for identities or context settings that must remain isolated,' plus the special-case use of stateId for restoring saved state. This is strong usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait beyond the annotations: 'state contents and secrets are not returned'. This prevents an agent from assuming that listing states returns full state data. Combined with the readOnlyHint, idempotentHint, and destructiveHint annotations, the tool's behavior is 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It front-loads the action and resource, then adds the scope and a crucial negative detail without unnecessary words.
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 zero-parameter listing tool with strong annotations and an output schema, the description is complete. It clarifies what is returned (IDs only) and what is not returned (contents/secrets), leaving no major gaps for an agent selecting or invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there is no parameter semantics to explain. The baseline for no parameters is 4; the description correctly implies no inputs are needed.
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 starts with the specific verb 'List' and identifies the resource as 'logical saved-state IDs', while also clarifying they are 'available for optional restoration when creating a new isolated session'. This clearly distinguishes it from sibling tools like browser_session_list or browser_state_save.
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 context: this tool is used to enumerate saved-state IDs for optional restoration during isolated session creation. It does not explicitly state when not to use it or name alternatives, but the use case is specific enough to guide an agent effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description adds valuable transparency by explicitly stating what the tool never returns (paths, launch arguments, environment values, browser state, raw errors). This gives users a clear picture of the tool's limitations and 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 concise and well-structured: two sentences that immediately state the action and scope, followed by a usage note and exclusions. No superfluous wording, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no input schema and the description lists what it returns (version, launch state, configuration, session counts) and what it excludes, it is complete for a diagnostic tool. The sibling tools are all action-oriented (create, close, navigate, etc.), so this runtime info tool is clearly differentiated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is effectively 100%. The baseline for zero parameters is 4. The description does not need to explain parameters, and it doesn't mislead. It adequately conveys the tool's input requirements (none).
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: reporting BrowserMesh runtime information (version, launch state, effective configuration, and session counts) without launching Chromium. It uses a specific verb 'report' and resource 'BrowserMesh runtime', and distinguishes itself from action-oriented sibling tools by explicitly mentioning it does not launch Chromium.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use this to diagnose setup and capacity safely'. It also contrasts with launching Chromium, implying when not to use it (i.e., when you need to launch or interact with the browser). 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, and idempotent behavior, so the description's burden is lower, but it still adds valuable non-obvious behavioral details: the wait occupies the session queue, is bounded by timeoutMs, and must not depend on future queued actions. No contradiction with annotations exists.
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 dense, information-rich sentence with a clear colon-delimited list of condition types. Every clause adds meaningful guidance: scope, condition kinds, queue behavior, timeout, and the alternative tool. No filler or redundancy.
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 complex tool with four parameters and zero schema description coverage, the description is remarkably complete: it defines the wait domain, frame targeting, condition taxonomy, timeout semantics, queue restrictions, and relationship to sibling tools. The output schema covers return details, so no further explanation is needed.
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 0%, so the description carries the full burden. It explains the meaning of condition categories, timeoutMs, 'safe-glob', iframe chains, and text case-sensitivity, going well beyond raw schema. It does not exhaustively narrate every nested locator strategy, but the schema enums cover those details.
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 ('Wait') and enumerates the exact supported condition types: exact/safe-glob URL, load states, locator state with optional iframe chain, and text presence/absence. It also distinguishes itself from the sibling browser_action_and_wait by clarifying this is for deterministic passive conditions only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use versus when not to use: 'must not depend on a later action queued in the same session; use browser_action_and_wait for action-triggered events.' It also mentions the session queue and timeout binding, giving clear operational 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:

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

Score Badge

Copy to your README.md:

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

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/scrollDynasty/BrowserMesh'

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