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

Annotations already declare readOnly/openWorld/non-destructive/non-idempotent, and the description layers substantial additional context on top: execution happens in a real headless browser, results can come back asynchronously as 'running' with a runId, and there is a billing/auth model (caller's own APIFY_TOKEN, Apify pay-per-event, nothing charged by this server). It also discloses the tool's accuracy limitation, which an agent needs in order to interpret results responsibly.

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?

Four sentences, front-loaded with the action and then descending into output, limitations, and billing/auth. Each sentence carries distinct, non-redundant information and nothing repeats the schema or annotations.

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 an output schema present, the description needn't enumerate return fields, and it still summarizes them (score, impact counts, pages, code-level fixes, report link). Combined with disclosed auth/billing, async behavior, and scope limits, an agent has everything needed to call this correctly and interpret 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 every parameter including the enum on wcagLevel and the spend cap is already documented in structured form. The description adds no parameter-level detail beyond the schema (e.g. it never explains maxPages or maxCostUsd trade-offs), 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 and resource ('Crawls pages in a real browser and runs axe-core WCAG 2.2 checks'), names the conformance standards (WCAG 2.2 A/AA/AAA, EN 301 549, EAA) and what it returns. This is clearly distinguishable from siblings like full_website_audit or scan_speed_and_revenue, which address different audit dimensions.

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

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

The use context (accessibility/legal compliance auditing) is implied strongly, and there is a useful caveat that automated testing covers only a subset of WCAG issues and does not replace a manual audit. However, no sibling alternatives are named and no explicit when-to-use/when-not routing is given, e.g. versus full_website_audit or when to follow up with get_audit_results (only the schema hints at that).

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?

Beyond the readOnly/openWorld annotations, the description discloses that the scan runs in a real browser, uses three consent scenarios, returns a score/fixes/report link, requires the caller's APIFY_TOKEN, and is billed by Apify pay-per-event with no charge from this server. This adds important operational and cost context not captured by annotations alone.

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

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

The description is front-loaded with the core behavior and then supplies outputs, use cases, and billing context without filler. Despite being information-dense, every sentence contributes to selecting or correctly invoking the 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?

With annotations and an output schema available, the description covers purpose, use cases, external account requirements, and billing well. The main remaining gap is that async behavior and retrieval via get_audit_results are documented in the waitSecs schema field rather than the description, but the definition is still largely complete.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters in detail. The description reinforces the three-visit scenario behind full scan mode, but it does not add parameter-level meaning beyond the schema, such as guidance on maxCostUsd, waitSecs, locale, or internalPages.

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 verb and resource: it loads a site in a real browser three ways and audits consent/tracking behavior. It distinguishes itself from generic website-audit siblings by naming concrete outputs such as pre-consent tags, cookies, Consent Mode v2 signals, GA4/GTM issues, duplicate page_views, and missing conversions.

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 clearly says to use this for GDPR/UK GDPR/PECR/ePrivacy cookie compliance and for questions about why analytics data is wrong. It does not explicitly compare against siblings like full_website_audit or check_ai_search_readiness, so there is no when-not/alternatives guidance, but the intended context is clear.

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

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

Annotations already cover read-only/destructive/open-world, and the description adds genuinely new operational context: execution happens on the caller's own Apify account via APIFY_TOKEN, billing is pay-per-event through Apify, and the server itself charges nothing. It also discloses the async escape hatch (status 'running' plus a runId) rather than failing, which an agent must plan for.

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, both dense with information: the first front-loads scope, the second front-loads the cost/ownership model and the async fallback. No restatement of the title and no filler.

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

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

An output schema exists so return values needn't be spelled out, yet the description still summarizes them (readiness score plus prioritised fixes). Combined with billing, auth source, timeout behavior, and the follow-up tool reference, nothing essential for a correct first call 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%, so all four parameters — including the maxCostUsd spend cap and waitSecs timeout behavior — are already documented in the schema. The description adds billing framing but no parameter-level semantics beyond what the schema provides, so the baseline 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 ('Checks whether AI assistants and AI search engines can find, read and cite') plus the exact artifacts inspected (robots.txt for GPTBot/ClaudeBot/PerplexityBot/Google-Extended, llms.txt, schema.org, sitemap). This is clearly distinguishable from siblings like audit_accessibility_wcag or scan_speed_and_revenue without opening any 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 listed checks establish the use case clearly and the description routes the agent to get_audit_results when the wait window expires ('the scan keeps going; use get_audit_results'). It does not, however, say when to prefer this over overlapping siblings such as full_website_audit, so there is no explicit when-not guidance.

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

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

Annotations already establish read-only, non-destructive, open-world behavior, but the description adds important operational context: it runs on the caller's own Apify account via APIFY_TOKEN and incurs Apify pay-per-event billing. It also explains that the tool returns actionable findings with exact DNS records to add, going beyond the annotations.

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

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

The definition is front-loaded with what is checked, followed by outcome value and billing/auth context. Every sentence contributes distinct information, and the parenthetical lists are dense but not wasteful.

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

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

Given the rich input schema, existing output schema, and annotations, the description covers the remaining gaps an agent needs: domain scope, billing/auth implications, and the actionable spoofing/bulk-sender findings. Return-value and async wait behavior are handled by the schema and output schema rather than needing repetition here.

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

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

Schema coverage is 100%, so all four parameters are already well documented in the input schema, including examples and constraints. The description adds no parameter-specific syntax or format details beyond what the schema provides, 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 states a specific verb and resource: checking a domain's email authentication, deliverability, DNS hygiene, and TLS setup. It enumerates the exact checks (MX, SPF, DKIM, DMARC, BIMI, MTA-STS/TLS-RPT, DNSSEC, CAA, nameservers), making it clearly distinct from sibling website-audit tools.

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

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

The description implies when the tool is useful by naming spoofing risk and Gmail/Yahoo bulk-sender gaps, but it does not explicitly say when to use this versus siblings such as full_website_audit or scan_speed_and_revenue. There are no exclusions or explicit alternative-routing instructions.

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?

Beyond readOnlyHint/openWorldHint, it discloses cost behavior (Apify pay-per-event, capped per run), that blocked sites are not charged, that robots.txt is respected and bot protection is never bypassed, and that includeEvidence costs tokens. Those are exactly the operational facts an agent needs before spending money on a run.

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 capability statement is front-loaded and the paragraph is dense with operational facts rather than filler. The middle sentence enumerating output convenience fields is somewhat list-heavy, but it is scoped to a single paragraph and nothing is redundant.

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 an 11-parameter, open-world, billed scrapter-style tool, the description covers inputs, output shape (even though an output schema exists), cost, rate/blocking behavior, and the hard capability limit. An agent has everything needed to decide and call correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns a bump by explaining how onlySitesUsing/excludeSitesUsing combine to build filtered lists and by framing mode as a coverage-vs-cost choice. It still doesn't add syntax or interaction detail for checkDns/checkTls/minConfidence beyond what the schema states.

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?

Opens with a specific verb+resource ('Detects the technology stack of one or many websites') and immediately enumerates the exact signals used: homepage HTML, script/stylesheet URLs, headers, cookies, DNS records, TLS issuer, robots.txt. This is clearly distinguishable from siblings like check_domain_email_health or audit_tracking_consent, which cover narrower slices.

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 concrete when-to-use guidance for the mode tradeoff ('http' fast/cheap vs 'browser' catches tag-manager-injected tags) and a when-not statement: 'It analyses only the sites you pass; it cannot list every site using a technology.' It also shows a real filtering workflow ("Shopify stores not using Klaviyo"). It does not name any sibling tool as an alternative, which keeps it short of a 5.

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

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

Annotations only cover safety profile (readOnly, openWorld, non-idempotent, non-destructive); the description adds the behavior an agent actually needs: robots.txt obedience, no paywall/login/CAPTCHA bypass, noai/TDM opt-outs, terminal statuses 'blocked'/'paywalled' with a reason and no content, truncation via maxCharsPerPage, and billing on the caller's own Apify account capped per run.

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 output contract, then mode/billing/policy clauses in a logical order, with no filler sentences. It is a single dense paragraph, so the policy, mode, and billing concerns run together without visual separation; light grouping would improve scanability.

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

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

Despite an output schema, the description still summarizes the return shape and flags the two terminal statuses, which is the information an agent needs to branch on. Combined with per-mode guidance and billing/rate constraints, nothing needed to invoke 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 coverage is 100%, so the baseline is 3; the description earns above baseline by explaining cross-parameter intent — why to use chunk:true, how mode 'sitemap'/'crawl' interacts with maxPages and includeGlobs, and the trigger condition for rendering 'auto' — rather than restating field docs. It does not cover chunkSize/chunkOverlap/maxDepth/maxCharsPerPage semantics, which remain schema-only.

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 ('Fetches public web pages and returns their main content as clean Markdown') plus the exact payload produced (title, author, dates, outline, citation). No sibling tool does page fetching, so the distinction is inherent, and the boilerplate-stripping scope is unambiguous.

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

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

Names concrete use cases ('read, quote or summarise a page or load documentation') and gives conditional guidance for each mode: chunk:true for long pages, sitemap/crawl for multi-page sites, rendering 'auto' only if a page comes back nearly empty. It also states an explicit stop condition — blocked/paywalled pages must not be retried by other means.

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?

Goes well beyond the annotations: discloses that checks run in parallel, that partial results are returned if one check fails, that it starts one Apify run per check on the caller's own Apify account (pay-per-event), and that the scan keeps running when waitSecs expires. These are the operational facts an agent needs before spending money or deciding to poll.

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

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

Three sentences, front-loaded with what it does, then the routing hint, then failure-mode and billing behavior. No filler and no repetition of schema content.

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?

Output schema covers return shape, and the description supplies the remaining essentials: auth/billing model (caller's Apify account, pay-per-event), partial-failure semantics, and the async handoff to get_audit_results. Nothing an agent needs to call 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%, so every parameter (url, checks, device, maxPages, waitSecs, maxCostUsd) is already documented in the schema, including defaults, enums and caps. The description adds only indirect context about the cost cap being spread across runs per check; 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+resource (runs five named audit checks in parallel on one website) plus the merged output: overall score, executive summary, severity-ranked fix list. This clearly distinguishes it from the sibling single-check tools (audit_tracking_consent, scan_speed_and_revenue, etc.) and from get_audit_results.

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

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

Explicitly routes the agent: 'Best first call for "audit my website" or "what should I fix first"', and points to get_audit_results when waitSecs elapses with status 'running'. It doesn't state when to prefer the individual sibling checks instead of this aggregate, which is the only missing piece.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is settled. The description adds context beyond them: no new scan is started and there is no additional cost. Return shape is covered by the output schema, so nothing further is owed there.

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 filler. The core action and the runId key lead, with the 'does not start a new scan' caveat placed where it prevents misuse.

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 an output schema and rich annotations, the description need only cover scope and cost, which it does. The one hole is the near-duplicate sibling get_run_results, which an agent could easily pick instead.

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 the schema already explains that runId comes from an earlier result and that check selects the result parser. The description adds essentially no parameter detail beyond that, so 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?

The description uses a specific verb and resource ('Fetches the status and results of an audit run') and pins the lookup key to runId. It also rules out starting a new scan, which separates it from the audit_* / scan_* siblings. It does not distinguish itself from get_run_results, the closest 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 gives a concrete trigger: use when a run was still 'running' when its launching tool returned, or for any earlier run. The negative case ('Does not start a new scan') is stated outright. It omits any routing guidance versus get_run_results.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world. The description adds genuinely non-obvious context: it does not initiate work and incurs no additional cost, which matters for agent retry/polling decisions. It omits what happens if the run is still incomplete at fetch time and any rate-limit guidance.

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 compact sentence pair that front-loads the core action and follows with the cost/scope reassurance. No filler, nothing redundant with the title.

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?

An output schema exists so return values need no explanation, and the description covers the trigger, scope, and cost profile for a 2-parameter read tool. The one gap is behavior when the run has not finished yet — retry/polling expectations — which an agent polling this tool would want.

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 both parameters documented and the tool enum fully specified. The description only restates 'by runId and tool name', adding no format, sourcing, or enum semantics beyond the schema, so 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 (fetches) and resource (status and results of a run), plus the precise scope: runs that were still 'running' when a data tool returned. This clearly separates it from the run-producing siblings like detect_tech_stack and monitor_website_changes, which the description implicitly contrasts by naming the runId/tool pair.

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 an explicit trigger condition — use it when a data tool returned with a still-'running' status — and a clear negative boundary: it does not start a new run. It stops short of naming the sibling tools that would start a run or giving polling cadence, but the when/when-not framing is solid.

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

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

Given readOnlyHint=false and idempotentHint=false, the description explains exactly why: it writes a private snapshot to the caller's Apify storage ('nothing on the target site changes'), runs on the caller's own Apify account with pay-per-event billing capped per run, and non-idempotency comes from baseline/diff semantics. It additionally discloses that blocked pages are not charged and that dates/UUIDs/copyright years are ignored by default to suppress false positives.

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, then output shape, then the baseline/state workflow, then constraints and billing. The single-dense-paragraph format and the mid-sentence catalog of detection types partly duplicate schema descriptions, which costs a point but does not bury the critical 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?

Despite 18 parameters, an output schema, and stateful cross-call behavior, an agent has everything needed to call it correctly: required urls, baseline semantics, state reuse, cost multiplier, false-positive mitigations, and billing model. Return fields are covered by the output schema, and the description's summary of them is a bonus rather than a 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 coverage is 100%, so the schema already carries the per-parameter text. The description still adds workflow-level meaning the schema cannot: stateStoreName must be reused across calls for comparisons, mode costs 3x in browser, and ignorePatterns/excludeSelectors exist specifically to suppress false changes. Some enumeration (prices, keywords, seoChecks, sitemap) largely restates schema properties, so it is not a full 5.

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?

Opens with a specific verb+resource: 'Checks web pages for uptime and for changes since the last check,' which cleanly separates it from siblings like full_website_audit (one-off audits) and fetch_clean_markdown (content retrieval). The enumerations that follow (uptime, diff, price/keyword/SEO change detection) confirm the scope without ambiguity.

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?

Explains the stateful workflow explicitly: the first call returns 'baseline' and later calls must reuse the same stateStoreName, and resetBaseline discards the snapshot. It also flags cost tradeoffs (browser mode 3x) and robots.txt blocking. It stops short of naming sibling tools or stating when not to use this versus a full audit, so not a 5.

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

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

Annotations already declare readOnly/openWorld/non-idempotent/non-destructive, and the description adds genuinely non-redundant context: it runs on the caller's own Apify account via APIFY_TOKEN, is billed pay-per-event by Apify with nothing charged by this server, and returns a score, metrics, prioritised fixes and a full-report link. That cost and auth disclosure is exactly the kind of behavior an agent can't get from the structured fields.

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

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

Three sentences, front-loaded with what is measured, then the conditional revenue feature, then the operational/cost caveat. Dense but every clause carries weight; the enumeration of metrics and bottleneck types is slightly list-heavy but justified by 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?

With 9 parameters, an output schema and annotations present, the description covers the remaining gaps an agent needs: billing/account model, auth token requirement, the conditional revenue-estimate inputs, and a summary of return contents. Nothing material for correct invocation appears 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%, so the schema itself documents url, device, currency, maxPages, waitSecs, maxCostUsd and the three revenue inputs. The description only loosely links monthlyVisitors/averageOrderValue (and implicitly conversionRatePct) to the revenue estimate, adding little beyond what the schema already states — baseline 3.

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

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

The description names the specific resource and metrics (Core Web Vitals — LCP, INP, CLS, TTFB — page weight, bottleneck categories) and the revenue-loss estimate, which clearly separates it from sibling audits like audit_accessibility_wcag, audit_tracking_consent and detect_tech_stack. It stops short of naming any sibling explicitly, so 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?

It explains the conditional enrichment path ('if you give traffic and order value, estimates monthly revenue lost'), which is genuine usage guidance, and the schema covers the async 'running'/runId fallback to get_audit_results. But there is no explicit statement of when to pick this over full_website_audit or the other audit siblings, so an agent must infer the choice from scope alone.

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