Skip to main content
Glama

Accessibility snapshot

page_snapshot
Read-only

Captures the current page as a compact accessibility tree with stable element refs, so agents can inspect structure and target interactive elements for clicks, typing, forms, and screenshots.

Instructions

Returns the page as a compact accessibility tree (roles, names, states, values) built by Chrome itself, including cross-origin iframes and shadow DOM. Every interactive element gets a stable ref like [ref=e12] to use with click, type, fill_form, screenshot, dom_inspect and other tools. Prefer this over screenshots for understanding structure.

Input Schema

NameRequiredDescriptionDefault
rootNoElement ref from page_snapshot or find, e.g. "e12".
tabIdNoTab to act on. Defaults to the session target tab (see tab_select).
maxCharsNoTruncate the output after this many characters (default 30000).
viewportOnlyNoOnly include elements currently inside the viewport.
interactiveOnlyNoOnly list interactive elements (buttons, links, inputs…), flattened.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already carry readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds real behavioral context: coverage extends into cross-origin iframes and shadow DOM, output is compact, and refs are stable. Truncation and viewport filtering behavior live in the schema rather than the prose, leaving a small gap.

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 sentences, front-loaded with what the tool returns and what makes it distinctive (Chrome-native tree, cross-origin/shadow coverage), then the ref mechanism, then the routing advice. No sentence is 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?

A read-only, no-required-param inspection tool with a fully documented schema and no output schema; the description supplies the qualitative return shape (compact tree of roles/names/states/values) and the ref handle an agent needs to act on the result. Nothing material is missing for correct invocation.

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 description coverage is 100%, so baseline is 3; the description earns above that by explaining what a ref is ([ref=e12]), that refs are stable, and that they are the currency of the click/type/fill_form family — which is exactly the semantics the `root` parameter depends on.

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?

A specific verb and resource — returns the page as a Chrome-built accessibility tree — with the exact content enumerated (roles, names, states, values), plus scope details (cross-origin iframes, shadow DOM). The sibling names page_read, dom_inspect and screenshot are effectively distinguished by the 'prefer over screenshots for structure' line and the tree/ref framing.

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?

Explicitly says to prefer this over screenshots for understanding structure, and explains the downstream workflow (refs feed click, type, fill_form, screenshot, dom_inspect). It stops short of stating when to choose page_read or dom_inspect instead, so the sibling routing is one notch below complete.

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