Skip to main content
Glama
Sign In
Auto-Browser

Auto-Browser

by LvcidPsyche
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

browser.get_html

Read-onlyIdempotent

Read a web page's full serialized DOM or, with text_only=true, its visible text. Returns content in chunks up to max_chars from a given offset, so paginated reads handle long pages.

Instructions

Read the current page: its serialized DOM (the whole document, not just the viewport), or with text_only=true its visible text — the cheapest way to read a page's content. Returns up to max_chars (default 20,000) from offset; when truncated is true, call again with offset=next_offset for the rest. On Chrome's error page for a navigation the pre-request gate stopped, blocked_navigation says what was stopped and why.

Input Schema

NameRequiredDescriptionDefault
offsetNoCharacter to start from. A result with truncated=true gives the next_offset to continue from.
max_charsNoMost characters to return.
text_onlyNoReturn the page's visible text instead of HTML: line breaks kept, table cells tab-separated.
session_idNoTarget session id, from browser.create_session or browser.list_sessions. Optional when exactly one session is live; observe and act tools create one when none is.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.1
  2. Removedv1.4.2
  3. Changed3 schema fields changedv1.0.3
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / session_id / maxLength
      Added value: +120
    • addedInput schema / properties / session_id / minLength
      Added value: +1
  4. First observedv0.5.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses the truncation contract (default 20,000 chars, truncated flag, next_offset continuation) and the special behavior on Chrome error pages where blocked_navigation explains a gateway-stopped navigation. That is exactly the kind of operational detail annotations 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.

Conciseness5/5

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

Three sentences, front-loaded with what is read, then the cost framing, then the pagination and error-page rules. No filler and no repetition of schema defaults beyond the useful 20,000 figure.

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?

There is no output schema, and the description compensates by describing the return content (serialized DOM vs visible text), the size limit, the truncation/continuation fields, and the blocked_navigation error field. An agent has everything needed to call and to handle the response.

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 100%, so the baseline is 3, but the description adds value by tying offset and max_chars together into a pagination loop ('call again with offset=next_offset') and by describing text_only's output shape. session_id is left entirely to the schema, keeping it from a 5.

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 ('Read the current page: its serialized DOM') and immediately clarifies scope ('the whole document, not just the viewport') plus the text_only variant. The phrase 'the cheapest way to read a page's content' implicitly separates it from sibling tools like screenshot and observe.

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 clear conditional guidance: use text_only=true for visible text as the cheapest read, and 'when truncated is true, call again with offset=next_offset' for continuation. It doesn't explicitly name alternatives like browser.observe or browser.screenshot, so the routing signal is implied rather than stated.

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