CloudBrowser

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/openWorld/non-destructive annotations, the description discloses the key behavioral traits: it renders a side panel rather than performing work, it does not allocate or connect a browser, and the screenshot display is optional. That prevents the most likely misuse of an ambiguously named tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with what is displayed, followed immediately by the exclusion and the optional behavior. No filler, though the final sentence about sessionId/address reads as a tacked-on workflow note.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does the work of conveying what comes back: a workspace view of active browsers and saved sessions, plus a screenshot when a browser is specified, and the sessionId/address used to continue. Sufficient for a low-risk, zero-required-parameter display tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter is already described as 'Optional owned browser to inspect.' The description adds only mild meaning, clarifying that supplying a browser makes it show that browser and its current screenshot; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action (show a workspace panel of active browsers and saved sessions beside the conversation) and explicitly excludes adjacent capabilities with 'Does not allocate or connect a browser,' which separates it from connect_to_browser and open_browser. It is slightly less clear about how it differs from get_browsers/get_saved_sessions, which return the same underlying data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use the sessionId and address from the selected browser to continue work' implies a follow-on workflow, but there is no explicit statement of when to call this instead of get_browsers or get_saved_sessions. Usage is inferable rather than prescribed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, which is the primary reason credit is limited. The description adds nothing beyond a one-line restatement of the action: it does not mention that clicks can trigger navigation or irreversible page state changes, nor any wait/settle behavior after clicking. With annotations carrying the safety profile, a 2 reflects only marginal added value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One short sentence with no wasted words and the action front-loaded. It is efficient, though its brevity borders on under-specification rather than true conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, open-world mutation tool with no output schema, the description omits what the agent should expect: post-click effects (navigation, DOM changes), failure modes for invalid selectors, and whether the call waits for load completion. Annotations cover the safety flags, but the operational context an agent needs is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters (sessionId, selector) are fully documented in the schema, so the description need not restate them. Baseline 3 applies because the description contributes no additional parameter semantics such as selector matching behavior or handling of non-existent elements.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a verb and resource ('Click on a page element'), so the basic action is identifiable. However, it offers no scope or distinguishing detail relative to siblings such as type_text or get_elements — an agent could not tell from this text alone which interaction tool is appropriate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this versus alternatives like type_text or get_elements, and no prerequisites (e.g., that a session must be connected first) are mentioned. The agent must infer everything from the name and schema.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and readOnlyHint=false, so safety is covered by structured data. The description adds no behavioral context beyond the name — it doesn't say whether the close is graceful, whether tabs/session state is lost, or what happens to an unknown address. With annotations carrying the burden a 2 is still warranted because the description contributes essentially nothing new.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with zero filler, though its brevity edges into under-specification rather than disciplined concision.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no output schema and a near-identical sibling, the description omits the consequences of closing and the disconnect-vs-close distinction an agent needs to choose correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single `address` parameter is fully documented in the schema, so the description need not repeat it. Baseline 3 applies since the description adds no format or sourcing detail (e.g., where to obtain the address) beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Close a specific browser"), which tells an agent what the tool does. However, a sibling `disconnect_browser` exists and the description offers nothing to distinguish closing from disconnecting, so differentiation from siblings is absent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this versus `disconnect_browser` or `browser_workspace`, nor any prerequisite such as needing an active connection first. The agent must infer everything from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds only the notion of 'direct control', which implies a persistent session, but says nothing about whether the connection stays open, whether a session must be released with disconnect_browser, or what happens on failure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence with the key concept front-loaded and no filler. It is efficient, though its brevity borders on under-specification for a stateful connection tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only two fully-documented parameters, an annotation set, and no output schema, the minimum is met. Still missing is what the agent should expect after connecting (does it return a handle? a confirmation?) and how this tool relates to open_browser and disconnect_browser in a typical workflow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%; both browserAddress (with WebSocket URL format) and sessionId are fully documented in the schema. The description adds no meaning beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Connect to CloudBrowser browser for direct control'. An agent can distinguish this from close_browser and disconnect_browser by the verb alone, though it never explicitly contrasts with the similarly-named open_browser sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance, no prerequisites (e.g. where sessionId comes from), and no mention of the alternative open_browser or of disconnecting afterwards. 'For direct control' hints that it precedes the element/script tools, but that is left entirely to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds real context beyond the annotations: destructiveHint=false is reinforced by stating the browser keeps running, so the agent knows state is preserved on the remote side. It doesn't cover what happens to the session ID's validity afterward or whether reconnect is possible, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action, second sentence carrying the crucial disambiguation. Zero waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-param, non-destructive teardown tool with full schema coverage and annotations, nothing material is missing — the lifecycle relationship to close_browser is the one thing an agent needs and it's stated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single sessionId param is already documented in the schema; the description adds no format, provenance, or reuse semantics beyond it. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ('disconnect') plus resource (

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

States the key selection rule: use close_browser if you actually want to stop the browser, implying this tool is for releasing the control session while leaving the browser alive. No explicit 'do not use when' beyond that, so not quite a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that – it does not define what counts as "active," whether closed or suspended browsers are excluded, or what the result list contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with the resource front-loaded and zero filler. It is efficient, though its brevity shades into under-specification rather than disciplined concision.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read tool this is close to adequate, and annotations cover the safety story. But with no output schema, the description should say what the returned list looks like and how "active" differs from connected, which it omits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is no parameter semantics to compensate for; baseline 4 applies. Nothing in the description conflicts with the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Get list of active browsers"), so the operation itself is unambiguous. However, it does not distinguish itself from the near-identical sibling get_connected_browsers, and "active" is left undefined, so an agent cannot tell which one to call from the description alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no prerequisites, and no exclusions. Given a sibling named get_connected_browsers that appears to serve the same need, the absence of any routing hint is a real gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this as a safe read-only, non-destructive, non-open-world operation. The description adds the useful caller-specific connected-browser scope, but does not describe return shape, empty-state behavior, or how connected browsers relate to saved sessions or general browser listings.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is a single front-loaded sentence with no wasted words. It states the action, resource, and scoping condition efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter, read-only list tool with annotations covering safety, the description is largely sufficient. It could be more complete by clarifying what the returned browser entries represent relative to sibling listing tools, but the core call context is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there are no parameter semantics to explain. With no input schema complexity, a baseline of 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: list browsers, scoped to those this caller has connected for direct control. That scope helps distinguish it from broader browser-listing siblings, though it does not explicitly name get_browsers as the alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the phrase 'this caller has connected for direct control,' suggesting it is for checking already-connected controllable browsers. However, it gives no explicit when-to-use guidance or comparison against sibling tools such as get_browsers or connect_to_browser.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is carried. The description adds nothing beyond that — no note on whether a selector matching zero elements errors or returns empty, no indication of result cardinality or size for broad selectors on live pages.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with zero filler, so nothing needs trimming. Brevity here is close to the useful limit; the only issue is that there is not enough content rather than too much.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A read-only two-parameter lookup with full schema coverage needs only modest prose, and the annotations cover the safety profile. However, with no output schema, the description never says what 'information' is returned, leaving the agent unable to predict the response shape.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both selector and sessionId are already documented in the schema. The description restates only the selector concept and adds no extra semantics such as selector syntax support, scoping, or behavior for multi-match selectors. Baseline 3 applies when the schema does the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a generic verb ("Get information about") and resource ("elements") plus the selector-based filter, so the domain is identifiable. But "information" is undefined — attributes? text? bounding boxes? counts? — and nothing distinguishes it from the sibling get_page_content, which plausibly returns similar data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this instead of get_page_content, click_element, or take_screenshot, and no stated prerequisites beyond the session. The agent must infer that this is for querying DOM elements by CSS selector rather than reading whole page content.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is largely covered. The description adds the authorization/terms constraint, which is useful, but says nothing about return size, what 'current page' means in the session, or whether the HTML is raw or processed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences, front-loaded with the core action, then usage constraints. No filler. Slightly verbose on the legal/authorization framing relative to the operational content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only fetch with a single fully-documented parameter and no output schema, the description covers purpose, scope, and ethical constraints. However, it leaves notable gaps: nothing about what the returned HTML looks like or how it relates to 'current page' in a multi-tab session.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single sessionId parameter is fully described in the schema (100% coverage) as the connected browser session ID. The description does not elaborate on the parameter or clarify multi-session behavior, so it adds no meaning beyond the schema — baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get the HTML content of the current page') with a clear purpose tied to answering the user's request. It implicitly differentiates from siblings like get_elements and take_screenshot by emphasizing HTML content, but never names those alternatives explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a real usage boundary: only for sites/accounts the user owns or is authorized to use, and explicitly not for crawling or bulk extraction of third-party sites. That is a clear when/when-not, though it doesn't route to a sibling tool for those excluded cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this as a read-only, non-destructive, non-open-world operation, so safety is covered. The description adds no behavioral context beyond the basic purpose, such as ordering, pagination, or what fields a saved session listing contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence with no wasted text, and the key concept is front-loaded. It is very terse, but it does not bury important information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple parameterless list operation with annotations and no output schema, the description identifies the resource adequately. However, it lacks any linkage to the sibling resume/remove saved-session tools, which would help an agent choose the right operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is nothing for the description to clarify beyond the schema. This meets the baseline expectation for a parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: 'Get list of saved sessions'. It is distinguishable from most browser-action siblings, but it does not explicitly differentiate itself from the closely related remove_saved_session and resume_saved_session tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit guidance on when to use this tool versus alternatives such as resume_saved_session or remove_saved_session. The intended use is only implied by the phrase 'Get list'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag destructiveHint=true and openWorldHint=true; the description adds real behavioral context beyond that — it disclaims CAPTCHA solving, says to halt at auth walls and MFA, and bounds the tool to authorized destinations. It doesn't describe what happens after navigation (page state, whether content is returned) or timeouts, which keeps it at 4.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core action, then the safety constraints. Every clause carries actionable information: scope, authorization, stopping conditions, and the CAPTCHA disclaimer.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a navigation tool with full schema coverage but no output schema, the description covers authorization, interruption behavior and safety well. It omits post-navigation expectations (e.g., that content is not returned and get_page_content should follow), which would round it out.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so url, sessionId, waitUntil and browserAddress are already documented including the enum and default. The description adds no extra parameter meaning (e.g., when to prefer networkidle0 vs load), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Navigate the connected browser to a URL') and scopes it to user-requested destinations. This clearly separates it from siblings like get_page_content, click_element or open_browser, which either read, interact with, or create the browser.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to-use conditions: only URLs the user asked for, only sites/accounts the user owns or is authorized to use, and it explicitly stops at logins, MFA and CAPTCHAs, handing control back to the user. It doesn't name sibling alternatives (e.g., use get_page_content after navigation), 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds one genuine behavioral disclosure beyond annotations: browsers open without stealth fingerprints, and a CloudBrowser account must already be connected. With readOnlyHint=false, destructiveHint=false already declared, the description leaves unaddressed resource-lifecycle behavior (auto-close on inactivity, session persistence) and what happens if the account is not connected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the action, then the policy constraint, then a short disclosure. No redundancy or filler; the middle sentence is the longest but is doing real work.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a fully documented schema and annotations covering safety hints, the description is nearly sufficient; the main residual gap is that no output schema exists and the description never indicates what opening returns (an instance label/id) or that follow-up tools like navigate_to_url operate on it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with defaults and enum values documented for all six parameters, so the schema carries the semantics and baseline 3 applies. The description contributes nothing parameter-level, not even the fact that all parameters are optional or how label/saveSession/recoverSession interact.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Open one remote browser in the cloud") and adds the account binding ("connected CloudBrowser account"), which distinguishes it from connect_to_browser/start_remote_desktop conceptually. It never names a sibling or explicitly excludes alternatives, so an agent must infer the boundary with connect_to_browser and resume_saved_session.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The second sentence gives an acceptable-use constraint (only sites/accounts the user owns and authorized to use, follow terms), which is policy guidance rather than tool-selection guidance. There is no statement of when to pick this over connect_to_browser, resume_saved_session, or start_remote_desktop, so selection remains implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds nothing beyond that: it never says whether deletion is permanent, whether the session's underlying browser state is retained, or what happens if the label does not exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single four-word sentence with no filler and the operation front-loaded. It is efficient, though nearly too terse for a destructive operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-read-only tool with no output schema, the description should say at minimum whether deletion is irreversible and how a missing label is handled. Instead it restates the name and leaves the agent to infer consequences.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the single `label` parameter is already fully documented in the schema and baseline is 3. The description contributes nothing additional about label format, case sensitivity, or matching behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ("Delete") and resource ("saved session"), so an agent immediately knows the operation. It does not differentiate against nearby siblings such as get_saved_sessions or resume_saved_session, which keeps it below a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this versus get_saved_sessions or resume_saved_session, and no prerequisites or confirmation conditions. With three session-related siblings, the omission of routing guidance is a real gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare the generic non-readonly/non-destructive profile; the description goes well beyond them by disclosing the reuse-vs-allocate branch, that allocation is metered, the 180-second idle timeout, and that cookies and storage are restored but tabs are not. The idempotency contract around requestId is also flagged, which is exactly the kind of non-obvious trait annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, each carrying a distinct obligation, with the core behavior front-loaded before the operational warnings. No filler and nothing buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should ideally say what the return payload contains; the phrase 'the returned browser' hints at it but leaves the shape unspecified. Otherwise, for a two-parameter read-or-allocate operation, the behavioral coverage is sufficient to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%, and the sole description is on requestId. The description does clarify that 'label' selects an active browser to reuse, which adds meaning beyond the bare string schema, but it never states whether the label refers to a saved-session name or a browser label, nor what happens on a label mismatch.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Resume an existing saved session owned by the connected account') and immediately qualifies it with the reuse-or-allocate mechanism, which cleanly separates it from open_browser and get_saved_sessions without needing to name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit gating condition ('Only call after the user requests resume'), an explicit retry prohibition ('Never retry an ambiguous allocation or change requestId'), and a follow-up obligation ('Close the returned browser when finished'). This is when/when-not guidance no sibling listing could improve on.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations establish that this is a non-read-only, non-destructive, closed-world operation, but the description adds no behavior beyond that. It does not say whether a persistent session is created, whether it must later be terminated with stop_remote_desktop, whether credentials or an existing connection are required, or what 'remote desktop' actually exposes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with the action front-loaded, so there is no waste. Brevity here reflects under-specification rather than disciplined conciseness, which caps the score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and rich sibling alternatives, the description should explain the session model and the pairing with stop_remote_desktop. It omits prerequisites, return behavior, and disambiguation from connect_to_browser, leaving real gaps for an agent deciding how to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single 'address' parameter is documented in the schema, so the description correctly adds nothing redundant. Baseline 3 applies since the schema does the heavy lifting and the description contributes no extra meaning such as format or where the address comes from.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

It names a specific verb ('start') and resource ('remote desktop access to a browser'), so the basic action is intelligible. However, it does not distinguish itself from the sibling 'connect_to_browser', which an agent could easily mistake for the same operation; only the 'remote desktop' phrasing hints at a difference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this instead of connect_to_browser, whether a browser must already be open, or when stop_remote_desktop should follow. The agent must infer the entire lifecycle from sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds nothing beyond them: it doesn't say what happens to the browser session, whether the tab/window closes, or what an agent should expect afterward (unlike close_browser, also a sibling).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with the action front-loaded and no filler. Brevity is appropriate for a one-parameter tool, though it under-delivers on state-changing context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-param tool with annotations and no output schema, the description is minimally sufficient to call it. It still leaves open whether a session must exist and how this differs in effect from disconnect_browser or close_browser.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter ('address') at 100% schema description coverage, so the schema carries the burden. The description adds no format hints or examples for the address, which is acceptable at this coverage level but not additive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb ('Stop') and resource ('remote desktop access to a browser'), so the effect is unambiguous. It implicitly pairs with the sibling start_remote_desktop but never names it or states the inverse relationship explicitly, keeping it just under a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to call this versus alternatives, nor any prerequisite such as an active remote desktop session or connected browser. The agent must infer that start_remote_desktop must have been called first.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds little beyond the schema, however: it does not explain capture return format, whether the image is returned inline or saved, or any session-related behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single, front-loaded sentence with no filler. The core action and scope are stated immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple screenshot tool with complete schema coverage and safety annotations, the description is minimally adequate. It omits what the tool returns, which is particularly relevant without an output schema, but otherwise leaves no critical invocation detail missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents the format, full-page flag, and session ID parameters. The description does not add any parameter-specific meaning beyond what the schema already provides, which is the expected baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: taking a screenshot of the current page. It is clear what the tool does, though it does not name any sibling or alternative because none of the listed sibling tools overlap with screenshot capture.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use this tool versus alternatives, nor any prerequisites such as requiring a connected browser session. Usage is only implied by the phrase 'current page'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already disclose destructive=true, readOnly=false, and openWorld=true, so the safety profile is covered externally. The description adds no behavioral context beyond the basic action: it does not mention overwriting existing content, the default clear behavior, or potential side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no filler. It communicates the core action efficiently, though it is minimal rather than richly structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given complete schema coverage and annotations that cover safety, the description is minimally adequate. However, for a destructive browser interaction tool, it lacks usage context and any indication of constraints or expected side effects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with all four parameters documented in the input schema, including the default clear behavior. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: "Type text into an element." An agent can distinguish this from click_element or navigate_to_url, though the description does not explicitly name alternatives or clarify when typing is preferred.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides no when-to-use guidance, prerequisites, or alternatives. It does not say whether the element must be focused, whether this works on hidden elements, or when to use click_element instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.