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

No annotations are provided, so the description carries the burden of behavioral disclosure. It discloses that the tool uses Playwright CSS coverage, finds specific issues, and reports per-stylesheet usage percentages and critical CSS opportunities. This gives the agent a good understanding of behavior, though it doesn't mention 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?

The description is a single, well-structured sentence that immediately states the purpose and capabilities. Every word adds value, with no redundancy or fluff.

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

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

Given the simplicity of the tool (one parameter, no output schema, no annotations), the description is complete. It clearly explains what the tool does and what kind of output to expect (per-stylesheet usage percentages and critical CSS opportunities). No additional context is needed.

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 the single parameter 'url', which already describes the format and purpose. The description adds no additional semantic information about the parameter, so the 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 it uses Playwright CSS coverage to find unused CSS, render-blocking stylesheets, and large framework bundles. It specifies the resource (CSS) and distinguishes from siblings like analyze_fonts and analyze_images.

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 CSS optimization tasks by listing specific problems it detects. While it doesn't explicitly state when not to use or name alternatives, the sibling list provides context, and the description focuses on its specific capabilities.

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 indicates a read-only 'Check' operation but does not disclose if it makes network requests, requires any permissions, or has side effects beyond analysis.

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 effectively lists the key checks. It is front-loaded with the purpose and avoids fluff, though it could be slightly more structured with bullets for readability.

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

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

The description covers what is analyzed but does not mention the output format or structure. Since there is no output schema, this is a gap for a diagnostic tool. However, the list of checks provides adequate context for most use cases.

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

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

Schema coverage is 100% with a single 'url' parameter described as 'The URL to analyze'. The description lists what is checked but does not add specific parameter 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 uses a specific verb 'Check' and clearly identifies the resource 'font loading strategy', listing concrete aspects like Google Fonts preconnect and WOFF2 format usage. This distinguishes it from sibling tools like analyze_css or analyze_images.

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 analyzing font loading but does not explicitly state when to use it versus alternatives like analyze_css or run_lighthouse. No when-not or alternative suggestions 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 full burden. It doesn't disclose whether the tool makes network requests, is read-only, has rate limits, error handling, or idempotency. Only the inspection categories are mentioned.

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

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

The description is a single 15-word sentence, front-loaded with the action 'Inspect HTTP response headers' followed by specific categories. No unnecessary words.

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

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

Given the tool's simplicity (one parameter, no output schema), the description lists what is inspected but omits return format, limitations (e.g., public URLs only), and error handling. Adequate but 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?

The schema has one parameter 'url' with a minimal description. The tool description adds meaning by specifying what header categories are analyzed (compression, caching, etc.), providing context beyond the schema.

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

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

The description clearly states the tool inspects HTTP response headers and lists specific categories (compression, caching, CDN detection, security headers, HTTP/2 support). This distinguishes it from sibling tools that analyze CSS, fonts, images, etc.

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

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

The description implies usage for inspecting headers but provides no explicit guidance on when to use this tool versus alternatives like cloudflare_inspector 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 carries the full burden. It clearly states the tool parses and checks for specific items (render-blocking, meta tags, etc.), indicating a read-only analysis. However, it omits potential details like whether it fetches the page itself, or any rate limits or dependencies.

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 communicates the tool's core function and specific areas of analysis. Every phrase adds value with no redundancy.

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

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

Given the simplicity (1 parameter, no nested objects) and no output schema, the description covers the what and checks well. It lacks details about the return format or output structure, which could help an agent understand what to expect. Still, it is largely adequate.

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

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

There is only one parameter 'url', which is fully described in the schema (type, format, description). The tool description does not add extra semantics for this parameter beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description specifies a clear verb ('Parse') and resource ('HTML of a page'), and lists actionable checks (render-blocking resources, meta tags, script strategy, head optimizations). This distinguishes it from sibling tools like analyze_css or analyze_javascript.

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 HTML-level performance and optimization checks, but does not explicitly state when to use this tool over siblings such as analyze_css or run_lighthouse. No 'when not to use' or alternative suggestions 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 discloses the checks performed (e.g., oversized images, formats) but does not mention behavioral traits like whether the tool is read-only, requires authentication, or has rate limits. It adds useful context but leaves safety profile unclear.

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

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

The description is a single sentence that efficiently lists multiple detection capabilities. It is front-loaded with the main action and is concise, though it could be structured with bullet points for readability, which is not required.

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

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

Given the tool has no output schema, the description should explain what the return value looks like or how results are presented. It only describes what is scanned, potentially leaving the agent unsure about the output format. This is a gap for completeness.

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

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

Schema coverage is 100% with a single 'url' parameter described as 'The URL to scan'. The description adds value by linking the parameter to the action ('scan all images on a page'), but does not provide additional semantics beyond what the schema already states. Baseline 3 due to high coverage.

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

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

The description explicitly states the tool's function with specific verbs and resources: 'Scan all images on a page' and lists exactly what it detects (oversized images, wrong formats, missing lazy loading, etc.). This clearly distinguishes it from sibling tools like analyze_css or analyze_javascript.

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 image optimization analysis but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or conditions. It is clear context but lacks guidance on prioritization.

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

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

With no annotations, the description carries full burden. It discloses that the tool uses Playwright JS coverage and finds specific script types and their load time impact. However, it does not explicitly state read-only nature or any side effects, though it is implied to be non-destructive.

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

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

The description is a single sentence that efficiently conveys the tool's purpose and key details. It is front-loaded with the main action and lists specifics, though slightly dense.

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 and no output schema, the description provides sufficient context about what the tool analyzes and the types of results. It lacks explicit output format details but is adequate for the tool's simplicity.

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

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

The schema covers 100% of parameters with a clear description for 'url'. The tool description does not add additional meaning beyond the schema for the parameter itself, thus baseline 3 applies.

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

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

The description clearly states the tool analyzes JavaScript using Playwright JS coverage, specifying exactly what it finds (unused JS, render-blocking scripts, large bundles, third-party scripts) and their impact on load time. This distinguishes it from sibling tools like analyze_css or analyze_html.

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 JavaScript performance analysis but does not provide explicit guidance on when to use this tool versus alternatives like analyze_css or analyze_images. 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?

Describes the components and output, but lacks details on side effects (e.g., network requests, external service calls) or required permissions. With no annotations, description carries the burden, and it provides only high-level transparency.

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

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

Single sentence effectively summarizes the tool's functionality, no redundant words, and is front-loaded with 'Full performance analysis'.

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 (multiple sub-analyses) and one required parameter, the description provides a clear overview of inputs and outputs. However, it could specify the structure of the returned prioritized list, especially since no output schema exists.

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

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

Schema coverage is 100% with a clear description for the URL parameter. Description adds no additional meaning 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?

Clearly states it performs a full performance analysis combining multiple tools (Lighthouse, PSI, headers, HTML, CMS) and returns prioritized improvements. Distinguishes from sibling tools that focus on individual 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?

Implies usage for comprehensive performance audit, but does not explicitly state when to use this versus individual tools like analyze_css or run_lighthouse. No exclusions or alternatives 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 provided; the description carries the burden. It implies network requests to the URL and generates rules, but does not explicitly state read-only nature, potential side effects, or performance considerations.

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?

One sentence with clear enumeration of capabilities and outputs. Efficient for the information conveyed, though slightly dense.

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 adequately indicates output types (rules, recommendations) but does not specify format or return structure. Lacks details on error handling or edge cases, but acceptable for a simple single-parameter tool.

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

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

Schema coverage is 100% for the single 'url' parameter. The description adds context about what the tool does with the URL, but does not enhance the parameter itself beyond the schema's 'URL to inspect'.

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

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

The description clearly states the tool detects Cloudflare and audits specific features (cache status, Brotli, HTTP/3, etc.) and generates rules/recommendations. It distinguishes itself from sibling tools like detect_cms or generate_cloudflare_rules by covering both audit and rule generation comprehensively.

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

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

No guidance on when to use this tool versus alternatives. It describes what it does but does not specify contexts where it is appropriate or when to prefer siblings like generate_cloudflare_rules.

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

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

With no annotations, the description carries full burden. It discloses output contents (Lighthouse scores, CWV, issues) but does not explicitly state the tool is read-only or non-destructive. The behavioral traits are partially addressed but lack explicit side-effect statements.

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

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

The description is two sentences, front-loaded with purpose, and succinctly lists what the delta report contains. Every sentence adds value with no wasted words.

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

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

The tool is simple (2 string params, no output schema), and the description fully explains inputs, purpose, and output contents. It provides sufficient contextual completeness for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description reinforces the requirement to pass JSON from analyze_website calls but does not add significant meaning beyond that. Baseline of 3 is appropriate.

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

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

The description clearly states the tool compares two analyze_website JSON reports and returns a delta report, specifying the resource and action. It distinguishes from siblings by explicitly linking to analyze_website output, making its unique purpose evident.

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

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

The description provides context on when to use the tool (comparing before/after a change) and prerequisites (passing raw JSON from two analyze_website calls). However, it does not explicitly mention when not to use or list alternatives, though the sibling tools are distinct.

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 of behavioral disclosure. It states it 'fingerprints' a website, which implies a read operation without side effects. However, it does not describe how it works (e.g., HTTP requests, response analysis), whether it has any rate limits, or what the output looks like. This 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 a single sentence that is front-loaded with the verb 'Fingerprint' and immediately specifies the objects. It is efficient, contains no unnecessary words, and every part adds value. The parenthetical list of examples is concise yet informative.

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

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

Given there is no output schema, the description should indicate what the tool returns (e.g., CMS name, version, platform). It does not, leaving the agent guessing about the response format. For a detection tool used as a precursor to more specific tools (like wordpress_inspector), this lack of output information is a significant gap.

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% coverage with a single parameter 'url' described as 'The URL to fingerprint'. The tool description adds no additional meaning beyond the schema's property description, so it does not improve understanding of the parameter's usage or constraints beyond what is already structured.

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: 'Fingerprint the CMS and hosting platform of a website'. It provides specific examples (WordPress, Shopify, Next.js, etc.) making the scope unambiguous. The tool is well-distinguished from siblings that analyze individual aspects (e.g., analyze_html) or focus on a single CMS (wordpress_inspector).

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 does not provide explicit guidance on when to use this tool versus alternatives. While the purpose implies it as a starting point for CMS identification, there is no mention of prerequisites, when to avoid it, or how it relates to sibling tools like wordpress_inspector. The usage context is only implicitly inferred from the tool name and sibling list.

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

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

No annotations are provided, placing the full burden on the description. The description does not disclose whether the tool modifies Cloudflare settings directly, requires authentication, has rate limits, or if it only outputs text. 'Generate' is ambiguous regarding 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 efficiently packs all key information: purpose, specific rule types, CMS awareness, and included features. No unnecessary words or repetition.

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

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

For a tool with one simple parameter and no output schema, the description covers the main deliverables and special features (CMS-aware bypass, security headers, static asset caching). However, it lacks details on output format or whether it requires authentication, which would be beneficial for completeness.

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

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

Schema coverage is 100%, and the description adds no additional meaning beyond the schema's parameter description ('URL of the site to generate rules for'). The description does not elaborate on URL format or constraints, so it meets the baseline but does not exceed it.

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 output: Cloudflare Cache Rules, Transform Rules, and recommended settings. It provides specific details such as CMS-aware bypass rules (WordPress, WooCommerce, Shopify), security headers, and static asset caching, which distinguishes it from sibling tools like generate_wp_rocket_config.

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 it is for generating Cloudflare rules for a domain but does not explicitly state when to use it versus alternatives. No exclusions or prerequisites are mentioned, though the context (e.g., CMS-aware rules) suggests it is best for sites using those CMS platforms.

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 carry the full burden. It states the output is a Markdown report and implies a read operation, but lacks details on potential side effects, authorization needs, or timeouts. The behavioral traits are partially disclosed but not comprehensive.

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

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

Two sentences, no wasted words. First sentence defines the tool, second gives usage context. Extremely concise and well-structured for quick parsing.

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

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

The description covers the output format and typical inclusions, which compensates for lack of output schema. However, it omits error behavior, execution duration, and any read-only hints. Given no annotations, more detail would improve completeness.

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

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

Schema coverage is 100% for the single 'url' parameter, which is already well-described in the schema. The description does not add any additional meaning or constraints 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 runs a full performance analysis and returns a Markdown report with specific metrics. It distinguishes itself from siblings by emphasizing a narrative summary vs. raw JSON, making the purpose and differentiation explicit.

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

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

The description provides explicit guidance: 'Use this when you need a shareable, narrative summary instead of raw JSON.' This helps the agent choose between this tool and siblings like run_lighthouse, though it does not explicitly mention when not to use it.

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

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

No annotations are provided, so the description must carry the full burden. It states it returns a JSON with rationale/warnings, but does not explicitly confirm it is read-only or disclose any side effects. This is adequate but could be more explicit about being non-destructive.

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

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

Two concise sentences with no wasted words. The first sentence states the action, and the second adds relevant details about considerations and output. Front-loaded and efficient.

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

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

Given the tool's simplicity (one param, no output schema), the description adequately covers what it does, what it accounts for, and the output format. It could slightly benefit from mentioning prerequisites (e.g., site must be accessible) but is otherwise 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?

Only one parameter (url) with schema coverage of 100% and a description that matches the schema's own description. The tool description adds no extra semantic meaning beyond what the schema already provides, warranting the baseline score.

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

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

The description clearly states the tool's purpose: analyze a WordPress site and generate recommended WP Rocket settings. It lists specific factors (page builders, WooCommerce, etc.) that differentiate it from sibling tools like analyze_css or analyze_fonts, which focus on individual aspects rather than producing a configuration.

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

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

The description implies the tool is for generating WP Rocket configs, but does not explicitly state when to use it versus sibling tools (e.g., for specific analyses like analyze_css or analyze_html). Lacks 'when not to use' guidance or alternative tool mentions.

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 transparently discloses that the data source depends on API key presence (real-user CrUX vs Lighthouse lab), which is beyond the tool name. It also lists the returned metrics, but could further detail permission requirements (e.g., API key setup) 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?

The description is two sentences with no wasted words. The first sentence immediately conveys the primary purpose and key differentiator (data source), and the second lists the output metrics. It is front-loaded and efficient.

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

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

For a tool with 2 simple parameters and no output schema, the description adequately covers the data source distinction and returned metrics. It does not describe the response structure, which would be helpful, but given the complexity level, it is fairly 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?

The input schema covers 100% of parameters with descriptions, so the description adds limited new parameter semantics. It reinforces the 'url' and 'strategy' parameters but does not provide additional detail beyond the schema. The baseline of 3 is appropriate given high schema coverage.

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

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

The description clearly states the tool fetches Core Web Vitals from Google PageSpeed Insights API, distinguishes between real-user CrUX data (when API key is set) and Lighthouse lab data, and lists the specific metrics (LCP, CLS, INP, FCP, TTFB). It is a specific verb+resource combination that differentiates it from siblings like run_lighthouse.

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

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

The description implies usage for fetching vitals and mentions the API key condition that switches between real-user and lab data. However, it does not explicitly state when to choose this tool over alternatives like run_lighthouse, detect_cms, or other performance tools, nor does it provide when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the full burden. It only lists what is returned but does not disclose behavioral traits such as audit duration, rate limits, required permissions, or whether the audit is run server-side or locally. This is insufficient for a tool that likely has performance and cost implications.

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 without unnecessary words. Every part contributes meaning.

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

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

For a simple two-parameter tool, the description covers the main purpose and outputs. However, given no output schema and no annotations, it could mention the structure of results or any side effects. The lack of behavioral context (e.g., potential delays) makes it merely adequate.

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

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

Schema description coverage is 100% with basic descriptions for both 'url' and 'strategy'. The description echoes the enum values ('mobile or desktop') but adds no extra semantic meaning beyond what the schema already provides.

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

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

The description clearly states the action ('Run a Lighthouse audit'), the resource ('a URL'), and the outputs ('scores, Core Web Vitals lab data, and improvement opportunities'). It distinguishes from sibling tools like get_core_web_vitals or analyze_website by specifying a full audit.

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

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

The description implies the tool is used for a comprehensive performance audit but lacks explicit guidance on when to prefer it over siblings like compare_performance or generate_report. No exclusions or conditions 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 is the only source. It discloses the tool detects plugins and provides recommendations with LCP impact, but doesn't detail side effects, auth needs, or rate limits. Transparency is adequate but not thorough.

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 that front-load the purpose and key details. The first sentence is slightly wordy but overall efficient. Minor improvement could be made to tighten the list of plugins.

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

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

Given the tool has one parameter and no output schema, the description adequately explains the tool's output (plugin detection, recommendations, LCP impact). It feels complete for the tool's simplicity.

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

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

Schema coverage for parameters is 100% (1 param: url). The schema already describes the parameter as 'URL of the WordPress site to inspect.' The description adds only the context that it's for WordPress, not additional parameter semantics beyond the schema.

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

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

The description clearly states it performs a 'Deep WordPress audit' detecting 20+ plugins and generating recommendations, which distinguishes it from sibling tools like detact_cms or analyze_website.

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 says 'Only useful on WordPress sites,' providing clear context for when to use it. However, it does not mention 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.