Retrieve structured layout data including bounding boxes, computed styles, paint order, colors to answer spatial questions like element positions or colors that view_page cannot answer.
Structured layout data: bounding boxes, computed styles, paint order, colors; refs match view_page. Only for spatial questions view_page cannot answer (is A above B? what color?).
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Element ref for a subtree snapshot |
Changes observed during successful MCP inspections.
v2.10.5Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / ref / descriptionPrevious value: -"Element ref (e.g. 'e42') to get subtree snapshot for"New value: +"Element ref for a subtree snapshot"v2.7.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility. It discloses the kind of data returned and the scope of use, and the data-only framing implies a read-only operation. It doesn't explicitly state that no page mutation occurs or what happens when ref is omitted, but it is reasonably transparent for a snapshot-introspection 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?
Two tightly packed sentences: the first lists the data categories and the cross-tool ref relationship; the second states the exclusive usage condition. No filler, no repetition, and key information is front-loaded.
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 one-parameter tool with no output schema, the description covers the nature of return data, the ref linkage to view_page, and the intended use case. A small gap is the unspecified default scope when ref is omitted, but the schema's 'subtree snapshot' partially addresses that. Overall, sufficient for correct invocation.
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?
The schema already documents the only parameter (ref) at 100% coverage, so baseline is 3. The description adds genuinely useful context by noting 'refs match view_page', telling the agent that refs are shared with the sibling tool and clarifying how to populate the parameter. This exceeds the schema alone.
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?
The description clearly states the tool's resource and function: it provides structured layout data including bounding boxes, computed styles, paint order, and colors. It explicitly distinguishes itself from view_page by naming the exact spatial questions it answers, so an agent can differentiate it from siblings without inspecting schemas.
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?
It explicitly says the tool is 'only for spatial questions view_page cannot answer' and provides concrete examples ('is A above B? what color?'). This is a clear when-to-use instruction and also implies when to prefer view_page, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.