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

With no annotations, the description fully carries the behavioral burden and does so thoroughly: it discloses that credentials are never visible to the AI, that selectors auto-detect and report used selectors, that screenshots are never returned, that it blocks up to 180s, and that consent is requested unless assumeConsent is set. No contradictions exist.

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 dense but well-organized, with the core purpose front-loaded. It is longer than minimal, but every sentence contributes critical operational or safety information, so the length is justified.

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 10 parameters, no output schema, and no annotations, the description provides remarkably complete guidance: return statuses, timeout behavior, security constraints, selector reporting, consent flow, and follow-up actions. An agent has enough context to call the tool correctly and interpret its result.

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 already covers all 10 parameters at 100% coverage, so the baseline is 3. The description adds meaningful runtime context beyond the schema: auto-detection of selectors, flow auto vs override behavior, source prompt vs vault, the meaning of otp_required, and consent handling.

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?

Clearly states it logs a user into a site with their account while keeping credentials hidden from the AI. It names the specific return statuses and references related actions (submit_2fa_code, manage_session), distinguishing it from 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 to call submit_2fa_code on otp_required, to capture a screenshot separately after success, and to use manage_session action=save. It also states when consent is skipped via assumeConsent, giving clear when/when-not 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 full responsibility and meets it: it discloses blocking behavior, return statuses (completed/cancelled/timeout), the visible window, state loss in managed mode, and the headless error path. It leaves no ambiguity about side effects 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?

Every sentence earns its place: purpose first, then behavior, then edge cases. The description is dense but not padded, and it front-loads the most critical fact (human-in-the-loop). No redundancy with the schema.

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 fully covers the tool's purpose, invocation context, parameter behavior, return values, and failure modes. It even addresses the important 'headless mode returns an error' caveat. For a 4-parameter tool with no output schema, nothing an agent needs to call it correctly 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 coverage is 100% and each parameter has a clear description. The tool description adds value by explaining how parameters interact (e.g., expectUrlContains auto-completes on URL match, timeoutMs ensures no hang) and the overall blocking semantics. It does not repeat schema details but enriches the mental model of how the tool works, warranting above-baseline credit.

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: 'Hand the live browser to the human for something the AI cannot or must not automate', then names concrete examples (Cloudflare check, CAPTCHA, interstitial). It also distinguishes from siblings by being 'The ONLY tool that shows a window', making its unique role clear.

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 states when to use (for challenges the AI cannot handle) and what it never does ('never solves the challenge and never bypasses anti-bot protection'). It also gives clear behavioral context: managed mode loses unsaved state, headless mode errors instead of hanging, and it blocks until conditions are met. This provides strong guidance without naming specific siblings, but the 'only tool' statement effectively separates 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 provided, the description carries the full burden of behavioral disclosure. It clearly states the workflow: navigates, applies optional viewport, scrolls the first match into view, and crops. It also discloses the output handling (full-resolution crop saved to disk, webp thumbnail on the wire). It does not mention error conditions or permissions, but for a non-destructive screenshot tool this is a solid disclosure. No contradictions with any structured metadata.

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 three sentences with zero fluff. The primary purpose and use case are front-loaded in the first sentence, followed by a concise process summary and output details. Every sentence earns its place, making it efficient and scannable for an agent.

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 tool with 4 parameters (2 required), no output schema, and no annotations, the description covers the core action, the use case, the behavioral steps, and the output format. It lacks explicit error-handling details or authentication prerequisites, but those are not critical for this simple screenshot tool. It is complete enough for an agent to invoke it correctly without further investigation.

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 100%, and every parameter already has a detailed description (e.g., reload behavior, selector semantics, viewport enum). The tool description adds minimal parameter-specific meaning beyond what the schema provides—it mentions scrolling the selector into view, which is also in the schema. Given the schema does the heavy lifting, a baseline of 3 is appropriate.

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 pair: 'Screenshot ONE element, cropped to its bounding box.' It immediately distinguishes itself from capture_page_screenshot by emphasizing the single-element scope and the cropping, and even signals cost efficiency ('far cheaper than a full page'). This makes the tool's purpose unambiguous and differentiates it from siblings 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 explicitly states when to use it: 'when you only need a button, card, or nav' and contrasts it with a full page capture. However, it does not mention when not to use it (e.g., for full-page layout analysis) or name any alternative tools beyond the implicit page screenshot. It gives clear context but stops short of explicit exclusions, so it earns a 4.

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 does so thoroughly. It discloses session persistence, the fact that re-requesting an open URL avoids reload, that a full-resolution copy is always saved to disk with its path reported, and which parameters affect wire-image cost. This is rich, non-obvious behavioral context that the schema does not convey.

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, each with a distinct job: state the purpose, explain session behavior, and clarify disk vs. wire output. It is dense but not bloated, with the most important scoping information 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 an 8-parameter tool with no output schema and no annotations, the description covers the critical operational context: session persistence, reload avoidance, disk-save behavior, and cost levers. It doesn't fully specify the response shape, but it does state that the path is reported and the image is what goes over the wire, which is sufficient to invoke the tool 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?

Schema description coverage is 100%, so the baseline is 3. The description adds a useful high-level framing—format, quality, maxWidth, and sizeMode together control wire cost—but it does not add per-parameter semantics beyond what the schema already provides.

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 states a specific verb (Screenshot), a resource (a URL), and a clear scope (one breakpoint). It implicitly differentiates the tool from siblings like matrix_responsive_audit and find_breakpoints, which target multiple viewports, and from capture_element, which targets an element rather than a 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 provides clear context: it captures a single breakpoint, relies on a persistent session that carries cookies/logins/state, and gives cost-control guidance. It does not explicitly name sibling alternatives or state when not to use this tool, 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 carries the full burden. It discloses that it saves files (baseline PNG and delta overlay), resets scroll to top, clips fullPage at 7900px with truncation reporting, and returns variance score, dimension drift, and delta overlay. It also mentions the reload default causing stale URLs. This is comprehensive, though it does not state permission requirements or reversibility explicitly.

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 four sentences and front-loads the core purpose, then adds details on behavior and edge cases. It is efficient and well-organized, though it could be tightened slightly without losing information.

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 7-parameter tool with no output schema, the description is remarkably complete. It explains both actions, the return metrics (variance, dimension drift, delta overlay), the fullPage clipping limit, scroll reset, and the reload staleness issue. No critical information an agent needs to call it correctly 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 coverage is 100%, so the baseline is 3. The description repeats parameter meanings (e.g., action, fullPage, maxVariancePct) without adding new semantics beyond the schema. It does not compensate for any gaps because there are none; it merely restates what the schema already provides.

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-resource structure: 'set_baseline renders... and saves a lossless PNG baseline; diff_against_baseline re-renders and pixel-diffs against it, returning...'. It clearly distinguishes the two actions and differentiates from siblings like capture_page_screenshot or visual_diff_regions by naming the exact operations and outputs.

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 the two actions and their behaviors (e.g., scroll reset, fullPage clipping) but does not explicitly state when to use this tool over alternatives like visual_diff_regions or capture_page_screenshot. No exclusions or conditional routing are provided, so the agent must infer usage from the action enum alone.

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 well: it reveals that an in-page DOM script runs, that findings have unique selectors, and that annotate (on by default) writes red-outline renders to disk and reports their paths. It also clarifies the image-token cost implication. It does not mention failure modes or verdict behavior, but the schema covers maxIssues.

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 tightly written sentences lead with the core value proposition and then add detection scope, output properties, and the annotate side effect. There is no filler or redundant restating 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?

The description is complete enough to invoke the tool correctly: it explains what is measured, what issues are flagged, what output shape to expect (selectors and optional saved renders), and the image-token cost. It does not spell out the exact response format, but that is partially covered by the rich parameter schema and the absence of an output schema is compensated by the explicit 'findings' language.

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 100%, so the schema already documents all five parameters. The description adds some contextual value around annotate by explaining the red-outline disk output, but it does not meaningfully enrich url, reload, maxIssues, or ignoreSelector beyond what the schema already provides.

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 pair ('layout diagnostics across all four breakpoints') and enumerates concrete defect types: horizontal overflow, spill/clipping, truncated text, collisions, and sub-44px tap targets. It distinguishes itself from screenshot-based siblings by emphasizing 'zero-image' and 'text-only' while promising unique addressable selectors.

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 clearly implies a use case: run a text-only, multi-breakpoint layout audit in one call. However, it never explicitly states when to prefer this over sibling tools such as matrix_responsive_audit, capture_page_screenshot, or find_breakpoints, nor does it mention 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?

Because no annotations are provided, the description carries the full burden and uses it well. It discloses the human-in-the-loop prompt ('The human types every secret ... into the localhost prompt'), the security boundary ('the AI never sees any value'), and the return shape ('non-secret summary'). This goes well beyond a minimal statement, though it doesn't mention failure modes or overwrite 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?

The description is three sentences long but front-loads the core action and purpose before adding details about the human prompt and optional storage. Each sentence adds distinct context (what/why, security model, extensibility). It is slightly dense but not wasteful.

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 no output schema and no annotations, the description adequately covers the essential workflow: what the tool does, how secrets are handled, what is returned, and how later tools consume it. It omits edge cases like what happens if the user cancels the prompt or if a credential already exists, but the main call path is clear.

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 100%, so the baseline is 3. The description adds value by clarifying that the actual secret values (passphrase, username, password, TOTP seed) are not passed as parameters—the agent only supplies the profile name and optional selectors/URL. This prevents the agent from trying to include secrets as arguments, which is meaning not present in the 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 uses the specific verb 'Save' with a clear resource: 'a profile's credentials to the encrypted vault'. It also names the dependent siblings (authenticate_login source=vault and submit_2fa_code source=totp) that consume the stored data, distinguishing this tool as the enrollment step for unattended login.

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 states when to use this tool (to enable later logins 'with no human present') and ties it to the consumer tools, implying that enrollment should happen before authenticate_login or submit_2fa_code can work. This gives the agent a clear decision rule relative to 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, the description must convey behavior; it discloses that the tool visits a URL and may persist tokens to .agent-eyes/styles/, which is useful. However, it does not mention network access, auth requirements, or that the default is to reuse an already-open tab (stale risk) — that lives only in the schema. It doesn't contradict anything, but carries only partial behavioral burden.

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 front-loads the purpose and packs the output list into one flowing sentence without redundancy. It's slightly long but every clause adds information; 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 output format is described (summary + CSS :root block) and the optional save location is named, so the agent knows what to expect. Yet with no output schema and no annotations, and a closely related sibling tool, the description would benefit from explicit notes on limitations or prerequisites (e.g., live site needed, fallback behavior).

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?

All four parameters are described in the schema (100% coverage), so the baseline is 3; the description adds value only for saveAs by naming the output path. It doesn't clarify reload or viewport semantics beyond the schema, which is acceptable given full schema coverage.

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 identifies the action (extract design tokens from a URL) and enumerates specific outputs (palette, type scale, spacing, radii, shadows), using concrete language. It doesn't explicitly differentiate from the similarly named sibling extract_site_design, so it falls short of the top score.

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 the primary use case ('make it look like <site>') and mentions optional saving, but never states when to prefer this tool over siblings like extract_site_design or review_design. No exclusions or alternatives are given, so an agent gets context but no routing 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. It discloses crawling behavior ('nav links first'), the merging and ranking logic, and clarifies it never copies images or logos. It does not mention potential side effects like file saving or timeouts, but the core behavior is 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 dense but well-structured, front-loading the purpose and then detailing the output components. It avoids fluff, though the long list of output elements makes it slightly lengthy; still, every sentence adds value.

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 tool without an output schema, the description explains the output in sufficient detail: fonts, color roles, type ramp, spacing, radii, shadows, section anatomy, and CSS/Tailwind theme. It also explains the merging logic (ranked by cross-page frequency). Missing details like exact return format are acceptable given the described pasteable output.

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 100%, so all parameters have adequate descriptions. The tool description adds marginal context ('nav links first' aligns with maxPages) but does not substantially elaborate on parameter usage or syntax beyond the 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 states a specific verb ('crawl') and resource ('same-origin pages'), and clearly defines the output as a consolidated design brief with merged tokens, section anatomy, and CSS theme. It distinguishes itself from siblings like extract_design_tokens by focusing on cross-page merging and explicitly excluding images and logos.

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 usage for whole-site design extraction but does not explicitly contrast with alternatives or state when not to use it. It lacks explicit exclusions or conditions that would guide selection among the many sibling tools.

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 does well: it discloses that the tool mutates the viewport, probes overflow, and 'restores the prior viewport afterwards.' It also clarifies it is image-free, which avoids expectations of screenshots. It does not mention wait/load behavior or exact reporting format, but core side effects are 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?

Two sentences, tightly written, with the core behavior front-loaded and no filler. The phrase about the four named viewports earns its place by explaining why this tool exists despite other responsive audits.

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 tool with no output schema, the description sufficiently states what is returned ('exact width ranges where the layout breaks') and covers side effects. It could be more explicit about output format or load-wait behavior, but the definition is complete enough 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 100%, so the schema already documents every parameter. The description adds algorithmic context by mapping minWidth/maxWidth and step to the width sweep, but it does not add per-parameter meaning beyond the schema. Baseline 3 is appropriate.

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 a specific verb and resource: it stress-tests responsive layout by sweeping viewport width and reporting breakpoint ranges. It is clearly distinguished from the sibling viewport audits by its zero-image, incremental width-sweep approach and by contrasting with the 'four named viewports'.

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 clear context: use this when you need to find width ranges where horizontal overflow occurs, especially ones 'the four named viewports skip over.' It does not explicitly name alternatives or give when-not-to-use rules, 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 the behavioral burden. It discloses that it builds a file, aggregates runs, and returns a path. It does not mention whether it overwrites an existing gallery.html, whether authentication or existing captures are prerequisites, or what happens on failure. These gaps keep it at a 3.

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 three sentences, with the first front-loading the core purpose and details of the artifact. Nothing is redundant; the list of fields and linkage to full-resolution files earns its place, and the final sentence on return value is concise. No fluff.

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 tool with no output schema, the description adequately covers the input scoping, the content of the generated gallery, and the return value. It could mention prerequisites like the existence of captures or overwrite behavior, but these are not essential for basic correct usage.

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

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

The schema already covers the 'run' parameter with 100% coverage, explaining its purpose and default behavior. The description merely restates 'Aggregates every run unless you scope it to one', adding no new semantic information beyond the schema. Baseline 3 applies.

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 'Build' and names the precise resource '.agent-eyes/gallery.html', then details its contents (sortable contact sheet, fields like URL, viewport, tool, selector, timestamp, dimensions, issue count). This clearly distinguishes it from capture and audit siblings like capture_page_screenshot or matrix_responsive_audit, which focus on taking screenshots or analyzing them rather than aggregating them into a gallery.

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: it aggregates all runs unless scoped to one, and returns a path for a human to open. This implies it is used after captures are taken, for human review. However, it does not explicitly name sibling tools as alternatives or provide 'when-not-to-use' guidance, so it misses the full 5 level.

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 ambiguous selector behavior ('acts on the first match and says so'), mentions blocking waits, and notes the prerequisite page opening. However, it does not disclose side effects of interactions (page state changes), failure behavior, or audit content specifics, leaving notable 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 description is five sentences, front-loaded with the main purpose, and every sentence adds substantive guidance (prerequisite, selector behavior, parameter hints). It is slightly dense but appropriate for a tool with 20 parameters; no redundant wording beyond acceptable summarization.

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 20 parameters and no output schema, the description is moderately complete. It explains the output generally (screenshot + text audit) and the prerequisite, but does not describe the audit content, error handling, or interaction side effects. An agent would still need schema details and possibly runtime feedback to fully understand expected behavior.

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 100%, so the baseline is 3. The description adds value beyond the schema by clarifying ordering ('Pass viewport to switch breakpoints before the selector resolves') and giving purpose to ignoreSelector ('mute known layout noise'). These contextual hints help an agent choose and sequence parameters correctly.

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: 'Perform ONE interaction on the currently open page, then return a webp screenshot AND a fresh text layout audit'. It also differentiates from siblings by emphasizing 'ONE' interaction, distinguishing it from run_interaction_sequence, and includes the audit output which is unique to this 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?

The description provides clear context: used after opening a page ('Open a page with capture_page_screenshot first') and for single-interaction verification. It implies the alternative (sequence tool) by stressing 'ONE', but does not explicitly name when-not conditions or alternative tool names. This is clear context without 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?

Since no annotations are provided, the description carries the full burden. It describes the overlay behavior, the elements targeted (including pointer cursor), and the output schema (screenshot plus legend). It also notes the overlay is removed after capture. It doesn't mention potential failures like non-interactive pages or permission issues, but gives solid context for a non-destructive tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, each earning its place: explains the mechanism, provides usage guidance, and notes the cleanup behavior. Slightly long but well-structured, with the core purpose front-loaded. No fluff.

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 tool that takes only a URL and optional parameters, the description covers the input-output contract well: what gets marked, output format, and how to use the results. It doesn't describe error cases or edge cases (e.g., no interactives found), but given the simplicity and clear schema, it's complete enough 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 description coverage is 100%, so the schema already documents all three parameters. The description doesn't add parameter-specific semantics beyond 'url', but it does implicitly clarify the viewport parameter by mentioning breakpoint switching. Since coverage is high, baseline 3 is appropriate.

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 function: paints numbered badges on all interactive elements, returns a marked screenshot with a legend. It distinguishes itself from siblings by specifying the set-of-mark technique and the specific output (legend with selectors and labels), which is unique among the listed 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 provides usage guidance: 'Pick your target off the picture by number, then act on its exact selector with interact_and_audit.' This tells the agent when to use this tool and how to chain it with a sibling. Also notes the overlay is removed after capture, implying it's a one-shot labeling step.

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?

Even without annotations, the description discloses key behaviors: session persistence across crashes, snapshot creation includes plaintext tokens (sensitivity), load recreates context requiring subsequent navigation, and clear rebuilds a clean context. It does not mention side effects like whether headers persist across navigations or if cookies are domain-restricted, but given the tool's inherent complexity, this is a strong disclosure.

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 tightly packed into three sentences with no fluff. It front-loads the purpose ('Reach authenticated pages') and then lists each action with its effect, making it easy to scan. Every clause adds operational value, including the warning about plaintext tokens.

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 complexity (5 params, nested objects, 4 distinct actions), the description covers the core workflow and key constraints (persistence, navigation requirement, gitignore warning). It lacks explicit detail on error handling or edge cases (e.g., what happens if save targets an existing name), but the schema and description together are sufficient for an agent to invoke the tool correctly in most scenarios.

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 100%, so the schema already documents each parameter. The description adds value by clarifying the role of 'name' (required for save/load) and the meaning of 'action' enum in context, but it doesn't elaborate on all nested properties (e.g., cookie attributes) beyond what the schema says. Still, the description enhances the action semantics beyond a simple enum.

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 it manages auth/session state (cookies, storage, headers) and enumerates each action (set, save, load, clear) with precise effects on the persistent session. It distinguishes itself from sibling tools like authenticate_login (which likely handles credential-based login) and manage_vault (which likely stores secrets), making its purpose unmistakable.

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 explicit usage guidance for each action: set adds cookies/localStorage/headers, save snapshots to disk, load restores a snapshot and then navigate to use it, clear drops everything. It also includes a critical warning about the snapshot file being gitignored due to plaintext tokens, helping the agent decide when to use this tool (e.g., for reaching authenticated pages) and what precautions to take.

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 behavioral transparency burden. It discloses important invariants: open makes the tab active, close never closes the last tab, the default tab is 'main', and other tools act on the active tab. It does not specify edge-case behavior such as closing the currently active tab, but the essentials are 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 dense but well-organized: it front-loads the use case, enumerates the actions in a compact list, and then adds the global active-tab rule and default label. Every clause carries operational meaning, 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?

Given no output schema and no annotations, the description does a good job: it explains what list returns and covers active-tab semantics, default label, and the never-close-last constraint. It does not state what open/switch/close return on success, but their effects are inferable from the stated behavior.

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 100%, so the baseline of 3 applies. The description mostly restates what the schema already says about the action parameter and label, adding no genuinely new parameter-level meaning beyond the schema's own 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 clearly states the tool's function: keeping multiple labeled browser tabs open and switching between them. It enumerates the four operations (open, switch, close, list) and explicitly distinguishes the tool from siblings with 'Every OTHER tool acts on the ACTIVE 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?

The description gives a strong usage context: use this when you need multiple concurrent real tabs with preserved state, and it clarifies that other tools operate on the active tab. It does not explicitly name alternatives or state when not to use the tool, but the guidance is clear enough for an agent to choose 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 provided, the description carries the full burden of behavioral disclosure. It explicitly warns that reset permanently DELETES the vault, requires the human to type RESET into a secure prompt, and that status never reveals secrets. The re-encryption behavior of change_passphrase is also stated.

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 cover all three actions, destructive warnings, and the post-reset step without padding. The opening 'Keep the credential vault recoverable' is slightly general, but the rest is dense and front-loaded with the most important behavioral caveats.

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-enum, no-output-schema, no-annotations tool, the description covers each action's effect, the key destructive consequence, the human confirmation requirement, and the recommended next step. An agent has enough information to invoke the tool correctly and safely.

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

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

The schema already covers the action enum at 100% with per-value descriptions, so the baseline is 3. The tool description adds meaningful semantics beyond the schema: permanent deletion, the escape-hatch purpose, and the re-enroll follow-up, which help an agent reason about consequences.

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 three precise verbs (status, reset, change_passphrase) each tied to a concrete outcome: reporting vault state without secrets, permanently deleting the vault, and re-encrypting all profiles. This clearly separates vault maintenance from the sibling enrollment/auth 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 reset action is explicitly scoped as the escape hatch for a forgotten passphrase, with re-enrollment called out as the follow-up. It does not explicitly state when to prefer enroll_credentials over this tool, but the context of vault maintenance vs. enrollment is clear enough.

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 discloses that all four full-resolution renders are saved to one run directory, paths are reported, the previously active viewport is restored afterwards, and webp compression is applied. It also notes that sizeMode 'thumb' shrinks the over-the-wire image. This is strong behavioral transparency for a capture tool, though it doesn't detail failure modes or exact path format.

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, front-loads the core action, and every clause earns its place. It packs compression, sizeMode behavior, disk saving, path reporting, and viewport restoration into a compact, readable form. 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 tool with 4 parameters, 100% schema coverage, and no output schema, the description covers the key behavioral aspects an agent needs: what gets captured, how images are delivered, where they are saved, and side effects on viewport. It doesn't describe the exact output format of the reported paths, but the absence of an output schema makes that a minor gap. Overall, it is complete enough 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 description coverage is 100%, so the schema already documents all four parameters. The description adds value by explaining the relationship between sizeMode and the four-image turn affordability, and by clarifying that disk always gets full-resolution even when thumb is sent. This goes beyond the schema's per-parameter descriptions, so a 4 is warranted.

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 ('Capture'), a specific resource ('one URL at all four breakpoints'), and the key outcome ('in a single call'). It also distinguishes itself from sibling tools like capture_page_screenshot and find_breakpoints by emphasizing the multi-breakpoint matrix behavior. The title reinforces the purpose, and the description adds concrete detail about compression and saved renders.

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 when to use this tool: when you need a responsive audit across all breakpoints in one call, and it mentions the sizeMode option to keep the turn affordable. It doesn't explicitly name alternatives or exclusions, but the context signals and sibling list make the use case clear. A 4 is appropriate because it gives clear context without explicit 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?

With no annotations provided, the description carries the full burden of behavioral disclosure abbrevia. It transparently explains the mechanism (getComputedStyle and getBoundingClientRect), the computed values returned, ancestor-composited color handling, and WCAG contrast thresholds. It stops short of noting side effects like page reload or viewport switching, though those are covered by the schema.

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 dense single sentence that front-loads the core identity and enumerates specifics without filler. It is slightly long and packed, but every phrase contributes functional information.

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 no output schema and no annotations, the description does well to explain what the tool returns and how the contrast verdict is derived. It covers the main dimensions, computed styles, color compositing, and verification purpose, leaving little ambiguity about call intent.

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 100%, so the baseline is 3. The description adds overall output context but does not materially enrich the parameter semantics beyond what the schema already documents; contrast details like large-text relaxation are already present in the 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 states a specific verb-resource pair ('measure an element') and clearly differentiates itself from image-based tools with 'Zero-image element inspector' and 'without image tokens.' It enumerates concrete outputs such as dimensions, computed styles, and contrast verdict, so an agent can immediately identify its 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 implies when to use it—verifying design-system and a11y specs—and contrasts with 'image tokens,' but it never names an alternative tool or gives explicit when-not-to-use guidance. The context is clear but exclusion logic is left to inference.

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 does so thoroughly. It discloses the observer timing (before page parses), the reload behavior, the ~2s watch window, the output (aggregate score and ranked elements), the cost profile (zero image tokens), and the side effect of discarding in-page state. This is comprehensive 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 a single dense paragraph with no wasted words. It front-loads the core purpose, then details mechanism, output, differentiator, and side effects in logical order. Every clause earns its place, balancing completeness with brevity.

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 moderate complexity, no output schema, and no annotations, the description is unusually complete. It explains the return format (aggregate score and element list), the thresholds for interpretation, the measurement method, and the side effects. An agent has enough to call it correctly and interpret results without further assumptions.

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 100%, so the schema already documents all parameters. The description adds value by providing CLS thresholds (good ≤0.10, poor >0.25) that directly inform the maxCls parameter and by explaining the measurement window (~2s) relevant to interpreting results. This goes beyond the schema's basic 'CI gate' wording.

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 ('arms', 'reloads', 'watches', 'reports') tied to a clear resource (layout shift) and scope (cold-load CLS diagnostic). It distinguishes itself from screenshot tools by noting 'jank no static screenshot shows', making its unique purpose evident.

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 usage for diagnosing layout shift on cold load and contrasts with static screenshots, but it does not explicitly name alternatives or state when not to use it. There is no clear routing to sibling tools like measure_element or matrix_responsive_audit. The guidance is implied rather than explicit.

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 full disclosure burden and meets it: stubs are context-level, survive navigations and crashes until cleared, and only apply to sub-resources. It also clarifies action semantics (add/clear/list) and persistence, which are not visible in the schema.

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?

Four sentences, each earning its place: purpose, action breakdown, persistence model, and scope limitation. It is front-loaded with the most important information and contains no filler or schema 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?

For a six-parameter, multi-action tool, the description covers action behavior, request scoping, persistence, and the top-level navigation restriction. Since every parameter is already documented in the schema, an agent has everything needed to invoke the tool 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?

Schema description coverage is 100%, so the baseline is met. The description adds value by mapping add to a URL glob → {status, contentType, body, headers} shape and explaining how clear/list use pattern, going slightly beyond individual parameter 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 specific verb and object ('Stub matching requests with canned responses') and immediately states the operational purpose: deterministic captures despite flaky or third-party endpoints. It enumerates the three actions (add/clear/list), making the tool's scope unmistakable and distinct from the capture/audit/screenshot 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 gives a clear trigger condition—use stubs when flaky or third-party endpoints could change captures—and an explicit when-not: top-level navigation can never be mocked. It does not name an alternative sibling tool, but none of the listed siblings offers mocking, so the context is sufficient without maximal 'vs alternatives' 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 are provided, so the description carries the burden. It discloses that this is a zero-image audit (no screenshots), that it measures the design system, and that it flags smells with selectors. However, it doesn't disclose whether the tool mutates state, whether it requires authentication, whether it navigates or reuses the current page, or what the response format looks like. The 'zero-image' note is useful but the behavioral profile is incomplete.

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 dense paragraph that front-loads the core purpose ('Zero-image DESIGN audit'), then lists measured elements and flagged smells efficiently. Every clause adds information; 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?

For a read-only audit tool with 100% schema coverage and no output schema, the description covers what it measures, what it flags, and how it differs from a sibling. It doesn't describe the response format or verdict behavior, but the schema's maxSmells parameter hints at the CI-gate behavior. The main gap is lack of behavioral context (auth, page reuse), but the core selection and invocation information 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 100%, so the schema already documents all four parameters. The description adds context about what the tool measures but doesn't add meaning to the parameters themselves beyond what the schema provides. Baseline 3 is appropriate.

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 ('measures'), a clear resource (the page's actual design system), and enumerates exactly what is measured (palette, type scale, spacing rhythm, radii, shadows) and what it flags (design smells with addressable selectors). It also explicitly distinguishes itself from scan_accessibility as the 'taste counterpart,' which differentiates it 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?

The description implies when to use it: when you need a design-system audit rather than an accessibility audit, and it names the alternative (scan_accessibility). It doesn't explicitly state when not to use it or list other alternatives, but the 'taste counterpart' framing gives clear context for selection.

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 key behaviors: returns ONE screenshot plus ONE layout audit after the final step, failure semantics (gesture/wait aborts at index, expect_* fails but flow finishes and marks whole response a FAILURE), and performance note ('far cheaper'). It also clarifies evaluate_script reads page state without a screenshot. It omits some details like reflow pauses and permission requirements, but covers the most critical behaviors.

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 dense but every sentence contributes: purpose and cost in the first clause, capability overview in the second, and failure semantics in the third. It's front-loaded with the most important distinction (cheaper than chaining) and uses concise, scannable language. 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 complex tool with nested steps, no output schema, and no annotations, the description covers the essential contexts: what it returns, failure modes, performance trade-off, and the range of actions. It doesn't detail the layout audit structure or explicitly mention the reflow pause (that's in schema), but the core agent-facing information is present. Slightly more detail on expected output shape would elevate it, but it's sufficient.

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 100%, so parameters are well-documented. The description adds meaning by explaining the overall flow: steps run back-to-back with a reflow pause, failure modes per step type, and the aggregate output. It also clarifies the action enum's relationship to interact_and_audit and the pointer_* actions' purpose for canvas/shadow DOM. This goes beyond the schema's individual parameter 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 clearly states the tool is a batch pipeline for multi-step flows like forms and nested menus, with specific verbs (navigates, matches viewport, runs steps) and a distinct resource (multi-step interaction sequence). It explicitly differentiates from chaining interact_and_audit by highlighting cost efficiency, so an agent can immediately understand its role.

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 names the alternative (interact_and_audit) and explicitly says it's 'far cheaper than chaining' that tool, giving clear context for when this tool is preferable. It also describes capabilities (mixing gestures, waits, expect_* and evaluate_script) but doesn't explicitly state when NOT to use it (e.g., for a single-step action), so it falls just 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?

No annotations are provided, so the description carries the full burden. It clearly discloses what is audited, what does not count, and the output form ('grouped text report with unique, addressable selectors'). It does not explicitly state read-only behavior or authentication needs, but 'audit' and 'scan' imply non-mutating 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?

Three sentences with no wasted words. The first sentence establishes the tool identity, the second enumerates concrete checks, and the third describes the output. Information is front-loaded and each 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?

Combined with the 100%-covered schema and the description's explicit output format, an agent has enough to invoke the tool correctly. It does not cover prerequisites like authentication or page-load state, but the schema's reload and viewport parameters cover the main operational concerns.

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 100%, so all four parameters are already fully documented. The description adds context about audit targets but no additional parameter-level meaning, which keeps this at the baseline.

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 action ('audit'), a specific target ('live DOM'), and a distinguishing scope ('Zero-image', 'WCAG foundation'). Enumerates exact checks so an agent can tell it apart from visual review or screenshot tools 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?

No explicit 'use this instead of X' guidance, but 'Zero-image' and 'WCAG foundation' make the intended context clear versus visual/design siblings. The CI-gate behavior described in the maxIssues parameter adds practical context for when to use it in a verification pipeline.

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 exceptionally transparent. It discloses that the AI never sees the code, the human enters it on a localhost page, the server fills the field, the tool never navigates, and it blocks until answered or 180s elapse. It also clarifies the only return values: success, error, or unknown.

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 core purpose and safety guarantee come first, followed by the mechanism, return contract, and timing constraint. Every sentence adds necessary information without redundancy or 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?

Even though there is no output schema, the description explicitly defines the return statuses and the follow-up action ('success (then manage_session action=save)'). It also covers the precondition, timeout, no-navigation guarantee, and selector auto-detection, providing everything an agent needs to invoke the tool 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?

Schema description coverage is 100%, so the baseline is 3 and the schema already documents source, profile, codeSelector, and submitSelector. The description adds only a small amount of parameter-related context, such as auto-detection of selectors and that codeSelector can be passed when page state is unknown, but it does not materially exceed the 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 opens with a specific verb and resource: 'Complete a two-factor challenge raised by authenticate_login, without the AI ever seeing the code.' It clearly distinguishes itself from the sibling auth flow by emphasizing the human-entered code is never exposed to the AI, and it adds concrete scope ('Acts on the page authenticate_login left behind and never navigates').

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 clearly situates this tool in the auth sequence: it completes a challenge raised by authenticate_login and acts on the page that tool left behind. It also states the blocking behavior and 180-second timeout. It does not explicitly name alternatives or exclusion cases, but the sequential context makes usage unambiguous.

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?

Without annotations, the description must carry transparency, and it does disclose useful error semantics (failed verdict marks response an error) and per-check evaluation. However, it states 'Reloads the URL by default' while the schema sets reload default false and says the default reuses the URL; this contradictory behavioral claim can mislead agents into relying on an automatic fresh reload.

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 are front-loaded with the core purpose, then mechanism/outcome, then motivating use case. No filler; 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?

It covers what the tool does, how it evaluates, and what it returns/error behavior, while the schema fully documents the parameters. The false reload-default statement and absence of any sibling-routing guidance prevent a perfect score, but overall an agent can invoke it 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?

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds general assertion semantics (measured vs expected) but no parameter-level detail beyond that, matching the baseline.

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 a specific observable objective—confirm a fix reached the deployed site rather than a stale local tab—and covers mechanism and output. It clearly separates this verification tool from similar capture/measure 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 gives a clear use case: checking that a fix actually landed and catching stale-local-tab false positives. It does not explicitly name alternatives or when not to use it, 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 carries full behavioral burden. It discloses that it saves a delta overlay to disk, requires a matching fullPage baseline, and can act as a CI gate via maxVariancePct. It does not cover failure modes or error handling, but it covers the main side effects and constraints adequately.

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 wasted words. The first sentence front-loads the core purpose and mechanism, while the second adds a critical prerequisite and parameter nuance. 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?

For a complex tool with 6 parameters, the description covers the essential usage context: baseline requirement, fullPage matching, CI gate behavior, and the delta overlay side effect. It does not mention output format or failure scenarios, but given the absence of an output schema and the tool's apparent role in a regression workflow, the coverage is strong.

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 100%, so the baseline for this dimension is 3. The description adds value by explaining the purpose of maxVariancePct as a CI gate, noting that fullPage clipping is reported, and clarifying reload's default behavior. These extra details go beyond the 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 states a specific verb (diffs), a precise resource (current render against a saved baseline), and the unique value proposition (element-resolved regression vs. pixel-level). It clearly distinguishes itself from siblings like compare_to_baseline by highlighting the element-resolution mechanism and output format.

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 requires a baseline from compare_to_baseline with matching fullPage, giving a clear prerequisite and pointing to a sibling tool. It implies when to use this tool (when element-level diff is needed) but does not explicitly state when not to use it or list alternative tools beyond the prerequisite.

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 present, so the description carries the burden. It discloses the race-avoidance timing, the response fields reported, the optional body snippet, and the timeout behavior of listing observed responses. It does not specify return structure or side effects, but for a waiter tool this is substantial.

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?

Four sentences, front-loaded with the core behavior, each adding distinct value: match/report, trigger timing, timeout diagnostics, and page scope. No fluff.

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 no annotations and no output schema, but the description covers what it waits for, what it reports, the trigger race, and timeout diagnostics. The nested trigger schema covers parameter detail. Minor gap: no explicit success/failure return semantics, but enough to invoke 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?

Schema description coverage is 75%, already high. The description adds no detail beyond 'URL matches a pattern' and 'optional body snippet', with the trigger timing also restated in the schema's trigger description. Baseline 3 applies.

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: 'Wait for a network response whose URL matches a pattern,' and enumerates the reported fields (status, method, content-type, size, body snippet). This clearly distinguishes it from interaction, screenshot, and mocking 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 states the trigger fires after the waiter is armed to avoid missing fast responses, giving a concrete usage scenario ('click Save, await POST /api/save'). It does not name exclusions or alternatives, but the context is clear enough for when to use.

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