ZeroDOM

Overview Schema Source Related Servers Discussions Admin

zerodom_parse_url

Navigate a URL to retrieve its interaction graph as compact text selectors. Optionally include iframes, limit to the visible viewport, or filter occluded elements.

Instructions

Navigate to a URL and return its interaction graph.

Returns the compact text graph: [03] button 'Sign In'. CSS selectors are kept server-side and resolved by node id, so they never cost context — pass verbose=True for the full JSON including selectors. Nodes sharing a repeated-list-item ancestor (<article>/<li>/<tr>, e.g. a feed or Hacker-News-style table) are grouped under @card "title": whenever a card holds 2+ controls — twenty identical button 'Upvote' lines are meaningless without knowing which story each belongs to.

Set frames=True when the controls you need are inside an iframe — embedded editors, payment fields, consent gates. Off by default because it costs a read per frame and most frames on a commercial page are advertising.

Set viewport_only=True on long feed/infinite-scroll pages (a social feed, a video site's homepage) where most of the graph is scrolled off-screen and you only need what's currently visible — this can cut node count by more than half on pages like that. On by default for interactive agents; costs a getBoundingClientRect() per element. Sticks for the rest of this session (every click/fill re-read honors it too) until the next zerodom_parse_url call changes it — same lifetime as frames. When nodes are being skipped, the graph's first line says how many; scroll and re-read to see them.

Set check_occlusion=True when clicks keep failing with Playwright's "element intercepts pointer events" — a modal backdrop, an open dropdown, or a cookie banner is covering nodes that are still in the DOM and still listed. This filters them out at parse time instead of at click time, same sticky-for-the-session lifetime as viewport_only. Off by default: the cost of an elementFromPoint() hit-test per node on a large page is unmeasured, so it isn't imposed on every caller by default.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes
`frames`	No
`verbose`	No
`viewport_only`	No
`check_occlusion`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.0.8Sep 23, 2026

addedInput schema / properties / check_occlusion

Added value: +{
+  "default": false,
+  "title": "Check Occlusion",
+  "type": "boolean"
+}

addedInput schema / properties / viewport_only

Added value: +{
+  "default": true,
+  "title": "Viewport Only",
+  "type": "boolean"
+}

First observedv0.0.6Sep 17, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it excels. It details the graph format, grouping of repeated-list-item nodes, session-sticky flag lifetimes, costs per read (getBoundingClientRect, elementFromPoint, read per frame), and even mentions that skipped nodes are reported in the first line. This is exemplary transparency, covering both operational effects and performance implications beyond what any annotation could provide.

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 description is long but well-structured, with each paragraph serving a clear purpose: an overview, return format, and then parameter-specific guidance. The most critical information (the tool's function) is front-loaded. While it could potentially be tightened, the length is justified by the complexity of the flags and session behavior, and there is no redundant or filler content.

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?

Given the tool's complexity—multiple boolean flags, session-sticky state, performance costs, and a detailed graph output—this description is remarkably complete. It explains the return format, grouping logic, session lifetime, defaults, and costs, leaving no critical aspect unaddressed. The presence of an output schema helps, but the description goes beyond by explaining how to interpret the graph and when to expect deviations (e.g., skipped nodes). No relevant operation details are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully explain each parameter, and it does. Every flag (frames, verbose, viewport_only, check_occlusion) receives a dedicated paragraph explaining its effect, default, and rationale. It even clarifies the interaction between sticky flags across session calls. The required url parameter is implicit in the tool's purpose. This level of parameter documentation fully compensates for the missing schema descriptions.

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 opens with a precise statement: 'Navigate to a URL and return its interaction graph.' This specifies the verb, resource, and output type, making it unmistakable what the tool does. It also distinguishes its role from sibling tools like zerodom_click_node or zerodom_find by focusing on graph generation, and the detailed explanation of graph format further reinforces its unique purpose.

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?

The description gives explicit, scenario-driven guidance for each optional flag: when to set frames (iframes), when to use viewport_only (long/infinite-scroll pages), and when to enable check_occlusion (click failures due to overlays). It also explains default behaviors and performance trade-offs, effectively telling the agent when to deviate from defaults. However, it does not explicitly compare against alternative tools like zerodom_read_page or zerodom_find, leaving some ambiguity about the boundary between reading the page graph and reading text content.

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