Skip to main content
Glama
AceAtDev

ascended-browser

by AceAtDev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

browser_open

Wake the workspace and open or navigate your current browser tab. Pass either url or a bounded urls list (maximum 5). To check several sites, open them in ONE call with urls: it opens independent tabs in the same authenticated browser…

Instructions

Wake the workspace and open or navigate your current browser tab. Pass either url or a bounded urls list (maximum 5). To check several sites, open them in ONE call with urls: it opens independent tabs in the same authenticated browser context and returns one compact, ordered result per URL; that results list is the authoritative source for each tab_id. A URL that fails (DNS, block) is reported on its own row and the other tabs stay open. Batch results omit page bodies: next, call browser_extract/observe for every returned tab_id together in one response, since calls on different tabs run in parallel. Returns once the page has settled. By default it reuses your current actor-owned tab, including across a resumed task; set reuse=false only for a genuinely independent second tab (the result carries reused=true when reused). The single-URL result includes a settled page snapshot; use it directly instead of immediately calling browser_observe. A page snapshot with login_available names matching saved vault accounts and directs you to browser_login. A page snapshot with auth_state.state=login_form_visible is not a fatal blocker: follow the user's request and call browser_login when appropriate. Only a returned attention_required=true represents an explicit handoff. A blocked=true page result does not suspend the run: decide whether to take another route or tell the user plainly what could not be completed. For broad public discovery use web_search rather than navigating this tab to a search engine; browser search remains valid when explicitly requested or interaction/personalization matters.

Input Schema

NameRequiredDescriptionDefault
urlNoSingle-page form. Set this URL and leave urls empty/omitted.
readNoReturn the page's readable text with this result, so opening a page in order to read it is one call rather than open then browser_extract.
urlsNoBatch form only. Leave url empty/omitted. Each URL opens its own tab, or returns your tab already open at that URL (reused=true); a failed URL does not close the others.
reuseNoSingle-page form only: default true. URL batches always use independent tabs so atomic rollback is possible.
atomicNoRarely needed. true closes every batch tab if any URL fails (all-or-nothing). Omit for the normal independent behavior.
dispositionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.6
    • changedInput schema / properties / urls / description
      Previous value: -"Batch form only. Leave url empty/omitted. Each URL opens its own tab; a failed URL does not close the others."New value: +"Batch form only. Leave url empty/omitted. Each URL opens its own tab, or returns your tab already open at that URL (reused=true); a failed URL does not close the others."
  2. First observedv0.1.1

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and discloses key behaviors: independent tabs for batches, failed URLs not closing other tabs, omitted page bodies in batch results, settled-page return timing, tab reuse across resumed tasks, and the meaning of attention_required versus blocked states.

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

Conciseness4/5

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

The purpose and main usage rule are front-loaded, and the dense detail is largely useful for a complex browser tool. It is somewhat long for a single paragraph, but most sentences earn their place by preventing common misuse.

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

Completeness4/5

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

There is no output schema, so the description appropriately explains the result shape for single and batch calls, including `results`, `tab_id`, page snapshots, and login-related states. The main gap is that the `disposition` parameter and its enum values are not explained anywhere.

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

Parameters3/5

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

Schema description coverage is high at 83%, so the schema already documents most parameters well. The description reinforces the `url`/`urls` split and `reuse` behavior, but does not explain `read` or `disposition` beyond what the schema provides, and one parameter lacks schema description.

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

Purpose5/5

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

The description states a specific verb and resource: open or navigate the current browser tab, with single-URL and bounded batch forms. It also distinguishes this tool from siblings by naming browser_extract, browser_observe, browser_login, and web_search for their respective roles.

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

Usage Guidelines5/5

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

It gives explicit guidance on when to use `url` versus `urls`, when to set `reuse=false`, and when to prefer `web_search` over navigating the browser tab. It also explains how to follow up on batch results and how to treat login-related page states.

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

Deploy Server

Other Tools