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 destructiveHint=true, openWorldHint=true, and readOnlyHint=false, but the description adds nothing about what a click triggers — navigation, form submission, waiting behavior, or failures when the selector matches nothing. For a destructive, open-world interaction, that missing context is a real gap rather than a minor one.

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 no waste, but it is under-specified rather than truly concise — the brevity costs the agent information it needs about a destructive action.

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?

The schema is fully documented and annotations cover the safety profile, but for a destructive browser-interaction tool with no output schema, the description should disclose at least what happens after the click and how failures surface. Nothing an agent needs beyond the raw parameter list 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?

Schema coverage is 100%, with selector and sessionId both documented, so the baseline is 3. The description adds no extra meaning, such as whether the selector must be unique or whether hidden elements are skipped, but the schema carries the load adequately.

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 (click) and resource (a page element), which an agent can distinguish from siblings like type_text or navigate_to_url. It stops short of naming how it differs from those siblings, so it is clear but not differentiating.

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 rather than evaluate_script, type_text, or navigate_to_url, and no prerequisites such as needing a connected session first. The agent must infer usage entirely 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds only the page scoping ('current page'); it does not disclose what detection produces, whether it waits for widgets, or how it interacts with page state. With annotations covering safety, this is adequate but thin.

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 wasted words. The scope ('current page') is placed where it matters, and nothing extraneous is included.

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 read-only detection tool with fully documented params and annotations, the basic call contract is clear. However, with no output schema and no statement about what detection returns (boolean, list of widgets, coordinates), the agent lacks important information about the result to expect.

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 parameters (sessionId, browserAddress) are fully documented in the schema. The description adds no parameter meaning beyond that, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb and resource: detect captcha widgets in the current page. An agent can tell this apart from generic siblings like get_elements or get_page_content by the captcha-specific target, though the description does not explicitly contrast 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?

No when-to-use, when-not-to-use, or alternative guidance is given. The purpose implies usage, but the agent gets no signal about whether to prefer this over get_elements or evaluate_script when checking for captchas.

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 declare a non-read-only, non-destructive, non-open-world operation, but the description adds nothing beyond the name: it doesn't say whether the session is terminated, whether it can be reconnected, or what state persists. For a session-mutating tool this is a meaningful gap.

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 short phrase with zero waste, but it is under-specified rather than concise; the brevity comes at the cost of missing behavioral and disambiguation 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 session-mutating tool with sibling ambiguity (close_browser), the description omits what happens to the session and when this tool is preferred. The schema covers the parameter, but the behavioral and selection context 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?

Only one parameter with 100% schema coverage that already documents sessionId. With a fully documented single param, the baseline is 4; the description adds nothing but doesn't need to.

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+resource (disconnect from the controlled browser) so the action is clear. However, it gives no differentiation from the closely related sibling close_browser, leaving ambiguity about the distinction.

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 indication of when to use this rather than close_browser or stop_remote_desktop, nor any prerequisites or exclusions. Usage must be inferred entirely by the agent.

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, so the safety profile is known. The description adds nothing beyond that — no mention that arbitrary script can mutate page state irreversibly, no timeout/execution-scope limits, and no statement of what is returned from the evaluated expression.

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 no padding, but it is under-specified rather than concise-but-complete — the brevity costs information an agent needs.

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 code-execution tool with no output schema, the description should at minimum indicate the execution context (page main world vs. isolated), what happens to the result, and any safety caveats. None of that is present, leaving significant gaps for a high-risk 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 description coverage is 100%, so both script and sessionId are documented in the schema itself. The description adds no 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 clear verb and resource ("Execute JavaScript code on the page"), which lets an agent grasp the basic action. However, it gives no differentiation from siblings like click_element, type_text, or get_page_content, which can also be used to manipulate or read a page; the agent cannot tell from the description where arbitrary JS execution fits in the toolset.

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 prefer this tool over the specialized DOM-interaction siblings, nor any exclusion or prerequisite. Usage has to be fully inferred from the name and annotations.

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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds only the 'connected' scoping, with no detail on freshness, auth requirements, or what the 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, front-loaded phrase with no wasted words. It is efficient, though it is brief enough that adding a clause about scope or alternatives would have helped.

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 parameterless read tool with no output schema, the agent still doesn't know what fields the returned browser list contains or how it differs from get_browsers. Annotations cover the safety profile but the description leaves the return shape and sibling distinction unstated.

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 the schema has nothing to document and the description has no parameter semantics to carry. Baseline 4 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 ('Obtener') and resource ('navegadores conectados'), so an agent knows it returns connected browser instances. It does not explicitly contrast with the sibling get_browsers, which is the closest alternative, leaving that distinction implicit.

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 statement of when to use this tool, when not to, or which sibling to prefer (e.g., get_browsers vs. this one). The 'connected' qualifier hints at scope but no usage guidance is given.

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, non-destructive, and open-world, so the safety profile is covered. The description adds nothing beyond that: it does not say whether all matches or just the first are returned, whether the call fails on no match, or what shape the element information takes — meaningful for a DOM query tool with no output schema.

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 no filler and the key condition front-loaded. It is efficient, though its brevity comes at the cost of under-specification rather than tight precision.

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 explain what "information about elements" actually contains and how multiple matches are handled; it does neither. For a DOM query tool operating in an open-world browser session, that leaves the agent guessing at the return contract.

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 sessionId and selector are documented (in Spanish) in the schema itself. The description's phrase "matching a selector" reinforces the selector's role but adds no format details or examples, so the 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 (get) and resource (elements) with the matching condition (by selector), so an agent knows it retrieves DOM element data. It does not differentiate itself from a sibling like get_page_content, leaving overlap ambiguity about which retrieval tool to pick.

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 versus get_page_content, evaluate_script, or click_element, and no mention of prerequisites such as an established browser session. The agent must infer usage entirely from the name and the selector parameter.

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 and the bar is lower. However, the description adds nothing about behavior beyond the structured fields: no mention of DOM size or truncation of large pages, no statement that a live session is required, and no indication of whether it returns the raw source or the rendered DOM.

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, front-loaded sentence with zero filler. It is efficient, though slightly under-specified rather than overly long.

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 single-parameter read tool with no output schema is relatively simple, and annotations cover the safety profile. The description still leaves open what 'current page' means (active tab vs. navigated URL) and whether large documents are truncated, which matters for a page-content scraper.

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%, with sessionId fully documented in the schema, so the baseline of 3 applies. The description does not add any meaning on top of the single parameter, but nothing more is required.

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 HTML content of the current page'), which is enough to separate it from siblings like take_screenshot, get_elements, and evaluate_script. It doesn't explicitly name those alternatives, but the resource word 'HTML content' makes the intent unambiguous.

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 take_screenshot, get_elements, or evaluate_script, nor any prerequisite such as needing a connected browser session. The agent must infer usage entirely from context.

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 declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so the safety profile is partially covered. However, the description adds no behavioral context beyond the annotations: it says nothing about waitUntil semantics, captcha detection/auto-solving, auto-submit side effects, or reconnect behavior, which matter for a complex navigation 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?

The description is a single front-loaded sentence with no wasted words. However, it is under-specified rather than appropriately concise for a nine-parameter tool with captcha automation and destructive behavior.

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?

This is a complex tool with nine parameters, captcha auto-solving, form auto-submission, reconnect support, and destructive/open-world annotations, plus no output schema. The description provides only the bare navigation action, leaving significant behavioral and contextual gaps.

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 documents all nine parameters including waitUntil, captchaType, detectCaptcha, autoSolveCaptcha, and autoSubmitCaptcha. The description adds no parameter meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource ("Navigate to a specific URL"), making the core action clear. It does not mention the browser-session context or distinguish this from sibling browser tools, which keeps it at a 4 rather than 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 tool versus alternatives such as connect_to_browser, open_browser, or evaluate_script. It only implies that the tool is for navigation, without context, prerequisites, or exclusions.

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, and openWorldHint=false, so the safety profile is partly covered. The description adds nothing beyond them — no statement about session lifetime, cost, whether opening creates a billable/side-effecting cloud resource, or how the browser is subsequently reached (presumably via connect_to_browser). For a tool that provisions an external resource this is thin.

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 zero filler and the action front-loaded. It is well-formed; the problem is omission rather than verbosity, which belongs to other dimensions.

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 nine optional parameters, session save/recover semantics, and a family of related browser tools, one sentence is not enough. The description should say where this fits in the lifecycle (open → connect → operate → close) and what happens on re-open with an existing label.

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 every parameter — args, browser enum, stealth, headless, keepOpen, saveSession, recoverSession, ignoredDefaultArgs — is documented inline. The description adds no meaning beyond the schema, which is the baseline 3 case, not a deficiency.

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: 'Open a remote browser in the cloud using CloudBrowser.ai'. It is unambiguous about what action is performed, but it never distinguishes this tool from close sibling names such as connect_to_browser, browser_workspace, or start_remote_desktop, which all sound like plausible entry points.

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 when-to-use guidance, no prerequisites (e.g. API key/auth), and no mention of which alternative to pick when a browser is already open. The agent must infer that this is the first step in a session lifecycle purely from the name.

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

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 only tell the agent this is a non-read-only, non-destructive, closed-world operation. The description adds nothing about whether it creates a session, what happens if access is already active, whether it blocks, or what it returns — meaningful gaps for a state-changing tool with no output schema.

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 is efficient, though its brevity borders on 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 state-changing tool with one vaguely labeled parameter and no output schema, the description omits the lifecycle context an agent needs: relationship to open_browser/connect_to_browser, session effects, and expected result. Only the bare purpose 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?

Only one parameter and schema coverage is 100%, so the schema already carries the documentation burden. The description does not clarify what 'address' means (URL, browser id, or websocket endpoint), leaving the ambiguous label unexplained beyond the schema's generic 'Dirección del navegador'.

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: start remote desktop access to a browser. The start/stop pairing with stop_remote_desktop is implicit in the name, but the description never distinguishes this from connect_to_browser or 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?

No indication of when to use this versus connect_to_browser, open_browser, or resume_saved_session, and no prerequisites such as whether a browser must already be connected or opened. The agent is left to infer the whole workflow.

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 and destructiveHint=false, but the description adds nothing further: it does not say whether this disconnects an active session, what happens if no session exists for the given address, whether the browser stays open, or whether the action is reversible. For a state-changing tool, that is a meaningful gap.

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 is efficient, though arguably under-specified rather than optimally sized for a state-changing 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 one-parameter tool with annotations and no output schema, the safety profile is largely covered by annotations, but the description leaves out the lifecycle context (start/stop pairing, session state requirements, failure behavior) that an agent needs to invoke 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 description coverage is 100%, and the schema documents 'address' as the browser address, so the baseline of 3 applies. The description adds no meaning about the parameter (e.g. that it must identify an active remote-desktop session).

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 ('Stop') and resource ('remote desktop access to a browser'), which an agent can easily distinguish from the sibling start_remote_desktop by antonym. It does not explicitly name or contrast with any sibling, so it falls short of a 5.

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

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

The description gives no when-to-use or when-not-to-use guidance, no prerequisites (e.g. an active remote desktop session must exist), and does not point to start_remote_desktop as the counterpart action. Usage is only implied by the name.

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?

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully carried by structured data and the description rightly does not repeat it. What it fails to add is any context beyond annotations: that the call requires a live connected session, what happens if the page is blank or still loading, or how the image is returned.

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, appropriately sized for a simple read-only capture action. It is efficient rather than padded, though its brevity borders on under-specification given the missing session prerequisite.

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 three-parameter, read-only tool with a fully described schema and clear annotations, the description is adequate but thin. There is no output schema, so a note on what is returned (e.g. raw image data or a reference) would help the agent know what to do with the result, and the connected-session requirement is unstated.

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% — format, fullPage, and sessionId are each documented in the schema, including the enum and defaults — so the description carries no parameter burden. Baseline 3 applies since the description adds nothing about the parameters beyond what is already structured.

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 gives a specific verb plus resource ('Take screenshot of the current page') that is unambiguous and distinct from the browser navigation, clicking, and content-reading siblings. It does not, however, distinguish this from other capture-style actions (e.g. capture of a specific element) or note the scope boundary relative to get_page_content, which returns text rather than pixels.

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 only implied: an agent infers this is the tool for visual capture within a connected browser session, but the description never states the prerequisite (an active session from connect_to_browser/open_browser) or when to prefer get_page_content over a screenshot. No alternatives or exclusions are named.

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?

The annotations mark this as destructive (destructiveHint=true) and open-world, and the schema's clear parameter defaults to true. Typing clears existing field content by default. The description says nothing about this destructive behavior, about failures, or about what happens if the selector does not match. With annotations in place, the description was expected to add context such as the clearing behavior. Instead, it adds almost nothing.

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 waste, but its brevity reflects under-specification rather than disciplined conciseness. It leaves too much unsaid for an action-oriented browser 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?

Given that the tool mutates page state, has a destructive annotation, and defaults to clearing the field, the description is too thin. It omits the clearing behavior, how the element is resolved, and how failures are surfaced. There is no output schema to cover the return values, so the description bears more of the burden.

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 already documents text, clear, selector, and sessionId. The description adds no meaning beyond that coverage, which establishes the baseline of 3. It could have clarified the default clearing behavior or how the text is inserted, but it does not.

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: type text into an element. It does not distinguish the tool from siblings such as click_element or evaluate_script, which could also interact with page elements. The core action is nonetheless unambiguous.

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 indication of when to use this tool instead of alternatives. It does not say when to use click_element versus type_text, when to use evaluate_script, or whether an element must first be focused or visible. No preconditions or exclusions are mentioned.

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