Skip to main content
Glama
xav-ie

Browser Session MCP

by xav-ie
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

take_screenshot

Read-only

Capture a PNG image of the session's active tab to inspect visual layout, styling, or images. Set fullPage to grab the whole scrollable page instead of just the visible viewport.

Instructions

Capture a PNG of the session's active tab and return it as an image. Use it when visual layout, styling or images matter; use take_snapshot for a cheaper text view of the page's structure, and evaluate to read specific values. fullPage captures the whole scrollable page instead of the visible viewport, which can make a very large image on long pages. It reads the page without changing it. Returns the image plus a caption with its size in bytes.

Input Schema

NameRequiredDescriptionDefault
fullPageNoCapture the whole scrollable page instead of only the visible viewport. Default false.
sessionIdYesThe id returned by open_browser_session. Errors if no open session has it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / fullPage / description
      Added value: +"Capture the whole scrollable page instead of only the visible viewport. Default false."
    • addedInput schema / properties / sessionId / description
      Added value: +"The id returned by open_browser_session. Errors if no open session has it."
  2. First observedv0.1.2

TDQS

A4.7/5.0
Behavior4/5

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

The statement 'It reads the page without changing it' aligns with readOnlyHint=true and reinforces it for a screenshot operation an agent might suspect of side effects. It adds a genuinely useful warning that fullPage 'can make a very large image on long pages' and discloses the return format (image plus byte-size caption). Minor gap: no mention of size limits, truncation, or failure modes for pages that never finish loading.

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?

Front-loads the core action, then routing to alternatives, then the one behavioral caveat and the return format. Every clause carries decision-relevant information; no restatement of the tool name or filler.

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 still explains the return value (image plus a caption with byte size) and covers safety and cost tradeoffs for the only optional parameter. Nothing an agent needs to invoke this correctly 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 baseline is 3, but the description adds a consequence not present in the schema: fullPage captures the whole scrollable page and may produce a very large image on long pages. That cost signal helps an agent decide whether to pass the flag, going beyond the schema's neutral 'Default false.'

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 ('Capture a PNG of the session's active tab') and the return shape ('return it as an image'), which is distinct from take_snapshot (text structure) and evaluate (specific values). An agent can distinguish it from every sibling without opening a 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?

Explicitly names when to use it ('when visual layout, styling or images matter') and names the two alternatives with the conditions that select them: take_snapshot for a cheaper text view, evaluate for specific values. Nothing is left to inference.

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