Skip to main content
Glama
AceAtDev

ascended-browser

by AceAtDev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

browser_open

Opens or navigates browser tabs to load web pages, supporting single URLs or batches of up to five, and returns settled page snapshots for each.

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. 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

TableJSON 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; 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. First observedv0.1.1

TDQS

A4.8/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 behavioral burden and does so: returns once the page has settled, batch results omit page bodies, failed URLs are reported per-row without closing siblings, atomic rollback is opt-in, reuse persists across a resumed task, and attention_required/blocked semantics are spelled out rather than suspending the run.

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?

Front-loaded with the core purpose and dense throughout, with each clause carrying operational detail. It runs long and some sentences (the web_search aside, the blocked/attention handoff) could be tightened, but there is very little filler.

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

Completeness5/5

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

No output schema exists, so the description must describe returns, and it does: the ordered results list as authoritative for tab_id, the settled page snapshot for single-URL, reused=true signaling, and attention_required/blocked fields. Nothing needed to call or interpret the tool correctly is missing.

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

Parameters4/5

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

Schema coverage is already 83%, so the schema documents most parameters. The description still adds real meaning beyond it: reuse defaults and cross-resumed-task behavior, the atomic all-or-nothing tradeoff, the url/urls mutual exclusivity, and the read flag's one-call shortcut. Only 'disposition' is left without prose explanation.

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?

States a specific verb and resource ('open or navigate your current browser tab') plus the secondary effect of waking the workspace. It also implicitly separates itself from siblings by directing content retrieval to browser_extract/observe and discovery to web_search.

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?

Gives explicit when-to-use rules: one call with urls for several sites, single url otherwise, reuse=false only for a genuinely independent tab, and web_search for broad public discovery. It names the alternative tools and the conditions that select them.

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