Raven

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

Annotations indicate readOnlyHint=true and destructiveHint=false, consistent with an audit tool. The description adds behavioral details: it infers the canonical value from the corpus when no token is supplied, flags the 'issue #9 single-blob blind spot,' and describes the return structure. 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?

The description is well-structured with a clear opening sentence. It uses efficient language and conveys critical information without unnecessary detail. A minor improvement could be to shorten the list of return fields, but overall it's appropriately concise.

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 absence of an output schema, the description thoroughly explains return values: per-page extraction, consistency dimensions, outliers, issues, score mapping, and summary. It also clarifies offline operation and the single-blob blind spot, providing complete context for correct interpretation.

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

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

Input schema covers 100% of parameters. The description adds context beyond schema: it explains that pages must be from different routes, tokens are optional, how they affect inference, and the purpose of each token. This adds meaningful guidance for parameter usage.

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

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

The description clearly states the tool's function: 'Audit multiple pages for cross-page consistency of content-container width and hero heading tier.' It specifies the verb ('audit'), the resource ('multiple pages'), and the specific aspects checked. This distinguishes it from siblings like audit_page (single page) and other 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 explicitly requires '≥2 pages' and specifies they should be 'from different routes on the same site.' It also notes 'Pure offline — no browser, no network.' While it doesn't explicitly state when not to use, the requirement for multiple pages implicitly excludes single-page scenarios, and sibling names provide 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds detailed behavioral info: return format (per-item verdict with pass/warn/fail, issues, rewrite, aggregate) and heuristic logic per content type.

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 5-6 sentences, front-loaded with purpose and output, then heuristics and guidance. It is structured and every sentence contributes value, though slightly verbose.

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 3 parameters (1 required) and no output schema, the description fully explains tool behavior: input (content array), heuristics, output format (verdicts, issues, rewrites, summary), and constraints (offline). No gaps remain.

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 domain-specific heuristic rules (e.g., metric items require number+unit, CTAs action-led ≤4 words), providing context beyond the schema's generic 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 'Evaluate an array of content items against UX-writing principles and deterministic heuristics', specifying the verb, resource, and scope. It distinguishes from sibling 'evaluate_design' with explicit guidance.

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 includes explicit usage guidance: 'Use this instead of evaluate_design when you need per-item content verdicts rather than the principle library.' It also notes the tool is pure offline, aiding 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds details about rendering a page and computing from DOM, which aligns with openWorldHint. No contradictions, but no additional behavioral traits like rate limits are discussed.

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 that front-load the core purpose, then detail output and value proposition. Every sentence contributes meaning without redundancy or fluff.

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

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

Given the absence of an output schema, the description adequately explains the return: pass/fail per element and failing pairs with specific fields. It covers both input modes. Slightly more detail on output format could be beneficial, but the description 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?

All three parameters have schema descriptions, providing 100% coverage. The description enriches understanding by contextualizing the 'screenshot' parameter as optional and for caller reference, and clarifying that ratios come from DOM, not pixels. This adds 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 computes WCAG contrast ratios for text elements, specifying it can work with a URL or dom_snapshot. It details AA and AAA standards and notes the output includes failing pairs with selector, ratio, and delta. This verb+resource pairing distinguishes it from sibling audit tools like audit_content or suggest_contrast_fix.

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

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

The description provides clear usage context by outlining two operating modes (URL or dom_snapshot). It implicitly distinguishes from manual methods, but does not explicitly mention when to avoid this tool or suggest sibling alternatives. The guidance is sufficient for most agents.

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?

Annotations already declare readOnlyHint=true. Description adds behavioral context: it computes specific accessibility checks (contrast, tap targets, etc.), which is useful beyond 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?

Description is moderately long but each sentence adds value, front-loaded with purpose. Could be slightly more concise but not wasteful.

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

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

Given no output schema, description explains input format and checks performed but does not explicitly state the output format (beyond 'score'). More detail on return structure would improve 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?

Schema coverage is 0%, but description outlines the structure of elements (label, value, hint, etc.) and viewport. However, it does not explain the optional 'options.minTarget' parameter or exact format of rect fields, leaving some gaps.

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 scores iOS accessibility snapshots for missing labels, tap targets, contrast, Dynamic Type, and VoiceOver order. It distinguishes from sibling audit tools by being iOS-specific and comprehensive.

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 mentions capture via AccessibilitySnapshot XCUITest/ios-capture harness, indicating appropriate context. It lacks explicit exclusions but 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?

Annotations already mark readOnlyHint true and destructiveHint false. The description adds detail on what is read and flagged (e.g., contradictions, secrets). It does not contradict annotations and provides useful 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.

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

The description is front-loaded with the main verb and purpose, then lists inputs and flags. It is detailed but every sentence adds value. Slightly lengthy, but well-organized and clear.

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 covers all 5 parameters, explains the return shape by referencing audit_page, and details the types of audits performed. It is complete for a read-only audit tool with no output schema, though it could mention error handling for missing required inputs.

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 5 parameters. The description adds further meaning: it explains the mutual exclusivity of info_plist and app_json, and clarifies the role of each parameter in the audit process, e.g., source enables contradiction checks.

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 audits iOS/React Native/Expo app privacy posture for App Review and user trust, listing specific checks (UsageDescription strings, permissions, ATS, secrets). It distinguishes itself from sibling audit tools by focusing exclusively on iOS privacy.

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 specifies the input types (Info.plist, app.json, optional files) and the context (auditing privacy for App Review). It implies when to use, but does not explicitly exclude scenarios or contrast with sibling tools. Still clear enough for an agent.

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 scoring criteria (44x44pt touch targets, iOS-specific contrast handling, visual rhythm) beyond the readOnlyHint annotation. No contradictions; description aligns with safe, non-destructive 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 efficiently convey purpose, usage, and scoring. Front-loaded with key information, though could be slightly more structured (e.g., bullet points for checks). Overall succinct and clear.

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

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

Given no output schema and nested object parameters, description adequately covers basic usage and checks but lacks detail on return shape beyond 'same as audit_page'. Could explicitly describe assessment fields or failure triggers.

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 description adds value by explaining optional parameters (profile, project) and clarifying that calling with no arguments yields expected snapshot shape. Outlines scoring criteria tied to parameter fields.

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 it audits an iOS screen from a snapshot, list specific checks (touch targets, contrast, rhythm), and identifies as an alias of audit_screen with platform:'ios', distinguishing it from sibling tools like audit_layout or audit_tap_targets.

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 clear usage instructions: call with no arguments for expected shape, or with elements/viewport to score. Does not explicitly exclude alternatives or specify when not to use, but context implies it's the comprehensive iOS screen audit tool.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false, which the description aligns with by describing a non-destructive analysis. The description adds crucial behavioral details: two separate calls, snippet generation, and the sequence of operations. 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 sentences, each serving a distinct purpose: purpose, first-call behavior, second-call behavior, and relation to sibling tool. 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?

For a two-step tool with no output schema, the description explains the output of the first step (DevTools snippet) and the scoring dimensions (alignment, gap-rhythm, optical-balance). Could be more precise about the format of the scores, but sufficient for basic 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?

Schema coverage is 100%, so the baseline is 3. The description explains the overall data flow but does not add meaningful detail about the parameters beyond what the schema already provides (e.g., structure of elements and viewport).

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 evaluates visual rhythm from a rendered page's geometry, specifies the two-step invocation process, and distinguishes itself from audit_page as the complement for rendered-only aspects.

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 describes when to call with no arguments and when to call with the JSON payload, and positions itself as the complement to audit_page. Does not list explicit alternatives or when-not scenarios, but 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?

Annotations already mark the tool as readOnly and openWorld. The description adds behavioral context: it launches headless Chromium, performs interactions, scroll settling, and adversarial verification. It does not contradict annotations and transparently explains these behaviors.

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

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

The description is moderately long but well-structured, with the main purpose front-loaded and details organized. It could be slightly more concise, but every sentence adds value. The use of bullet-style lists in text is effective.

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

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

Given the tool's complexity (9 parameters, nested objects, no output schema), the description is thorough. It covers the return format (pass/fail per check with fix instructions), the effect of each parameter, and even edge cases like containerMaxWidth. No significant gaps.

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?

With 89% schema description coverage, the schema already documents most parameters. The description adds significant semantic value, e.g., explaining how containerMaxWidth makes the max-width check token-aware, and how compact and adversarial_verify work. This goes 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 tool audits HTML/CSS against Raven's design quality standards, listing specific checks like typography, accessibility, responsive patterns, etc. It distinguishes itself from sibling audit tools (e.g., audit_typography, audit_contrast) by being a comprehensive audit covering multiple dimensions.

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 implicitly indicates usage for a broad design quality audit but does not explicitly compare with sibling tools or state when to use this vs. specialized audits. However, the detailed list of checks makes it clear what it covers, aiding 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. The description adds behavioral context: it checks spatial relationships and produces per-relation flags. It does not contradict annotations. It could be more explicit about handling missing elements, but for a read-only analysis tool, the disclosure is adequate.

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 action and purpose. It gives examples and a concrete use case without wasting words. 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 the complexity (nested objects, enums, 3 required parameters, no output schema), the description is somewhat brief. It explains what to provide and the purpose but does not describe the output format or edge cases (e.g., missing elements). For a read-only analysis tool, the agent might infer the output, but explicit output details would improve 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?

Schema description coverage is 0%, so the description must compensate. It broadly describes the parameters: 'ios+android {elements,viewport} snapshots and a checklist[]'. It does not detail the structure of each property beyond what the schema shows. The description adds some meaning (e.g., that elements have rects, viewport has dimensions) but is not comprehensive.

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 iOS and Android element snapshots against a checklist of spatial relationships and flags match/mismatch/uncertain. It gives concrete examples (vertical centering, baseline alignment) and a real use case (cross-platform layout drift). This distinguishes it from sibling audit tools like audit_layout (likely single platform) or audit_consistency (broader).

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 tells what to provide (ios+android snapshots and a checklist), but does not explicitly state when to use this tool vs alternatives (e.g., single-platform audit tools). The context is clear enough from the name and description that it's for cross-platform parity, but no exclusions or alternative tool references are given.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read operation. The description adds useful behavioral details: it requires headless chromium, categorizes flags as 'likely-oversight' vs 'intentional', and returns a table. This exceeds what annotations provide.

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

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

The description is three sentences long with no fluff. The main action is front-loaded, and each sentence adds value: what it does, how it categorizes, and what it returns. Perfectly concise for a moderately complex tool.

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 no output schema, the description explains the return format (a table of selector, hiding-class, mobile-visible, desktop-visible, category). It covers prerequisites (headless chromium) and the categorization logic. The tool is moderately complex, but the description is complete enough 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 parameters are fully documented in the schema. The description adds minimal extra meaning (e.g., default breakpoints [390, 768, 1440, 2160] and default viewport height 900), but these are also inferable from 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: render a URL at multiple breakpoints and flag content that is visible on desktop but hidden on mobile. It specifies the verb 'audit/responsive visibility' and distinguishes from sibling audit tools that focus on different aspects (e.g., contrast, layout).

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 context ('Requires headless chromium') but does not explicitly state when to use this tool over alternatives or specify when not to use it. Usage is implied from the purpose, but no direct guidance or exclusions are given.

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?

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral context by detailing what the tool checks (accessibility, sizes, colors, etc.) and its scope, without contradicting 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 well-structured, starting with purpose, then listing checks, and ending with scope. It is slightly verbose but each sentence adds value, and there is no wasted 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?

The description covers the tool's purpose, specific checks, scope, and relationship to audit_ios_screen. Without an output schema, it mentions 'Same return shape as audit_page,' which provides enough context for an agent.

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 does not add significant meaning beyond what the schema already provides for parameters; it focuses on the overall behavior rather than individual parameters.

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

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

The description clearly states the tool audits React Native/Expo source against iOS HIG and Android Material conventions. It lists specific checks (e.g., accessibility, hitSlop, font scaling) and distinguishes from siblings like audit_ios_screen by noting RN renders to native widgets.

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 limits the tool to RN-native checks and says 'no web/CSS or SwiftUI rules.' It also references audit_page for return shape, providing context. However, it doesn't explicitly state when not to use it relative to other auditing 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?

The description adds behavioral context beyond annotations: it explains that the tool scores touch targets, contrast, and visual rhythm, and that it returns the same shape as audit_page. It also describes platform-specific behavior. No contradiction with annotations (readOnlyHint=true).

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 that front-load the main purpose and then provide necessary details. No redundant information, and every sentence contributes to understanding.

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

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

Given the complexity (7 params, nested objects, no output schema), the description provides a solid overview. It references the return shape via audit_page, which is helpful but assumes knowledge of that tool. It covers platform differences and key scoring areas. Minor gaps in error handling or output details.

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 86%, so the schema already documents most parameters. The description adds value by explaining the platform parameter's effect and the behavior when called with no arguments. This is useful but does not fully compensate for the minor missing parameter details.

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

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

The description clearly states the tool's purpose: auditing a rendered mobile screen from a view-hierarchy/accessibility snapshot. It specifies the verb 'audit', the resource 'mobile screen', and differentiates from sibling tools like audit_page by focusing on mobile and platform-specific metrics.

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 guidance on when to use the tool (e.g., with a snapshot, and platform choices). It explains calling with no arguments to get the expected snapshot shape. However, it does not explicitly exclude alternative tools or provide when-not-to-use guidance.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false. The description adds rich behavioral detail: flags hardcoded fonts, colors, missing accent color, small frames, and ad-hoc spacing; rewards semantic systems. 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.

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

The description is detailed and informative, but somewhat long. It front-loads the purpose and then enumerates checks. Could be more concise, but 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?

No output schema exists, but the description mentions return format: 'Returns pass/fail per check with fix instructions.' This is sufficient. The complexity of inputs (5 parameters) and audit scope are well covered.

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 all parameters are described in the schema. The description does not repeat parameter details but explains the audit logic, which adds value beyond the schema. For a fully covered schema, a 4 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 audits SwiftUI source against Apple's Human Interface Guidelines, listing specific checks (fonts, colors, accent color, frames, spacing) and what it rewards. This distinguishes it from sibling audit tools like audit_ios_a11y or audit_typography.

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 limits to iOS-native checks ('no web/CSS rules'), implying use for SwiftUI iOS development. However, it does not explicitly state when not to use this tool or suggest alternatives from the sibling list.

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?

Annotations already indicate readOnlyHint=true. The description adds transparency about the tool's behavior: it collects specific elements, measures rendered dimensions, and outputs a sorted fix table. No contradiction 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.

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

The description is densely packed with essential information (standard, elements, output format, modes, sorting) in a structured manner. Slightly verbose but every sentence contributes meaning.

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

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

Given the tool's complexity, the description fully covers its purpose, input modes, default behavior, output format, and sorting. No gaps remain.

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

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

Schema coverage is 100%, so parameters are well-documented. The description adds value by explaining the two modes (url vs elements) and the default minSize, providing context 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 explicitly states the WCAG 2.5.5 / Apple 44pt tap-target audit purpose, lists the exact interactive elements collected, and details the per-element fix table output. This clearly differentiates it from sibling audit tools like audit_contrast or audit_layout.

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 outlines two modes (url with headless chromium or elements snapshot) which imply appropriate usage contexts. However, it does not explicitly state when not to use this tool or name alternatives for different audit types.

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 adds behavioral context beyond the annotations: it discloses that the tool requires headless chromium for url mode, what the output contains (scale, line_height, etc.), and that it emits a focused report. Annotations already indicate readOnlyHint and no destruction, and the description aligns with them.

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 moderately concise (around 150 words) and front-loaded with the tool's purpose. It covers key details without excessive verbosity, though it could be slightly streamlined.

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 no output schema, the description thoroughly explains the return structure (scale, line_height, weight_ladder, nodes_analyzed, findings with subfields). Given the tool's complexity and lack of output schema, the description is complete and informative.

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 meaning by explaining the purpose of each parameter: url mode needs headless chromium, nodes are pre-collected text nodes. This enhances understanding beyond the raw schema.

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

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

The description states it audits the typographic scale of a rendered page or snapshot, and details three specific output categories (modular scale, line-height consistency, weight ladder). It also distinguishes itself from audit_page by noting it goes beyond pass/fail checks, making the purpose clear and differentiating it from siblings.

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

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

The description explains two modes (url and nodes) and mentions that url mode requires headless chromium. It also implies when to use this tool over audit_page by stating it goes beyond pass/fail checks, providing clear context for its use, though it doesn't explicitly list 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?

Description elaborates on the capture process (scroll-settle, interactions, hover/click/focus) and the audit rules (WCAG contrast, responsive-visibility, sliced-image edge symmetry, etc.) beyond the annotations' readOnlyHint. 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.

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

The description is well-structured, starting with the core purpose, then detailing the process, and finally listing what it catches. It is dense but not overly verbose. 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 explains that findings are 'tagged confirmed | likely-artifact | inconclusive with its evidence, ranked by severity' and lists types of audits. It covers the main aspects of what the tool does and returns, though the structure of findings could be more detailed.

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 does not add significant new semantics beyond what's already in the schema for each parameter; it provides context for how parameters are used in the overall process but not per-parameter details.

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

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

The description uses a specific verb-phrase 'Layer 0 render-and-capture audit' and clearly identifies the resource ('LIVE URL') and the action (renders, captures, audits). It distinguishes itself from sibling tools like audit_consistency, audit_page, etc., by stating it catches 'real-world visual nits invisible to HTML-string/geometry audits'.

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 that this tool catches 'cropped images, blank videos, hover white-wash, sliced exports, and hidden-on-mobile content' and contrasts with 'HTML-string/geometry audits'. While it doesn't list explicit when-not-to-use scenarios, the specificity of its capabilities guides appropriate usage.

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?

Description adds context beyond annotations by detailing the two execution paths (browser rendering vs. deterministic re-analysis) and the classification output. No contradiction with annotations (readOnlyHint, non-destructive).

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 front-loaded: first sentence defines core action, second adds motivation, third details usage modes. Could be slightly more concise but is well-organized.

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

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

Given the tool's complexity (3 parameters, no output schema), the description fully covers inputs, outputs (classification categories), and the two operational modes. No gaps.

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%, baseline 3. Description adds meaning by explaining the purpose of each parameter: live vs. snapshot mode, and the observeMs timing. It also clarifies the expected fields in dom_snapshot.

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

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

The description uses a specific verb ('observe' and 'classify') and resource ('video playback'), clearly defining the tool's function. It distinguishes from siblings by focusing on dynamic video playback detection, which no other audit tool addresses.

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

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

The description provides clear usage guidance: it explains the two input modes (live URL vs. pre-collected DOM snapshot) and the tool's advantage over static audits. However, it does not explicitly state when not to use this tool or compare directly with 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?

Annotations already indicate readOnlyHint=true and non-destructive nature. The description adds context about mixing tokens from multiple systems and provides an example, enhancing behavior understanding beyond 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 extremely concise with one sentence and a clear example. Every element is necessary with no superfluous text, and key information is front-loaded.

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

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

The description lacks information about return value or output format, which could be important for an agent. While annotations are present, the description should ideally cover what the tool produces, though it is adequate for a simple composition 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% description coverage, already explaining 'compositions', 'format', 'system', and 'group'. The description does not add parameter-specific details 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 uses a specific verb 'mix' and resource 'tokens from different design systems', clearly indicating the tool's function. The example 'Linear's colors + Stripe's typography' provides concrete understanding and distinguishes it from sibling audit, evaluation, and generation 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 implies usage for creating custom composites via an example but does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or prerequisites.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds no extra behavioral context. It does not disclose any additional traits such as computational cost or external dependencies, which would be valuable.

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

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

The description is a single sentence that efficiently conveys the tool's purpose and output. Every word earns its place, and the structure is front-loaded with the core action.

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 having 6 parameters and no output schema, the description is minimal and does not elaborate on the structure of returned principles, violations, or suggestions. This lacks completeness for a tool with no output schema to compensate.

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 input schema already documents all parameters. The description adds no further meaning beyond what is in the schema, warranting the baseline score of 3.

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 evaluates a design description against UX principles and lists return types. It distinguishes from sibling audit tools by being a general evaluation rather than a specific audit, though it does not explicitly name alternatives.

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 for evaluating designs against UX principles, providing a clear use case. However, it offers no explicit guidance on when to use this tool versus sibling audit tools or 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?

Annotations declare readOnlyHint=true and destructiveHint=false. The description adds context about exporting artifacts (HTML, CSS, JSON, etc.) without mentioning permanent storage or side effects, which aligns with a read-only computational tool. It goes beyond annotations by detailing output formats.

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 wasted words. First sentence states purpose and key features; second adds a benefit. Front-loaded and scannable.

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 core functionality (brand color, style, format exports) but omits mention of parameters like 'base_system' and 'dark_mode'. Schema descriptions cover those, so it's nearly 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%, but the description adds significant meaning: it explains that brand_color drives palette auto-generation, style influences multiple properties, and format controls export type. This enriches the agent's 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 generates a complete custom design system with full token set, specifying the verb 'generate' and resource 'design system'. It distinguishes from siblings like 'get_design_system' by implying creation rather than retrieval.

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 by describing the action (generate, provide brand color, pick style, export) but does not explicitly state when to use this tool vs alternatives like 'get_design_system' or 'compose_system'. No guidance on 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?

Annotations declare readOnlyHint=true and destructiveHint=false, which the description does not contradict. The description adds that the tool renders an HTML page and supports optional ideal-state side-by-side rendering, providing further behavioral 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 a single paragraph of 3-4 sentences, efficiently conveying the main purpose and modes. It is front-loaded with the core function, but could benefit from bullet points for mode clarity.

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 output is a self-contained HTML page but does not detail its appearance. However, for a generation tool, this is acceptable. All 5 parameters are covered by the schema, and the description adds mode 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 description coverage is 100%, but the description adds meaning beyond the schema by explaining the two modes and the role of the `actors` parameter. It clarifies that the ideal-state is rendered side-by-side, which is not fully captured in 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 tool renders a service blueprint as a self-contained HTML page, and distinguishes between two modes: classic single-actor and two-actor HI-loop. This is specific and differentiates it from sibling tools which are primarily audit-related.

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

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

The description explains when to use each mode: classic when no `actors` supplied, two-actor when `actors.b` is provided. It does not explicitly state when not to use or list alternatives, but given the sibling tools, no alternative exists for this purpose.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context by detailing the types of principles included and the filtering capability, without contradicting 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 concise (two sentences) and front-loaded with the core purpose. It could benefit from a slightly more structured format, but 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?

Given the low complexity (2 optional params, no output schema), the description adequately covers the tool's functionality, including what topics are included and how to filter. It does not explain the return format, but this is acceptable due to the simple nature of the tool.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds examples of topics but does not provide additional meaning beyond the schema's 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 specifies the exact resource ('brand and visual-design principles') and lists specific sub-topics (logo usage, gradient usage, imagery, etc.), clearly distinguishing it from sibling tools like audit_* or compose_system.

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 includes an explicit usage hint ('Use when the user asks about branding...'), providing clear context. It does not, however, state when not to use or name 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?

Adds context beyond annotations: matches against 12 known systems, provides closest match with ready-to-use CSS, token set, style guide, and instructions. No contradiction with readOnlyHint=true.

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?

Concise three sentences with a clear example and description of output. Could be slightly tighter but 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?

For a read-only retrieval tool with no output schema, the description sufficiently explains what is returned (tokens, style guide, instructions) and includes parameter defaults. No missing critical 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 covers all 3 parameters with descriptions (100% coverage). The description adds some context on expected output (full token set etc.) but doesn't significantly augment parameter 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 it retrieves a complete design system based on a company's branding, with examples like Spotify. It distinguishes from siblings like 'get_design_system' by focusing on branding, though not explicitly.

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 an example of when to use ('Say 'Make me an app with branding like Spotify''), but lacks explicit guidance on when not to use or comparison to alternative sibling tools like 'get_design_system' or 'get_content_system'.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that trends are time-stamped and should be used as a calibration signal, which provides additional behavioral context beyond 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 sentences with no filler. The first sentence front-loads the core purpose; the second adds calibration guidance. Every word earns its place.

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

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

Without an output schema, the description provides sufficient detail about what the tool returns (list of trends with examples). Sibling tools are primarily audit and design system tools, making this tool's role clear. Adequate for a simple, no-parameter 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?

There are no parameters, so the baseline is 4. The description compensates by listing example trend categories, which gives the agent a sense of what the return value contains.

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 that the tool retrieves current brand and visual-design trends, with specific examples (bento grids, monospace type, etc.). It uses a specific verb+resource pattern and is distinct from sibling tools like get_brand_principles.

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

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

The description provides clear context on how to interpret the output ('treat as a calibration signal, not a prescription'). However, it does not explicitly state when to avoid using this tool compared to 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?

Annotations already indicate readOnlyHint=true and destructiveHint=false. Description adds content scope but does not disclose additional behavioral traits beyond what annotations provide, such as potential output format or pagination.

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 efficiently convey the tool's purpose and coverage. No filler words, 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 no output schema, the description does not explain the return format or detail. For a read-only tool with two parameters, describing the output structure would improve completeness. Current description is 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?

Schema coverage is 100% with descriptions for both parameters. Description adds some context about the content areas but does not significantly enhance understanding of 'type' and 'stage' beyond the schema definitions.

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 'Get' and the resource 'business and monetization strategies for digital products'. It lists specific coverage areas (monetization models, retention, etc.), distinguishing it from sibling tools that focus on audits or design systems.

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 use for strategic information retrieval but provides no explicit guidance on when to use this tool versus alternatives. Sibling tools are mostly for audits and design specifics, so context is clear, but no exclusions or when-not advice is given.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that the tool returns actionable yes/no items, but no further behavioral details are disclosed. With annotations present, the description adds minimal value.

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, front-loaded sentence with no extraneous words. Every word is necessary and contributes to understanding the tool's 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?

For a simple 2-parameter tool with no output schema, the description provides clear purpose and return type. However, it could add more detail on the nature of the checklist items or how to use the yes/no results. Siblings are distinct, so context is adequate but not fully comprehensive.

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 both parameters adequately. Description only restates the type concept ('for a specific UI type') and adds no new semantic value 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 uses specific verb 'Get' and resource 'pre-publish checklist for a specific UI type', clearly distinguishing it from sibling audit tools which focus on specific checks.

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 when/why or alternatives are given. The context of sibling tool names implies this is a generic checklist versus targeted audits, but guidance is only implied.

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?

Annotations already indicate read-only and non-destructive behavior. Description adds value by detailing the output composition (do's/don'ts, examples, checklist), which goes beyond annotations. 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?

Two sentences, front-loaded with purpose, lists return items concisely. 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?

Given annotations and simple schema, the description adequately covers the tool's behavior and return contents for a retrieval tool. No output schema exists, but description compensates by listing return elements. Minor gap: no mention of result format or size.

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 'type', which is documented with enum values and a brief description. The description does not add further meaning or context for each enum value, so baseline score applies.

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

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

Description clearly states 'Get content design patterns' and lists four specific categories (error messages, empty-state copy, notifications, form validation), with detailed return items (do's, don'ts, examples, evidence, checklist). This distinguishes it from sibling audit and system 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?

Description implies use when needing content patterns for the listed categories, but lacks explicit guidance on when not to use or alternatives. However, the detailed return items help agents infer appropriate scenarios.

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?

Annotations already declare read-only and non-destructive behavior. The description adds context about the tool's content (principles listed) and filtering capability but does not disclose additional behavioral traits like return format or performance characteristics. With strong annotations, this is adequate.

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: the first clearly communicates the core purpose with examples, the second explains filtering. Every sentence adds value, and there is no redundancy or fluff.

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

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

For a simple read-only tool with no required parameters and good annotations, the description covers the main use case. It could briefly mention the return format (e.g., 'returns a list of principles') but is still largely 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%, so the schema already describes both parameters. The description adds example values for 'context' but does not significantly enhance meaning beyond the schema, especially for 'format' which is enumerated. 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 'Get UX-writing principles' and lists specific examples (clarity over cleverness, active voice, error-message anatomy). This distinguishes it from sibling tools like 'get_principles' and 'get_brand_principles', making the purpose very specific and actionable.

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

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

The description provides guidance on filtering by context (e.g., 'error messages', 'notifications'), which helps the agent use the tool effectively. However, it does not explicitly state when not to use this tool or mention alternatives, leaving room for improvement.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is well covered. The description adds useful content scope but no further behavioral details such as auth requirements, rate limits, or return format. No contradiction 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.

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

A single, front-loaded sentence with no fluff. Every listed content category is informative and earns its place, making the description efficiently sized and easy to parse.

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 read-only getter with well-annotated schema, the description adequately lists the content domains returned. It lacks explicit return-shape or filtering details, but the schema covers filtering and the content list is sufficient for agent expectations.

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 both id and section described. The description adds meaning beyond the enum labels by explaining section contents, e.g., 'vocabulary (use/avoid/never)' and 'content patterns for errors/empty-states/buttons/etc.', which is valuable for agents choosing a section param.

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

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

The description uses a specific verb+resource: 'Get a brand's content design system' and then enumerates the exact contents (voice attributes, tone shifts, vocabulary, grammar rules, content patterns, inclusive language guidance). This clearly distinguishes it from sibling tools like get_design_system or get_content_pattern.

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

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

The description provides clear context for when to use the tool: when the full content design system with its sections is needed. It does not explicitly name alternatives or exclusions, so it stops short of a 5, but the content list helps differentiate from more specific 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's behavioral disclosure is not critical. The description lists what is returned but adds no extra behavioral traits (e.g., auth needs, rate limits). It is adequate given the 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, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose 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 no output schema, the description adequately lists the returned templates. The single optional parameter and simple scope make the description complete enough for the tool's function.

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 enum and description for the stage parameter. The tool description does not add meaning beyond the schema; it only restates the default. 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 gets D4D framework templates and lists specific components returned (customer problem statement, ideal state, etc.). It distinguishes itself from the many sibling audit and system tools by specifying the D4D context.

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 structured product thinking but provides no explicit when-to-use or when-not-to-use guidance. It does not compare with sibling tools like get_design_system or get_content_pattern, leaving the agent to infer applicability.

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?

Annotations already indicate read-only (readOnlyHint=true) and non-destructive (destructiveHint=false). The description adds specific behavioral details about the returned token categories and formats, providing context beyond the 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?

Single sentence, 25 words, instantly communicates purpose and output. No unnecessary 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?

No output schema exists, but the description partially compensates by enumerating token types and formats. Lacks details on response structure, pagination, or error handling, but sufficient for a simple retrieval 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 covers 100% of parameters with descriptions. The tool description adds minimal parameter-specific meaning beyond listing return categories; it does not elaborate on parameter usage or constraints.

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 'Get design tokens' and specifies the resource (design system) along with token categories and formats, distinguishing it from sibling tools like audit_* or generate_design_system.

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 versus alternatives. The description implies usage for retrieving tokens, but does not mention when not to use or differentiate from similar get_* tools (e.g., get_brand_system).

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?

Annotations already indicate readOnlyHint=true and destructiveHint=false. Description adds that it returns 'structure, when-to-use, pitfalls, and examples', providing behavior beyond 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?

Three sentences with no wasted words. First sentence immediately states purpose and lists options, followed by return content and usage guidance.

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

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

No output schema, but description adequately explains return content (structure, when-to-use, pitfalls, examples). Parameter behavior is fully covered. Slightly more detail about return format could push to 5.

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 parameters with descriptions. Description adds value by enumerating valid framework IDs ('heart, aarrr, north-star-metric...') and explaining behavior when 'id' is omitted (list all).

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 uses specific verb 'Get' and resource 'product-metrics framework', listing distinct frameworks (HEART, AARRR, etc.). Clear differentiation from sibling tools which focus on audits, design, etc.

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 asks 'how should we measure success?' or 'what metrics should we track?''. Does not mention exclusions or alternatives, but context from siblings makes usage 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?

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the tool is clearly a safe read operation. The description adds that it returns 'do's, don'ts, evidence, and checklists,' which is consistent but does not elaborate further on behavioral traits like auth requirements or data scope.

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 states purpose, second lists design types. Efficient and front-loaded, but the list of types could be more structured (e.g., bulleted). 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 3 simple parameters, annotations, and no output schema, the description adequately explains the return content (do's, don'ts, evidence, checklists) but does not specify return structure, ordering, or default behavior. Sufficient for a straightforward query tool but not fully 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 description coverage is 100%: all three parameters ('goal', 'type', 'platform') already have clear enum or description in the schema. The description adds context by listing example values for 'type' (signup flows, etc.), but this mostly repeats the enum choices. No 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?

The description clearly states it retrieves UI/UX patterns for a specific design type and lists example types (signup flows, pricing pages, etc.). The verb 'get' with 'pattern' is clear, but it does not explicitly differentiate itself from sibling tools like 'get_content_pattern' or 'get_service_pattern' beyond listing design-type examples.

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 vs. alternatives such as 'get_content_pattern' or 'get_service_pattern'. The description does not mention context, prerequisites, or exclusions. It simply states what it does, leaving the agent to infer usage.

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?

Annotations already mark as read-only. Description adds that it returns matched principles, but does not disclose rate limits, authentication, or data source. Acceptable given read-only nature.

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 well-formed sentence covering purpose and scope. 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?

Covers purpose and output types, but lacks details on output structure. Acceptable given no output schema and simplicity of 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 clear descriptions for each parameter. Description adds no extra parameter info beyond general context matching.

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 'Get design principles relevant to a UI context' with specific types (usability heuristics, laws of UX, Gestalt principles, etc.). Distinguishes from sibling audit tools that evaluate existing designs.

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?

Implicitly indicates use for designing new UIs, but does not explicitly state when to avoid or contrast with alternatives like get_brand_principles or get_checklist.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, making safety clear. Description adds value by detailing returns: protocols, do/don't guidance, evidence, checklist. 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.

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

Three sentences, no fluff. Front-loaded with the primary action and then expands on categories and return types. 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 read tool with 2 optional parameters, the description covers purpose, categories, return content, and usage context. No output schema, but return items are described adequately.

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 covers both parameters with descriptions, achieving 100% coverage. The description repeats category names but adds no extra syntax or usage nuance 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 uses a specific verb 'Get' with the resource 'research method details', enumerates categories and return items, and clearly distinguishes the tool's purpose from siblings.

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

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

States 'Use when the user is designing a study or asking how to measure something' providing clear context. Does not explicitly mention when not to use or alternatives, but the context is specific enough.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description is not needed for those behavioral traits. However, the description adds value by specifying exactly what the tool returns (patterns, do/don't guidance, evidence, checklist), which helps the agent understand the output beyond the 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 two sentences, front-loaded with the action and the list of patterns. Every sentence contributes essential information: what it gets, what it returns, and when to use it. 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 tool has only one parameter, no output schema, and annotations cover read-only behavior, the description is complete. It fully covers the input semantics, output content, 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?

There is only one parameter 'type' with an enum, and its schema description is minimal ('Service design pattern type'). The tool description lists the five enum values explicitly in the narrative, adding semantic meaning beyond the schema. Since schema coverage is 100% but schema descriptions are sparse, the description compensates well.

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 a service design pattern and lists the five specific types (service blueprinting, human handoff, signup-as-service, omnichannel continuity, moments of truth). It also mentions the returned content (patterns, guidance, evidence, checklist). However, it does not explicitly differentiate from sibling tools like get_content_pattern or get_service_standard, but the name and listed types make the purpose distinct enough.

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 guidance: 'Use when the user is designing a service flow, escalation, cross-channel experience, or moment of truth.' This clearly frames when to invoke the tool. It does not mention when not to use it or alternative tools, but the context is sufficiently clear for an AI agent.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about the standard's origin and applicability, but does not disclose return format or any behavioral traits like rate limiting. Still, for a simple read tool, the added context is sufficient.

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 action and content. Every sentence is informative with 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 zero parameters and no output schema, the description explains the tool's content and usage context. It is nearly complete, though it could briefly mention that it returns the full standard or a summary.

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?

No parameters exist, and schema description coverage is 100%. The description adds no parameter details, but none are needed. Baseline for 0 parameters is 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 specifies the verb 'get' and the resource 'GOV.UK Service Standard'. It distinguishes from sibling audit tools by highlighting its broad applicability as a checklist, not just an audit tool.

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

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

Explicitly states 'Use when the user asks how to evaluate a whole service', which is clear guidance. However, it does not mention when not to use it or suggest alternative tools for specific cases, leaving room for improvement.

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 annotations already declare readOnlyHint=true and destructiveHint=false, which aligns with the 'browse' action. The description adds the specific content systems (Conversational Product Voice, GOV.UK, etc.) as useful context but does not disclose additional behavioral traits such as pagination or auth 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?

The description is a single sentence, front-loaded with the purpose, and includes relevant examples without wasted words. It effectively balances clarity and brevity.

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

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

Given the tool's simplicity (2 optional parameters, no output schema) and the presence of annotations, the description is adequate. It mentions the browse functionality and filter/search capabilities, though it does not explicitly describe the return format, which is acceptable for a list-type tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds the phrase 'search by name' which is a slight simplification of the schema's 'name, description, or tag' but does not introduce incorrect semantics; it aligns with the parameter descriptions.

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

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

The description clearly states the tool's function: browsing available content design systems, with specific examples of voice and tone guides. It uses a specific verb ('browse') and resource ('content design systems'), but does not explicitly distinguish from the sibling tool 'list_design_systems'.

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 by stating the tool browses content design systems and supports filtering/search. However, it does not provide explicit guidance on when to use this tool versus alternatives like 'get_content_system' or 'list_design_systems'.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only behavior is known. The description adds context about provider-agnostic nature and routing mechanism, but does not detail return format, pagination, or error handling, 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?

Two sentences, front-loaded with the purpose, and no unnecessary words. Every sentence earns its place by stating what the tool does and how to use it.

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

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

Given the tool's simplicity (browse/filter), the description covers the core concept and dependency. No output schema exists, but explanation of return format is not critical. Some details about filtering behavior could improve completeness, but overall 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% with both parameters described adequately. The description provides general context about capabilities but does not add specific parameter-level guidance beyond what the schema provides, meriting a baseline score.

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

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

The description uses specific verb 'Browse' and resource 'Raven's provider-agnostic creative model catalog', clearly distinguishing it from sibling tools like list_content_systems or list_design_systems by focusing on creative models and capability slots for image, video, 3D, audio, etc.

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

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

The description provides clear context: 'Use a configured RAVEN_CREATIVE_RUNNER to route jobs', indicating prerequisite setup. However, it does not explicitly state when to use this tool over alternatives or when not to use it, which prevents a top score.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about preset categories but no behavioral traits beyond annotations, so it provides moderate additive value.

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 is concise and front-loaded with the main action. Slightly broad listing of use cases but 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?

For a simple read-only tool with two optional parameters and no output schema, the description covers the purpose and examples adequately. Could mention sorting or pagination but not critical.

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 parameters with descriptions (100% coverage). The description lists preset examples but does not add parameter-specific meaning beyond the schema, warranting the baseline score.

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

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

The description clearly states the tool browses creative presets and lists many specific use cases (product photoshoots, UGC ads, etc.), making the purpose specific and distinct from sibling audit/compose 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?

No guidance on when to use this tool vs. alternatives like list_content_systems or list_creative_models. The description does not specify when not to use it or provide any usage 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so description adds value by specifying filter capabilities. However, no additional behavioral traits like output format or pagination are mentioned.

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 purpose, 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?

Tool is simple with no required parameters and no output schema. Description adequately covers functionality. Minor improvement could mention response 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 coverage is 100% with descriptions for both parameters. Description restates the category options but does not add significant 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 lists design systems with optional filters, using specific verbs 'Browse' and 'Filter'. Distinct from sibling tools that are audits, evaluation, or generation 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?

Implies usage for browsing and filtering design systems, but does not explicitly mention when not to use or name alternatives. Clear enough given siblings are different operations.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds transparency by stating it is a 'transparent heuristic' and not proprietary, which complements the safety profile. 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.

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

Single sentence with no wasted words, clearly front-loaded with the tool's action and scope.

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 all described in schema, no output schema, and a clear explanation of what is scored, the description covers the essential context. However, it does not specify the return format or scoring scale, which is acceptable given the lack of output schema.

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 each parameter described. The description lists the scoring criteria but does not add significant meaning beyond schema definitions for 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 scores creative content for multiple specific dimensions (hook strength, benefit clarity, etc.), distinguishing it from sibling tools like 'score_page'.

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

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

The description implies use for creative prompts/scripts/ad concepts and sets expectations by calling it a 'transparent heuristic', but does not explicitly exclude alternative tools or provide when-not-to-use guidance.

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

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

The description explains key behaviors: scores are deterministic, no browser required for html, and url triggers headless chromium rendering. Annotations (readOnlyHint, openWorldHint, destructiveHint) are consistent with these details, and the description adds context beyond 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 informative but somewhat lengthy. It front-loads the core purpose and splits into two main modes. Every sentence adds value, though minor restructuring could improve 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 the tool's complexity (4 parameters, no output schema), the description covers return values (overall score, grade, weakest category, guidance on missing categories) and usage details thoroughly, leaving no major gaps.

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

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

All 4 parameters have schema descriptions (100% coverage), and the description adds extra meaning: url triggers headless rendering, containerMaxWidth forwarded to a specific check. This provides 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 scores an HTML/CSS page across 7 design categories, each rated 0–10, and returns an overall score and grade. It explicitly connects to audit_page and distinguishes itself by noting it covers fewer categories but provides guidance on the missing ones, differentiating it from sibling audit and scoring 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 two clear usage modes: pass html directly or pass url for headless rendering. It also mentions strict mode and containerMaxWidth. It gives guidance on which tools to use for categories not assessed (brand, conversion, motion), but lacks explicit 'when to use vs. alternatives' statements.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds scope (across categories) but does not disclose search behavior like pagination, ranking, or empty results. Adequate given 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. Every word adds value, no redundancy. Efficient structure.

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 and usage, but lacks description of return format or result structure. Given no output schema, a brief note on what the search returns (e.g., relevant items with titles/snippets) would improve completeness. Still functional for a simple search 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 clear descriptions for both parameters (query and layer). The description adds no extra semantic value beyond what's in 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 searches across design principles, UI patterns, and business strategies, using a specific verb 'Search'. It distinguishes from siblings like get_pattern or get_principles which retrieve specific items, while search_knowledge is for cross-category search.

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 when you need to find specific guidance or don't know which category to look in', giving clear context. It implies alternatives (specific get_* tools) but does not name them explicitly.

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?

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds context about 'Pure offline math' and that it computes minimal changes, complementing annotations without contradiction.

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: purpose, per-pair behavior, and integration with audit_contrast. It is front-loaded, no waste, and efficiently covers key 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 tool's simplicity (read-only, offline math, good schema), the description fully explains inputs, outputs, and processing without gaps, even without an output schema.

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 enriches meaning by explaining how 'level' is a default fallback, how 'pairs' items work with optional fields like fontPx/bold for large-text threshold, and that targetRatio overrides level.

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 returns the minimal color change for failing WCAG pairs, specifies the verb 'return' and resource 'minimal color change', and distinguishes from sibling tools like audit_contrast by explicitly stating it feeds from its failing pairs.

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

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

The description gives clear when-to-use guidance: after audit_contrast, to get passing values instead of manual brute-forcing. It lacks explicit when-not-to-use but provides sufficient context through the alternative mentioned.

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