Raven

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

With no annotations, the description carries the full burden. It states 'Pure offline — no browser, no network,' implying no side effects. It explains inference behavior when tokens are not supplied, but does not explicitly state it is read-only.

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

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

The description is a single paragraph covering essential aspects without redundancy. It is front-loaded with purpose, then details. While concise, it could be slightly more structured (e.g., bullet points for outputs).

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 missing output schema, the description thoroughly details the return fields (per-page extraction, consistency dimensions, outlier names, issues, score, summary), making the tool's behavior fully understandable.

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 value by explaining the purpose of optional tokens (inference when omitted) and their expected formats. It also explains the pages parameter requirement for cross-route sampling.

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 cross-page consistency of container width and hero heading tier. It specifies the input of ≥2 pages and output details, distinguishing it from single-page audit tools like audit_page.

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

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

The description provides clear context for use: 'Pass ≥2 pages collected from different routes on the same site' and explicitly flags a blind spot that single-page audits miss. It implies when not to use (single page), but does not explicitly list alternatives.

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

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

No annotations provided, so description carries full burden. It details heuristics per content type, output structure (verdict, principle ids, issues, rewrite, summary), and confirms no network/browser dependency.

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?

Dense but well-structured, front-loaded with purpose and key heuristics. Slightly long but every sentence adds value; no fluff.

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

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

Given no output schema, description fully compensates by detailing output. Only 1 required param and simple schema; description covers all necessary context for correct invocation.

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

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

Schema coverage is 100%, but description adds significant meaning by explaining heuristics and output details. Baseline 3 is elevated due to extra context beyond schema.

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

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

The description explicitly states the tool evaluates content items against UX-writing principles, lists supported types, and distinguishes itself from 'evaluate_design' by specifying per-item verdicts rather than a principle library.

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?

Clearly states when to use ('Use this instead of evaluate_design when you need per-item content verdicts'), and notes it is pure offline, guiding appropriate invocation.

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

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

With no annotations, description carries full behavioral disclosure burden. It explains output format (AA/AAA pass/fail, failing pairs) but does not mention side effects, permissions needed, or error handling. A read-only inference is reasonable but not explicit.

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 redundancy, front-loaded with core purpose. Every word adds value, clearly explaining inputs, outputs, and context.

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

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

Given no output schema, description fully explains return values (fail/success per element, selector, ratio, delta-to-pass). It covers both input modes and the tool's purpose comprehensively.

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 clarifying the role of each parameter: 'url' triggers rendering, 'dom_snapshot' bypasses it, and 'screenshot' is for reference only (ratios from DOM). This goes beyond the schema's basic 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?

Description clearly states the tool computes WCAG contrast ratios for text elements from a URL or dom_snapshot, with specific thresholds (AA/AAA). It distinguishes itself from siblings like 'audit_contrast' vs 'suggest_contrast_fix' by focusing on measurement rather than suggestions.

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 explains two usage modes (URL or dom_snapshot) and implies use for contrast checking. However, it lacks explicit guidance on when to choose this over sibling tools like 'suggest_contrast_fix' or 'audit_content'.

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

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

No annotations exist, so the description carries full burden. It describes what the tool does (scores a snapshot) and lists checks and output format, suggesting a read-only operation. It adds useful context about the capture harness but does not discuss auth or rate limits.

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

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

Two dense but clear sentences with front-loaded purpose and output details. Every word contributes value; no redundant or 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?

Given the tool's complexity and lack of output schema, the description covers the tool's purpose, checks, output fields, and capture method. Missing explicit parameter explanations, but otherwise provides sufficient context for an agent to understand 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 description coverage is 0%, and the description does not explain the three parameters (options, elements, viewport). The input schema is complex with nested objects, but the description only implies the input is a snapshot without mapping to schema 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?

The description clearly states the tool scores an accessibility-enriched iOS element snapshot, listing specific checks (missing labels, tap targets, contrast, Dynamic Type, reading order) and output fields. It distinguishes from siblings like audit_contrast or audit_tap_targets by covering multiple accessibility aspects combined.

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

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

The description mentions a capture method ('AccessibilitySnapshot XCUITest / ios-capture harness') implying a prerequisite but provides no explicit guidance on when to use this tool versus alternative audit tools, nor when not to use it.

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

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

No annotations are provided, so the description carries full burden. It details what the tool checks (NS*UsageDescription, entitlements, ATS exceptions, secrets, default data-egress) and implies read-only behavior. It could be more explicit about non-destructive nature, but is sufficiently transparent.

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

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

The description is a single dense paragraph that efficiently packs a lot of information. It front-loads the purpose and then details checks. While slightly long, every sentence earns its place. Could be improved with bullet points, but current structure is acceptable.

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 explicit output structure. It mentions 'Same return shape as audit_page' but does not describe the output schema. Given the complexity of the tool (flags multiple issues), a complete description should detail the return format. However, the flags are listed, providing some 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 100%, so baseline is 3. The description adds value beyond schema by explaining how each parameter enables specific checks (e.g., 'source enables code-vs-declaration contradiction checks and default-egress detection'). This extra context justifies a higher 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 it audits privacy posture for iOS/React Native/Expo apps for App Review and user trust. It specifies inputs and what it flags, and distinguishes from sibling tools by mentioning 'Same return shape as audit_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 usage for privacy auditing of iOS apps, listing required inputs (Info.plist or app.json) and optional ones. It does not explicitly state when not to use it or compare to alternatives, but the context from sibling tools makes it reasonably 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?

No annotations provided, so description carries full burden. It discloses that geometry is scored from snapshot (not pixels), treats iOS standard colors as platform-standard (warn not fail), and references audit_page for return shape. Lacks mention of idempotency or side effects, but overall 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?

Well-structured with clear sections: purpose, calling conventions, list of checks. Could be slightly more concise, but 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?

Given no output schema, description references audit_page for return shape, which is adequate if audit_page is well-documented. Covers input shape thoroughly, but could benefit from more detail on output 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?

Schema coverage is 100%, yet description adds value: explains the elements array shape, viewport, screenshot's optional role, and the binding/project parameter behavior for design notes. Adds clarity beyond schema 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?

The description clearly states the tool audits a rendered iOS screen from a view-hierarchy/accessibility snapshot, lists specific checks (touch targets, contrast, visual rhythm), and identifies itself as an alias of audit_screen with platform iOS, distinguishing 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?

Provides explicit calling conventions: 'Call with no arguments for the expected snapshot shape. Call with {elements:...}' and notes the return shape matches audit_page. However, it does not contrast with similar audit tools like audit_ios_a11y or audit_screen.

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

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

With no annotations provided, the description carries full burden. It discloses the two-step workflow and output format (JSON). It could mention whether it's read-only or has side effects, but the audit nature suggests safety. Overall, it's sufficiently transparent.

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

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

The description is brief, front-loads the main purpose, and includes essential workflow details without unnecessary words. 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 two-step workflow and absence of output schema, the description adequately explains how to use the tool, what it returns, and how it relates to siblings. No critical 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 baseline is 3. The description adds value by explaining the parameters are the JSON output from the first step, which is not obvious from schema alone. This clarifies the usage flow beyond the property 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 it evaluates visual rhythm from rendered page geometry. It outlines a two-step process: first call returns a DevTools snippet, second call with that JSON returns scores. It also distinguishes itself from audit_page as the complement for rendered-only content.

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 the tool (for rendered page geometry) and identifies audit_page as a complement for other aspects. It does not explicitly list when not to use it, but the context is clear.

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

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

In the absence of annotations, the description robustly discloses tool behavior: it launches headless Chromium when a URL is provided, runs specific checks, and returns pass/fail results with fix instructions. It also explains advanced features like adversarial_verify and scroll_settle. No contradiction with annotations (none provided).

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 but well-structured, starting with the core purpose and then listing check categories. It is appropriately sized for a complex tool with 9 parameters, though it could be slightly more concise by grouping related parameters.

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 params, no output schema), the description covers inputs, behavior, and a summary of output (pass/fail per check). It lacks details on output structure but this is acceptable given the schema coverage and the inline explanation of return 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 high (89%), and the description adds significant meaning beyond parameter names and types. For example, it explains how containerMaxWidth makes the max-width check token-aware, and how interactive interactions capture dynamic states. This enriches 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?

The description clearly states the tool 'Audit HTML/CSS against Raven's design quality standards' and enumerates specific check categories (typography, accessibility, responsive, style guide, visual rhythm). This is a specific verb+resource that distinguishes it from sibling audit tools that focus on narrower 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?

The description provides implicit guidance by detailing what the tool checks and how parameters like containerMaxWidth customize behavior. However, it does not explicitly state when to use this tool versus alternatives (e.g., audit_typography, audit_tap_targets) 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?

With no annotations, the description must disclose behavioral traits. It explains that the tool compares snapshots and flags per-relation match/mismatch/uncertain, and mentions catching cross-platform layout drift. However, it does not explicitly state that the tool is read-only (non-destructive) or describe any side effects, auth requirements, or rate limits. The behavior is adequately described but lacks full transparency for a read-heavy audit tool.

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

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

The description is concise at two sentences. The first sentence states the core function with examples, and the second specifies required inputs. It is front-loaded with the verb 'Compare' and efficiently uses space. However, it could be slightly more structured by separating the input specification more clearly.

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 of the inputs (nested objects with multiple required fields) and the absence of an output schema, the description is mostly complete for understanding what the tool does. However, it does not describe the output format beyond 'flag per-relation match/mismatch/uncertain,' which leaves the agent uncertain about the return structure. It adequately covers the purpose and inputs but lacks output specification.

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

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

The description provides a high-level overview of inputs ('ios+android {elements,viewport} snapshots and a checklist[]') but adds no details about the parameters' structure or meaning beyond what the schema already conveys. Since schema coverage is 0% (no parameter descriptions), the description should compensate but does not. The schema is self-explanatory for the nested objects, but the description fails to clarify any parameter semantics.

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: comparing iOS vs Android element snapshots against a checklist of spatial relationships and flagging matches/mismatches/uncertain. It provides specific examples of relationships (vertical centering, baseline/left alignment, etc.) and a concrete usage scenario (cross-platform layout drift), making it easy to distinguish from sibling 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 states the required inputs: 'Provide ios+android {elements,viewport} snapshots and a checklist[].' It implicitly indicates the tool is for cross-platform parity checking, which differentiates it from sibling tools like audit_ios_screen or audit_layout. However, it does not explicitly state when not to use it or mention alternatives.

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

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

Discloses rendering at breakpoints, flagging hidden elements, categorization, output format, and requirement for headless chromium. Could mention scrolling behavior or limitations, but adequate given no annotations provided.

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

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

Two sentences packed with essential information, no filler. Front-loaded with main 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?

Explains output format (table with columns) and categorization logic. No output schema, but description compensates fully. Covers all necessary aspects for 3-param 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% and already includes defaults for breakpoints and viewportHeight. Description adds no extra meaning beyond the schema, so baseline 3 applies.

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

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

Clearly states it renders a URL at multiple breakpoints and flags content hidden on mobile, specifying hiding techniques and categorization. Distinguishes 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?

Explicitly requires headless chromium, implying environment prerequisites. Does not explicitly state when not to use or alternatives, but the specific purpose and sibling names provide clear context.

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

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

No annotations are provided, so the description carries the full burden. It discloses the list of checks (accessibility, touch targets, font scaling, SafeAreaView, etc.), rewards, and that source arrays are concatenated. It also notes the same return shape as audit_page. However, it does not mention any side effects, authentication needs, or rate limits, but for a read-only audit tool, the transparency 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 a single, dense paragraph but is well-structured: it opens with the tool's purpose, lists checks and rewards, then clarifies scope and return format. It is not overly verbose, though using bullet points could improve scannability. Every sentence adds value, and the essential 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?

Given the complexity (5 parameters, no output schema, no annotations), the description is thorough. It covers input format, parameter behavior (strict, profile, project, color_scheme), checks performed, rewards, and the output shape is referenced via 'Same return shape as audit_page.' This is sufficient for an agent to use the tool correctly in context.

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

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

Schema coverage is 100%, and the description adds significant value beyond the schema descriptions. It explains that 'source' is concatenated, 'strict' changes warning handling, 'profile' is optional and searches bindings, 'project' verifies design notes, and 'color_scheme' suppresses dark-mode checks when set to light or dark. This enriches the agent's understanding of parameter behavior.

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

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

The description explicitly states the tool audits React Native/Expo source for iOS HIG and Android Material conventions. It lists specific checks (accessibility, touch targets, font scaling, etc.) and rewards (SafeAreaView, hitSlop, Platform-aware code). It also distinguishes from siblings by noting 'RN-native checks only' and referencing audit_ios_screen for rendered screen scores.

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

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

The description clearly indicates when to use the tool (for RN/Expo source) and distinguishes it from other audit tools (e.g., audit_ios_screen, audit_page). It states 'RN-native checks only — no web/CSS or SwiftUI rules' and mentions 'Same return shape as audit_page.' However, it does not explicitly list when not to use it or provide direct alternatives for non-RN 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?

With no annotations, description fully discloses behavioral traits: it scores touch targets, contrast, visual rhythm, and details platform differences (48dp vs 44pt, semantic colors). 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?

Single paragraph is concise and front-loaded with key purpose. Some redundancy in platform explanation, but overall efficient.

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

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

Covers core functionality but lacks details on output shape beyond referencing audit_page. Missing explanation for 'scroll_settle' parameter. With no output schema, description could be more 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 86%, and description adds value by explaining platform parameter effects and the role of elements array. However, 'scroll_settle' lacks description in both schema and text.

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 a rendered mobile screen from a view-hierarchy/accessibility snapshot. It specifies platform-specific scoring (iOS/Android) and differentiates from sibling tools like audit_ios_screen and audit_tap_targets by focusing on holistic screen audit.

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

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

Provides clear guidance on when to use the tool (audit a screen), including a hint to call with no arguments for expected input shape. Does not explicitly list when not to use, but sibling tool context implies alternatives.

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

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

No annotations provided, so description bears full burden. It details specific checks (fonts, colors, frames, spacing) and output format ('Returns pass/fail per check with fix instructions'). It is transparent about scope and behavior.

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

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

The description is a single paragraph that front-loads the purpose and lists checks compactly. Though somewhat long, every sentence adds necessary detail without redundancy.

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

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

With 5 parameters, no output schema, and no annotations, the description covers the tool's function and expected output. Minor gaps (e.g., error handling, performance) do not detract from overall 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?

100% schema coverage (baseline 3), but description adds significant value by explaining that arrays are concatenated, and clarifying the role of profile, project, and accent_color_contents parameters beyond their 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?

The description clearly states the tool audits SwiftUI source against Apple's Human Interface Guidelines with a specific list of checks and rewards. It distinguishes from sibling tools like audit_ios_a11y and audit_typography by stating 'iOS-native checks only — no web/CSS rules.'

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 indicates the tool is for iOS SwiftUI code and explicitly excludes web/CSS. It gives context for when to use, but does not name alternative tools for other platforms or non-SwiftUI audits.

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

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

Given no annotations, the description fully covers behavioral traits: it uses headless chromium for rendering, measures real getBoundingClientRect, and emits a per-element fix table sorted worst-first. It does not mention side effects or performance, but these are minimal for an audit tool.

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

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

The description is a single paragraph but efficiently packs key information: purpose, element types, output format, and modes. It is front-loaded with the standard name and avoids unnecessary words, though some structure (e.g., bullet points) 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?

For a complex audit tool with no output schema, the description covers the input modes, element selection criteria, measurement process, and output format (fix table with fields). It is sufficiently complete to understand what the tool does and what to expect, though a brief mention of return value structure would be beneficial.

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

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

Schema coverage is 100% with descriptions for all three parameters. The description adds significant context beyond the schema: it explains that 'url' triggers headless chromium rendering and real measurement, while 'elements' is a pre-collected snapshot mode. It also notes the default minSize of 44px.

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

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

The description clearly states the tool performs a WCAG 2.5.5 / Apple 44pt tap-target audit for the web. It specifies exactly what elements are collected and what output is produced, distinguishing it from sibling audit tools that focus on other aspects like consistency, contrast, or 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 explicitly mentions two modes (URL with headless chromium or elements[] snapshot), making it clear when each is appropriate. However, it does not provide guidance on when not to use this tool or compare it with other sibling tools for alternative approaches.

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

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

With no annotations, the description carries the full burden. It details what the tool emits but does not explicitly state whether it is read-only or has side effects. For an auditing tool, it is likely non-destructive, but the lack of explicit disclosure lowers the score.

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 elaborating on the three audit components and output format. It is concise given the complexity, with no unnecessary 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 tool's complexity (three audit aspects) and the absence of an output schema, the description provides a thorough overview of what the tool returns, listing specific fields (scale, line_height, weight_ladder, nodes_analyzed, findings). It fully prepares an agent to understand the tool's capabilities.

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. The description adds context by explaining the two modes (url and nodes) and highlighting the headless chromium requirement for url mode, which goes beyond the schema's simple 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 typographic scale, line-height consistency, and weight ladder. It distinguishes itself from the sibling tool 'audit_page' by noting it goes beyond pass/fail checks, providing a focused report. The verb 'audit' and specific resource 'typographic SCALE' make the purpose unambiguous.

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

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

The description explains two modes (url or nodes) and warns that url mode requires headless chromium. It contrasts with audit_page but does not explicitly list when to use this tool versus other siblings like audit_consistency or audit_layout. However, the guidance is sufficient for a focused 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?

No annotations present, so description carries full burden. It discloses behavior: renders live URL, scroll-settles, fires interactions, captures pixels and DOM, runs specific checks, and tags findings with confidence levels and severity. 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?

Description is verbose but front-loaded with purpose. Each sentence adds information about the tool's capabilities. Could be slightly more concise, but structure is logical.

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 9 parameters and no output schema, description covers the tool's operation, outputs (specific finding types and confidence levels), and use cases. Lacks explicit return format details but provides high-level understanding.

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 value beyond schema by explaining purpose of compact (drop screenshots), interactions (diffed against baseline), and scroll_settle (reveals IntersectionObserver content). Adds context not in schema property 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?

Description clearly states it is a 'render-and-capture audit' that catches 'real-world visual nits invisible to HTML-string/geometry audits', distinguishing it from sibling tools. Uses specific verb 'audit' and resource 'URL'.

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 contrasts with other audit tools by mentioning what it catches that others miss. Explicitly notes prerequisite ('Requires headless chromium'). Provides guidance on when to use compact=true to avoid blowing budget.

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

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

With no annotations provided, the description carries full burden. It details the core behavior: headless Chromium rendering, sampling currentTime before/after play, classification categories, and two modes. However, it lacks information on authentication, rate limits, or error handling.

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, front-loading the core functionality, then adding value and usage modes. Every sentence contributes meaning without redundancy.

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

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

The description covers input modalities and high-level behavior, but lacks any indication of the output format or structure. Since there is no output schema, the description should briefly mention the expected result shape to help the agent understand what to expect.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by clarifying the two operational modes (URL-based or pre-collected snapshot) beyond the individual parameter descriptions, making the tool usage more intuitive.

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 page in headless Chromium and observe whether each <video> actually advances...classifying every clip into playing|paused|stalled|empty|error with a reason.' It distinguishes itself from sibling audit tools by focusing specifically on video playback defects that static audits miss.

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 url to render + observe, or dom_snapshot to classify pre-collected observations without a browser.' It implies when to use this tool (for dynamic video behavior), but does not explicitly state when not to use it or suggest alternatives.

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

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

No annotations provided; the description lacks behavioral details such as validation of system existence, error handling, or any constraints on mixing. Only states what the tool does without disclosing side effects or limitations.

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

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

Two efficient sentences: first defines the tool, second provides a concrete example. No wasted words, front-loaded 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?

Adequately describes the composite operation but lacks context on where design systems are sourced, prerequisites, output format details, or constraints. Missing 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 covers both parameters (format, compositions) with descriptions. The description adds value via the example showing how to use compositions, offsetting the baseline 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 verb 'mix', resource 'tokens from different design systems', and result 'custom composite'. It distinguishes itself from sibling audit, evaluation, and retrieval 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?

Provides an example (Linear's colors + Stripe's typography) that clarifies usage context. Does not explicitly mention when not to use or list alternatives, but the sibling list makes the differentiation clear.

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

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

With no annotations, the description is the sole source of behavioral info. It only mentions return values (principles, violations, suggestions) but fails to disclose input size limits, side effects, or permissions. The screenshot-based diff behavior is described in the schema but not in the description.

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 filler. However, it omits critical functionality (screenshots), which slightly reduces its value despite the 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?

The tool has 6 parameters and no output schema, yet the description only vaguely describes return values. It fails to explain the screenshot diff feature or the expected format of goals, which are important for correct invocation.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds no further meaning beyond what the schema already provides (e.g., goals, compact, context, description, screenshots).

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 'Evaluate a design description against UX principles', which specifies a verb and resource. However, it omits the screenshot diff functionality present in the schema, so it doesn't fully represent the tool's scope. It partially distinguishes from siblings but lacks completeness.

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

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

The description provides no guidance on when to use this tool versus alternatives like audit_consistency or audit_content. There are no contextual cues or examples to help an agent decide.

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

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

No annotations are provided, so the description bears full responsibility. It discloses that the tool auto-generates a palette, supports style presets, and exports in various formats. However, it does not mention any side effects, auth requirements, rate limits, or the process of generation. Adequate but not rich.

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

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

Three sentences with no wasted words. The purpose is front-loaded, and the description is efficient and clear. 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 (6 parameters, 2 enums, no output schema), the description covers inputs and output formats adequately but lacks details on what the tool returns (e.g., file path, download URL, or raw data). The comment about HTML export being a self-contained page is helpful but incomplete.

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

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

Schema coverage is 100% with descriptions for all 6 parameters. The description reinforces the parameter purposes (e.g., brand color auto-generates palette) but adds only marginal value beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states that the tool generates a complete, custom design system with full token set, and specifies inputs (brand color, style preset) and outputs (multiple export formats). This distinguishes it from sibling tools, most of which are audits or retrievals.

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

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

The description implies when to use (when a new design system is needed from a brand color), but does not explicitly state when not to use or mention alternatives like 'get_design_system' or 'compose_system'. No explicit guidance 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?

No annotations are provided, so the description alone must convey behavior. It explains output as a self-contained HTML page, the two rendering modes, and the components included. This is sufficient for a generation tool.

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

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

The description is a single, well-structured paragraph. Every sentence adds necessary information without redundancy. It is front-loaded with the core purpose and then provides mode details.

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 (nested objects, two modes, optional side-by-side), the description covers all essential aspects. It explains mode switching, component roles, and the ideal-state option. No output schema exists, but the description does not need to explain return values per rules.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds value by explaining how params like 'actors' and 'ideal' affect the output (single vs two-actor, side-by-side).

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 HTML, describes two modes (classic single-actor and two-actor HI-loop), and lists components. This distinguishes it from sibling tools, which are audits and design system generators.

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

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

It explicitly specifies when to use each mode: omit actors for classic, supply actors for two-actor. It also notes optional ideal-state for side-by-side. However, it does not mention when not to use the tool or alternative tools.

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

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

No annotations are provided, so the description must fully convey behavior. While it implies read-only retrieval by describing content, it does not explicitly state that the tool is non-destructive or mention authentication requirements or rate limits. The description is adequate but could be more transparent.

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

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

The description is a single, moderately long paragraph that efficiently covers purpose, topics, and usage. It front-loads the main intent. While not overly verbose, it could be more structured (e.g., bullet points) for easier scanning.

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 (two optional parameters, no output schema), the description is complete. It explains what the tool returns, lists supported topics, and provides usage guidance. No additional information is necessary for an agent to invoke it correctly.

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

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

Schema coverage is 100% with descriptions for both parameters (topic and format). The description adds value by listing example topics and output formats, but it does not significantly extend beyond the schema. The baseline score of 3 is appropriate as the schema already does the heavy lifting.

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 brand and visual-design principles and enumerates specific subtopics (logo usage, gradient usage, imagery, visual hierarchy, brand-as-system). This distinguishes it from sibling tools like get_brand_system or get_brand_trends, which focus on different 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?

The description explicitly says 'Use when the user asks about branding, logos, gradients, imagery, visual consistency, or how to treat a brand across surfaces,' providing clear usage context. However, it does not specify when not to use the tool or suggest alternatives like get_brand_system or get_brand_trends.

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

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

With no annotations, the description discloses matching against 12 known design systems and providing closest match with CSS. It describes output components (token set, style guide, instructions). It doesn't mention error handling for unknown companies or rate limits, but the read-only nature is clear.

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

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

The description is two sentences: first states the core function, second provides an example and behavioral detail. No fluff or repetition; very 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 tool's moderate complexity (matching, multiple output formats), the description covers the purpose, example, matching behavior, and output. It lacks details on response structure for edge cases, but overall is sufficiently complete for an agent to infer usage.

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

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

Schema coverage is 100%, so baseline is 3. The description does not elaborate on parameter meanings beyond the schema, but it contextualizes the company parameter via example. Mode and format are adequately described in the schema.

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

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

The description clearly states it provides a complete design system with branding from a specific company, using the verb 'get' and resource 'design system'. It distinguishes from sibling tools like get_design_system by focusing on brand-specific matching and ready-to-use CSS.

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

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

The description gives a concrete example of when to use ('Make me an app with branding like Spotify') and implies usage for brand-matching. However, it does not explicitly exclude cases where a custom system is needed or compare to siblings like generate_design_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?

No annotations are provided, so the description carries full burden. It discloses that trends are time-stamped and lists example categories. No side effects or destructive actions are implied, and no contradictions exist.

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

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

The description is two sentences: the first states the purpose, the second lists examples and provides guidance. No wasted 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 adequately explains what the tool returns (trends with timestamps). It covers the nature of the data and its intended use, making it complete for a simple query 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, and schema coverage is 100%. The description adds context about the content of the output (list of trends with timestamps) beyond the empty schema.

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

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

The description clearly states the tool returns current brand and visual-design trends for 2026, listing specific examples. It uses a specific verb ('get') and resource ('brand trends'), and distinguishes itself from sibling tools that focus on audits, design systems, or 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 advises to treat the results as a 'calibration signal, not a prescription,' guiding interpretation. While it doesn't explicitly state when to use versus alternatives, the sibling tools are sufficiently distinct in 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?

No annotations provided, so description carries full burden. It discloses the tool is read-only and what topics it covers, but does not mention auth needs, rate limits, or error handling. Adequate but not rich.

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

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

Two sentences, no wasted words. First sentence states purpose, second lists coverage. Excellent 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?

No output schema; description does not explain return values or how the 'stage' parameter affects results. Missing information for a complete understanding.

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 parameter descriptions. The description adds context by listing strategy areas, but does not significantly enhance 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 'Get business and monetization strategies for digital products' and enumerates specific areas covered (monetization, retention, onboarding, growth, metrics), distinguishing it from sibling tools like get_brand_principles 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?

No explicit guidance on when to use this tool over alternatives (e.g., other 'get_*' siblings). No exclusions or when-not-to-use scenarios are provided.

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

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

No annotations are provided, so the description carries the full burden. It states 'Get' implying a read-only operation, but does not explicitly disclose that it has no side effects, nor does it mention error handling or data source.

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, direct sentence that conveys the tool's purpose and output. No extraneous words, front-loaded with key action and resource.

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 tool with two straightforward parameters and no output schema, the description adequately covers what the tool does and returns (actionable yes/no items). It lacks details on error handling or edge cases, but these are minor for this use case.

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

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

Schema coverage is 100% with descriptions for both parameters. The 'type' description provides helpful examples. The 'platform' description is notably detailed, explaining enum values 'ios' and 'react-native' with specific checks, adding significant value beyond the enum itself.

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

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

The description clearly states the verb 'Get', the resource 'pre-publish checklist', and specifies it's for a specific UI type. It distinguishes from sibling audit tools by focusing on a checklist rather than audit analysis.

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

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

The description implies usage when needing a prepublish checklist but offers no explicit guidance on when to use this tool versus sibling audit tools (e.g., audit_page, audit_screen). No when-not-to or alternative suggestions.

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

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

No annotations are provided, so the description carries the full burden. It lists the return contents (do's, don'ts, examples, evidence, checklist) but does not disclose whether it is read-only, any authorization needs, or performance characteristics.

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, concise, front-loaded with the tool's purpose, and contains 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 the single parameter with full schema and no output schema, the description adequately conveys the tool's return structure. However, it does not mention if the result is a list or a single pattern, and there is potential overlap with 'get_checklist'.

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 context by explaining the enum values (e.g., 'copy recipes for error messages') but does not add syntax or format details beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states it retrieves content design patterns and lists the specific types (error messages, empty-state copy, etc.) and what is returned. It distinguishes from sibling tools like 'get_content_principles' (principles vs patterns) and 'get_content_system' (system vs 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 implies when to use via the enum values but does not explicitly state when not to use or how it compares to siblings like 'get_checklist', which also returns a checklist. No alternative tools are mentioned.

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

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

No annotations are provided, so the description carries the full burden. It states the tool retrieves principles with optional filtering, which implies a read-only operation. However, it does not disclose any side effects, authentication needs, rate limits, or behavior for invalid inputs. The description is adequate but lacks depth.

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

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

The description is one well-structured sentence that immediately states the purpose and provides key examples. It is concise with no wasted words, and the filtering mechanism is clearly mentioned upfront.

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 retrieval tool with no output schema and 2 optional parameters, the description lists the types of principles and usage examples. It could mention the return structure (e.g., array of principle objects) but is otherwise sufficient given the tool's simplicity.

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

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

The input schema covers both parameters with descriptions and enum for format. The description adds value by providing concrete examples for the context parameter (e.g., 'error messages', 'notifications', 'form labels') and stating the default format as 'full'. This supplements the schema 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 'UX-writing principles' with specific examples like 'clarity over cleverness, active voice, error-message anatomy, inclusive language, voice vs tone'. This distinguishes it from sibling tools like 'get_principles' (general principles) and various 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 says to filter by writing context (e.g., 'error messages') and to omit the context parameter to get all principles. It does not explicitly mention when not to use this tool or alternatives, but the filtering guidance is clear and actionable.

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

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

No annotations are provided, so the description carries full burden. It explains what the tool returns but does not disclose behavioral aspects like authentication requirements, side effects, or response format. This is adequate but not rich.

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

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

The description is a single sentence that front-loads the purpose and then enumerates components. It is efficient and covers key aspects without excessive verbosity.

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 parameters are well-defined in the schema and no output schema exists, the description adequately explains the resource and sections. It could mention the return format, but this is minor.

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 adds context by providing example IDs and confirming the section enum values, but does not significantly enhance 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 uses a specific verb ('Get') and resource ('brand's content design system'), and lists detailed components (voice, tone, vocabulary, etc.), clearly distinguishing it from sibling tools like get_design_system or 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 implies usage for retrieving content design system details but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_brand_system, get_design_system) 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?

With no annotations provided, the description bears the full responsibility for behavioral disclosure. It states the tool 'Returns' templates, implying a read-only, idempotent operation. However, it does not disclose permissions, rate limits, or potential side effects. For a simple retrieval tool, this is adequate but not exemplary.

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 immediately communicates the tool's purpose and enumerates the return content. Every word serves a function, with no fluff or redundancy.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description is largely complete: it explains the tool's function and output. It could optionally mention that templates are returned in a structured format, but the current description suffices for minimal viable understanding.

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%: the 'stage' parameter is fully described in the input schema with an enum and a description ('Which stage of the D4D loop to return. Default: full'). The tool description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly states the verb 'Get' and the specific resource 'Design for Delight (D4D) framework templates', listing the exact templates returned (customer problem statement, ideal state, etc.). This distinguishes it from sibling tools like get_brand_principles or get_business_strategy, which target different frameworks.

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

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

No explicit guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusion criteria. Given the presence of many sibling tools, the lack of differentiation reduces utility for agent selection.

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

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

No annotations are provided, so the description must cover behavioral traits. It only states it 'returns' tokens, but does not disclose if the operation is read-only, idempotent, requires authentication, or has rate limits.

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

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

Two sentences with no wasted words. The first sentence clearly states the purpose, the second details the output. Well front-loaded.

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

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

For a read tool with 3 parameters and no output schema, the description adequately covers what the tool returns. It could mention the structure of the output, but this is not critical since the schema covers parameters.

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. The description adds value by explaining the output contains specific token types and formats, which clarifies the purpose of the group and format 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 retrieves design tokens for a specific system, listing the token types and formats. This distinguishes it from sibling tools that audit or generate 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?

No explicit guidance on when to use this tool vs alternatives like get_brand_system or get_content_system. The context of sibling tools suggests multiple 'get' tools, but no differentiation is provided.

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

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

No annotations provided, so description carries burden. It states returns structure, usage, pitfalls, and examples, which is sufficient for a read-only tool. No hidden effects disclosed.

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

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

Two efficient sentences with key information front-loaded; no redundant words. Lists frameworks compactly.

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 retrieval tool with no output schema, the description fully covers what the tool returns (structure, examples, etc.) and parameter behavior, making it complete.

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

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

Schema coverage is 100% with both parameters described. Description adds value by explaining 'id' as framework id and that omission lists all, complementing 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 product-metrics frameworks (HEART, AARRR, etc.) with specific details, distinguishing it from sibling audit/design tools.

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

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

Explicitly tells when to use: when user asks 'how to measure success' or 'what metrics to track'. Lacks explicit when-not-to-use or alternative tools, 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?

No annotations; description indicates read operation but doesn't disclose side effects, authentication needs, or data source. Lists output components (do's, don'ts, evidence, checklists) but could be more explicit about 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?

Single sentence clearly front-loads purpose, but the list of examples makes it slightly long. Still concise with no filler.

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

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

No output schema; description lists output components but lacks structure details. Given parameter richness, it's mostly complete but could specify return 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%, but the description adds value by enumerating many pattern types beyond the schema's short examples, and explaining that 'goal' and 'platform' are filters.

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 design types, listing specific examples. It differentiates from sibling tools like audit_* or get_checklist.

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 obtaining design patterns, but lacks explicit when-to-use or when-not-to-use guidance compared to similar tools like get_checklist or get_design_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?

No annotations provided, but the tool name 'get' and description indicate a read-only lookup. The description clearly states what is returned (matched principles) without hidden behaviors, though it does not explicitly note idempotency.

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

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

Single sentence, front-loaded with the core purpose. The list of returned principles is somewhat lengthy but still efficient. 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?

No output schema, so description should clarify return structure. It lists types of principles but not format (e.g., array, text). Missing details on pagination or limits. Adequate for a simple lookup 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 coverage is 100% with good parameter descriptions. The tool description adds only marginal context ('matched to what you're designing') beyond the schema. No additional parameter semantics are provided.

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 design principles relevant to a UI context, listing specific categories (heuristics, laws of UX, etc.). It distinguishes from siblings like get_brand_principles by focusing on general UI design 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 implies use when designing a UI component, but does not explicitly compare to siblings or specify when not to use it. No exclusions or alternatives are mentioned.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns specific protocols, guidance, evidence, and a checklist, implying a read-only operation. However, it does not mention any behavioral traits such as authentication requirements, rate limits, or side effects. For a simple lookup, this is adequate but not exceptional.

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 about 60 words, front-loading the purpose and listing categories concisely. Every sentence adds value, with no redundancy. It could be slightly more structured (e.g., using bullet points) but is efficient as-is.

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

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

Despite lacking an output schema, the description fully explains the return value (protocols, guidance, evidence, checklist). The tool has only two simple parameters, and the description covers the use case. It 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 description coverage is 100% for both parameters, so the schema already documents their meaning. The description adds context about what the tool returns but does not enhance parameter semantics beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Get research method details', enumerates the categories (qualitative, quantitative, usability), and specifies the returned content (protocols, do/don't guidance, evidence, checklist). This is specific and distinguishes it well from sibling tools like 'get_design_system' or 'get_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 explicitly states when to use: 'Use when the user is designing a study or asking how to measure something.' This provides clear context. It does not list when not to use or mention alternatives, but the tool's niche is well-defined, so no exclusions are necessary.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return content (patterns, do/don't guidance, evidence, checklist), which is sufficient for a read-only operation. It does not discuss side effects or auth, but those are not critical for this tool.

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

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

Two sentences cover pattern types, return content, and usage guidance. No fluff, 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?

With only one parameter fully described in schema and no output schema, the description sufficiently explains what the tool does, what it returns, and when to use it. It is complete for its complexity.

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

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

Schema coverage is 100% with a clear enum description. The description lists pattern types but adds little meaning beyond the schema. It does provide context on the return content, but that does not directly enhance parameter understanding.

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

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

The description clearly states it gets a service design pattern, lists specific types (service blueprinting, human handoff, etc.), and describes what it returns. This distinguishes it from sibling tools, which are mostly audit or 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?

The description explicitly states when to use the tool: 'Use when the user is designing a service flow, escalation, cross-channel experience, or moment of truth.' It does not mention when not to use or provide alternatives, but given the simple enum parameter, this is adequate.

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

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

No annotations provided, but the description indicates this is a read-only retrieval tool (Get). Does not contradict any annotations (none exist). For a simple retrieval, this is sufficiently transparent.

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

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

Two sentences, front-loaded with the core purpose, no fluff. 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 parameters, no output schema, and a simple retrieval task, the description fully explains what the tool returns and when to use it.

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

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

No parameters exist; schema coverage is 100%. Description adds no param info but baseline is 4 for zero-param tools.

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 tool retrieves the GOV.UK Service Standard, a 14-point checklist, and explicitly contrasts with sibling audit tools by focusing on evaluation of whole services.

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

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

Provides explicit instruction to use when the user asks how to evaluate a whole service. Could mention when not to use, but the context and sibling list make it 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?

No annotations are provided, so the description carries the full burden. It does not disclose any behavioral traits such as pagination, rate limits, or whether the operation is read-only. Minimal behavioral context is given.

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 at two sentences, front-loading the purpose and then adding filtering options. Every sentence adds value without redundancy.

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

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

Given no output schema, the description does not specify the structure of returned data (e.g., fields like name, description). For a listing tool, this is adequate but not complete; a user might want to know what details are provided in results.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds examples of company systems and additional context about the content (brand voice and tone guides), but does not provide details on how parameters handle partial matching or case sensitivity.

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

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

The description clearly states the verb 'browse' and the resource 'content design systems', providing specific examples like Mailchimp, GOV.UK. This distinguishes it from sibling tools like list_design_systems, which likely list general 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 for browsing and filtering, but does not explicitly state when to use this tool versus alternatives like get_content_system for retrieving a specific system. No exclusion criteria are provided.

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

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

With no annotations, the description should disclose behavioral traits. 'Browse' implies a read-only operation, but no explicit statement about idempotency, side effects, or safety. No mention of authentication needs or limitations, leaving an agent uncertain about the tool's side effects.

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

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

Extremely concise: two sentences that front-load the core purpose and immediately clarify scope. No redundant information or fluff. Every sentence adds substantive 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 should at least hint at the return format (e.g., a list of model identifiers or capabilities). It does not, leaving an agent without expectations for the tool's response. The parameter coverage is good, but the lack of return information weakens 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 for parameters is 100%, so the schema already documents 'capability' and 'media_type'. The description adds value by listing example capabilities (image, video, audio, etc.) and the concept of 'capability slots', but does not explain parameter behavior beyond what the enum and description provide.

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 a provider-agnostic creative model catalog and lists example capabilities (image, video, audio, etc.). It distinguishes from siblings like list_content_systems by focusing on creative models. However, it could be more explicit about what data is returned (e.g., a list of model names/details).

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. It mentions using a RAVEN_CREATIVE_RUNNER for job routing, but that relates to using the models after browsing, not to the tool's own invocation. Sibling tools (e.g., list_creative_presets) are not contrasted.

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

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

With no annotations provided, the description carries the full burden. It does not disclose whether the tool is read-only, idempotent, or has any side effects. The behavioral traits are only implicitly assumed from 'Browse' but could be clearer.

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 that efficiently conveys the tool's purpose. No unnecessary words, though it could be slightly more structured with bullet points for the categories.

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 list tool with optional filters, the description provides adequate context about the preset categories. However, it lacks details about output format, pagination, or any limitations, which could help the AI set 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 parameters (search, media_type) described. The description adds no additional meaning or usage context for the parameters beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool browses creative presets with specific use cases (product photoshoots, marketplace cards, UGC ads, etc.), distinguishing it from sibling tools like list_creative_models. However, it could be more explicit about it being a read-only list operation.

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 browsing presets but provides no explicit when-to-use or when-not-to-use guidance compared to alternatives like list_creative_models. No exclusions or prerequisites are mentioned.

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

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

No annotations are provided, so the description must disclose behavioral traits. 'Browse' implies a read-only operation, but the description does not explicitly state that it is non-destructive, whether authentication is required, or other side effects.

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

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

The description is a single sentence that is concise and front-loaded with the tool's purpose. Every word adds value without redundancy.

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

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

Given the simplicity of the tool (2 optional params, no output schema), the description provides enough context for basic usage. However, it lacks details about the returned data structure, which would be helpful.

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 100% schema description coverage, the input schema already explains both parameters well. The description adds minimal extra value by mentioning 'tokens' and listing the five categories, which partially mirrors 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 action ('Browse') and the resource ('available design systems for tokens'). It mentions filtering capabilities, which helps distinguish from unrelated siblings, though it doesn't explicitly differentiate from other list tools like 'list_content_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 provides some context on when to use the tool (browsing design systems with optional filters) but does not give guidance on when not to use it or direct comparisons to sibling list 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?

Without annotations, the description compensates by stating it is a transparent heuristic, not a proprietary model, which sets expectations about its nature. No side effects or destructive actions are indicated.

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 the core action, no wasted words. Efficiently communicates purpose and nature.

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 details about the output format or return values, which is needed since no output schema is provided. Also, usage context like whether both channel and audience are required is implied but not explicit.

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 meaning by linking parameters to scoring dimensions (e.g., channel fit, audience fit), enhancing understanding beyond 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 scores creative prompts, scripts, or ad concepts on multiple specified dimensions (hook strength, benefit clarity, etc.), distinguishing it from sibling audit and get 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 evaluating creative concepts and highlights its heuristic nature, but does not explicitly specify when not to use it or provide alternatives among siblings.

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

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

With no annotations, the description carries the full burden. It discloses deterministic scoring, no browser required, and lists all categories. It mentions returning overall score, grade, weakest category, and guidance for three categories. It does not explicitly state side effects (likely none) but provides sufficient behavioral context for a non-destructive scoring tool.

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

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

The description is a single coherent paragraph, front-loaded with the key purpose and details. Each sentence adds meaningful information without redundancy. It could be slightly more structured, 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 no output schema, the description adequately hints at the return: overall score (0–100), grade (A–D), weakest category, and guidance for three categories. However, it does not detail the exact output structure or fields, which could require agents to infer from sibling tools or experience.

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 already described. The description adds value by explaining that strict mode counts warnings as failures, and that containerMaxWidth is forwarded to a specific check. 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 scores an HTML/CSS page across 7 named design categories with 0–10 ratings, plus an overall 0–100 score and grade. It explicitly distinguishes from sibling audit_page by noting deterministic same checks, weakest category identification, and guidance for categories not mechanically assessed.

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 that it uses the same checks as audit_page, implying a direct comparison. It also advises that for brand, conversion, and motion categories, only guidance is provided, signaling that other tools may be needed. However, it does not explicitly state when to prefer this tool over audit_page or other siblings.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only states the action and usage guidance, but does not mention what the tool returns (e.g., list of matches, full content), pagination, or any side effects. The parameter descriptions in the schema cover input details, but the tool's behavior beyond input is not described.

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

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

The description consists of two sentences. The first sentence states the purpose, and the second provides usage guidance. Every 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 tool has a simple interface with two parameters and no output schema. The description covers the purpose and usage context. However, it does not describe the output format or any limitations (e.g., max results, sorting), which would be helpful for an agent to interpret the results. Given the simplicity, it 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 description coverage is 100%, so the baseline is 3. The description adds 'or don't know which category to look in', which echoes the layer parameter's purpose but does not provide additional meaning beyond what the schema already states. No extra semantic detail is given.

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

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

The description uses the specific verb 'Search' and identifies the resources as 'design principles, UI patterns, and business strategies'. It clearly distinguishes from sibling tools by offering a cross-category search capability, while siblings are focused on specific audits or retrievals.

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

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

The description explicitly states when to use: 'when you need to find specific guidance or don't know which category to look in'. It does not list exclusions or explicit alternatives, but the context implies that if the category is known, one could use specific get_* or audit_* tools instead.

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

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

No annotations provided, so description carries full burden. It explains the computation (smallest adjustment, ratio, direction) and claims 'pure offline math' for no side effects. Missing details on input validation or limits.

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

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

Two sentences, front-loaded with purpose, no unnecessary words. Every sentence provides essential 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?

Describes output (foreground and background adjustments with ratio and direction) despite no output schema. No error handling mentioned, but sufficient for a straightforward computation 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%, and description adds context like how targetRatio overrides level and fontPx/bold determine contrast thresholds. This provides meaning 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?

The description clearly states the tool computes minimal color adjustments for failing WCAG pairs. It explicitly distinguishes from sibling audit_contrast by noting it takes failing pairs and returns concrete passing values.

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

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

The description advises using this tool after audit_contrast by saying 'Feeds directly from audit_contrast's failing pairs.' It implies the tool is for remediation, but does not explicitly state when not to use or list alternatives.

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