Extract all readable text from the current page, optionally targeting a specific tab. Use for reading web content without visual parsing.
Extract all readable text from the current page.
Args: tab_id: Optional tab to target. Defaults to active tab. For non-active tabs, prefer this with tab_id over browser_page_text_by_tab_id — they do the same thing now.
| Name | Required | Description | Default |
|---|---|---|---|
| tab_id | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose that it defaults to the active tab and that it is functionally identical to a sibling, which is useful. However, it says nothing about return format, truncation limits, hidden/offscreen content, or whether it waits for page load — meaningful gaps for a DOM-reading tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One-line purpose statement followed by a short Args block; no filler, and the core purpose is front-loaded before the parameter detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only extraction tool with no output schema, the description covers what it does, the default targeting behavior, and sibling routing. Only the shape of the returned text is unspecified, which is a minor omission given no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the lone parameter is otherwise undocumented, so the description must compensate — and it does, explaining that tab_id is optional, defaults to the active tab, and should be preferred over the sibling's equivalent parameter. It stops short of defining valid tab_id values or behavior for an invalid id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Extract all readable text from the current page.' An agent can distinguish it from browser_dom, browser_html, browser_markdown, and browser_readability. The only wrinkle is that 'current page' undersells that it can target arbitrary tabs via tab_id, but the Args section clarifies that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the alternative sibling browser_page_text_by_tab_id and states the selection rule: prefer this tool with tab_id for non-active tabs because they are now equivalent. No when-not conditions are given, but the routing guidance is concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.