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

No annotations provided; description carries burden. It states the tool checks for violations and reports issues with fix instructions, but does not mention side effects (none expected) or specific behaviors like URL accessibility requirements.

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 action and scope, no redundant 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?

Covers purpose, standards, and output report style. Lacks explicit mention of return format or limitations, but sufficient for a straightforward audit tool with one parameter.

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?

Single parameter (url) with 100% schema coverage. Description adds context about axe-core and WCAG but not about the parameter itself. 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?

Description clearly states the tool runs an automated accessibility audit with axe-core, specifies WCAG 2.1 Level A and AA, and distinguishes from siblings like seo_audit or performance_audit.

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 guidance on when to use this tool over alternatives like lighthouse_audit or compare_sites. Does not mention prerequisites 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?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states the tool 'analyzes' but does not clarify whether it is read-only, what output is produced, or if any side effects occur (e.g., report generation). This is a significant gap given the absence of annotations.

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 sentence that is concise and front-loaded with the main action. It lists the issue categories efficiently without wasted words, though it could benefit from slightly more structure (e.g., bullet points).

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 lack of an output schema and annotations, the description is incomplete. It does not mention what happens after analysis (e.g., returns a report, saves results) or how the agent can access the results. Sibling tools like 'export_report' suggest downstream steps, but this connection is not made.

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% with a single parameter that already has a description ('Absolute path to the frontend source directory'). The tool description adds no further parameter-specific meaning, meeting the baseline for high 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 states the tool analyzes frontend source code for a specific set of quality issues (accessibility, CSS, complexity, design, performance). It distinguishes itself from more specialized sibling tools like accessibility_audit or performance_audit by offering a broad, combined analysis.

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 a general analysis use case but provides no explicit guidance on when to choose this tool over the many specialized sibling tools. It lacks when-to-use/when-not-to-use context, leaving the agent to infer the appropriate scenario.

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 takes on the full burden. It discloses that the tool navigates to the URL, listens for console output and uncaught exceptions, returns structured results with counts, and warns that output may contain sensitive data unfiltered. It also notes it is free and runs within Claude Code, adding useful context.

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 paragraphs: first explains purpose and behavior, second warns about sensitive data, third notes it is free. It is front-loaded with the key action and value. Some sentences could be consolidated without losing meaning, but overall it is efficient.

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?

Despite lacking annotations and an output schema, the description covers the tool's behavior, input parameters, data sensitivity, and pricing. It does not detail the exact output structure beyond 'message counts by level', but the context is sufficient for an agent to understand usage and risks.

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?

Input schema has 100% coverage with descriptions for both parameters (url and waitMs). The tool description explains the overall process but does not add significant detail beyond the schema. The note about sensitive data is relevant but not parameter-specific. 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 captures all console messages during page load, specifying message types (log, warn, error, info, debug). It effectively differentiates from siblings like 'capture_errors' by emphasizing the full console output, though it does not explicitly contrast with 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?

The description says the tool is 'useful for debugging runtime issues, detecting warnings, and finding errors that only appear in the browser console,' implying usage context. However, it does not provide explicit when-not-to-use guidance or mention alternative tools for similar tasks.

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 provided. Describes itself as free but lacks disclosure of side effects, authorization needs, or whether it modifies page state. The tool likely only reads errors, but this is not stated 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?

Two sentences plus a free note, front-loaded with purpose. No redundant 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?

Adequately explains what the tool does and returns for a single-parameter tool without output schema. Missing details like timeout or error handling for inaccessible URLs, but overall complete enough.

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% with a clear description for the url parameter. The description adds context about capturing errors during page load and the return format, but does not provide substantial additional meaning 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?

Clearly states it captures JavaScript errors, uncaught exceptions, unhandled promise rejections, and failed resource loads. Distinguishes from sibling tools like capture_console and capture_network by focusing on errors specifically.

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 usage for finding runtime JS errors and broken resources, but does not explicitly state when to use versus alternatives or provide 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?

No annotations are provided, so the description carries the full burden. It explains it captures during page load and returns a summary, but doesn't state side effects (e.g., page navigation, state changes) or permissions needed. For a capture tool, it's likely read-only, but not explicitly said.

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-loaded with the core purpose. The first sentence is somewhat long but packs information efficiently. A minor improvement would be to split it for readability.

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, the description mentions the summary output (total requests, failed, size, breakdown). It covers common use cases and explains the tool's nature (free, within Claude Code). It doesn't detail pagination or filtering but is fairly complete for a network request capture 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 100% as both parameters (url, waitMs) have descriptions in the schema. The description adds no extra meaning beyond what the schema provides, so 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 captures network requests during page load, listing specific details (status codes, sizes, timing, resource types) and provides a summary. It distinguishes from sibling tools like capture_console or capture_errors by focusing on network-level data.

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 says it's useful for finding failed API calls, slow requests, etc., giving good usage context. It notes the tool is free and runs within Claude Code, but doesn't explicitly exclude alternatives or mention when not to use it. Sibling tools like performance_audit exist but no direct comparison is made.

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 provided, so description carries full burden. It mentions running fresh audits and being free/in-Claude, but lacks detail on side effects, caching, or destructive actions.

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?

Description is well-structured: first sentence states purpose, then details, example JSON, and a free note. Each part is necessary 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?

Gives clear output format and configuration details. Lacks mention of output schema but compensated by describing return value. Complete enough for a straightforward budget check.

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 covers both params with descriptions (100% coverage). Description adds value by explaining the budget config structure and the role of codeDir.

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?

Description clearly states the tool checks budgets against .uimaxrc.json config, runs audits, and returns pass/fail. Distinct from sibling audit tools that produce raw scores.

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?

Description implies usage when budget config exists and pass/fail check is needed, contrasting with standalone audits. However, no explicit alternatives or when-not-to-use.

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 two-screenshot process and comparison, returning both images and difference percentage. However, it could clarify the interpretation of the percentage (e.g., threshold for 'support').

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-loading the purpose and concisely explaining the process and output. No wasted 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?

Given no output schema, the description covers return values (screenshots, difference percentage). It lacks details on potential errors or limitations but is adequate for a 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 100% with a description for the url parameter. The tool description does not add further semantic details about the url beyond what the schema provides, so it meets 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 clearly states the tool detects dark mode support via screenshots and comparison, with a specific verb ('Detect') and resource ('dark mode'). It distinguishes from sibling tools like compare_screenshots and screenshot by focusing on light/dark comparison.

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 for checking dark mode implementation and provides context, but does not explicitly state when not to use it or mention alternatives among 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?

No annotations are provided, so description carries full burden. It discloses returning screenshot for visual verification and the need for URL if not navigated. Does not mention potential side effects like navigation or error handling if element not found.

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 concise sentences with front-loaded purpose. Every sentence adds value. No waste.

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?

Covers main behavior, return value (screenshot), and optional navigation. No output schema, but description adequately explains what to expect. Lacks error handling details but sufficient for a 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 has 100% coverage so baseline is 3. The description adds context for 'url' and 'waitAfter' (e.g., 'for animations/transitions'), adding slight value beyond 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?

Clearly states 'Click an element by CSS selector' with specific verb and resource. Distinguishes from siblings like select_option and type_text. Mentions return of screenshot for verification.

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?

Provides guidance: if page not navigated, provide URL first. Implicitly tells when to use (need to click) and why URL param exists. Lacks explicit alternatives or when-not-to-use cases.

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 transparently states the tool captures screenshots, computes pixel-level diff, and returns both original images plus a diff image. No side effects or constraints are mentioned, but the behavior is well-described.

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, front-loading the core action ('Before/after visual comparison with pixel-level diffing') followed by the process and use cases. No redundant or unnecessary 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?

With 4 parameters (2 required) and no output schema, the description adequately covers what the tool does and what it returns (images + diff). It lacks details on output format, but for a visual comparison tool, the explanation is 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% with descriptions for all parameters. The description adds context by labeling urlA and urlB as 'before' and 'after' and providing example values, and explaining width/height as viewport size, adding value 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 clearly states the tool does before/after visual comparison with pixel-level diffing, capturing screenshots of two URLs and returning images plus a diff. It distinguishes from siblings like 'compare_to_baseline' or 'compare_sites' by specifying the exact process.

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 provides use cases: 'verify UI changes, compare staging vs production, or check before/after states of a redesign.' It lacks explicit when-not-to-use or alternatives, but the context is clear enough for agent 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 discloses key behaviors: concurrent audits, return of screenshots and grade comparison table, and that it is free. However, it does not state if the tool is read-only, mention potential performance impacts, or describe error conditions. More context on side effects would improve 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 two short paragraphs with no redundant information. The first paragraph immediately states the tool's purpose and actions, and the second provides usage guidance and a note about cost. 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?

Given no output schema, the description adequately explains the output (screenshots and grade comparison table). It covers the main inputs, actions, and outputs. It could benefit from more detail on the output format or error handling, but it is sufficiently complete for an agent to understand the tool's role.

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% with clear descriptions for each parameter. The description adds minimal extra meaning beyond the schema; it reiterates the URLs and their purpose (first and second URL to audit). Baseline of 3 is appropriate given sufficient 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 states the tool performs competitive benchmarking by auditing two URLs side-by-side and producing a comparison report card. It explicitly lists the audit types (accessibility, performance, SEO) and differentiates from sibling tools like 'compare_screenshots' and individual audit 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 provides explicit use cases: 'benchmark their site against a competitor, compare staging vs production, or evaluate two different sites.' It implies when to use this comprehensive tool over single-audit tools, but does not include explicit negative guidance or alternatives.

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. It discloses key behaviors: runs fresh audits, loads previous baseline from file, shows deltas. Also notes it's free and runs locally. No contradictions.

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 in two paragraphs, front-loaded with the main purpose, followed by process details and usage guidance. No redundant or extraneous text; 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?

For a simple two-parameter tool with no output schema, the description fully explains what it does, how it works, and when to use it. It covers inputs and the process sufficiently for an agent 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 100%, so baseline is 3. The description adds context by mentioning 'URL' and 'previous baseline from .uimax-history.json', reinforcing the codeDir parameter's purpose, but doesn't add substantial new information 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?

Description clearly states the verb 'compare', the resource 'audit state against baseline', and the outcome 'shows what improved and regressed'. It distinguishes itself from siblings like 'save_baseline' by focusing on comparison.

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?

Provides explicit when-to-use context: 'Use this after making changes to verify you improved the metrics you intended.' No explicit when-not or alternatives, but the guidance is clear 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 exist, so the description fully discloses behavior: discovers internal links, deduplicates, visits up to maxPages (with default and max), and performs screenshot, axe-core audit, and Performance API metrics on each page. It also notes the tool is free and runs within Claude Code. This is comprehensive for a read-only audit 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 concise (5 sentences) with each sentence adding unique value. It is front-loaded with the core functionality and ends with a note on cost. 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?

While there is no output schema, the description lists what each page audit produces (screenshot, axe-core, Performance API) and the page limit. It could be more complete by describing the return format or structure, but it provides sufficient context for an agent 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 coverage is 100%, so the baseline is 3. The description adds value by specifying the max for maxPages (10) beyond the schema's default, and clarifies the purpose of codeDir as 'reserved for future use'. This extra context justifies a 4.

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 crawls multiple pages from a starting URL and runs accessibility + performance audits. It distinguishes itself from the sibling lighthouse_audit by explicitly stating it does NOT run Lighthouse.

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 advises using this tool to 'audit an entire site section quickly' and clarifies it does not run Lighthouse, providing clear differentiation from sibling tools. However, it does not explicitly state when not to use it or list alternative 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?

No annotations provided, so description carries full burden. It discloses that the tool runs a full review pipeline and is 'FREE' within Claude Code, but does not detail side effects (e.g., runtime, file overwrite, state changes). Adequate but has 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?

Three sentences, each serving a clear purpose: main action, usage guideline, and a free note. No fluff, front-loaded with key 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 three parameters (all described), no output schema, and no annotations, the description covers the tool's purpose, output, and when to use. Missing details on prerequisites (e.g., app must be running) and error handling, but sufficient for a file-generation 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 100% with descriptions for all three parameters. The description adds minimal extra meaning (e.g., outputPath default). With high schema coverage, 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?

Clearly states the tool generates a standalone HTML report with all audit findings embedded. It specifies the full pipeline (screenshot, accessibility, performance, code analysis) and distinguishes from siblings by focusing on a shareable file output.

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 states when to use: 'when the user wants a downloadable/shareable report of their UI review.' Does not specify when not to use or mention alternatives, but the context of siblings implies alternatives for individual audits.

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 returned data (attributes, styles, screenshot) fairly well. However, it does not explicitly state that the tool is read-only or idempotent, which would be helpful with no annotations.

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 concise sentences, front-loaded with purpose and key details. Every sentence adds value, no 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?

Given no output schema, the description adequately enumerates return fields (tag name, text, attributes, bounding box, styles, screenshot). For a read-oriented tool with moderate complexity, this is 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?

The schema already describes both parameters (selector and URL) with descriptions. The description adds minimal value beyond schema, clarifying selector as CSS and URL as optional navigation. With 100% schema coverage, 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 retrieves detailed information (tag name, text, attributes, bounding box, computed styles) and returns a screenshot. It uses a specific verb (get) and resource (element), and distinguishes from sibling tools like screenshot.

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 tool is used for inspecting specific DOM elements, but provides no explicit guidance on when to use it versus alternatives like accessibility_audit or analyze_code. No exclusions or when-not-to-use context.

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 full burden. It discloses that the tool is free and runs entirely within Claude Code, implying no external API calls. The read-only nature is clear from the verb 'view'. It does not explicitly mention that it reads from a local file, but the parameter documentation covers that.

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 very concise with two short sentences for purpose and one sentence for the free note. It is front-loaded and free of fluff, earning 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 is simple, and the description covers its purpose and key output fields. The schema explains parameters. Without an output schema, the description mentions what the output shows (scores, issues). It could mention ordering or pagination but is sufficient for a basic history 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 100%, so the schema already documents all parameters. The description adds no new 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 clearly states the tool's purpose with a specific verb 'view' and resource 'past UIMax reviews'. It lists the data fields (when reviews were run, scores, issues) and frames the use case as understanding frontend health over time, distinguishing it from siblings like 'get_review_stats' which likely provides aggregate statistics.

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 says 'Use this to understand the project's frontend health over time' and notes the tool is free, which provides context for when to use it. However, it does not specify when not to use it or mention alternatives 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?

No annotations exist, so the description carries the burden. It mentions the tool is free and runs locally, which is useful behavioral context, but does not disclose data freshness, side effects, or permissions needed.

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: first explains what the tool does, second adds a key usage note (free). No wasted words, front-loaded with essential info.

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 stats retrieval tool with no output schema, the description covers the input parameter, output contents, and a behavioral trait (free/local). Minor gaps (e.g., live vs cached data) but adequate for the tool's 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?

Schema coverage is 100%, and the description adds no extra meaning beyond the schema's own parameter description. Baseline score of 3 is appropriate as the schema already documents the parameter fully.

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 retrieves aggregate statistics from UIMax reviews, listing specific outputs (total reviews, score trends, etc.). This differentiates it from sibling tools like 'accessibility_audit' or 'analyze_code' which have distinct purposes.

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 notes the tool is free and runs within Claude Code, implying it should be used when cost is a concern, but it does not explicitly compare with alternatives or specify 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?

No annotations are present, so the description must carry the full burden. It describes the outputs (element identification, measurements, suggestions) but does not disclose behavioral traits such as whether the tool modifies state, requires network access, or has resource implications. The description is adequate but could be more explicit about side effects.

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 no redundant information. It front-loads the purpose and efficiently covers what the tool does and what it returns. Every sentence contributes 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?

Given there is no output schema, the description adequately explains what the tool returns (element ID, measurements, suggestions). The single parameter is well-documented in the schema. The description is complete for the tool's function and context.

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 covers the single parameter 'url' with a clear description. The tool's description does not add additional meaning beyond the schema; it just sets context. Since schema coverage is 100%, 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 clearly states it is a 'Deep Largest Contentful Paint (LCP) analysis' and enumerates specific capabilities: identifying the LCP element, measuring TTFB, resource load time, render delay, and providing optimization suggestions. This is a specific verb-resource combination that distinguishes it from sibling audit tools like 'performance_audit' or 'lighthouse_audit'.

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 improving LCP performance and mentions a threshold (2.5s), but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusion or comparison to siblings is provided, leaving the agent to infer context.

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 must cover behavioral traits. It implies a read-only audit ('run a full Lighthouse audit') and mentions it is 'heavier' (resource cost), but does not explicitly confirm non-destructive nature, permissions, or rate limits.

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 concise sentences that front-load the action and output, then briefly compare to a sibling. No filler, 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 single-parameter tool with no output schema, the description adequately covers purpose, output, and relative weight. Missing details like return format or exhaustive list of findings are minor given the simplicity.

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% with a clear description for the 'url' parameter. The tool description does not add additional semantic context beyond the schema, meeting the baseline for full 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 states it runs a full Lighthouse audit on a URL and returns scores and findings. It distinguishes from sibling 'performance_audit' by noting it is heavier and provides industry-standard scores.

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 contrasts with 'performance_audit' providing a when-to-use hint. However, it lacks explicit 'when not to use' or mention of other siblings like 'seo_audit', 'accessibility_audit', etc., which are all related but not compared.

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 adequately discloses key behaviors: waiting for network idle and returning specific data. However, it does not mention potential side effects (e.g., altering browser history) or error cases, which would enhance 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 concise and well-structured: the first paragraph states the action and return, the second provides usage guidance. Every sentence adds value without 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?

Despite the lack of an output schema, the description fully explains what the tool returns. It covers all necessary aspects for a simple one-parameter tool: action, behavior, return values, and usage context.

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 describes the 'url' parameter with full coverage (100%), including an example. The description adds no additional semantic value beyond what the schema provides, so a baseline score 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 clearly states the action ('Navigate to a URL'), the return values (final URL, title, status code, screenshot), and waits for network idle. It distinguishes from sibling tools like 'click' or 'screenshot' by indicating that this tool is for opening a page, not for interacting or taking standalone screenshots.

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 instructs when to use: 'Use this when you need to open a page before performing interactions, or to verify a page loads successfully.' This provides clear context and expectations for the agent, differentiating it from interaction or verification 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?

No annotations provided, so description carries full burden. Implies a read-only measurement operation, but does not explicitly state non-destructive behavior or side effects. Adequate for a simple measurement 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?

Single sentence, front-loaded with the action and metrics, no redundancy. Maximum conciseness.

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 simple tool with one parameter and no output schema, description covers the key purpose. Could describe return format implicitly, but sufficient for selection.

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% for the single 'url' parameter, which is described clearly in the schema. The description adds no additional meaning beyond what the schema 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 clearly states the tool measures Core Web Vitals and performance metrics, listing specific metrics like FCP, LCP, etc. It distinguishes from sibling tools like accessibility_audit and lighthouse_audit, though it could explicitly mention when to use this over Lighthouse audit.

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 guidance on when to use this tool versus alternatives like lighthouse_audit or check_budgets. Missing explicit context 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?

No annotations are provided, so the description carries the burden. It reveals that a full Lighthouse audit runs under the hood, but does not disclose read-only behavior, potential network usage, or side effects. Some transparency is present but not exhaustive.

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 concise sentences: first sentence states the purpose, second explains the mechanism. No wasted words, front-loaded with core functionality.

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 covers the main function and result format (pass/fail). Lacks mention of prerequisites (e.g., network) or limitations, but is generally complete.

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% with a clear description of the 'url' parameter. The description adds no additional meaning beyond the schema, so 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 it checks PWA readiness, listing specific aspects (manifest, service worker, HTTPS, offline). It distinguishes from siblings like performance_audit and lighthouse_audit by focusing solely on PWA criteria.

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 for PWA verification but does not explicitly state when to use this tool over alternatives like lighthouse_audit (which also runs Lighthouse) or other specialized audits. No when-not guidance is provided.

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?

Discloses that the tool is free and runs entirely within Claude Code. Mentions capturing a screenshot and returning it with a design review. However, it does not detail whether the tool modifies state, requires user input after capture, or the exact nature of the return behavior. The description mixes instructions to the user with tool 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?

Description is concise with three sentences. The first sentence clearly states purpose. The subsequent sentences add context and usage guidance, though the instruction about analyzing the screenshot could be considered redundant or user guidance rather than tool description.

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 simplicity (one parameter, no output schema, no annotations), the description adequately covers purpose, exclusions, and usage context (rapid design iteration). It lacks information about error conditions or return format, but these are minimal concerns for this 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 100% for the single parameter, so the schema already provides a clear description. The description adds no additional parameter semantics beyond 'captures a screenshot' which is implicit from the tool's purpose.

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 is a 'design-only review' that captures a screenshot and provides visual/UX feedback. Explicitly distinguishes from siblings by stating 'No code analysis, no performance audit — just visual/UX feedback.' The verb+resource is specific and the scope is well-defined.

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?

States it is 'Great for rapid design iteration' and excludes code/performance analysis, implying when to use. However, it does not explicitly name alternatives or provide exclusion criteria beyond the implicit contrast with non-design 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, the description carries full burden for behavioral traits. It does not mention that the tool is read-only, has no side effects, or any prerequisites (e.g., page must be loaded). The description only describes output, not 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 sentences, no unnecessary words. Front-loaded with 'Full resource breakdown', immediately conveying purpose. 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?

Given one parameter and no output schema, the description adequately lists what the tool returns (transfer size, type breakdown, requests, top 10, render-blocking). Could mention result format (JSON) but not required for basic completeness.

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?

Single parameter 'url' with 100% schema coverage. Description adds example format (http://localhost:3000) but schema already provides format=uri and description. Baseline 3 is appropriate as schema covers the meaning, and description adds marginal value.

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 performs a 'full resource breakdown' listing specific metrics (transfer size, type breakdown, requests, top 10, render-blocking). It distinguishes from siblings like performance_audit by focusing on resource loading rather than overall performance scores.

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 guidance on when to use this tool versus alternatives (e.g., performance_audit, lighthouse_audit). The description implies it's for identifying heavy resources, but lacks when-not or comparison to 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?

No annotations are provided, so the description bears full responsibility. It does not disclose behavioral traits such as error handling, return format (base64 or URLs), or whether screenshots are saved. The description only states the action without any side effects or limitations.

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 consists of two sentences with no unnecessary words. The primary action is front-loaded, and the second sentence adds relevant context. Every part 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?

With no output schema, the description should explain what the tool returns (e.g., an array of screenshot data). It fails to do so. However, the task is simple (single parameter, three viewports), so the gap is moderate. Adequate for minimal use but incomplete.

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% for the single parameter 'url', which includes its own description. The tool description adds the context of capturing at three viewports but does not elaborate on the parameter's format or constraints 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 clearly states 'Capture screenshots at mobile (375px), tablet (768px), and desktop (1440px) viewports.' It uses a specific verb ('capture') and resource ('screenshots at specific viewports'), and distinguishes itself from sibling tools like 'screenshot' (single viewport) and 'compare_screenshots'.

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 'Perfect for reviewing responsive design' indicates the primary use case. While it does not explicitly mention when not to use or name alternatives, the context is clear given the sibling tool list (e.g., 'screenshot' for single viewport).

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 that the tool is free and runs locally in Claude Code, which is helpful. However, it does not state whether the tool is read-only, whether it has side effects, or what the output format is. This leaves 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 description is concise with two sentences plus a notable line about being free. It is front-loaded with the core purpose. The free note is useful but slightly extraneous, keeping it from a 5.

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 3 parameters, no output schema, and no annotations. The description covers the purpose and output highlights but does not mention output format, error conditions, or prerequisites (e.g., reviews must exist). Adequate but not thorough.

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 provides 100% coverage with clear descriptions for each parameter (codeDir, reviewIdA, reviewIdB). The description adds little beyond noting the tool shows new/resolved issues and score changes, which does not directly explain parameter usage. 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 compares two specific reviews and shows what changed (new issues, resolved issues, score changes). This is specific and distinguishes it from sibling tools like get_review_history or semantic_compare.

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 mentions it is free and runs within Claude Code, which hints at when to use, but does not explicitly state when to use this tool versus alternatives like quick_review or compare_sites. No guidance on prerequisites or when not to use.

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 burden. It discloses that the tool captures a screenshot, runs audits, and returns data with methodology. However, it does not explicitly state whether it modifies anything (e.g., navigates to URL, changes files), nor does it describe potential side effects or permissions needed. The claim 'runs entirely within Claude Code' is helpful but 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 front-loaded with the purpose, but it includes an all-caps emphasis and a list of mandatory steps that could be more concise. The first paragraph is efficient, but the subsequent instructions add verbosity without being excessively long.

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 large number of sibling tools (e.g., lighthouse_audit, accessibility_audit, quick_review), the description fails to explain how review_ui relates to them or when to prefer an individual audit. No output schema exists, yet the description only says 'returns ALL data' without detailing what fields or structure to expect, leaving the agent uninformed.

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 baseline is 3. The description does not add any extra meaning beyond what the parameter names and schema descriptions already provide. Parameters are straightforward (url, codeDirectory, width, height), and the description doesn't clarify formats or constraints further.

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's a pipeline for UI review, capturing screenshots and running multiple audits. It specifies when to use it (when user asks to 'review my UI', etc.). However, it doesn't explicitly differentiate from sibling composite tools like quick_review or the individual audit tools, which share overlapping functionality.

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 'Use this when the user asks to...' and provides mandatory post-usage steps (study screenshot, analyze data, generate review, implement fixes). It also notes the tool is free. No when-not-to-use guidance is provided, but the context is clear.

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 burden. It discloses that the tool runs multiple audits (screenshot, accessibility, performance, Lighthouse) and saves results to a specific file. It also notes it is free and runs within Claude Code. However, it does not mention prerequisites (e.g., app must be running) 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?

Three sentences, front-loaded with purpose, then details, then usage context. The promotional line about being free is slightly extraneous but does not detract. Overall efficient.

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 2 parameters, no output schema, and a description that explains what the tool does, its output file, and when to use it, the description is fairly complete. It could mention the connection to 'compare_to_baseline' but is adequate.

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 description adds value by explaining that `url` must be of a running application and that `codeDir` defaults to cwd. This provides context 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 clearly states the verb 'Save' and the resource 'baseline snapshot', and explains it runs multiple audits. It implicitly differentiates from siblings like 'compare_to_baseline' by establishing a baseline, but does not explicitly distinguish from other audit tools like 'lighthouse_audit'.

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 usage context: 'Use this to establish a baseline before making changes, so you can compare later.' This implies when to use but does not mention when not to use or explicitly name alternative tools (e.g., 'compare_to_baseline' for comparison).

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 partially discloses behavior by stating it returns a PNG image, implying a read-only operation. However, it does not explicitly mention non-destructiveness, authentication needs, rate limits, or any side effects. The lack of such detail reduces trust, but the core behavior is clear enough for a simple capture.

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 sentence that front-loads the action verb and resource. Every word serves a purpose: 'Capture', 'screenshot', 'webpage', and the return value. It wastes no space, making it easy 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?

Given the tool has 5 parameters and no output schema, the description provides minimal context beyond 'returns a PNG image'. It does not explain the format (e.g., base64), the effect of parameters, or any edge cases. For a simple tool this is adequate but not comprehensive; missing details like timeout or error handling reduce completeness.

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?

Input schema coverage is 100%, so parameters are fully described structurally. The description adds no extra meaning beyond the schema. Baseline 3 is appropriate since the description does not need to compensate for missing schema details, but it also does not enhance parameter understanding.

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 captures a screenshot of a webpage, which is a specific verb+resource. It distinguishes from siblings like 'accessibility_audit' or 'lighthouse_audit' that perform different tasks. The addition of 'for design issues, layout problems, and UI quality' provides context without conflating with similar tools like 'responsive_screenshots'.

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 no guidance on when to use this tool versus alternatives like 'responsive_screenshots', 'compare_screenshots', or 'lighthouse_audit'. There is no mention of prerequisites, when to avoid, or which sibling is better for specific scenarios. This leaves the agent without decision criteria.

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 provided, so the description must disclose behavior. It adds that a screenshot is returned after scrolling, which is valuable. However, it omits details on scrolling behavior (smooth/instant), handling of iframes, error states for missing selectors, or effect of the url parameter.

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 packed with essential information: action (scroll), modes (pixel or element), and output (screenshot). No wasted 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?

Given the four optional parameters and no output schema, the description is mostly complete: it explains the two scroll modes and the screenshot return. Minor missing details like what happens if toSelector fails or if amount exceeds page length, but adequate for typical use.

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?

Input schema has 100% description coverage, so the baseline is 3. The description does not add extra meaning beyond the schema for parameters, but the overall purpose of returning a screenshot is separate.

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 scrolls by pixel amount or to an element and returns a screenshot. It distinguishes itself from siblings like navigate (which goes to URLs) and click (which interacts), but does not explicitly differentiate from any similar scrolling tool, as none exist.

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 when scrolling is needed with visual verification, but lacks explicit 'when to use' vs 'when not to use' or alternatives. The presence of toSelector vs direction/amount suggests two modes, but no guidance on choosing between them.

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 provided. Description mentions using Lighthouse and returning pass/fail with severity, implying a read-only operation. However, it lacks details on permissions, rate limits, or side effects, leaving some behavioral aspects unspecified.

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 sentence with a clear list of checks, front-loaded with purpose and no extraneous 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?

With one parameter and no output schema or annotations, the description is largely complete. It covers the tool's purpose and output nature. Minor gap: does not explain severity levels or scoring format.

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 covers 100% of parameters with a description. The description adds context by specifying the URL format and linking it to security auditing, enhancing understanding 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 clearly states the tool checks security posture via Lighthouse, listing specific items (HTTPS, CSP, etc.) and returns pass/fail with severity. It distinguishes from sibling audit tools like performance_audit or seo_audit.

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 for security auditing but does not explicitly state when to use it versus alternatives (e.g., performance_audit, seo_audit) or when not to use it. No exclusions or context provided.

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?

Discloses that a screenshot is returned after selection, but does not discuss side effects, DOM mutations, or potential failures like disabled selects.

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; first sentence states action, second adds 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?

Describes the main action and return value, but does not cover error handling, edge cases, or the role of the optional URL parameter.

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%, but the description adds no extra meaning to the parameters; it does not elaborate on selector format or value constraint.

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 the tool selects an option from a <select> element by value and returns a screenshot, distinguishing it from sibling tools like 'click' which is generic.

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?

Indicates the tool is for selecting from dropdowns by value, but does not provide when-not-to-use or mention alternatives like clicking the option directly.

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 fully discloses that it is free, runs within Claude Code, requires no API keys, and returns screenshots, diff image, percentage, and a semantic prompt. It explains the use of Claude's vision. Missing details on error handling or prerequisites, but covers key behavioral traits.

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 short paragraphs: first explains purpose and differentiation, second details return values and pricing. Every sentence adds value—no redundancy, tautology, or fluff. Front-loaded with purpose.

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 explains return values, methodology, and cost model, which is good for a tool with no output schema. It lacks details on error handling (e.g., invalid URLs) or prerequisites (e.g., running servers), which are minor gaps. Overall, it provides sufficient context for 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?

Schema description coverage is 100%, so the schema already documents each parameter's meaning. The description adds context for the overall workflow (e.g., changeDescription is for the intended change) but does not enhance individual parameter semantics 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 clearly states it does 'AI-powered visual comparison' for semantic evaluation of UI changes, differentiating from pixel diffing. It establishes a specific verb ('compare' implicitly) and resource (before/after screenshots with change description). Among siblings like compare_screenshots, compare_sites, and compare_to_baseline, it uniquely focuses on semantic intent.

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 when to use—'to understand intent' and 'determine if changes match what was requested'—but does not explicitly say when not to use or name alternatives. However, the context is clear enough for an agent to choose this over pixel-based 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 adds context: it checks 18 signals, returns score/recommendations, runs within Claude Code, and is FREE. It implies read-only behavior without stating destructive effects. No contradictions.

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 well-structured sentences covering purpose, signals, usage guidance, and free status. No wasted words; 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?

Given the simple input (single URL), no output schema, and no annotations, the description sufficiently covers tool behavior, what it checks, and what it returns. Also notes it's free, which is helpful context.

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% for the single parameter 'url'. The description does not add parameter-level details beyond the schema, but the schema itself is clear. 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 runs a comprehensive SEO audit, lists 18 specific signals checked, and specifies the output (0-100 score and recommendations). This distinguishes it from sibling audit tools (e.g., accessibility_audit, performance_audit).

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?

Provides explicit guidance on when to use: checking SEO health, improving search visibility, or ensuring social sharing metadata. However, it does not explicitly exclude other scenarios or mention alternatives.

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 exist, so the description must carry the burden. It returns a screenshot and notes options, but does not disclose potential side effects (e.g., focus changes, waiting for element, typing speed). Basic behavioral traits are covered but not detailed.

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. Information is front-loaded: purpose, return value, then options. 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 simple typing tool with no output schema, the description covers the purpose, return (screenshot), and all parameters. No missing information 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% with good descriptions. The description adds context beyond the schema by explaining the screenshot return and clarifying the optional boolean params, which aids understanding.

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 types text into an input field or textarea using a CSS selector, with a specific verb and resource. It differentiates from sibling tools like click, select_option, and scroll by focusing on text input.

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 filling input fields and mentions optional behaviors (clear first, press Enter). It lacks explicit alternatives or when-not-to-use, but the context is clear enough for an agent to infer appropriate use.

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?

The description transparently states it runs Lighthouse and extracts specific audits, disclosing the method and output (resource bytes, savings). No annotations provided, but the description compensates by clearly describing the tool's 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 with no wasted words. It front-loads the purpose, then explains method, then provides benefit. Clean and efficient.

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 a single required parameter and no output schema, the description adequately explains what results to expect (resource details with bytes and savings). It does not specify response format, but is sufficient for the tool's simplicity.

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 defines a single 'url' parameter with a basic description. The tool description adds context by explaining that the URL is for a page to analyze, and that results include resource details, adding meaning 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 clearly states it finds unused JavaScript and CSS on a page using Lighthouse audits, specifying exact resource details. It is specific and distinct from sibling tools like 'lighthouse_audit' which may run a full audit.

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 mentions 'Great for reducing bundle size' as a use case, but does not provide explicit guidance on when not to use it or compare to alternatives like 'resource_analysis' or 'performance_audit'.

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?

Describes the outcome (grade transitions, resolved issues count) and that it closes the loop. With no annotations, the description bears the burden and does well, though it could mention side effects or data persistence. No contradiction with missing annotations.

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: what it does, when to use, what to pass, and a cost note. Front-loaded with key action and 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?

With 4 params and no output schema, the description covers the return (Report Card with transitions, resolved/remaining issues). Could include error handling or prerequisites but sufficient for core 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 baseline is 3. The description only mentions url and codeDirectory, not width/height, but schema already describes them. No added parameter meaning beyond 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 clearly states the tool re-runs the full audit pipeline and compares against the original review, showing a before/after Report Card. It uses specific verbs and resources, and the purpose is distinct from siblings like review_ui.

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 states 'Use this AFTER implementing fixes from a review_ui run' and instructs to pass the same URL and code directory. Also notes it's free and runs within Claude Code, providing clear when-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?

Without annotations, the description must fully convey behavior. It explains waiting and return values, but omits details like timeout handling, failure conditions, or that it blocks execution. This is adequate but not comprehensive.

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 extremely concise with two sentences, each serving a clear purpose: describing the core action and providing usage advice. No unnecessary 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?

Given the tool's moderate complexity (4 parameters, no output schema), the description covers the purpose, usage, and return values. It lacks details about default timeout or interplay between 'visible' and 'selector', but overall it is 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?

The input schema has 100% description coverage for all parameters, so the description adds no additional meaning beyond what the schema provides. The description's mention of return values is not parameter-specific.

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 ('Wait for an element') and resource ('in the DOM'), and specifies the return values (tag name and text content). It distinguishes itself from siblings like 'get_element' by emphasizing the dynamic waiting behavior.

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 advises using this tool 'before interacting with dynamic content', giving clear context. However, it does not mention when not to use it or provide alternatives, leaving some room for improvement.

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