whereamimentioned

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true and idempotentHint=false, so the safety profile is covered. The description adds what the analysis surfaces (severity-tagged findings, strengths, score, top fixes), which is useful behavioral context, but it omits how the page is obtained, whether live fetching or rate limits apply, and why the call is non-idempotent.

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 leads with the core action and then lists outputs compactly; no filler. The trailing list is dense but every item earns its place by telling the agent what comes back.

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 not be spelled out, yet the description does summarize them, which is a plus. However, for a tool that fetches an external page, key operational context (fetch behavior, failure modes on unreachable pages) is missing, leaving it only adequate rather than 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?

There is one parameter (url) with 0% schema description coverage, and the description only alludes to it as 'a page'. It adds no meaning about accepted URL forms, whether redirects or relative paths are handled, or whether the page must be publicly reachable — so it does not compensate for the schema gap.

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 and resource: 'Analyze how well a page is chunked for retrieval', and then enumerates the concrete artifacts produced (per-heading sections, word/token counts, severity findings, score, top fixes). This clearly separates it from the sibling tools (crawler access, meta description, llms.txt, sitemap, structured data), though it never names a sibling or states the boundary explicitly.

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 only implied by the phrase 'for retrieval' — an agent can infer this is a content/AEO readiness check, but there is no statement of when to reach for it versus validate_llms_txt or validate_structured_data, and no preconditions (e.g., page must be publicly fetchable).

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 readOnlyHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real value by disclosing the breadth of the crawler set and that each verdict comes with the exact rule and line that decided it, but it says nothing about failure modes such as a missing, unreachable, or unparseable robots.txt.

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 verb and outcome, then the coverage scope, then the evidence guarantee. Nothing is redundant or restated from the 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 and annotations covering safety, the description needs only to convey scope and intent, which it does. The remaining gap is edge-case behavior (no robots.txt, fetch errors), which matters for a network-dependent checker but is a minor omission.

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 0% for the single required `url` parameter, so the description must compensate. Saying "a site's robots.txt" implies the argument is a site root rather than an arbitrary page, but it never states whether a deep path is accepted or how redirects are handled, leaving a real ambiguity for the only input.

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 (check) and resource (a site's robots.txt rules for AI crawlers), and enumerates the crawler set (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, ~30 others). No sibling tool touches robots.txt, so an agent can route here unambiguously.

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 purpose: check crawler permissions for a site. There is no explicit when-to-use/when-not statement and no reference to the sibling tools (e.g. generate_llms_txt), so the agent must infer that this is the diagnostics step rather than a content-generation step.

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 readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds value by disclosing the analysis dimensions and outputs (pixel widths, desktop and mobile truncation, score, per-check findings), which tells an agent how deep the inspection goes. It does not mention crawl or fetch behavior, rate limits, timeouts, or what happens when the page cannot be retrieved — notable gaps for an open-world, non-idempotent read 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?

One dense, front-loaded sentence lists scope and outputs with no filler. It is appropriately sized for a single-purpose check and puts the analyzed fields first.

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 output schema exists, so the description need not explain return values, and it wisely only summarizes them. However, for an open-world read tool with a two-parameter schema at 0% description coverage, the definition is incomplete: it never explains what 'keyword' does or what the analysis requires to succeed. Adequate but with clear 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?

Schema description coverage is 0% and neither parameter appears in the description. The 'keyword' parameter is particularly non-obvious: it could check keyword inclusion in the meta description, highlight occurrences, or feed the scoring. That ambiguity is left entirely unresolved, which is a real gap when the schema documents nothing.

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 a specific verb ('Analyze') and specific resources (title, meta description, og:description, opening paragraph) and enumerates outputs (character and pixel widths, desktop/mobile truncation, score, per-check findings). It is clear on its own terms, but it does not distinguish itself from siblings that also inspect page content, such as validate_structured_data or analyze_content_chunking.

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 explicit when-to-use or when-not-to-use guidance, and no alternative tools are named. An agent must infer from the name and sibling list that this is the metadata-length check, which is a reasonable inference but not stated. No preconditions are given, such as whether the page must be crawlable or whether rendered or raw HTML is analyzed.

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 readOnlyHint=true, openWorldHint=true, destructiveHint=false and idempotentHint=false. The description adds real value beyond them by disclosing the crawl caps (30 pages for index, 20 for full), which tells the agent the tool silently truncates on large sites. It omits crawl time, rate limiting, and where the generated file goes, keeping it at a 4.

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, zero filler, and the core action is front-loaded before the depth-mode detail. Nothing repeats the title verbatim or wastes tokens.

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-value explanation is not needed, and annotations cover the safety profile. What remains thin is the two optional metadata parameters and any indication of cost or latency for the crawl, but for a read-only generator this is close to 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 0%, and the description compensates only partially: it fully explains the 'index' vs 'full' enum meanings and their page limits. siteName and description (with their 120/400 char caps) are never mentioned, so an agent gets no guidance on those beyond the raw schema constraints.

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 artifact: "Crawl a site and generate an llms.txt," and immediately distinguishes the two output modes. It never names the neighboring tools (generate_sitemap, validate_llms_txt), so the differentiation is by resource name only rather than explicit routing.

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 clarifies which depth value produces which artifact, which is a form of usage guidance, but it says nothing about when to pick this over generate_sitemap or validate_llms_txt, or when generation is inappropriate. Usage is implied by the task name 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?

Annotations already declare readOnly, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: a 200-page cap, sitemap-first discovery with a link-following fallback, and the guarantee that lastmod appears only when actually observed. That last detail is important because it tells the agent not to expect fabricated timestamps.

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 sentence, front-loaded with the verb and resource, with the limiting details packed into parentheses. Every clause carries information: page cap, crawl strategy, output format, and lastmod policy.

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-shape explanation is unnecessary. Given the tool's simplicity (one parameter), the description covers the behavior an agent needs: what gets crawled, how far, and how timestamps are handled. It lacks only guidance on when this tool is preferred over its siblings.

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 one parameter with 0% schema description coverage, so the schema only supplies name and a uri format. The description implies 'url' is the site to crawl, which is minimal but sufficient for a single obvious required parameter. No detail is given on URL normalization, subdirectory scoping, or whether the root domain is required.

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: crawl a site and return a sitemap.xml. The scope constraint (up to 200 pages) and strategy (sitemap-first with link-following fallback) sharpen it further. It does not explicitly contrast itself with siblings like generate_llms_txt, but the resource is distinctive enough that confusion is unlikely.

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 only implied: you'd use this when you need a sitemap for a site. There is no statement of prerequisites, no explicit when-not to use it, and no pointer to siblings such as check_ai_crawler_access or generate_llms_txt, which an agent might otherwise consider for site-audit-style tasks.

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 safety (readOnly, non-destructive) and open-world network access, yet the description adds real behavioral context: it fetches a remote file, resolves the URLs that file links to (implying additional outbound requests and latency), and probes for a sibling llms-full.txt. It does not say what happens when llms.txt is missing or unreachable (error vs. findings), which is the main remaining behavioral gap.

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 with the action first and the returned artifacts after; every clause names a distinct output, so nothing is filler despite the density.

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 enumerating return values is bonus rather than necessity, and the safety profile is carried by annotations. The definition is nearly complete for a one-parameter remote-check tool; only the failure mode for missing/unfetchable llms.txt is unaddressed.

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

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

With a single parameter at 0% schema description coverage, the description must clarify the url argument, and it only partly does: 'a site's llms.txt' hints at a site-level URL but leaves ambiguous whether the agent should pass a bare domain, a homepage URL, or the direct llms.txt URL. The uri format in the schema constrains type but not this choice.

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 validate') and resource ('a site's llms.txt'), and enumerates concrete outputs (findings with severity/line numbers, 0-100 score, counts, URL resolution, sibling llms-full.txt). This clearly separates it from generate_llms_txt, which produces rather than checks the file.

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 only implied by the verb 'validate' — there is no explicit when-to-use or when-not guidance, and no statement about prerequisites (e.g., whether the site must be publicly reachable or whether to run generate_llms_txt first). An agent can infer intent but not selection criteria against siblings.

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

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

Annotations already declare read-only, open-world, non-idempotent, non-destructive. The description adds real value beyond that: it discloses a network fetch of a live page, the nature of the output (severity per entity, entity counts, a score), and that microdata/RDFa are counted but not validated. Missing only failure modes (unreachable page, no JSON-LD present).

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

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

Two sentences, front-loaded with the core action and followed by the secondary output. The 'without validating them' qualifier earns its place by preventing a 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?

A single-parameter tool with an output schema, where the description covers action, scope, and exclusion clearly. It is only marginally short of complete for omitting what happens when the page is unreachable or contains no JSON-LD.

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 0% and the single 'url' parameter has no schema description, so the description must compensate. 'Fetch a page' implies url is the page to fetch and validate, which is the minimum needed, but it adds no format, scheme, or reachability constraints.

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 chain (fetch, validate, report) and resource (JSON-LD entities against schema.org types) with the exact output shape (per-entity findings with severity, counts, score). No sibling tool does this, and the description makes that scope unmistakable.

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 scope boundary is stated clearly ('also reports how many microdata and RDFa annotations are present, without validating them'), which tells an agent what this tool will NOT check. But there is no explicit when-to-use guidance, no prerequisites, and no named alternative among siblings.

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