Skip to main content
Glama

Open page and read digest

browser_open
Idempotent

Navigate to a URL and get the semantic DIGEST (~2-3KB): landmark regions with ids, headings with their section, and the top-15 RANKED actionables with complete absolute navigation hrefs in structuredContent (privacy rules still apply).

Instructions

Navigate to a URL and get the semantic DIGEST (~2-3KB): landmark regions with ids, headings with their section, and the top-15 RANKED actionables with complete absolute navigation hrefs in structuredContent (privacy rules still apply). Embedded data URLs instead return a resource descriptor with MIME type, encoded length, explicit omission and bounded browser_text recovery arguments; no opaque payload is silently truncated. PDF links include a document hint with URL, title, evidence and source observation/id for an external PDF reader. A successful application/pdf response returns document {type, mediaType, url, title, source?, reader, textExtracted: false}, instead of pretending its text was observed; source retains the prior observation/id/title/href when an exact current link supplied the destination. Navigation metadata includes requestedUrl, finalUrl, navigationUrlsSanitized: true (navigation query values and opaque payloads remain hidden), and redirectChainAvailable. When available, redirectChain lists observed HTTP response URLs/statuses, with redirectChainScope: http, redirectChainTotal and redirectChainTruncated; client-side navigations are reflected by finalUrl, never invented as HTTP redirects. Ids (n_xxx) expire on every new observation. A top entry with placeholder: true is an EMPTY form field whose name is its placeholder — a prompt, never data from the site. Every observation reports authState and cookiesForOrigin: this tool drives ITS OWN isolated per-session BrowserContext, cookie jar and storage. authState is conservatively unknown; a cookie count is evidence, not proof of identity, because authentication can also live in storage, bearer state or the URL. For a task that needs the real signed-in session from another browser, this is the wrong instrument. If the site answered with a bot-mitigation interstitial, structuredContent carries blocked: true and challenge {vendor, reason, status, signal, and vendors when more than one is detected — vendors chain, and a confidently wrong name is worse than unknown for per-vendor retry routing}: the content was WITHHELD, which is a different answer from a page that has little on it — fall back to another fetcher rather than recording an empty result. A request that never reached an HTTP response returns failure {layer: dns|tls|transport|http, code, hostUp} with ok:false and navigationCompleted:false. Without an HTTP response, finalUrl is null and retainedUrl identifies the previous page separately; a DNS or certificate failure is neither a block nor an empty page. The open waits (bounded) for window.onload AND briefly watches the fresh document for timer-delayed first paints (entry ads armed via setTimeout at parse time), so late overlays/modals enter the FIRST digest; if the document is STILL not complete, structuredContent carries loading {readyState, waitedMs} and the prose says so — treat the digest as a truthful walk of an UNFINISHED page and re-observe before trusting completeness. Returns runtime (version/build) for reproducible feedback and observationId (opaque identity of this observation) in structuredContent, and digest (marks/heads/top) in structuredContent and prose — read the fields, do not parse the text. When observed images exist, digest.visualContent declares that their pixels have not been read as text, with bounded example IDs; a negative text search is not evidence that content inside those images is absent. Use browser_screenshot when those pixels matter. After a SAME-ORIGIN navigation, structuredContent may also carry carried: which strong-identity elements (data-testid / authored accessible names) persisted from the previous page and how their state/content moved (the cart badge "1"→"2"), including contentChanges that identify changed semantic components without exposing raw values, plus only-before/only-after COUNTS of page-specific content — those counts are "different page", never removals/additions. Optional redact: session privacy rules — any name/label/text/state string containing a listed term leaves every observation as [redacted], and each observation carries an attestation that the policy ran (policyRevision, rulesActive) — never hit counts, which would tell you whether and how often the hidden term occurs. Raw form values are never returned; sensitive categories use coarse change signals and declare same-bucket uncertainty.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesURL (https implied; file:/data: accepted)
digestNocompact = the extraction profile: no bbox, no section, and the prose collapses to one line because the digest is already in structuredContent. Halves the per-page cost for a sweep that reads fields and never clicks.
redactNoSession privacy rules: strings to redact from every observation from now on (replaces any previous rules)
sessionIdNooptional: the session this call belongs to (from browser_session_open). Omitted uses the shared default session.
waitForChallengeNoms to wait for a bot-mitigation interstitial to clear by itself (capped at 30000). Many do within a few seconds. Omitted = do not wait, just report.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.1/5.0
Behavior5/5

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

Far exceeds the annotations: it discloses session isolation (own BrowserContext/cookie jar), id expiration on each observation, the untrusted placeholder semantics, blocked/challenge and failure layer reporting, loading state, and redaction attestation without hit counts. This is exactly the behavioral context annotations (readOnly=false, idempotent=true, openWorld=true) cannot convey.

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

Conciseness3/5

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

The purpose is correctly front-loaded in the first sentence, but the body is an extremely dense wall of prose covering many edge cases. The volume is high even accounting for the tool's complexity, and some detail could be deferred, so it sits at the minimum-viable level for structure.

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?

With no output schema, the description carries the full return-value burden and does so thoroughly: structuredContent fields, digest/heads/top, failure, blocked/challenge, loading, runtime, observationId, carried, and redaction attestation are all specified. An agent has everything needed for this complex tool.

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

Parameters3/5

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

Schema description coverage is 100% and the schema already explains url, digest profiles, redact, sessionId, and waitForChallenge, so the baseline is 3. The prose adds some behavioral meaning for redact (attestation, no hit counts) and the compact profile, but largely restates schema-documented behavior.

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

Purpose4/5

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

The opening sentence states a specific verb (Navigate) and resource (URL) and enumerates what the DIGEST contains (landmarks, headings, ranked actionables), so the agent knows exactly what it gets back. It does not systematically distinguish itself from siblings like browser_text or browser_page, though it does name browser_screenshot as the pixel alternative.

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

Usage Guidelines4/5

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

Gives genuine when-not guidance: 'Use browser_screenshot when those pixels matter', 'fall back to another fetcher rather than recording an empty result' on a block, 're-observe before trusting completeness' on a loading page, and 'For a task that needs the real signed-in session from another browser, this is the wrong instrument.' No explicit exclusions against sibling digest/text tools, so not a 5.

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