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

With no annotations, the description carries the full burden. It mentions using an external API and local heuristics, but does not disclose side effects, read-only status, rate limits, or behavior when url or html are missing. It also fails to explain what happens if both or neither are provided, leaving critical behavioral ambiguity.

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, efficient sentence that front-loads the core purpose. Every word contributes to the definition without redundancy or fluff.

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

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

The tool is complex with four optional parameters and no output schema or annotations. The description does not clarify whether url or html is required, how results are returned, or what the impact of missing inputs is. This leaves significant gaps for an agent to call 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 description coverage is 100%, so all parameters are already documented. The description adds no extra meaning about parameter usage or constraints beyond the schema, so it stays at the baseline 3 for 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 audits CLS and Core Web Vitals via Google Lighthouse/PageSpeed API and local heuristics. It names specific metrics and methods, making the purpose distinct from general audit tools. However, it does not explicitly differentiate from comprehensive_seo_audit or audit_technical_seo, so a 4 rather than 5.

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 is provided on when to use this tool versus its siblings. It does not mention alternatives, prerequisites, or conditions that would make it the preferred choice. The agent is left to infer usage based solely on the description.

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 what the tool audits but not how it behaves: whether it fetches the live URL, what happens if both url and html are provided, whether the operation is read-only, or how errors are handled. For an auditing tool this is a meaningful gap in transparency.

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

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

The description is a single, dense sentence that front-loads the tool's purpose and uses a colon to introduce a compact, well-separated list of audit areas. There is no fluff, repetition, or wasted wording; every element contributes to understanding the tool's scope.

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

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

For a multi-faceted audit tool with no annotations and no output schema, the description is incomplete. It does not explain what the tool returns, whether url and html are mutually exclusive or complementary, or whether at least one of them is required despite the schema listing zero required parameters. This leaves an agent uncertain how to 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 every parameter. The description adds some context by listing the audit categories but does not clarify the relationship between url and html, which one is preferred, or how optional content parameters are combined. 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 ('Audits') and a clear resource ('Technical SEO foundations'), then enumerates exactly what is checked: H1-H6 hierarchy, Schema.org JSON-LD, robots.txt, sitemap.xml, and text-to-HTML ratio. This concrete list distinguishes it from siblings like extract_human_intent_keywords or audit_lighthouse_cls_vitals without needing to open the schema.

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 intended use is implied clearly: use this when you need a technical SEO foundation audit. However, it gives no explicit guidance about when to prefer it over comprehensive_seo_audit or scan_onpage_seo, nor does it state any exclusions or alternative conditions. The domain is clear, but routing among overlapping siblings is left to inference.

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 zero annotations provided, the description carries the full burden of behavioral disclosure. It does state the output nature ('a single prioritized report with scores and action steps'), but for a composite tool that aggregates four separate audits it omits critical behaviors: runtime/performance cost, the fact that it performs multiple underlying calls, offline-vs-live execution requirements, and the implications of the optional PageSpeed API key (quota/cost). These gaps are significant for such a heavy 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 core purpose is front-loaded ('all-in-one comprehensive SEO audit'), which is good, and every component listed earns its place. However, it is a single dense run-on sentence that crams six component lists plus the output format into one clause, making it harder to parse than a structured two-sentence breakdown would be. Efficient but not optimally structured.

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?

This is a complex composite tool (5 parameters, 4 underlying audits, no annotations, no output schema), and the one-sentence description is insufficient. It touches on the return value ('prioritized report with scores and action steps') but leaves critical context unstated: how prioritization/scoring works, expected runtime, failure modes when the URL is not live, and whether html and url are alternatives or combinable. For a tool this heavy, the description must compensate for the missing annotations and output schema.

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

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

Schema coverage is 100%, so the schema already documents all five parameters well ('Live web page URL to audit,' 'Raw HTML markup string to audit offline,' etc.). The description adds marginal linking context—Human Intent Keywords maps to targetKeyword and Lighthouse CLS maps to strategy—but does not add syntax or format detail beyond what the schema provides. Baseline 3 is appropriate when the schema 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 opens with a specific verb and resource ('Runs an all-in-one comprehensive SEO audit') and enumerates every component: On-Page metadata, Open Graph/Twitter, Image Alt, Lighthouse CLS & Core Web Vitals, Technical Schema/Headings, and Human Intent Keywords. This clearly differentiates it from the individual sibling tools (scan_onpage_seo, audit_lighthouse_cls_vitals, audit_technical_seo, extract_human_intent_keywords) as the combined superset.

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 'all-in-one' framing implies the use case: run this when you want the full combined audit in a single pass. However, the description never explicitly states when NOT to use it or names the sibling alternatives as the targeted option for single-dimension checks. The routing is implied by contrast with siblings rather than stated.

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 carry the behavioral disclosure burden. It lists several analysis actions but does not specify side effects, input requirements (e.g., whether at least one of url/html/text is needed), or output format. It is a read-only analysis tool by nature, but that is not explicitly stated.

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 sentence that front-loads the primary purpose and then lists supporting functions. It is efficient with no filler, though the long clause list makes it a bit heavy. Still, every phrase adds 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?

The description covers the tool's high-level capabilities but omits practical details such as how to choose among url/html/text inputs, whether inputs are mutually exclusive, and what the output structure looks like (no output schema exists). For a multi-function tool, this is a moderate 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?

Schema description coverage is 100%, so parameters are already documented. The description adds context that the tool works on content and classifies intent, which helps interpret the parameters, but it does not elaborate on each parameter 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 states a specific action ('Extracts Human Search Intent Keywords from content') and enumerates distinct functions (classification, query synthesis, question mining, slop detection). It clearly differentiates from sibling audit tools, which focus on technical/on-page checks rather than content intent 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 makes the tool's purpose clear, so an agent can infer it is for content analysis rather than technical audits, but it does not explicitly state when to use it versus alternatives, nor does it mention any conditions or exclusions. The intended context is implied, not stated.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool fetches a live URL or audits offline HTML, and mentions CLS checks for images. However, it doesn't disclose potential side effects like network requests, rate limits, or whether the tool modifies anything. Since it's a scan/audit tool, the read-only nature is implied but not explicitly stated. The description adds some behavioral context (CLS checks) but could be more transparent about fetch behavior and limitations.

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

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

The description is a single, well-structured sentence that front-loads the core purpose and then lists the specific elements checked. It's concise and informative without redundancy. The only minor issue is that the list of elements is long, but it's necessary for clarity. 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 has no output schema, so the description should ideally hint at what the scan returns. It doesn't describe the output format or how results are structured. Given the tool's moderate complexity (multiple SEO elements checked), an agent might need to know if results are a report, scores, or raw data. The description is adequate for understanding what the tool does but incomplete for predicting the return value. Sibling tools like audit_lighthouse_cls_vitals suggest a broader audit context, but this tool's standalone completeness is moderate.

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 ('url' and 'html'). The description adds context by explaining that 'url' is for live pages and 'html' is for offline auditing, which aligns with the schema. However, it doesn't add details about parameter constraints, mutual exclusivity, or what happens if both are provided. Baseline 3 is appropriate since the schema 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's function with a specific verb ('Scans') and resource ('On-Page SEO elements from a live URL or HTML string'), and enumerates the specific elements it checks (Meta title, Meta description, Open Graph, Twitter Cards, Canonical, Image Alt). This distinguishes it from sibling tools like audit_technical_seo or comprehensive_seo_audit, which are broader in scope.

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

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

The description explicitly provides two usage modes: 'live URL' or 'HTML string', which tells an agent when to use each input. It doesn't explicitly state when not to use this tool versus siblings, but the specific focus on on-page elements implies it's for targeted on-page audits rather than broader audits. The lack of explicit exclusions or alternatives is a minor gap.

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