Skip to main content
Glama
leeguooooo

chrome-use

by leeguooooo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

chrome_use_read

Fetch a URL or the active Chrome tab as agent-readable text or markdown; optionally return raw HTML, outlines, links, or content from a site's llms.txt.

Instructions

Fetch a URL (or the active tab, if url is omitted) as agent-readable text/markdown.

Input Schema

NameRequiredDescriptionDefault
rawNoReturn raw HTML instead of cleaned markdown.
urlNoURL to read; omit to read the active tab.
llmsNoRead from the site's llms.txt instead of the page itself.
forceNoWith tabId: act on a tab this session does not own (the user's own, or another session's), in place and in the background (--tab <handle> --force). Only when the user asked you to act on that tab; the result has forced: true and the tab's title and url.
linksNoAppend the page's links as absolute URLs (a `## Links` section; at most 100 unless maxLinks).
tabIdNoTarget tab id (e.g. t2), label, or targetId (--tab).
filterNoLiteral, ASCII-case-insensitive filter for page sections, llms links/sections or outline headings. Not a regex; page reads prefer matching headings and their descendants.
outlineNoReturn only the heading outline instead of full content.
sessionNoIsolated session name (chrome-use --session <name>). Each session gets its own tab group, browser tab and element refs. Omit it unless several agents share ONE MCP server — the session is otherwise derived per agent automatically. When you do share a server with sibling agents, pass a name unique to you on every call, or you will drive their tabs and invalidate their refs.
maxLinksNoCap for links (1-1000); implies links.
requireMdNoFail instead of falling back to raw text if markdown conversion is unavailable.
timeoutMsNoKill the underlying chrome-use process if it hasn't responded after this many ms (default 30000).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden, yet it only says the result is text/markdown. It does not mention read-only semantics, whether fetching a URL navigates or mutates the browser, the markdown-to-raw fallback (only visible in the requireMd schema), session ownership rules, or timeout behavior.

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?

A single front-loaded sentence with no filler; the default behavior is stated immediately after the primary action. There is no wasted text to trim.

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

Completeness3/5

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

The schema is rich and fully described, which covers most parameter-level needs, and the description states the return format. But for a 12-parameter tool with no annotations, the description does too little to route the agent among sibling tools or to flag browser-state implications, leaving real gaps.

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%, so the schema already documents all 12 parameters in detail, including llms, force, session, and requireMd. The description only restates the url-omitted behavior and adds no parameter meaning beyond the schema, which makes the baseline 3 appropriate.

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?

States a specific verb (fetch) and resource (a URL or the active tab) with the output form (agent-readable text/markdown). It is clear what the tool does, but it does not distinguish itself from siblings like chrome_use_open or chrome_use_snapshot, which an agent could easily confuse with this.

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?

The parenthetical 'or the active tab, if url is omitted' gives one usage condition, but there is no guidance on when to prefer this over chrome_use_open, chrome_use_snapshot, or chrome_use_eval, and no exclusions or prerequisites are 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