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

With no annotations, the description carries the burden and does well: it enumerates the full returned payload, notes the no-API-key/free constraint, and explains that pagespeed=true attaches PSI metrics with a local-engine fallback. It stops short of documenting error/rate-limit behavior or how the URL is fetched, so it is strong but not exhaustive.

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?

Front-loads the purpose and keeps the critical workflow instruction (ask the user, then call export_audit_pdf) as the final sentence. The long enumerative middle sentence is dense but each listed check conveys real capability, so waste is minimal.

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 or annotations exist, yet the description fully describes the return contents, the free/no-key constraint, the optional performance layer, and the downstream PDF handoff. An agent has everything needed to call it and to act on the result.

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 all five parameters, including local/detail/strategy. The description only reinforces the pagespeed flag and carries it forward into the PDF step ('same pagespeed/strategy'), adding workflow meaning but no syntax beyond the schema — the 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?

States a specific verb+resource ('Full on-page SEO audit of a URL') and enumerates exactly what is checked (title, meta, canonical, indexability, redirect chain, headings, links, structured data, issues, score). This clearly separates it from siblings like audit_site (site-level), pagespeed (performance-only), and check_robots (single concern).

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?

Gives clear operating context ('Free, no API key'), explains the pagespeed=true option to add PSI metrics, and prescribes a concrete follow-up workflow with export_audit_pdf. It does not, however, state when to prefer this over the sibling pagespeed tool or audit_site for whole-site scans, so exclusions are missing.

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 and does so well: it discloses that the operation is keyless (no auth), concurrency-limited (rate control), driven by sitemap discovery including sitemap-index resolution, and that PageSpeed is deliberately NOT run. It also describes the default response shape (compact, worst-first) and the cost tradeoff of detail=true.

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

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

Front-loaded with the core verb and scope, and every sentence carries information an agent needs (pipeline, defaults, exclusions, alternatives). It is a single dense paragraph with long clauses, which is slightly heavy but not padded.

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?

There is no output schema, so the description must describe returns, and it does: site-level aggregates, min/max/average score, pages with errors, site-wide gaps, issue rollup, and the per-page table. Combined with the default/detail distinction, an agent has everything needed to call and interpret this 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 already 100%, so the baseline is 3. The description adds real value beyond the schema for detail by explaining the payload-size rationale for keeping it false, though it says nothing about the 'max' parameter (default 50) beyond the schema's own 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?

The description opens with a precise verb+resource+scope: 'Site-wide on-page SEO audit' and then spells out the exact pipeline (sitemap discovery, per-page audit, site-level aggregates). It explicitly contrasts itself with audit_page, pagespeed, and export_site_pdf, so an agent can distinguish it from every relevant sibling.

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 names alternatives and the conditions that select them: 'Use audit_page or pagespeed for deep per-page performance, or export_site_pdf for a formatted report,' and it states when to set detail=true versus leaving it off. Both the routing decision and the parameter tradeoff are explicit.

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 behavioral burden. It discloses the output shape (user-agent groups, rules, sitemaps) but says nothing about failure modes (missing robots.txt), rate limits, redirect handling, or permission requirements.

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

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

One efficient sentence that front-loads the action and lists the returned fields without waste.

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?

Adequate for a simple single-parameter read tool, but with no annotations and no output schema, the description should disclose more about what happens when robots.txt is absent or how the response is structured.

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 single parameter 'url' is documented as 'Any URL on the site'. The description adds no parameter-level detail beyond the schema, so the baseline of 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?

States a specific verb (Fetch and parse) and resource (/robots.txt) and enumerates the returned content (user-agent groups, allow/disallow rules, sitemaps). Clearly distinguishable from siblings like check_sitemap and 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?

Usage is implied by the tool's nature (robots.txt retrieval) but there is no explicit when-to-use guidance or comparison to alternatives such as check_sitemap. The agent must infer 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?

With no annotations provided, the description carries the full burden. It discloses the output shape (index vs urlset, URL count, sample URLs), which is useful behavioral context, but says nothing about network behavior, fallback order when /sitemap.xml is absent, error cases, 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?

A single front-loaded sentence that states the action and immediately enumerates the returned artifacts, with no filler. Every clause 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 no output schema, the description does the work of explaining what comes back, which is the key need for this read tool. It stops short of covering failure modes (missing sitemap, robots.txt fallback behavior) or the size/format of the URL sample, leaving minor gaps.

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

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

There is a single parameter and schema description coverage is 100%, with the schema already explaining it accepts 'Any URL on the site'. The description adds no parameter-level meaning, so the baseline of 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 gives a specific verb ('Discover and summarize') plus the resource ('sitemap') and enumerates what is returned: index vs urlset, URL count, and sample URLs. It is clearly distinguishable from most siblings, though it does not explicitly contrast itself with the closely related check_robots, which it only mentions as a discovery route.

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?

Usage is implied by the context of the sibling audit tools (an agent would infer this is for inspecting a site's sitemap), but there is no explicit statement of when to call this versus check_robots or audit_site, and no preconditions such as what happens when no sitemap exists.

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 and does disclose the key side effects: it re-runs the audit (fresh network work) and writes a .pdf to disk, returning the file path. It omits overwrite behavior, latency expectations, and failure modes, which keeps it short of a 5.

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?

Purpose is front-loaded in the first clause, followed by side effects and then usage, so the agent can stop reading early. The parenthetical inventory of report sections is long but earns its place by telling the agent what the artifact contains.

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

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

No output schema exists, but the description states the return value (file path) and the write-to-disk behavior, and all five parameters are covered by the schema. A note on whether an existing file is overwritten would close the remaining 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 every parameter (url, path, detail, strategy, pagespeed) is already documented, and the enum on strategy is self-explanatory. The description adds report-content context that loosely maps to pagespeed/detail but no format or constraint detail 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?

States a specific verb (Generate) and resource (PDF report of an on-page SEO audit) and enumerates the report contents, so the agent knows exactly what artifact comes back. It also distinguishes scope from the sibling export_site_pdf by tying itself to a single URL 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?

"Use this after audit_page when the user asks for a PDF report" gives an explicit precondition and trigger. It does not, however, draw an exclusion against the sibling export_site_pdf, leaving the single-page vs site-wide routing 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 no annotations, the description carries the burden, and it does convey useful traits: this performs a site-wide crawl (implied network cost and latency, bounded by max), writes a file to disk (a side effect), and returns the path. It does not mention whether an existing file is overwritten, permission requirements, or how failures during the audit are surfaced.

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, front-loaded with the action, with the rest spent enumerating the report contents. The long parenthetical list is dense but each item is informative for judging the output; slightly overloaded for a single sentence.

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

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

No output schema exists, and the description compensates by describing both the artifact (PDF sections) and the return value (file path). Report contents and the primary return are covered; only failure/overwrite behavior is absent.

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 every parameter (url, max, path, details) is already documented in the schema; baseline 3 applies. The description adds only indirect context — the details flag maps to the 'full per-page details section' and the table ordering is 'worst-first' — without explaining parameter syntax 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?

States a concrete verb+resource — run a site-wide audit and write a multi-page PDF report — and enumerates the report's contents, so the agent knows exactly what artifact is produced. It does not, however, distinguish itself from the sibling export_audit_pdf, whose name implies a very similar 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?

There is no when-to-use, when-not-to-use, or prerequisite guidance. The presence of a closely named sibling (export_audit_pdf) makes the missing differentiation a real gap — the agent must open both schemas to decide which export tool to call.

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, and it does disclose meaningful behavior: it reports microdata itemtypes in addition to JSON-LD, and surfaces JSON-LD parse errors rather than failing on malformed markup. However, it says nothing about network fetching, read-only/safe nature, permissions, 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?

One sentence, front-loaded with the core action, with the enumerations placed in a parenthetical rather than padding the main clause. Every element earns its place and nothing is repeated.

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 single-parameter read tool with no output schema and no annotations, the description adequately conveys what comes back (types, itemtypes, errors). It stops just short of complete by not clarifying whether the page is fetched live or read from an existing audit result.

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 exists and schema description coverage is 100% ('Page URL'), so the schema fully documents it. The description adds no format, scope, or fetch-behavior detail beyond what the schema already states, making the baseline of 3 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?

States a precise verb ('Extract') and resource ('JSON-LD structured data from a page'), then enumerates the concrete outputs (schema.org @types, microdata itemtypes, parse errors). None of the siblings (audit_page, check_robots, pagespeed, etc.) touch structured data, so the agent can place it immediately.

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?

There is no statement of when to use this tool versus audit_page or the other audit siblings, and no prerequisites or exclusions are given. Usage is only inferable from the purpose itself, not from any routing guidance in the text.

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 usefully discloses the method (HEAD requests) and the failure criteria (4xx/5xx or unreachable), but omits operational details such as redirect handling, timeouts, auth needs, and whether the operation is purely 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?

A single, front-loaded sentence that states the action, method, and result criteria with no wasted words. It is appropriately sized for a simple two-parameter tool.

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

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

There is no output schema, so the description should explain what the report looks like. It conveys the semantic result (broken/unreachable links) but not the return structure, pagination, or how max affects truncation, leaving some gaps for an agent to infer.

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 both parameters (url and max) are fully documented in the schema. The description adds no syntax or format details beyond what the schema already provides, making the baseline score of 3 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?

States a specific verb and resource: check links on a page and report 4xx/5xx or unreachable ones. It is clear and actionable, but does not explicitly distinguish itself from the broader sibling audit_page or explain scope relative to other audit tools.

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

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

The description gives no when-to-use guidance, no exclusions, and does not name an alternative such as audit_page or pagespeed. An agent must infer the context from the purpose alone.

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 and does meaningfully discharge part of it: it discloses the underlying source (Google Suggest), the cost profile (free), and a hard output limitation (no search volume, related queries only). It omits rate limits, authentication needs, and result-set size, which are the remaining behavioral gaps.

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, front-loaded with the action and resource, with the clarifying constraints tucked into a compact parenthetical. Every clause earns its place.

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

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

For a two-parameter, no-output-schema tool this covers purpose, source, cost, and the key output caveat. The main omission is any hint about the shape or volume of returned ideas and whether 'lang' materially changes results, but nothing critical to invoking it correctly is missing.

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% and both parameters are documented there, so the description needn't restate them. It references the seed concept implicitly but adds no format or syntax detail (e.g., how to handle multi-word phrases), 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?

States a specific verb (Get) and resource (related keyword/query ideas) plus the data source (Google Suggest), which is exactly what an agent needs to know. It is unmistakably distinct from the sibling audit/robots/sitemap tools, so no sibling disambiguation is required.

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 parenthetical 'free; related queries only, no search volume' tells the agent when this is the right pick (a no-cost, related-term expansion) and implicitly when it is not (when search volume is needed). It stops short of naming an alternative tool for volume-bearing keyword data, so it is clear context rather than a full when/when-not routing rule.

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 behavioral burden and does so well: it discloses rate limiting, API-key requirements, automatic fallback behavior on quota exhaustion, that the local path requires Chrome on the host, that local runs headless Chrome silently, and that field (CrUX) data is only available via PSI. These are exactly the operational facts an agent needs before invoking.

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?

Outputs are front-loaded in the first sentence, followed by engine behavior and the local override, so the reader gets the what before the how. It is dense but every clause carries distinct information; the long parenthetical lists add bulk without much waste.

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

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

With no output schema, the description does useful work by naming the metrics returned and noting that detail=true expands to full category scores, diagnostics, and prioritized suggestions. Minor gap: it never states whether results are a single snapshot or if auditing multiple URLs requires the sibling audit_site.

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 four parameters are already documented in the schema, including the local flag's requirement for Chrome and its lab-only nature. The description largely restates that schema text, adding only the engine-selection framing rather than new parameter semantics. 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?

States a specific verb and resource ('Run Lighthouse') plus the exact outputs it produces: performance score 0-100, lab Core Web Vitals (LCP, CLS, TBT, FCP, Speed Index, TTI), and improvement opportunities. This distinguishes it from siblings like audit_page and audit_site, which are not described as Lighthouse/PSI runs.

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?

Gives clear context for the engine decision: default PSI adds CrUX field data but is rate-limited, set PAGESPEED_API_KEY to raise quota, auto-fallback to local on quota exhaustion, and set local=true to force local (no key/quota, needs Chrome, no field data). It does not, however, explain when to choose this tool over sibling audit_page/audit_site, so it stops short of full when/when-not/alternatives guidance.

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