Skip to main content
Glama
Intrect-io

lyra-browser

Official
by Intrect-io

read_page

Extract a page's rendered text or a tree of actionable elements with aria-ref tokens for clicking and typing. Limit to a region or paginate long output.

Instructions

Read the page as text, or as a map of what can be acted on.

mode="text" (default) returns the rendered text (innerText), not HTML. links=true adds the page's visible links as {text, href} — absolute, de-duplicated, at most 100 (tree lines carry their own href).

mode="tree" returns one line per visible thing you can act on — links, buttons, inputs, selects, checkboxes, tabs, menu items — plus headings::

aria-ref=e12 link "Pricing" -> /pricing
aria-ref=e15 button "Save"
aria-ref=e16 checkbox "Remember me" [checked]

Pass the aria-ref=... token exactly as written as the selector of click or type_text. It reaches what a text selector cannot name: icon-only links, several links with the same text, elements inside open shadow roots and iframes. A ref is good for the page it was read from and only while its element stays; a region read (selector) replaces the refs of the read before it. When a ref is rejected or matches nothing, read the tree again. Elements on screen come first (in_viewport counts them). Input values are never shown. refs: false means this Playwright predates aria refs: lines then carry none, so address elements with role=link[name="Pricing"] or text= selectors.

selector limits either mode to one region (first match); it returns not_found at once when nothing matches. offset and max_chars page through long output: total_chars is its full length, truncated says more follows, next_offset is where to continue. Tree pages hold whole lines, so a ref is never cut in half. Every call reads the page as it is now, so pages read while it changes or scrolls may not line up.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNotext
linksNo
offsetNo
selectorNo
max_charsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/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 does so richly: refs are valid only for the page/read they came from and go stale, a region read replaces prior refs, input values are never shown, in_viewport elements come first, and not_found/truncated/total_chars/next_offset behaviors are all disclosed.

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?

It is long but front-loaded and well organized, leading with the default mode then proceeding through links, tree refs, selector, and paging. The examples earn their space; a couple of edge-case sentences (refs:false) are dense but still purposeful.

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?

For a complex browser-reading tool with an output schema, the description is complete: it explains return shapes, staleness, ordering, truncation continuation, and failure modes, so an agent has everything needed to invoke and interpret it correctly.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate for all 5 undocumented parameters, and it does: it defines mode's two values, what links=true adds, that selector scopes to the first match and returns not_found, and how offset/max_chars page long output.

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 opening sentence states a specific verb+resource ('Read the page') and immediately splits the two output modes (text vs action map). It clearly distinguishes itself from siblings like read_draft, read_form, and screenshot by describing exactly what page content it exposes.

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?

It gives strong conditional guidance: use mode=text for rendered text, mode=tree when you need to act on elements, pass the aria-ref token to click/type_text, and re-read the tree when a ref is rejected. The only gap is it doesn't explicitly compare against sibling alternatives like screenshot or read_form for the same intent.

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