Browser Session MCP

Overview Schema Source Related Servers Discussions Admin

read

Read-only

Extracts only the passages from a browser tab that answer your question, returning relevant sections in page order to reduce context use. Use it for page content and snapshots for structure.

Instructions

Read only the parts of the session's active tab that help answer a question, instead of the whole page: the page's visible text (an open dialog's, when one is showing) is split into passages of about 600 characters under their headings, the Jev decision model rates each one's relevance in parallel requests, and the relevant ones come back in page order under ## heading lines, up to maxChars. A long article shrinks to the few sections that matter, saving the agent's context; a page under 8,000 characters comes back whole without asking Jev. Use take_snapshot for the page's structure and controls, and read for its content. Needs TYPESAFE_API_KEY; any Jev problem is an error. It reads the page without changing it.

Input Schema

Name	Required	Description
`maxChars`	No	Most characters of passages to return, the most relevant first if they don't all fit. Default 12000.
`question`	Yes	What you want to know from the page, e.g. "When and why did Japan surrender?" or "the refund policy".
`sessionId`	Yes	The id returned by open_browser_session. Errors if no open session has it.

Output Schema

Name	Required	Description
`url`	Yes
`kept`	Yes	Passages returned.
`text`	Yes	The passages kept, in page order, under their headings as `## ` lines; empty when nothing looked relevant.
`title`	Yes
`filtered`	Yes	False when the page was short enough to return whole, without Jev.
`passages`	Yes	Passages the page was split into.
`pageChars`	Yes	Visible characters on the page.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.18Nov 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses concrete mechanics: ~600-character passage splitting, parallel relevance scoring, page-order reassembly under `## heading` lines, the 8,000-character bypass threshold, and that the operation never modifies the page. The API key requirement and error behavior are also named, which 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.

Conciseness4/5

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

The value proposition is front-loaded in the first clause, and the rest explains mechanism, limit, and alternative. It is dense but purposeful, with only minor redundancy in the closing reassurance that it reads without changing the page, which the readOnlyHint already covers.

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 three-parameter read tool with an output schema, the description covers what is returned (passage structure, headings, ordering), how much is returned, when filtering is skipped, prerequisites, and failure behavior. Nothing an agent needs in order to call it correctly is missing.

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 all three parameters are already documented. The description reinforces that `question` drives relevance and that output is capped by `maxChars`, but it adds no format, syntax, or edge-case detail beyond what the schema states (the schema already explains relevance-ordered truncation and the 12000 default).

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 states a specific action and resource: it returns only the relevant parts of the active tab's visible text, split into passages and filtered by a relevance model. It also distinguishes itself from take_snapshot by contrasting page structure/controls with page content, so an agent can choose between them without opening either schema.

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

Usage Guidelines5/5

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

It explicitly names the alternative ('Use take_snapshot for the page's structure and controls, and read for its content') and gives an implicit exclusion: pages under 8,000 characters come back whole without Jev, so this tool's filtering is only relevant for long pages. It also states the prerequisite (TYPESAFE_API_KEY) and that Jev failures surface as errors.

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