Skip to main content
Glama
LvcidPsyche

Auto-Browser

by LvcidPsyche
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

browser.get_html

Read-onlyIdempotent

Retrieve a page's full HTML or visible text, with offset-based pagination to fetch large documents without truncation, enabling content extraction and analysis.

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.

Input Schema

TableJSON 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.5/5.0
Behavior5/5

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

The description adds meaningful behavior beyond the annotations: it returns serialized DOM (not just viewport), text_only strips to visible text, output is subject to max_chars/offset, and truncation is handled by calling again with offset=next_offset. This gives the agent a clear mental model of pagination and output modes that annotations do not 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?

Two sentences with no wasted words. The core purpose is front-loaded, the text_only variant is introduced immediately, and the pagination contract is stated compactly in one sentence. Every clause earns its place.

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 burden of explaining return behavior, and it does: max_chars, offset, truncated, and next_offset. The text_only behavior is also described well enough for an agent to know exactly what it will receive. Session_id requirements are already covered by the schema, so nothing essential 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 100%, so the schema already describes all four parameters clearly. The description adds value by explaining the relationship between offset, max_chars, truncated, and next_offset, and by detailing what text_only does (visible text with line breaks and tab-separated cells). This goes beyond the baseline schema documentation.

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 names a specific verb ('Read') and resource ('current page'), and immediately clarifies scope: serialized DOM of the whole document versus visible text with text_only=true. It also differentiates itself from viewport-only reads, which helps distinguish it from browser.screenshot and browser.observe.

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

Usage Guidelines3/5

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

It gives clear context for when to use the tool ('the cheapest way to read a page's content') and explains the trade-off between DOM and text-only modes. However, it does not explicitly mention when to prefer siblings like browser.observe, browser.eval_js, or browser.find_elements, so exclusion guidance is left implicit.

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