Server Quality Checklist

Tool Scores

• extract_layoutA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety and side-effect basics. The description adds output detail (DOM tree, computed styles), but does not disclose behavioral traits like headless rendering, network requests, or lazy-loading effects, which are relevant for an AI agent.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the verb and resource, and every clause adds value. The second sentence clarifies the tool's distinct focus on structure rather than tokens, with zero redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite the tool's complexity (12 params) and presence of an output schema, the description provides a sufficient high-level overview of what the tool does and its output shape. It could be improved with explicit usage guidance or browser-behavior notes, but it is not critically incomplete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all 12 parameters are already documented in the schema. The description adds no parameter-specific semantics beyond that, which matches the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Return') and resource ('simplified DOM tree of a page/subtree'), and clearly specifies the content ('layout-relevant computed styles', 'section labels'). It distinguishes from siblings by focusing on layout structure rather than assets or tokens.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The second sentence implies the tool's value ('Shows how the page is structured'), but there is no explicit guidance on when to use it instead of alternatives like analyze_html or inspect_component. No exclusions or when-not-to-use cases are mentioned.

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

• capture_screenshotA
  3.9/5.0
  Behavior3/5

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

  Annotations already cover readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the output is for the agent to look at and that it may save to disk, but it does not disclose side effects like network access, scrolling behavior, or timeouts. No contradictions with annotations.

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

  Conciseness5/5

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

  Two sentences that front-load the core purpose with no filler. Every clause contributes relevant context: browser, output type, capture modes, and optional file save.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 13 parameters, the description is minimal but sufficient for selecting the tool. It omits caveats like allowPrivateNetwork restrictions, clipping, or resource usage, but the schema and output schema fill these gaps. Adequate yet with clear gaps for a complex tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all 13 parameters are documented. The description adds a high-level summary of modes and output path, but does not provide semantics beyond what the schema already offers. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool captures a website screenshot via Chromium, with three capture modes (viewport, full page, element). It specifically names the resource and the verb 'capture', distinguishing it from sibling tools like extract_assets or analyze_site.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use when the agent needs a visual screenshot by saying 'return a screenshot the agent can look at.' It does not explicitly list alternatives or exclusions, but the context is clear enough for an agent to select it over siblings.

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

• analyze_htmlA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it renders in Chromium (a headless browser) and extracts the same data as analyze_site, but does not disclose details about execution such as JavaScript handling, network requests, or result structure beyond the output schema. This adds some context but not rich behavioral detail.

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

  Conciseness5/5

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

  The description is two sentences long and front-loaded with the core operation ('Render supplied HTML and optional CSS in Chromium, then extract...'). The second sentence adds targeted use cases. Every word contributes value, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the output schema and annotations, the description provides sufficient context for an agent to select and invoke the tool. It clarifies the input mode, scope, and typical scenarios. The only minor gap is that 'design system data' is not explicitly defined, but referencing analyze_site provides the needed referent.

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

  Parameters3/5

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

  Schema description coverage is 89%, so the baseline is 3. The description does not introduce parameter-specific information beyond the schema; it only mentions 'optional CSS' and 'supplied HTML,' which mirror the html and css parameters. No additional semantic value is provided over the well-documented schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool renders supplied HTML and optional CSS in Chromium and extracts the same design system data as analyze_site. It distinguishes itself from the sibling analyze_site by input type (supplied markup vs. live site) and names specific use cases: generated markup, offline pages, and tests.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool—'for generated markup, offline pages, and tests'—and implies that analyze_site is the alternative for live sites via 'same design system data as analyze_site.' It does not explicitly state exclusions or enumerate alternatives, but the intended usage context is evident.

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

• clone_sectionA
  4/5.0
  Behavior4/5

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

  Beyond the annotations, the description discloses meaningful behavior: scripts/handlers are stripped, inline SVG is preserved, CSS is scoped to the matched subtree and its @keyframes/@font-face dependencies, and assets are downloaded/rewritten when outputDir is set. This gives the agent a clear model of what transformations occur, though it does not touch on rate limits or overwrite behavior.

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

  Conciseness5/5

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

  The description is two sentences and front-loaded with the primary action, followed by a precise list of outputs and the outputDir conditional. Every clause adds information—there is no filler or repetition of the tool title.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 14 parameters, rich schema descriptions, an output schema, and annotations, the description efficiently covers the core output contract and the key mode switch (outputDir). It leaves edge-case behavior (e.g., asset embedding without outputDir) to the output schema/schema defaults, which is acceptable.

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

  Parameters3/5

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

  The input schema achieves 100% description coverage for all 14 parameters, so the baseline is 3. The description only refreshes the meaning of outputDir (downloading and rewriting asset URLs) and does not add new semantics for individual parameters beyond what their schema descriptions already state.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Return a self-contained copy of one section' and enumerates the exact contents: cleaned HTML, scoped CSS with keyframes/font-face, assets, and screenshot. This clearly distinguishes it from siblings like capture_screenshot or extract_assets by focusing on a fully standalone section clone.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The explanation of the outputDir mode ('With outputDir the assets are downloaded and URLs rewritten...') gives conditional guidance, but there is no explicit statement of when to choose clone_section over alternatives like extract_assets or inspect_component. Usage context is implied rather than directly contrasted with sibling tools.

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

• analyze_siteA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context by specifying it opens the site in Chromium and computes styles, which implies a real browser environment. It does not contradict annotations and provides some extra behavioral context, though it omits details like external resource loading.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that lists the complete scope of extraction without redundancy. It is front-loaded with the primary action ('Open a website in Chromium') and enumerates outputs efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 12 parameters, an output schema, and open-world behavior, but the description covers the core purpose sufficiently. The output schema handles return-value details, and annotations cover safety. The description could mention edge cases (e.g., inaccessible sites) but is complete enough for an agent to decide to use it.

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

  Parameters3/5

  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 names the extraction outputs but does not add meaning beyond the parameter schemas. All 12 parameters are thoroughly described in the schema, so no compensation is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool extracts computed design tokens (color palette, typography, CSS variables, spacing/radius/shadow primitives) and reusable component families, using a specific verb ('extract') and resource ('website design'). This distinguishes it from sibling tools like extract_assets (raw assets) or analyze_html (markup structure).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for design-system analysis by listing the extracted elements, but it does not explicitly mention when to use it over alternatives or exclude cases. Sibling names provide context, but no explicit guidance is given. This is 'clear context, no exclusions', matching a 4.

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

• capture_interactionsA
  4.2/5.0
  Behavior4/5

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

  Annotations indicate non-read-only, non-idempotent, non-destructive, open-world behavior. The description adds that the tool 'operate[s] interactive triggers' and captures screenshots, providing useful behavioral context beyond the annotations. It doesn't disclose potential side effects like form submissions, but the openWorldHint covers general live-site interaction.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the primary action and supported by concrete examples of trigger types and outputs. Every sentence earns its place, with no fluff or repetition of schema information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (13 parameters, output schema exists), the description provides a sufficient high-level overview: what it finds, how it operates, and what it captures. The output schema covers return details, so the description does not need to explain them. Minor gap: it doesn't mention the need for a real browser or network access, but that's not essential.

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

  Parameters3/5

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

  The schema has 100% coverage with detailed descriptions for all 13 parameters, so the baseline is 3. The description does not add parameter-specific details beyond what the schema provides, but that is acceptable given the high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('operate') and resource ('interactive triggers') and clearly distinguishes itself from siblings by stating it 'surfaces the parts of a design that never appear in a static extraction,' which differentiates it from static capture tools like capture_screenshot.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use it: when hidden interactive UI needs to be revealed, contrasting with static extraction. It does not explicitly exclude alternatives or name sibling tools, but the context is clear enough for an 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.

• create_replication_kitA
  4.2/5.0
  Behavior4/5

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

  The description discloses meaningful behavior beyond annotations: it writes to a local folder, loads the page once, and generates a defined set of output files. This complements annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) with no contradiction.

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

  Conciseness5/5

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

  Two sentences, no fluff. It leads with the core purpose, enumerates outputs in a scannable colon list, and ends with a performance benefit. Every clause earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is complex (18 parameters, many outputs), but the schema and output schema handle detailed specifications. The description adds the essential context of aggregation and speed advantage. A brief caveat about potential heaviness or overwrite behavior could push it higher, but current coverage is solid.

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

  Parameters3/5

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

  The input schema covers all 18 parameters with detailed descriptions, so the baseline is 3. The prose description doesn't add parameter-level details, but it doesn't need to because the schema is exhaustive.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('capture') and resource ('everything needed to replicate a website') and clearly lists the deliverables. It distinguishes itself from siblings by emphasizing it captures everything in one shot and is faster than calling individual tools separately.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states the advantage over calling individual tools separately ('Loads the page once, so it is much faster'), giving clear guidance on when to prefer this tool. However, it doesn't explicitly mention when not to use it or edge cases where individual tools might be preferred.

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

• extract_animationsA
  4.2/5.0
  Behavior4/5

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

  Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable behavioral context: it scrolls the page and compares styles before/after to capture reveal effects, and it detects specific libraries. This goes beyond the annotations without contradicting them.

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

  Conciseness5/5

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

  The description is a single sentence that is dense with useful specifics, front-loaded with the primary action ('Extract a website's motion design'). Every clause adds value, listing concrete extraction targets without redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (11 parameters, output schema, annotations), the description sufficiently captures the core function and behavior. It does not explain return structure, but the output schema covers that. It covers the main behavioral trait (scrolling) and the range of extracted data, making it complete enough for agent selection.

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

  Parameters3/5

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

  The schema has 100% parameter description coverage, so the baseline is 3. The description only mentions 'scrolling' implicitly but does not add any parameter-level meaning beyond what the schema provides. It neither repeats nor enhances the parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb ('Extract') and resource ('website's motion design') and enumerates concrete outputs: @keyframes definitions, per-element animation/transition settings, animation libraries, and scroll-triggered effects. This level of detail distinguishes it from sibling tools like extract_layout or capture_interactions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool by listing exactly what it extracts (motion design, libraries, scroll effects), implying use cases for animation analysis. It does not explicitly mention when not to use it or name alternative tools, so it misses the top tier for this dimension.

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

• extract_assetsA
  4.2/5.0
  Behavior4/5

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

  Annotations indicate open-world behavior (false readOnly, true openWorld), and the description adds that it downloads files into a local folder and generates a manifest.json mapping origins. It goes beyond annotations by clarifying the side effect of writing to disk, though it doesn't mention overwrite behavior or any authorization needs.

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

  Conciseness5/5

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

  Two sentences, no fluff. The first sentence front-loads the action and deliverables, the second places it in the replica workflow. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex 14-parameter tool, the description plus rich schema and annotations give a complete enough picture for selection and invocation. It covers what it does, what it outputs, and why. It doesn't discuss edge cases, but that's appropriately left to the schema and output schema.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the description doesn't need to explain individual parameters. The tool description does align with the types enum and mentions the manifest output, but overall it adds little beyond the schema's thorough parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Download' and clearly enumerates the resource types (real images, background images, inline SVG icons/logos, videos, favicons, web fonts) along with the output (local folder + manifest.json). This strongly differentiates it from sibling tools like extract_animations or capture_screenshot.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states the use case: 'Lets a replica reuse the exact original assets instead of re-drawing them.' This provides clear context for when to use it, though it doesn't explicitly name when not to use it or name alternative tools for layout/structure extraction.

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

• inspect_componentA
  4.2/5.0
  Behavior4/5

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

  With annotations already declaring readOnlyHint, idempotentHint, and no destructive action, the description adds value by detailing the exact returns (bounds, styles, pseudo-elements, etc.), giving the agent expectations for output. It does not contradict annotations and provides a bit more behavioral context beyond them.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core action, and every word is useful. It avoids fluff and efficiently conveys purpose and return contents.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (12 parameters, output schema, sibling tools), the description adequately covers the essential purpose and return values. It does not need to explain every parameter since the schema does that. A small gap is the lack of mention of auto-scrolling or network behavior, but these are covered by annotations and param descriptions.

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

  Parameters3/5

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

  The input schema has 100% parameter description coverage, so the baseline is 3. The tool description reinforces the 'selector' and 'live website' aspects but does not add meaning beyond what the schema already explains. No new parameter syntax or format details are introduced.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Inspect'), identifies the resource ('elements matching a CSS selector on a live website'), and lists concrete return types (bounds, computed styles, attributes, pseudo-elements, child structure, HTML sample). This clearly distinguishes it from siblings like capture_screenshot or analyze_site.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it is for inspecting specific components on a live website via CSS selector. It does not explicitly name alternatives or exclusions, but the focus on selector-based inspection implies when it is appropriate (e.g., for a specific element) versus other tools.

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

• compare_replicaA
  4.3/5.0
  Behavior4/5

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

  The description adds behavioral details beyond annotations: animations frozen, same viewport, pixel-diff approach, and output contents. Annotations already declare read-only/idempotent hints, so the bar is lower; the description complements rather than repeats. It does not mention potential network access or timeout behaviors, but those are covered by parameters.

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

  Conciseness5/5

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

  Three compact sentences: action, output, and usage loop. Everything earns its place and the main purpose is front-loaded. No fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 15 parameters and an output schema, the description covers the core workflow and return values. It is complete enough to select and invoke correctly for the intended loop-based iteration. The output schema handles detailed return structure, so the description need not elaborate further.

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

  Parameters3/5

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

  Schema description coverage is 100% with detailed parameter descriptions. The description adds minimal new parameter semantics; it mentions 'local file or URL' which aligns with replicaPath/replicaUrl, but otherwise the schema carries the burden. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb+resource: 'Screenshot the original website and a replica... then pixel-diff them.' It clearly distinguishes from siblings like capture_screenshot by focusing on comparison and diffing. Returns are explicitly listed (match percentage, worst-matching regions, visual diff image).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides a clear usage loop: 'Use in a loop: build, compare, fix the worst regions, repeat.' This tells the agent when to use the tool in an iterative workflow. It does not explicitly name alternative tools or when not to use it, but the context is strong.

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

• extract_responsiveA
  4.4/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context by disclosing the optional file-saving side effect when outputDir is provided ('also saves a screenshot per width') and by detailing what will be extracted. It doesn't contradict the annotations and gives the agent a clear picture of the tool's actions.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core action and result, and every clause adds information. There is no fluff or repetition of schema details, making it highly efficient and easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (14 parameters, output schema, many siblings), the description adequately covers the essential aspects: what it extracts, the optional screenshot output, and the per-viewport nature. The output schema handles return-value details, so the description doesn't need to enumerate them. It could mention defaults or conditions like 'when no widths are provided', but these are already visible in the schema, so the description is sufficiently complete.

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

  Parameters4/5

  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 semantic value by linking the 'widths' parameter to the per-viewport layout tree extraction and by clarifying that screenshots are only saved when outputDir is provided. This connects parameters to tool behavior in a way the schema descriptions don't explicitly do.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Extract') and clearly identifies the resource ('how a website adapts across screen sizes'), then lists the concrete outputs: breakpoints from @media rules, media query summaries, and layout trees at requested viewport widths. This distinguishes it from siblings like extract_layout (single layout) or capture_screenshot (just a screenshot), making the tool's purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use the tool: whenever you need to understand a website's responsive behavior across multiple screen sizes. It even specifies the kind of data produced (breakpoints, media queries, layout trees). However, it doesn't explicitly state when not to use it or mention alternatives, so it falls short of a 5 but provides solid contextual guidance.

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