stillindexed SEO checkers

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

Adds genuinely useful behavior beyond the annotations: invalid URLs degrade to per-row errors while HTTP status stays 200, result order is preserved, and each URL consumes one unit of a 60 fetches/hour budget. This is exactly the kind of cost/error context annotations cannot convey. It stops short of 5 because the shape of a successful per-URL result is never described.

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 short sentences, zero filler, and the batch scope is front-loaded. Every clause (order, error handling, rate budget) carries information an agent needs.

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 should cover return values; it does so partially by explaining per-row errors and order preservation, but never says what a successful row contains. Combined with the rate-budget disclosure, coverage is good but not 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 coverage is 100% and the single 'urls' parameter already documents 'Up to 20 http(s) URLs.' The description's 'up to 20' and 'one per URL' cost note mirror the schema's maxItems rather than adding new syntax or format meaning. Baseline 3 applies when the schema carries the load.

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: 'Indexability check for up to 20 URLs in one call.' The batch scope implicitly distinguishes it from stillindexed_check_url, but the sibling is never named, so an agent must infer the relationship rather than being told it.

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?

Batch capability is stated, which implies using this instead of the single-URL checker for multiple URLs, but there is no explicit when-to-use/when-not guidance and no mention of the alternatives among the eight sibling tools (check_url, check_domain, check_robots, etc.).

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, idempotent, non-destructive, openWorld), so the bar is lower, and the description still adds real behavior: the operation costs up to 5 fetches and performs an extra edge probe per AI search crawler. It does not mention caching or how repeated calls are deduplicated, but the load/network profile is disclosed, which is exactly the kind of context annotations cannot carry.

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 action and resource, then layered with the secondary probe behavior and the fetch cost. The closing pointer to the equivalent web tool is somewhat promotional but cheap and useful for parity checks; overall three sentences carry almost 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?

With no output schema, the description has to describe the return shape, and it does: per-crawler allowed/blocked status with the deciding group and rule named. Combined with the one fully documented input and the cost disclosure, an agent has everything needed to invoke correctly and interpret results.

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 with 100% schema description coverage, so the schema already explains that it accepts an absolute http(s) URL or a bare hostname (https assumed). The description adds no further parameter meaning beyond that, 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 (check robots.txt for the 13 tracked AI crawlers) and pins down the exact reporting granularity: per-crawler allow/block plus the deciding group and rule. It also adds a second capability (edge probing as OAI-SearchBot, Claude-SearchBot, PerplexityBot), which clearly distinguishes it from the generic robots/URL siblings without needing to name them.

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 rather than stated: an agent can infer this is the tool for AI-crawler access questions, and the cost note ('up to 5 fetches') helps with selecting a lighter sibling. But there is no explicit when-to-use guidance, no exclusions, and no pointer to stillindexed_check_robots or stillindexed_check_url for the non-AI case.

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 covered. The description adds real behavioral value beyond that: it names the underlying protocol (RDAP) and, importantly, discloses the failure mode for ccTLDs without RDAP — the tool reports the absence rather than fabricating an expiry, which directly shapes how an agent should interpret results.

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 tight sentences, correctly front-loaded with what the tool does, followed by the one caveat that changes interpretation of results. 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?

For a single-parameter, read-only lookup with no output schema and annotations covering the safety profile, the description covers the essentials plus the notable RDAP gap. It stops short of describing what a successful response contains (expiry date, registrar, status), which would fully close the loop.

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 and schema coverage is 100%, so the schema already explains that a full http(s) URL or a bare hostname (https assumed) is accepted. The description adds nothing about the input format, 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 resource (domain registration) and data source (RDAP), making it clearly about domain expiry rather than page/URL checks. It never names a sibling such as stillindexed_check_url or stillindexed_check_tls, so an agent must infer the boundary from the resource noun alone.

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 scope ('domain registration expiry'), but there is no explicit when-to-use statement, no mention of when a sibling is preferable, and no prerequisites. The ccTLD caveat is informative about outcomes, not about when to pick this tool.

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/openWorld/non-destructive, and the description adds substantial context on top: the 100-path cap, the full list of evaluated crawlers, the lint categories (unsupported fields, 500 KiB limit, BOM, HTTP status semantics), the diff-only output shape when 'proposed' is set, and a concrete cost disclosure ('Each sitemap fetch costs one unit of the hourly budget'). The rate-limit/budget statement is exactly the kind of behavior an agent cannot get from 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?

Purpose is front-loaded in sentence one, followed by input modes and then the return shape, so an agent can stop reading once it has what it needs. The paragraph is dense and packs several unrelated concerns (crawler list, lints, cost, diff behavior) into one block, but no sentence is wasted.

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 and five parameters, the description fully compensates by describing the return payload (per-crawler verdicts, deciding rule and line number, lint list, flipped-verdict-only changes) and the fetching behavior. An agent knows what it will get back and what each mode costs without inspecting anything else.

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 is already documented with its interaction rules (content vs url, proposed semantics, use_sitemap cost). The description largely restates those same rules rather than adding new meaning; the only marginal addition is 'up to 100, or use_sitemap to read them from the file's Sitemap line', which is already implied by the schema. Baseline 3 applies 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?

States a specific verb and resource ('Validate a robots.txt with RFC 9309 and Google's parsing rules') and enumerates the scope of the output: per-path verdicts for eleven named crawlers, the deciding rule and line number, and lints. The robots.txt focus is distinctive enough to separate it from most siblings, though it never explicitly contrast itself with stillindexed_check_ai_crawlers or stillindexed_crawler_diff, which overlap on the crawler-verdict angle.

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 explains invocation modes clearly ('Give url to fetch the live file, or content to test a pasted one, plus proposed to diff a second version'), which tells an agent how to drive the parameters. It gives no guidance on when to prefer this tool over stillindexed_check_ai_crawlers, stillindexed_crawler_diff or stillindexed_check_url, leaving the sibling selection 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?

Annotations already declare read-only, idempotent, open-world, and non-destructive, so the safety profile is covered. The description adds genuine value by disclosing what a call returns (status, XML validity, URL count) and the implicit /sitemap.xml fallback, which is not captured in the schema. It does not cover error behavior or nested sitemap indexes.

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, then the return payload. No filler or repetition of the tool name.

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, the description adequately covers both input (URL/hostname with fallback) and output (status, XML validity, URL count). Minor gaps remain around failure modes and sitemap-index handling, but nothing essential for a correct 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 coverage is 100% and the schema already explains the URL/hostname forms, so the baseline is 3. The description adds the fallback semantics ('or the host's /sitemap.xml'), which tells the agent the parameter can resolve to a default path beyond the literal 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 pair (fetch/report) and resource (sitemap), plus the concrete outputs: status, XML validity, and URL count. The resource name separates it from siblings like check_robots or check_tls, though no sibling is named 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?

No when-to-use guidance, no conditions for choosing this over stillindexed_check_url or stillindexed_check_robots, and no prerequisites. The only hint is the fallback to the host's /sitemap.xml, which is input behavior rather than usage 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 declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds the inspection targets, which is useful context, but says nothing about failure modes (expired cert, unreachable host) or how results are reported.

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 with no filler, front-loaded with the resource being examined and followed by the three result facets. Appropriately sized for a one-parameter read tool, though it offers no routing context to justify anything beyond the minimum.

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 usefully sketches the return shape (days remaining, chain validity, hostname match). However it omits what happens on connection failure or an invalid certificate, which an agent calling a network-dependent check would benefit from knowing.

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

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

Only one parameter (url) with 100% schema description coverage, so the schema already explains that http(s) URLs or bare hostnames are accepted. The description adds no further parameter meaning; 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 the resource precisely (TLS certificate for the host) and enumerates what is examined (days remaining, chain validity, hostname match), which cleanly separates it from siblings like check_domain or check_url. It lacks an explicit verb ('check') but the intent 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?

No statement of when to reach for this tool versus the other stillindexed checks, no exclusions, and no note that it targets TLS specifically rather than general domain health. Usage must be inferred entirely from the purpose sentence.

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, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description goes beyond them by disclosing the full inspection surface (redirect chain, meta robots, X-Robots-Tag, canonical, title, H1, indexability), which tells the agent what a fetch actually does. No mention of rate limits or auth needs, so not 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?

Two tight sentences with the core capability front-loaded. The trailing reference to the equivalent web tool is mildly extraneous but reinforces scope parity, so it earns its place only marginally.

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 compensates by enumerating the returned signal set, which is precisely what an agent needs to know before calling. The single required parameter is fully documented, leaving no material gap for this scope.

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 schema itself explains that hostnames imply https, so the schema carries the parameter burden. The description adds no format or syntax detail beyond what is already documented, making the baseline 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 ('Fetch one URL') and enumerates exactly what is inspected and returned. The word 'one' implicitly contrasts with stillindexed_bulk_check and check_domain, so an agent can route correctly without opening 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 single-URL framing implies this is for individual page inspection rather than bulk or domain-wide checks, but no when-to-use or when-not-to-use condition is stated and no sibling is named as an alternative. Usage is inferable but not 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: it performs four separate fetches (a cost/rate consideration) and reports the comparison dimensions.

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 front-loaded sentence covering the action, the four agents, and the compared fields, followed by a short cost caveat. 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?

For a single-parameter read tool with no output schema, the description tells the agent what will be compared (status, directives, content) and the fetch cost. Return formatting is unspecified, but nothing critical for correct invocation 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 the single url parameter is fully documented in the schema, including the hostname/https-assumed behavior. The description adds nothing further about the parameter, 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?

Names a specific verb and resource (fetch the same URL as four distinct user agents) and states exactly what is being compared: status, indexability directives, and content. This multi-agent comparison distinguishes it from single-check siblings like stillindexed_check_url or stillindexed_check_robots.

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 rather than stated: an agent can infer this is the tool to use when it wants to see how a URL renders across crawlers. The 'Costs 4 fetches' note softly signals it is heavier than single-fetch siblings, but no alternative or when-not-to-use condition is named.

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 readOnly, idempotent, non-destructive and open-world, and the description adds real value on top: an explicit cost of 6 fetches, the exact diagnostic sequence, the result vocabulary (ruled_out/suspect/confirmed/unknown) with evidence, and a pointer to the equivalent web tool. That is precisely the behavioral context an agent needs before spending fetches on an open-world call.

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 purpose, then the check list, the result shape, the cost, and the web equivalent. The parenthetical enumeration is dense but each item carries diagnostic meaning; nothing pads.

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 one-parameter, no-output-schema tool this is complete: the agent knows the trigger, what is inspected, what the result categories mean, what evidence accompanies them, and the fetch cost. No output schema is needed because the description names the return vocabulary.

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 url parameter is documented in the schema (absolute http(s) URL or hostname with https assumed). The description adds nothing about the parameter, so this is the baseline-3 case where the schema does all the work.

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 (triage) and resource (a domain that disappeared from Google) and enumerates the nine checks it performs in crawl-then-index order. This clearly distinguishes it from the single-check siblings like stillindexed_check_robots or stillindexed_check_tls: this one is the composite diagnostic.

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?

"Triage a domain that disappeared from Google" gives a clear triggering context, and the ordered list implies it supersedes running the individual checks one at a time. It never explicitly says when-not to use it or names the narrower siblings as alternatives, so it falls 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 already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior the annotations cannot: the aggregation scope and an explicit 'Up to 12 fetches' cost/bound, plus the return artifact (SKILL.md). It stops short of describing failure/partial-failure behavior.

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 action and return artifact; the upstream-fetch list is compact. The 'Up to 12 fetches' constraint and the generator link are both load-bearing. The first sentence is somewhat dense/run-on but wastes no 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?

No output schema exists, so the description must carry the return contract, and it does: a SKILL.md installable for that host, assembled from the listed fetches. The fetch budget is disclosed. What is missing is any hint of the SKILL.md's contents/structure or pagination/truncation behavior.

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 and schema coverage is 100% – the schema already explains that a hostname is accepted with https assumed and that an absolute http(s) URL works. The description adds nothing beyond that, so the baseline 3 for high-coverage schemas 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 ... then return a SKILL.md) and the resource (an installable skill for a host), and it enumerates the exact data it aggregates (robots.txt, sitemap, host variants, crawler diff, TLS). That enumeration maps closely onto the sibling check_* tools, so an agent can infer this is the composite generator, but the differentiation is left implicit rather than named.

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

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

The description implies usage by framing the output as a 'SKILL.md an agent can install for that host,' which tells you the scenario. It never says when to prefer this over the individual stillindexed_check_robots / check_sitemap / check_tls / crawler_diff siblings, nor when not to use it, so the guidance is only implied.

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 the sampling strategy (evenly across the file, up to 5 children of a sitemap index), the user agent used, that Googlebot-specific robots.txt blocking is checked, the canonicalization check, and the identical/future-dated lastmod reporting. It also discloses the separate rate-limit budget and expected duration, which are exactly the cost signals an agent needs before calling.

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 action and the input alternatives, then the sampling mechanics, then cost/rate limits. It is dense but nearly every clause carries operational meaning; the closing URL reference to the web tool is the one mildly expendable element.

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-only audit with no output schema, the description supplies everything the agent needs: valid inputs, what is examined, what findings are produced, how long it takes, and how it is rate-limited. No material gap remains.

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 schema already explains that a hostname is accepted with https assumed. The description adds value on top by explaining the consequence of passing a hostname — the robots.txt-declared sitemap is resolved — which tells the agent what actually gets audited in each case.

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 ('Audit a sitemap') and immediately defines scope: sampling up to 200 URLs, fetching with stillindexedbot, and the exact problem classes it flags. This is far more than a restatement of the name and lets an agent distinguish it from stillindexed_check_sitemap, which presumably only parses/validates rather than samples and fetches.

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 two accepted input modes (sitemap URL vs hostname, with robots.txt resolution) and gives operational context (90s runtime, 2 audits/IP/hour under a separate allowance). It stops short of naming when to prefer this over stillindexed_check_sitemap or stillindexed_bulk_check, so alternative-selection guidance is implied rather than explicit.

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