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

With no annotations, the description carries the full burden, and it delivers meaningful behavioral detail: storage_state must be a Playwright JSON file (cookies + origins), header does not support comma-repeated values so you must call again, and the 'live' identity is always available. It does not disclose edge-case behaviors like what happens on duplicate names or invalid storage_state, but the key usage behaviors are well covered.

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?

The description is front-loaded with purpose, then uses clean paragraph breaks for parameter details and workflow context. Every sentence earns its place — the storage_state explanation, the header limitation, the live-identity note, and the compare_identities handoff all add non-redundant value. No filler.

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 3-parameter tool with an output schema, the description covers purpose, parameter semantics, workflow sequencing, and sibling relationships — nearly everything an agent needs to invoke it correctly. The main gaps are edge cases (duplicate name registration behavior, storage_state validation) and persistence semantics across calls, but these are minor given the rich context already provided.

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?

Schema description coverage is 0%, so the description must compensate — and it does. storage_state is fully explained (Playwright JSON, cookies + origins, one per account), and header is explained with format and a limitation ('repeatable via comma isn't supported'). The name parameter is only implied via 'e.g. user B' rather than explicitly defined, but its role as an identity label is reasonably inferable.

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 opens with a specific verb+resource: 'Register a second identity (e.g. user B) for cross-tenant IDOR testing.' This states exactly what the tool does and why it exists, and it distinguishes itself from the sibling zerodom_compare_identities by describing the workflow handoff. No ambiguity about what action this tool performs.

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?

The description gives clear workflow context: register identities first, then zerodom_compare_identities(url) consumes them. It also tells the agent when registration is NOT needed — 'The current logged-in session is always available as identity "live" without registering.' It lacks an explicit 'use this instead of X when Y' formulation, but the sequencing and the live-identity shortcut provide solid usage guidance.

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

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

No annotations, so the description carries the full burden. It does disclose meaningful behavior (the group joins the sandbox and becomes the active group) and a precondition (must be a group you created yourself, referenced by title). However, it omits side effects like what happens to the previously active group and any permission or failure conditions.

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 tight sentences, front-loaded with the core action and outcome. No filler, though the parenthetical precondition slightly interrupts the flow.

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?

An output schema exists so return values need not be explained, but with no annotations and a 0%-covered required parameter, the description leaves gaps around side effects and matching semantics. Adequate for invoking the tool, thin for predicting its behavioral footprint in the group-management workflow.

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?

Schema coverage is 0% for the single 'name' parameter, so the description must compensate. The phrase 'by title' clarifies that name is the group's title, which adds real meaning, but no format, case-sensitivity, or matching behavior is specified.

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?

States a specific verb+resource: 'adopt' an 'existing Chrome tab group' and describes the outcome (joins the agent's sandbox, becomes the active group). Clear enough to distinguish from create_group/close_group, though it never contrasts with the very similar-sounding zerodom_use_group, leaving some ambiguity in the group-management cluster.

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?

Implies the scenario ('pre-arrange tabs and then scope the agent to exactly them') but gives no explicit when-to-use vs when-not, and never names an alternative such as use_group or create_group. Usage is inferable but not spelled out.

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

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

With no annotations, the description carries the full burden and succeeds: it discloses diff notation, full-graph return on navigation, ambiguity of same-page no-ops, the no-retry policy, and the network-request suppression case. This is exactly the kind of side-effect and edge-case transparency an agent needs.

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?

The first sentence states the core contract; every subsequent sentence earns its place by explaining diff behavior, navigation, retry risk, and network suppression. Despite length, it is tightly structured and 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 interaction tool with no annotations and an output schema, the description covers all tricky scenarios: same-page no-op ambiguity, double-submit risk, navigation renumbering, and slow async auth actions. Nothing essential to predicting behavior is missing.

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 has one parameter, node_id, with 0% schema description coverage, so the description must explain it. It only says 'a node' and never clarifies where node_id comes from or how it relates to zerodom_find/read_page output, leaving the agent to infer the identifier's origin.

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?

Opens with a specific verb and object: 'Click a node and return what changed on the page.' It distinguishes itself by promising a diff rather than a full page listing, separating it from read_page and other interaction siblings.

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?

The usage is implied: call this to click a node and see what changed. It gives rich behavioral context about diff returns, navigation, and retries, but never explicitly says when to prefer it over siblings like hover, fill_node, or press_key, and provides no when-not-to-use exclusions.

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

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

With no annotations, the description carries the full burden and delivers the most important behavioral trait: the group's tabs are ungrouped and the group forgotten, and if it was the last group the sandbox turns off so the agent can drive any tab again. It still omits reversibility (a zerodom_restore_groups sibling exists) and any error/permission behavior.

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 tight sentences, front-loaded with the action and followed by the consequence. Every clause earns its place with no filler.

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?

An output schema exists so return values needn't be described, and the core behavior is covered. However, with zero annotations and an undocumented parameter, the definition leaves the agent guessing about the identifier and about whether the close can be undone.

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?

Schema description coverage is 0% and the single required 'name' parameter is never mentioned in the description. It is loosely inferable from 'an agent group', but the description does not state that the group is identified by name, so it fails to compensate for the coverage gap.

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?

States a specific verb and resource ('Close an agent group') and immediately clarifies the mechanics ('ungroup its tabs and forget it'). This distinguishes it from tab-level siblings like zerodom_close_tab, though it doesn't explicitly name an alternative group-lifecycle tool.

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?

There is no when-to-use or when-not-to-use guidance, and no reference to alternatives such as zerodom_restore_groups or zerodom_adopt_group. The sandbox-off consequence hints at context but is a side effect, not usage direction.

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

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

With no annotations, the description carries the behavioral burden. It discloses the default-active behavior and the last-tab refusal, which are valuable. However, it does not state what happens on failure, whether closing is irrevocable, or how tab_id resolution behaves, leaving some behavioral gaps.

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?

The whole description is one tight sentence with no filler. The verb and primary behavior are front-loaded, and the last-tab guardrail is added economically.

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 single-optional-parameter tool with an output schema, the description is largely sufficient: it names the action, the default, and the key edge case. Minor omissions like error behavior on invalid tab_id are not likely to block 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?

Schema description coverage is 0%, so the description must compensate. It explains the default-null behavior ('active one by default'), which helps. But it never explicitly states that tab_id identifies a specific tab to close or where to obtain a valid tab_id, so the parameter semantics remain partially implicit.

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 uses a specific verb and resource: 'Close a tab', and adds the default-active-tab behavior. The guardrail 'Refuses to close the last tab' makes it clearly distinct from siblings like new_tab, switch_tab, and list_tabs.

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?

Clear context is given: this closes a tab, defaults to the active one, and will not close the last tab. It does not explicitly name alternatives like switch_tab or new_tab, but the usage is unambiguous for a tab lifecycle tool.

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

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

With no annotations, the description carries the full disclosure burden, and it does so richly: the default identity set ("the live session plus every registered one"), the distinct transport paths (in-page Chrome fetch for the live identity vs Playwright HTTP client for registered ones, cookies included but no Chrome TLS fingerprint), and the WAF-fingerprinting implication of each path. This is exactly the context an agent needs to interpret diverging responses correctly.

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?

Front-loaded with the one-line purpose before the mechanics, and every sentence adds substance (defaults, transport, IDOR signal). The final sentence is slightly long/dense but earns its place by explaining a non-obvious behavioral difference.

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?

An output schema exists, so return values need not be spelled out, though the description helpfully notes it reports status and size per response. For a fetch-and-compare tool the coverage is nearly complete, with only the `body` parameter left unexplained.

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?

Schema description coverage is 0%, so the description should compensate, and it does well for url, method, and identities (including the default behavior). But `body` is never mentioned, leaving one of four parameters entirely undocumented in both schema and description, which caps the score.

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 opening line gives a specific verb and resource ("Fetch one URL as each identity and diff") and immediately names its security purpose ("the cross-tenant IDOR check"). It is easily distinguishable from siblings like zerodom_add_identity or zerodom_replay, which manipulate identities rather than compare responses across them.

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?

The stated goal — the cross-tenant IDOR check — provides clear context for when to reach for this tool, and the description explains the default identity set. However, it names no explicit alternatives or when-not-to-use conditions, leaving the agent to infer that plain reads should use zerodom_read_page instead.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it never clicks or submits, deny-matched links (logout/delete defaults) are never followed, blocked routes are recorded but not descended into, session scope and its max_rps limit are enforced per URL, it runs in the active tab and resolves authenticated routes on an attached session, and it leaves the tab on the last crawled page. Those are exactly the destructive-boundary and state-side-effect facts an agent needs.

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?

Front-loaded with the core operation and output contract, then breaks out behavioral rules in short, dense sentences that each add information. It is on the long side for a tool description and the CLI/parenthetical asides could be tightened, but no sentence is filler given the behavior it has to convey without annotations.

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 4-parameter, annotation-free crawl tool this covers everything material: what it walks, what it records (aided by the output schema), what it refuses to do, rate/scope enforcement, tab-state side effects, and the follow-up call. Only max_pages is left unexplained, which is a minor gap against otherwise complete disclosure.

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?

Schema description coverage is 0%, so the description must compensate, and it defines three of four parameters: `scope` (extra in-scope hosts, comma-separated, beside the start URL's host), `deny` (overrides the link-follow regex, defaults to logout/delete-style links), and `url` by implication as the start URL. `max_pages` and its default of 10 are never mentioned, leaving one parameter undocumented in both schema and description.

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?

States a specific verb and resource — 'BFS-walk an app's in-scope routes' — plus the exact output shape (one JSONL record per page enumerating URL, forms, links, XHR calls, hidden fields, blocked status). It explicitly distinguishes itself from action siblings with 'Recon, not action: it navigates and reads, never clicks or submits,' so an agent can separate it from click_node/fill_node/read_page without opening 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?

Clear context for use: reconnaissance of a whole route graph rather than single-page inspection, with the natural next step named ('call zerodom_read_page to see it') and the interaction with zerodom_set_scope spelled out. There is no explicit when-not-to-use exclusion against siblings like zerodom_network_log or zerodom_find, but the recon-vs-action framing provides strong implied routing.

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

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

No annotations are provided, so the description carries the whole burden, and it does so well: persistence across browser restarts, extension-side storage, the enforcement rule that attaching to non-agent tabs is refused, and the relay-mode restriction. Gaps remain on mutation edge cases (duplicate names, idempotency) but the meaningful behavioral traits are disclosed.

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?

Front-loaded with the action and its consequence, then constraints and the color enumeration. Five short sentences, each carrying distinct information; slightly dense but no filler to cut.

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?

Output schema exists, so return values need not be explained, and the description covers the sandbox model, persistence, and the color parameter for a two-parameter tool. Missing only duplicate-name behavior and the explicit hand-off to sibling group tools once a group exists.

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?

Schema description coverage is 0%, so the description must compensate. It fully enumerates the valid `color` values (grey, blue, red, yellow, green, pink, purple, cyan, orange) — information absent from the schema, which has no enum and only a default. `name` is only implied by 'named', which is a minor gap.

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?

Specific verb+resource ('Create a named, colored tab group') plus the resulting state change ('make it the target for new tabs'), which distinguishes it cleanly from siblings like zerodom_use_group, zerodom_adopt_group, and zerodom_list_groups. An agent knows without opening a schema whether this is creation, selection, or inspection.

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?

Gives clear operating context — 'Relay mode only (the extension drives your real Chrome)' and the sandbox precondition that once a group exists the agent may ONLY drive tabs inside its groups. It does not name the alternative to call when a group already exists (e.g., zerodom_use_group), so it stops short of full when/when-not routing.

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

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

No annotations are provided, so the description carries the full burden. It does disclose that the tool 'return what changed,' giving some indication of output behavior. However, it doesn't mention side effects (e.g., whether the drag permanently modifies state), preconditions (e.g., draggable elements), or error behavior. It's minimally transparent but not misleading.

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?

The description is concise and well-structured: the core action is front-loaded, followed by illustrative use cases. Two short paragraphs with no redundancy. Every sentence adds value, making it efficient for an agent to parse quickly.

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?

With an output schema present, the description doesn't need to detail return values. It covers the essential behavior and usage scenarios. However, it lacks explicit parameter semantics and preconditions, which are partially mitigated by the schema and the tool name. Overall, it's sufficient for an agent to understand when and how to invoke it.

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?

Schema description coverage is 0%, so the description must explain the parameters. It does implicitly define source_node_id and target_node_id through 'Drag source onto target,' but it doesn't specify the expected format (e.g., CSS selectors, IDs) or provide examples. This adds basic meaning but leaves room for ambiguity about how to identify nodes.

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 action: 'Drag source onto target' and explains the purpose with concrete examples (reorder lists, upload zones, sliders). It explicitly contrasts with click/fill pairs, distinguishing it from sibling tools like click_node and fill_node. The verb-resource pairing is specific and unambiguous.

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?

The description gives clear usage context: it's for cases where a click/fill pair can't express the gesture. It implies when to use this tool over simpler interactions and mentions alternatives (click/fill) without naming specific tools. This is strong guidance, though it could be more explicit with sibling names or exclusions.

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

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

With no annotations provided, the description carries the full burden, and it is transparent about arbitrary code execution in the live page via Runtime.evaluate. This signals potential mutation and risk. It could add caveats about side effects or result serialization, but the 'same power as DevTools console' comparison makes the behavioral profile clear.

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?

The description is one dense, well-ordered sentence: action and target first, then the protocol-level clarification. Every clause earns its place, and there is no padding or repetition of schema fields.

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 eval tool with an output schema, the description covers what code runs, where it runs, and how it is executed, which is the core context an agent needs. It could explicitly mention async/promise handling or serialization limits, but the output schema and the DevTools-console analogy cover most of the remaining ambiguity.

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?

Schema description coverage is 0%, so the description must compensate, and it does: it clarifies that the sole 'code' parameter is arbitrary JavaScript executed in page context, adding real meaning beyond the bare field title. It does not document expression-vs-statement semantics or serialization, but the single parameter's meaning is essentially fully established.

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 names the specific verb ('Run'), the target resource ('active tab's real page context'), and the outcome ('return the result'). It clearly distinguishes this from sibling action/read tools by framing it as arbitrary JavaScript evaluation with the same power as the DevTools console.

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?

The description conveys that this is the general-purpose 'do anything via JS' tool and implies it is the fallback for behavior not covered by specialized tools. However, it does not explicitly state when to prefer it over siblings like zerodom_click_node or zerodom_read_page, nor does it mention exclusions.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the text is echoed back, that the diff is specifically structural, and gives concrete examples of what structural change means. It does not cover every side effect, but it provides meaningful transparency.

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?

The description is compact and front-loaded. Both sentences earn their place: the first states the operation, and the second clarifies the meaning of the diff output.

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?

The tool is simple and has an output schema, so return-value explanation is less necessary. However, with no annotations and no parameter documentation, the description leaves node_id semantics and the relationship to sibling tools implicit, creating a noticeable gap.

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?

Schema description coverage is 0% and the description does not explain node_id at all. Text is only implied by 'Type text,' and there is no discussion of node_id format, how to obtain it, or how the two parameters relate. The property names themselves carry the only meaning.

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 states a specific action ('Type text into a node') and its observable outcome ('return what changed on the page'). This clearly distinguishes it from sibling tools like click, read, find, and parse.

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?

The context of use is clear: it is for entering text into a node and checking structural side effects such as validation errors or autocomplete. It does not explicitly mention alternatives or say when not to use it, but the behavior is distinct enough from the siblings.

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

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

With no annotations provided, the description carries the full burden. It discloses the search behavior (case-insensitive substring match on label and type), implying a non-destructive read operation. It also mentions performance characteristics (three lines vs full graph). It doesn't explicitly state that it doesn't modify anything, but the search nature is clear. It doesn't cover error conditions or return format, but those are covered by the output schema. Overall, it's transparent enough.

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 sentences with no waste. The first sentence states the core purpose; the second provides usage guidance and cost comparison. The most important information (what it does) is front-loaded. Every word earns its place.

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?

Given the tool's simplicity (one parameter), the presence of an output schema, and the sibling differentiation, the description is complete. It explains the search criteria, matching behavior, and usage context. The agent has enough information to invoke it correctly. The output schema handles return values, so nothing else is needed.

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 single parameter 'query' has 0% schema description coverage, so the description must compensate. It explains that the query is a substring used for case-insensitive matching on node labels and types. This adds semantic meaning beyond the schema's name/type, telling the agent exactly what the query affects. It could be more detailed (e.g., whether regex is supported), but it sufficiently clarifies the parameter's role.

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 states a clear verb ('Search'), a specific resource ('current page's graph'), and the action (matching nodes by query). It also distinguishes itself from siblings by explicitly advising to prefer this over re-reading the whole page, and it names the sibling alternative implicitly. This is specific and actionable.

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?

The description gives explicit when-to-use guidance: 'Prefer this over re-reading the whole page when you already know what you are looking for.' It contrasts the cost of this tool ('three lines') with the full graph read, making the decision clear. It doesn't explicitly list when-not-to-use cases, but the positive guidance is strong.

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

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

With no annotations, the description carries the burden, and it succeeds by disclosing the CDP/Playwright mechanism and the meaningful difference from document.cookie: it sees httpOnly cookies. This gives the agent a concrete behavioral expectation beyond a generic 'get cookies'.

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?

The description is compact and front-loaded: the one-line purpose is immediately followed by a short mechanism note. Every sentence adds value, and there is no filler.

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 zero-parameter, read-only cookie retrieval tool with an output schema present, the description fully covers what the agent needs to know: scope ('active tab's origin'), method (CDP via context.cookies()), and a key behavioral caveat (httpOnly visibility).

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?

There are zero parameters)Skip this baseline of 4. The description adds no parameter-level detail, but none is needed since the input schema is empty and the operation is fully self-contained.

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 opens with a precise verb-plus-resource statement: 'List cookies visible to the active tab's origin.' It clearly scopes the operation and adds implementation detail that helps distinguish it from related browser inspection tools like reading storage or page text.

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?

The context is implied: use this when you need cookies for the active tab's origin and especially when httpOnly cookies matter. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named.

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

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

With no annotations provided, the description carries the full behavioral burden. It explicitly states the tool is read-only, operates in page context, returns keys and values, and decodes JWT-shaped values into claims. This is meaningful behavioral disclosure beyond the schema. Minor gaps like cross-origin restrictions or storage-quota behavior are not disclosed, but the core safety profile is clear.

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?

The description is front-loaded with the primary purpose and then adds contextual value: session-state examples, the safety comparison to eval, and JWT decoding. It is somewhat wordy in the middle sentence, but every sentence contributes useful differentiation or behavioral detail.

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 zero-parameter read-only tool with an output schema, the description fully covers what an agent needs: what is listed, where it comes from, why it matters, and a notable value transformation. Nothing essential is missing for correct invocation or interpretation.

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 tool has zero parameters and schema coverage is 100%, so there is nothing for the description to add about parameter usage. Baseline 4 is appropriate because parameter semantics are irrelevant here and the description appropriately omits them.

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?

Opens with a specific verb and resource: 'List localStorage and sessionStorage keys the active tab's page holds.' This clearly identifies what data is accessed and scopes it to the active tab. The read-only distinction from zerodom_eval_js further differentiates the tool from a sibling.

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?

The description gives clear usage context by positioning storage inspection as safer than zerodom_eval_js: 'Same trust boundary as zerodom_eval_js... but purpose-built and read-only.' This helps an agent choose it for reading session state without eval capabilities. It does not explicitly enumerate exclusions or other sibling alternatives, so it stops short of a 5.

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

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

With no annotations, the description must carry behavioral disclosure. It explains that it runs in the real page over the shared chrome.debugger connection and avoids the ~300-property dump, which is useful. However, it does not explicitly state read-only guarantees, behavior on invalid node_id, or limitations (e.g., element nodes only).

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?

The description is compact and front-loaded with the core purpose before the implementation detail. The second sentence earns its place by distinguishing from eval_js, though it is slightly dense.

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 single-parameter read tool with an output schema, the description covers purpose and implementation context well, but it omits any guidance on sourcing node_id. This is a noticeable gap for an otherwise simple tool.

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?

Schema coverage is 0% and the description never mentions node_id, so it adds no meaning beyond the schema's type and title. It doesn't explain how to obtain or format node_id (e.g., from zerodom_find), which is a real gap for a required parameter.

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 names the resource (computed styles and box-model dimensions for a node) and the operation (Runs getComputedStyle()), and differentiates itself from zerodom_eval_js by offering a curated property list. This is specific enough to distinguish from all siblings.

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 names zerodom_eval_js as the ad hoc alternative and frames this tool as the purpose-built version with a curated list, giving the agent a clear selection criterion. It stops short of stating exclusions or when not to use it, so not a 5.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It explicitly discloses the key nontrivial behavior: hidden fields are excluded from the node graph, and results are name/value/CSS-selector triples. It does not explicitly state that the tool is read-only, but 'List' and the output framing make side effects very unlikely.

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?

Three sentences with no filler: the first announces the action, the second explains the rationale for the tool's existence, and the third describes the output and downstream use. Every sentence earns its place, and the most important 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 zero-parameter, read-only listing tool, the description fully covers selection trigger, output shape, and downstream usage. It even explains why hidden fields are not part of the normal node graph, addressing a likely source of agent confusion. The presence of an output schema also reduces the need for the description to detail return structure.

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 tool has zero parameters, so there is no schema information for the description to supplement. The description still adds useful implicit scope by saying 'current page' and explaining how returned values feed into zerodom_fill_node. This matches the baseline for a zero-parameter tool.

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 first sentence names the exact verb and resource: list hidden `<input type="hidden">` fields on the current page. It also distinguishes itself from general page/finding tools by explaining that hidden inputs are deliberately not graph nodes. This is specific and immediately differentiates it from siblings like zerodom_find or zerodom_read_page.

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?

The description gives a concrete trigger: use this when re-submitting a POST after a stale parse is missing hidden payload fields such as CSRF tokens or view state. It also explains why hidden fields should not be treated as clickable nodes and points to zerodom_fill_node as the downstream consumer. This gives an agent both when and how to use the tool.

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

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

With no annotations, the description carries the full behavioral burden, and it delivers: it discloses that the tool fires a hover event that mutates graph state ('isn't in the graph until this fires') and that it returns a diff of page changes. It could add caveats about hover side effects (e.g., triggering navigation), but the core mechanism is honestly disclosed.

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 sentences with zero filler. The main action and return value are front-loaded in the first sentence, and the second sentence earns its place by explaining why the tool exists and how it differs from click-based interaction.

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 single-parameter tool with an output schema present, the description covers the essential context: what triggers the action, what changes on the page, and what the return reflects. Minor gaps remain around prerequisites (e.g., node visibility or hover stability), but nothing critical for correct invocation is missing.

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?

Schema description coverage is 0%, so the description must compensate. The lone parameter, node_id, is self-explanatory from its name and the description's opening 'Hover over a node' clarifies it as the hover target. This is adequate for a single simple parameter, though the description adds no explicit format or provenance details.

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 opens with a specific verb+resource+outcome: 'Hover over a node and return what changed on the page.' It further distinguishes itself from siblings by noting it surfaces 'content that a click alone would never surface,' which clearly separates it from zerodom_click_node and the other interaction tools.

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?

The description gives clear context for when to use the tool: whenever hover-triggered menus or tooltips need to be revealed, explicitly contrasting with click behavior. It does not name an alternative tool explicitly or give when-not-to-use conditions, but the implied usage is strong enough for an agent to route correctly.

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

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

With no annotations, the description carries the full burden. It meaningfully discloses persistence across restarts and the behavioral implication of an empty list (sandbox off; unrestricted tabs), which is valuable context beyond the schema. It does not describe read-only safety or return shape, but the output schema covers the latter.

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 sentences, front-loaded with the primary action and followed by the key edge-case interpretation. Every sentence earns its place and there is no redundant text.

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 zero-argument list tool with an output schema, the description supplies what is needed: what is listed, that it is persisted, and how to interpret the empty result. No missing operational context prevents 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?

There are zero parameters, so per the scoring rule this is the baseline 4. The schema is empty and the description has no parameters to clarify, so no gap exists.

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?

States a specific verb and resource: 'List the agent's named tab groups (its sandbox).' The parenthetical defines the resource and distinguishes it from tab-level siblings like zerodom_list_tabs, and 'as remembered across restarts' adds scope.

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?

The second sentence gives interpretation for an empty result ('No groups → the sandbox is off and the agent can drive any tab'), which implies the tool can be used to check sandbox state. However, it does not explicitly say when to call this versus alternatives such as zerodom_list_tabs or zerodom_create_group, leaving usage context implied rather than stated.

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

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

There are no annotations, so the description carries the full burden. It clearly communicates that the tool is read-only ('List') and discloses the special behavior of marking the active tab with `*`. It does not explicitly state that no tab state is modified, but 'list' strongly implies a non-destructive operation.

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?

The description is a single, compact sentence that front-loads the primary action and includes only the essential behavioral detail. Every word contributes to understanding, with no filler or redundancy.

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 zero-parameter, simple read-only list tool with an output schema available, the description is complete. It states what is listed and how the active tab is indicated; the output schema covers return value details, so no further description is necessary.

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 input schema has zero parameters and full schema coverage, so no parameter-level description is needed. The baseline for zero-parameter tools is 4, and the description adds no unnecessary parameter information.

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 states a specific verb ('List') and resource ('every open tab'), and adds a distinguishing behavioral detail: marking the active tab with `*`. This makes it easily distinguishable from sibling tools like switch_tab, close_tab, and new_tab without needing to inspect 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?

The description implies use when the agent needs a complete view of open tabs, but it does not explicitly state when to prefer this over alternatives or mention that it is a prerequisite for switching/closing tabs. The use case is clear enough from context, but explicit guidance is absent.

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

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

With no annotations, the description carries the full burden and does well: it discloses passive-only behavior, the 200-entry cap, the reset semantics via clear=True, and explicitly disclaims modification of traffic. No annotation contradiction exists.

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?

The description is compact, front-loaded with the core behavior, and every sentence adds value: scope, cap, non-interception, and alternatives. It avoids restating schema fields or repeating the tool name.

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 simple one-parameter log tool with an output schema, the description is complete: it defines what is captured, the retention window, the cap, the meaning of clear, and what the tool does not do. An agent has enough to invoke and interpret this correctly.

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 only parameter, clear, has 0% schema description coverage, but the description explains its effect by saying the log covers entries since the last call with clear=True. It strongly implies reset-on-clear, though it does not explicitly state 'set clear=true to clear the log'.

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?

States a specific function: show requests/responses made by the active tab, with method/status and URL. The description clearly distinguishes this passive log tool from traffic-interception approaches and sibling tools.

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?

Explicitly says this is passive visibility only and not interception, then names the alternatives: page.route() for full interception and zerodom_eval_js for ad hoc fetch/XMLHttpRequest overrides. This gives clear when-to-use and when-not-to-use guidance.

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

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

Since there are no annotations, the description carries the behavioral burden. It discloses the key side effect: the new tab becomes active and routes all subsequent tool calls to it. It also adds useful context about the zerodom tab group in attached real-browser sessions, though it does not cover URL-omission behavior or failure modes.

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?

The description is compact and well-structured: the first sentence front-loads the core purpose and activation behavior, and the second adds a relevant session detail. Every sentence earns its place with no filler.

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?

The core behavior and tab-routing lifecycle are adequately described, and an output schema exists so return values need not be explained. However, the only parameter is left entirely undocumented, including its optionality and null semantics, which leaves a real gap for an agent deciding how to call the tool.

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?

Schema description coverage is 0% and the description never mentions the 'url' parameter. An agent must infer from the property name alone that it is the URL to open. The default null behavior—whether it opens a blank tab or does something else—is completely undocumented.

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 uses a specific verb and resource: 'Open a new tab and make it the active one.' It further clarifies the behavioral consequence that all other tools target this tab until switch_tab is called, which clearly differentiates it from zerodom_switch_tab.

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 gives clear context: after opening, every other tool acts on the new tab until you zerodom_switch_tab away. It names the exit condition and implies this is for creating a new active tab, but it does not explicitly state when to prefer switch_tab for existing tabs or list exclusions.

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

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the behavioral disclosure burden. It clearly describes the action and the outcome, but leaves gaps: whether the tool focuses the node first, whether key press is atomic, and what 'what changed' specifically covers. Acceptable but not rich.

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 compact sentences with no redundancy. The core action is front-loaded, and the second sentence efficiently adds key-format details plus usage context.

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?

The tool has only two required parameters and an output schema, so the description does not need to explain return values. Still, for an automation action with no annotations, it would benefit from stating whether the node must already be focused and how node_id relates to prior discovery steps.

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?

Schema description coverage is 0%, so the description must compensate. It does well for 'key' by specifying Playwright key names with examples, and it ties 'node_id' to the focused node. However, it does not explain how to obtain node_id or whether it must already be focused, leaving a meaningful gap for one of the two required parameters.

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?

States a specific verb ('Press'), a resource ('a node'), and the observable result ('return what changed'). The closing note that this is for keyboard-only widgets 'a click/fill can't drive' distinguishes it from sibling input tools like click_node and fill_node.

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?

Gives concrete scenarios: 'press Enter to submit' forms, 'Escape to close a modal', and keyboard-only widgets. It implies this tool is the right choice when click/fill cannot drive behavior, though it does not explicitly name sibling tools or say when not to use it.

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

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

With no annotations, the description carries the burden and does well: it discloses that no navigation/reload occurs, preserves page state, and honors prior parse settings. It stops short of explicitly stating there are no other side effects, but 're-read' and 'does not reload' imply a safe, read-only operation.

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?

Three sentences, front-loaded with the core purpose, followed by use cases and the key distinction. Every sentence earns its place with no filler or redundancy.

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 simple one-optional-parameter read tool with an output schema, the description covers the main invocation context: when to call, how it differs from alternatives, and what state it preserves. The only notable gap is the undocumented verbose parameter, but the tool's core usage is fully explained.

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 only parameter, verbose, has 0% schema description coverage and is not mentioned in the description. The parameter name is somewhat self-explanatory, but the description adds no meaning about what verbose controls or when to set it. For a low-coverage schema, the description should compensate but does not.

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 states a specific action ('re-read the current page') and resource ('current page'), and immediately distinguishes it from zerodom_parse_url by noting it does not reload. An agent can clearly tell what this tool does and how it differs from a key sibling.

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 when to use ('after an action changed the page, or when node ids look stale') and contrasts with zerodom_parse_url, clarifying that typed content is preserved. This gives practical, actionable selection guidance.

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

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

With no annotations, the description carries the full burden of disclosing side effects. It says it sends a request and returns status/size/body preview, but it never warns that replaying arbitrary methods (POST, PUT, DELETE) can mutate server state, nor does it mention authentication requirements, rate limits, or whether the request is sent from the agent's context. The 'Burp Repeater' analogy implies tampering, but the safety profile is not disclosed.

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 sentences plus a usage line, front-loaded with the analogy and core mechanics. Every sentence earns its place – the first defines, the second explains parameters and return, the third gives use cases and a pairing. Zero fluff, ideal density for an agent to scan quickly.

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?

The output schema exists, so return details are covered; the description correctly mentions status/size/preview anyway. However, it omits any error handling, authentication prerequisites, or the range of valid as_identity values. For a tool that can fire arbitrary HTTP requests, an agent needs more guardrails (e.g., 'requires an active session' or 'only one header allowed'). The core is complete, but the edges are under-specified.

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?

Schema description coverage is 0%, so the description must compensate. It does mention all five parameters in one sentence and gives the header format ('K: V'), but it leaves as_identity ambiguous (what values? identity names?) and does not explain body format or constraints beyond 'optional'. The default method GET is implied but not stated explicitly. This is thin compensation for a 5-param tool with no schema descriptions.

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 opens with a crisp verb+resource statement ('Replay an HTTP request under a chosen identity') and the 'Burp Repeater for the agent' analogy instantly frames the tool. It clearly separates itself from browser-automation siblings like zerodom_click_node or zerodom_network_log by focusing on raw HTTP replay, and names a natural companion (zerodom_compare_identities).

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?

Explicitly lists concrete use cases: 'probe an endpoint, tamper with a request, or check an object reference' and even suggests an iterative workflow ('change the id/body and replay again'). It names a sibling to pair with for A-vs-B diffing. It does not state when not to use it (e.g., if a browser-level interaction is needed), but the guidance is strong and actionable.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does an excellent job: it explains why the call works despite CDP limitations, warns that it can succeed without visible effect on tiling window managers, and details the Wayland protocol restriction. This far exceeds typical tool descriptions.

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?

The core purpose is front-loaded in the first sentence, with important caveats following. The prose is dense and includes some implementation archaeology like CDP method names and a docs reference that go beyond what a caller strictly needs, but none of it is filler—it all helps explain edge behavior.

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?

The description thoroughly covers the non-obvious environment restrictions: headless sessions, tiling window managers, Wayland, and floating windows. An output schema exists, so return-value documentation is not needed. The only real gap is the lack of parameter units and limits, which keeps it from a perfect score.

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?

Schema description coverage is 0%, and the description never mentions width or height units, bounds, or how the values map to window geometry. The parameter names 'Width' and 'Height' are somewhat self-explanatory, but the description adds no semantic detail to compensate for the empty schema.

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 leads with a specific verb and object: 'Resize the real browser window', then immediately disambiguates from the page viewport, which differentiates it from the sibling tool zerodom_set_viewport. This is exactly the kind of precision an agent needs to select the right tool.

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 gives clear when-not guidance: the call is only meaningful for an attached real-browser session and a headless session has no window. It also warns about tiling window managers and Wayland compositors. It doesn't explicitly name an alternative tool for viewport resizing, only says 'not just the page's viewport', so it stops short of a perfect 5.

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

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

With no annotations, the description does real work: it declares best-effort semantics and explicit failure behavior ('a tab whose URL now hits a login wall or is otherwise unreachable is skipped, not fatal'). It re-groups under saved name and color, so the mutation outcome is clear. It doesn't mention permissions or whether it overwrites existing groups.

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 written sentences, zero filler, with the core action front-loaded and the failure caveat following naturally.

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?

An output schema exists, so return values need not be described, and with zero params the main open questions are behavioral — which are largely answered. The remaining gap is whether the operation affects or overwrites live groups outside this restore.

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?

Zero parameters, so there is nothing for the description to document and the baseline is 4. The empty schema fully defines the call signature.

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?

Specific verb ('Reopen') plus specific resource ('remembered tabs of every agent group'), with the trigger context ('after a browser restart') making it unmistakable against siblings like create_group, use_group, or list_tabs.

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?

The description states the condition that selects this tool — after a browser restart — which is clear usage context. It stops short of naming alternatives or when-not to use it (e.g., versus manual re-adoption via adopt_group/use_group).

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

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

With no annotations, the description carries the full disclosure burden, and it clearly states the side effect (screenshot saved to disk), the return behavior (path returned), and the default behavior when path is omitted (temp file used). It also specifies the full-page capture scope. It does not mention overwrite behavior or file format, but those are minor for this operation.

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?

The first sentence is front-loaded and efficiently states the core purpose, behavior, and return. The second paragraph adds useful but somewhat tangential implementation context about report.py and the async/sync split, which may distract an agent; however, it is not redundant and the overall length remains reasonable.

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?

The tool is simple: one optional parameter and an output schema, so the description does not need to explain return structure in detail. It covers the operation, save behavior, path semantics, and default. Minor details like path format or whether an existing file is overwritten are unstated but are not critical 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?

Schema coverage is 0%, but the description fully compensates for the single parameter: path selects the save location, and omitting it uses a temp file. This adds exactly the practical meaning an agent needs beyond the bare string/null type and default. This is a strong example of description-driven parameter documentation.

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 opens with a specific verb and resource: a full-page screenshot of the active tab, saved to disk, returning the path. This clearly communicates the tool's function and distinguishes it from the many DOM-interaction siblings like zerodom_click_node or zerodom_eval_js. It is not a tautology and includes the outcome and return value.

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?

The description gives context that this screenshot capability is for the attached async session, contrasting with report.py's separate CLI sync browser. This is an implied when-to-use signal, but the reference to report.py and playwright_wrapper.py is not framed as an actionable alternative-selection rule. It does not explicitly state when to avoid this tool or prefer a specific sibling.

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

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

No annotations are provided, so the description carries the full burden. It discloses the real wheel event mechanism, which is a key behavioral nuance affecting which container is scrolled, and notes that it returns newly visible content. It does not cover edge cases like scroll failure or bounds, but for a scroll tool this is reasonably transparent.

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?

The description is concise and well-structured: one sentence for purpose, one for parameters, and one for the mechanism. Every sentence earns its place with no filler or repetition.

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?

An output schema exists (though not shown), so return format is presumably covered there. The description explains the scroll behavior and what is returned, which is adequate for a scroll tool. It could mention edge cases (e.g., no scrollable area) but that is minor given the complexity.

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 has 0% parameter description coverage, so the description must compensate. It explains direction values ('up' or 'down') and gives a practical hint for amount ('roughly one screenful is 800'), adding meaning beyond the schema's bare defaults.

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 purpose: 'Scroll the page and return what's newly visible.' It names a specific verb (scroll) and resource (page), and explains the unique mechanism of dispatching a real wheel event at the viewport center, which distinguishes it from generic scrolling and other tools like zerodom_eval_js.

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?

The description explains how the tool behaves (scrolls whatever container is under the cursor) but does not explicitly state when to use it versus alternatives. It contrasts with window.scrollBy, implying a use case, but lacks an explicit 'use this when...' or 'instead of...' statement. No direct alternatives are mentioned.

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

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. It clearly states that navigation, replay, and clicks to unauthorized hosts are refused, that deny is a regex to block destructive actions, and that max_rps throttles requests. It also discloses the limitation that a locked scope cannot be widened. This is thorough and transparent.

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?

The description is slightly verbose but well-structured: the main purpose is front-loaded, followed by a parameter explanation block, and then an important constraint about the env var. Every sentence adds value, though a few could be tightened. It is not wasteful and is easy to scan.

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 security-sensitive configuration tool, the description covers purpose, usage, all parameters, behavioral effects, and limitations. It mentions the env var lock and that a locked scope cannot be widened. Since an output schema exists, return values are not required. An agent has all necessary information to invoke this tool correctly and understand its consequences.

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?

Schema description coverage is 0%, so the description must fully explain the parameters. It does: hosts as comma-separated globs with examples, deny as a regex with default patterns, max_rps as a throttle. This adds significant meaning beyond the raw schema, which only provides types and titles. Each parameter's semantics are precisely defined.

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 states a specific verb ('constrain'), a clear resource (authorized targets), and explains the enforcement mechanism ('enforced in code, not on trust'). It clearly distinguishes from sibling tools which are about other operations like cookies, storage, or navigation. The purpose is unambiguous and immediately apparent.

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?

The description explicitly explains when to use the tool (to constrain the hunt) and provides a critical exclusion: an operator can lock scope via ZERODOM_SCOPE env var, and once locked, the scope cannot be widened here. It also describes the effect of each parameter, giving clear context for when to set deny or max_rps. This is comprehensive guidance.

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

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

With no annotations, the description carries the full burden and does substantial work: it clarifies this is Emulation.setDeviceMetricsOverride, affects the page's rendered layout, and does not touch the browser chrome. It doesn't mention persistence or how to reset the override, but the core behavioral scope is clearly disclosed.

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?

The description is front-loaded with the core purpose and then immediately provides the key differentiation from the sibling tool. Every sentence adds value: scope, mechanism, and usage guidance.

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 simple two-parameter tool with an output schema, the description gives enough context to call it correctly and choose it over the sibling. The main gap is that height is not explicitly explained and reset/teardown behavior isn't mentioned, but these are minor for this use case.

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?

Schema coverage is 0% and the description only meaningfully explains width ('at a given width', 'renders at width X'). Height is left entirely to inference, and there is no note about units, value ranges, or how these map to the emulation behavior.

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 states a specific verb and resource: 'Resize the active tab's viewport' for responsive-design testing. It explicitly distinguishes itself from zerodom_resize_window, so an agent can tell which tool handles viewport emulation versus real window resizing.

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 provides direct routing guidance: use this tool for 'how does this render at width X' and zerodom_resize_window for a genuinely different-sized window. It also names the sibling tool explicitly and clarifies what this tool is not.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It is transparent about what the tool reports, including connection state, session status, active tab, and log tail, and it frames the behavior as a non-mutating diagnostic. It could go further by explicitly stating that it makes no changes, but the detail provided is strong.

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?

The description is a single focused sentence with the core purpose front-loaded after 'Diagnose the current connection'. The trailing clause adds valuable rationale about replacing manual probing and log-tailing, without wasting words.

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 zero-parameter diagnostic tool with an output schema present, the description covers everything an agent needs: what is diagnosed, what sub-aspects are included, and why this tool exists as a convenience. No additional context is necessary.

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 tool has zero parameters, and the schema already reflects this with an empty properties object. The baseline for zero-parameter tools is 4, and the description appropriately focuses on observable behavior rather than hypothetical parameters.

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 begins with a specific verb, 'Diagnose', and names the resource ('the current connection') plus four concrete diagnostic aspects: relay reachability, browser session attachment, active tab, and the relay's log tail. This clearly sets it apart from sibling action-oriented tools like zerodom_press_key or zerodom_read_page.

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?

The description gives clear context for when this tool is useful: whenever one needs a single-call status overview instead of manual WebSocket-probing and log-tailing. It does not explicitly name sibling alternatives or state exclusions, but it communicates the intended diagnostic scenario well.

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

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

With no annotations, the description carries the full burden. It discloses a key behavioral trait: node ids are per-tab, so you must re-read the returned graph before clicking or filling. It also states the tool returns the interaction graph, which is beyond what the input schema shows. It doesn't mention side effects like whether the previous tab is closed or if state is lost, but the critical per-tab id warning is valuable.

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?

The description is two sentences with no wasted words. The core action is front-loaded, and the critical per-tab warning is placed immediately after. Every sentence earns its place.

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?

The tool has one parameter, no annotations, and an output schema exists. The description explains the return value (interaction graph) and the critical caveat about per-tab node ids. It doesn't mention how to obtain the tab_id or what happens if the tab_id is invalid, but for a simple switch operation, the essential context is present.

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?

Schema description coverage is 0%, so the description must compensate. It mentions 'tab_id' implicitly by saying 'another open tab' and 'the tab you just switched to,' but it doesn't explain where to get the tab_id (e.g., from zerodom_list_tabs). The description adds some context but doesn't fully clarify the parameter's provenance or format.

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 verb and resource: 'Make another open tab active' and 'return its interaction graph.' It distinguishes itself from sibling tools like zerodom_list_tabs and zerodom_close_tab by focusing on switching to an existing tab. However, it doesn't explicitly name a sibling alternative, so it falls short of a 5.

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?

The description provides clear context: use this to switch to another open tab, and it returns the interaction graph so you can re-read before interacting. It implies this is the tool to use when you need to change active tabs, but it doesn't explicitly state when not to use it or name alternatives like zerodom_list_tabs for listing tabs. Still, the guidance is actionable and context-rich.

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

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

With no annotations provided, the description carries the full behavioral burden. It adds a genuinely valuable security disclosure: 'path is resolved on the machine driving the browser — the same trust boundary as zerodom_eval_js, not a new one,' which tells the agent the path is interpreted on the driver host and introduces no additional trust risk. It also discloses the return behavior ('return what changed'). It omits edge cases like invalid paths or event firing, but the trust-boundary context is significant enough to justify a 4.

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?

Exactly two sentences, both earning their place: the first conveys the action and return behavior, and the second adds a security-relevant boundary note. There is zero filler, and the primary behavior is front-loaded ahead of the caveat.

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?

Complexity is low (two required string params, no enums, no nesting) and an output schema exists, so return values need not be explained. The description covers the core mechanics and security context. However, it leaves usage routing, prerequisites (target node must be a file input), and error behavior (e.g., nonexistent path) unstated, which an agent would need for fully confident 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?

Schema description coverage is 0%, so the description must compensate. It does clarify the critical parameter: 'path' is a local file path resolved on the driver machine, adding meaning beyond the bare string type. However, 'node_id' receives no elaboration and relies on the zerodom_* sibling convention of identifying nodes. One of two parameters is well-explained; the other is left implicit, so the compensation is only partial.

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 states a specific verb and resource: 'Set a file input's value to a local file path and return what changed.' It clearly scopes the tool to file inputs and names the outcome (what changed), which distinguishes it from siblings like zerodom_fill_node (general text filling) and zerodom_eval_js (arbitrary JS execution). An agent can determine what this tool does without opening the schema.

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?

The scope is implied by the description: 'a file input' signals when the tool applies, and the trust-boundary sentence references the sibling zerodom_eval_js. However, the description never explicitly states when to prefer this over zerodom_fill_node, nor does it give exclusions such as 'do not use for non-file inputs.' Context is present but relies on inference rather than explicit routing.

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

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

With no annotations, the description carries the full burden, and it does disclose the key state change and its forward-looking effect on new tabs. It omits other behavioral facts an agent needs: whether the group must already exist, what happens if `name` is unknown, and whether the active-group selection persists across calls or sessions.

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?

A single tight sentence that front-loads the action and appends the consequential side effect. Nothing is wasted and no reading is required to find the operative verb.

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?

An output schema exists, so return values need not be explained. For a state-mutating tool in a crowded group-management family, though, the definition lacks the error behavior and persistence details that would let an agent call it confidently without trial and error.

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?

Schema coverage is 0% and the sole parameter has no description, so the description is the only source of meaning; it establishes that `name` refers to a group. It doesn't clarify whether this is a group name, an ID, or a title, nor case sensitivity or matching rules, leaving the single parameter under-specified.

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?

States a specific verb and resource ('make `name` the active group') and clarifies the observable effect ('subsequent new tabs join it'), which distinguishes it from siblings like zerodom_create_group, zerodom_list_groups, and zerodom_close_group. It doesn't explicitly contrast against the closer-sounding siblings zerodom_adopt_group or zerodom_set_scope, so it stops short of full sibling differentiation.

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?

The phrase 'subsequent new tabs join it' implies the use case (routing upcoming tabs into a group), so the context is inferable. However, there is no explicit guidance on when to use this versus zerodom_adopt_group, zerodom_set_scope, or zerodom_create_group, and no prerequisites are stated.

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