sandboxed-browser-mcp

Overview Schema Source Related Servers Discussions Admin

Snapshot

browser_snapshot

Read-only

Captures the current screen as structured text, listing viewport elements with roles, names, text, refs, and states plus counts of content above and below. Use index mode to list only controls.

Instructions

Returns what is on screen now, as text: one line per element in and near the viewport (role, name, text, [ref], states) and counts of what lies above and below. With mode "index", only the controls. Actions already report their changes, so this is rarely needed right after one.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "browser_snapshot"
  }
}

Input Schema

Name	Required	Description	Default
`mode`	No	"a11y" (default) shows the page as it reads; "index" lists only the controls, one per line.	a11y
`profile`	No	Which browser profile (a separate signed-in session) to use. Leave it out for the default one; name another only when the user's task names it. Profiles: default.	default

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.2.0Nov 12, 2026

addedInput schema / properties / profile

Added value: +{
+  "default": "default",
+  "description": "Which browser profile (a separate signed-in session) to use. Leave it out for the default one; name another only when the user's task names it. Profiles: default.",
+  "type": "string"
+}

Changed3 schema fields changedv1.1.0Oct 31, 2026

addedInput schema / additionalProperties
```
Added value: +false
```
addedInput schema / properties / mode / default
```
Added value: +"a11y"
```

changedInput schema / properties / mode / description

Previous value: -"a11y (default): everything in view, with text. index: only controls; shorter, for forms and navigating"New value: +"\"a11y\" (default) shows the page as it reads; \"index\" lists only the controls, one per line."

First observedv1.0.0Oct 24, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description adds real value beyond that by disclosing the viewport-relative scope of the output and the presence of above/below element counts. It stops short of discussing output size, truncation, or how the returned [ref] values are consumed by sibling tools.

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?

Three tight sentences: output content first, the mode narrowing second, the when-not-to-call note last. No filler and nothing buried.

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

Completeness4/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 takes on return-format explanation and does so at a reasonable level of detail. Minor gaps remain around what [ref] tokens are for and what happens with very large pages, but an agent has enough to call it correctly.

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%, with both mode and profile already documented inline, including the enum values. The description only restates the "index" mode behavior, adding nothing about profile selection or the a11y mode that the schema does not already say.

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?

The description names a concrete verb and resource (returns what is on screen, as text) and specifies the payload shape: one line per element with role, name, text, [ref] and states, plus counts above and below. That distinguishes it from the image-based browser_screenshot and from browser_get_text, but it does not name those siblings explicitly, leaving the differentiation partially implicit.

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

Usage Guidelines4/5

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

It gives a clear negative-use rule — "Actions already report their changes, so this is rarely needed right after one" — and notes that mode "index" narrows output to controls. That is useful context, though it never names an alternative tool for its overlapping jobs (screenshot, get_text, find).

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

Deploy Server