Adam Hale Tools: Web Research and Open Data

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), yet the description adds substantial operational context beyond them: $0.004 USDC pricing, the paid-only model, the exact failure shape (isError plus x402 v2 PaymentRequired object with amount/network/payTo/endpoint), the retry channel, the no-charge guarantees, and fetch-policy details (robots.txt, User-Agent, SSRF refusal). This is exactly the kind of behavior an agent cannot infer from 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?

Front-loaded with the core verb and resource, then dense semicolon-separated clauses that each carry real information (limits, exclusions, pricing, payment protocol, fetch policy). Slightly overloaded for a single paragraph, but almost nothing is 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 still conveys the return substance (Markdown output, 250k character ceiling, optional metadata block) and the failure modes, which is most of what an agent needs. It does not describe the success-response envelope itself, leaving a small gap for a tool whose result is delivered out-of-band.

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, but the description earns an extra point by explaining the x402_payment round-trip (what a PaymentRequired response looks like and how to resubmit the payload via params._meta) — semantics the schema only gestures at. It is silent on include_metadata's effect, which keeps it from a 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?

Specific verb (Convert) plus resource (document at a public URL) and an explicit scope: text-layer extraction into Markdown, with the full lattice of accepted formats enumerated. It stops short of naming sibling page_to_markdown, which is the natural alternative for plain HTML pages that also appear in this tool's format list, so the differentiation is inferential rather than explicit.

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

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

Gives clear when-it-works conditions (formats, 10 MB, 250k chars) and strong when-not conditions: not OCR, scanned PDFs, images, PPTX and encrypted files are refused. It does not route the agent to a specific alternative such as page_to_markdown, so it lands one notch below fully explicit 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 cover the safe-read profile (readOnly/idempotent/destructive false), and the description goes well beyond them: cost ($0.003 USDC per call), the x402 v2 PaymentRequired error shape, the exact retry path via params._meta["x402/payment"], and non-billing behavior for invalid or fully-failed calls. It also discloses crawler etiquette (robots.txt, User-Agent AdamHaleTools/1.0) and SSRF refusal of private/internal addresses.

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?

It is dense but front-loaded, leading with what the tool returns before the payment mechanics. Every sentence carries operational information, though the payment and fetching policies could be tightened slightly for readability.

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 must carry the return-shape burden — and it enumerates the returned field groups explicitly, along with error and billing semantics. An agent has everything needed to construct a call and interpret a failure.

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, but the description adds real value beyond the schema: the per-call cost, the multi-domain cap, and the full payment retry flow for x402_payment. The 'no registrant personal data' note also clarifies what the domain input will and will not yield.

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 exact resources returned — RDAP registrar/created/expires/status/nameservers/DNSSEC, DNS records (A, AAAA, MX, NS, TXT, CAA) and email setup (provider, SPF, DMARC). It also delineates scope with 'No registrant personal data,' which is exactly the boundary an agent needs. No sibling tool overlaps this domain-intelligence function, so it stands clearly apart.

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 establishes clear context (paid tier only, 1–3 domains per call, domains reduced from URL/email) and states the invalid-input/all-fail no-charge condition. It does not explicitly say when to prefer it over siblings like url_status_check or tech_stack_lookup, but none of them compete for this purpose, so the gap is minor.

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 declare the generic read-only/idempotent/open-world profile, yet the description discloses the paid x402 v2 flow in detail: cost per call, the PaymentRequired error shape, the exact retry path via params._meta['x402/payment'], and the rule that invalid or fully failed calls are never charged. It also adds robots.txt compliance, the User-Agent used, and private-address refusal — behavioral traits no annotation conveys.

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?

Single dense block that is front-loaded with the purpose and return shape before moving to constraints and payment mechanics; every sentence carries information. It is long, but the density is warranted rather than padded.

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

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

With no output schema, the description carries the return-value burden and does so fully (Markdown body plus title, description, language, canonical URL, word count), while also covering size limits, bot-wall limits, and payment failure semantics. Nothing an agent needs to call this 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, but the description meaningfully extends both params: the 3-URL paid cap and the payment retry contract for x402_payment (base64 signed payload, PAYMENT-SIGNATURE header, never a private key) supply operational context beyond the schema text.

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

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

States a specific verb and resource ('Read web pages... returns each page's main content as clean Markdown') and enumerates exactly what is stripped (navigation, scripts, ads) and what is kept. This clearly distinguishes it from the sibling document_to_markdown, which handles files rather than live URLs.

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 strong when-not guidance ('Does not get past bot walls', refuses private/internal addresses) and lays out the paid-tier condition and charge policy. It never names a sibling alternative such as document_to_markdown or url_status_check, so the agent must infer routing, but usable context is clearly present.

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 the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description goes well beyond them: pricing and per-call URL cap, the exact x402 v2 PaymentRequired error shape and retry path via params._meta['x402/payment'], the rule that invalid input and all-fail calls are never charged, the outbound User-Agent string, and the refusal of private/internal addresses. This is unusually rich behavioral disclosure.

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 purpose, and each subsequent clause adds distinct operational detail (agent defaults, pricing, error handling, fetch policy). It is a dense single paragraph whose payment clauses run together, so it is efficient but not maximally scannable.

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 carries the burden of explaining results, and it does list what is returned per agent/URL (permission, crawl-delay, sitemaps, llms.txt). It stops short of describing the response shape or ordering, so it is nearly but not fully 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%, so the schema already documents urls, agents, and x402_payment, making 3 the floor. The description adds value beyond it by listing the default agent set (GPTBot, ClaudeBot, etc.) that applies when 'agents' is omitted, and by pointing to params._meta['x402/payment'] as the preferred payment location.

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 precise verb+resource+scope: a 'crawl preflight' that checks whether each user agent may fetch each URL under robots.txt, with RFC 9309 longest-match and '*' fallback semantics spelled out. It is clearly distinguishable from siblings like url_status_check and sitemap_urls, and it enumerates the extra outputs (crawl-delay, listed sitemaps, /llms.txt presence).

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?

'Crawl preflight' frames the natural use case (run before crawling), and the payment tier rules (5 URLs per call, $0.001 USDC, when calls are/aren't charged) give concrete operating context. However, it never names a sibling it should be preferred over or states explicit when-not-to-use conditions, 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 (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint) are consistent, and the description adds far more: the x402 v2 payment protocol, the exact PaymentRequired fields returned, the retry mechanism via params._meta, and the rule that invalid input or all-items-failed calls are never charged. It also discloses crawler behavior (robots.txt compliance, User-Agent AdamHaleTools/1.0, refusal of private/internal addresses).

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?

Dense but front-loaded: the core purpose and input modes come first, then normalization, then pricing/payment. The long paragraph mixes pricing, protocol and crawling policy, which is slightly heavy, but every sentence carries substantive 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?

With no output schema, the description compensates by enumerating the normalized item fields (title, url, publishedAt, author, categories, summary) and the 100-item cap, plus the full payment/error contract. An agent has everything needed to call and interpret results correctly.

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

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

Schema description coverage is 100%, so the schema already documents both parameters including the bare-domain rule and the PaymentPayload format. The description largely restates these (bare domain handling, _meta payment path) without adding syntax or constraints 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?

Opens with a specific verb and resource ('Read news feeds or blogs as clean JSON') and names the exact input form and transformation (RSS 0.9x/2.0, RDF, Atom, JSON Feed to one item schema). It is unmistakably distinct from siblings like page_to_markdown, sitemap_urls and document_to_markdown.

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

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

Gives clear context: use for feeds or plain site URLs, with discovery via <link rel=alternate>, and lays out the free-vs-paid tier boundary (1 feed free, up to 5 feeds for $0.003 USDC). It never explicitly excludes or routes against sibling tools such as page_to_markdown for non-feed pages, so it stops 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 read-only, idempotent, open-world, non-destructive, but the description adds substantial behavior beyond that: the x402 payment flow, the isError + PaymentRequired object shape on unpaid calls, the retry path via params._meta["x402/payment"], the fact that invalid input and all-failed calls are never charged, robots.txt compliance, the User-Agent AdamHaleTools/1.0, and refusal of private/internal addresses. This is exactly the extra 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 audit scope, then pricing, then the error/payment protocol, then fetch policy — a logical ordering. It is dense and long, but nearly every sentence carries distinct operational information; only the enumeration of every check type could be trimmed.

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 must hint at returns; it says results come with machine-readable issue codes but does not describe the result structure for the URLs. Otherwise it fully covers limits, cost, failure modes, payment protocol, and fetch constraints, which is strong for a two-parameter tool.

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

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

Schema coverage is 100% and the schema itself documents URL format limits and the payment payload, so the baseline is 3. The description adds value by explaining the payment parameter's role in the retry loop (signed PaymentPayload returned in the x402 object, sent back via params._meta) and the URL-count cost tiers, giving semantics beyond the field definitions.

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 — an on-page SEO audit of web pages — and enumerates the checks it performs (title/meta lengths, canonical, robots/X-Robots-Tag, headings, hreflang, OG, Twitter card, JSON-LD). This clearly separates it from sibling tools like robots_txt_check, url_status_check, tech_stack_lookup and page_to_markdown.

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 operating conditions: free for 1 URL when the free web tool is enabled, up to 3 URLs per call for $0.004 USDC, and what happens on uncharged calls. It does not, however, name a sibling alternative or state when NOT to use this audit (e.g. single-URL vs sitemap-wide crawling), so the routing guidance is contextual rather than 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?

Goes far beyond annotations: details free tier limits (2,000 URLs/12 files), paid tier pricing (5,000 URLs/20 files for $0.004 USDC), payment error behavior (x402 v2 PaymentRequired object with fields), retry mechanism, charging rules (invalid input never charged), and fetch behavior (robots.txt respect, user-agent, private address refusal). Highly informative.

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

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

Front-loads purpose and discovery mechanism, then tiers, payment, and behaviors. Well-structured and dense with information, but slightly long. Every sentence adds value, though could be marginally tightened.

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?

Complete for a read-only extraction tool: covers discovery, tiers, payment flow, error handling, and fetch constraints. No output schema, but the description implies return format (URLs with lastmod). Annotations cover safety, and description adds extensive behavioral context.

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 description provides context about the url parameter (domain vs. sitemap file) and bulk (paid tier), but does not add syntax or format details beyond the schema. Baseline 3 is appropriate when 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 (list/extract) and resource (pages from sitemaps), and details how discovery works (robots.txt, common paths, sitemap indexes). Distinguishes from siblings like robots_txt_check and url_status_check by focusing on sitemap URL extraction with lastmod.

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?

Provides clear context: use by passing a domain to discover sitemaps or a specific sitemap URL. Describes free vs. paid tiers, when paid is needed (bulk=true), and error handling. However, does not explicitly compare to sibling tools (e.g., when to use this versus seo_meta_tags_check).

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, yet the description adds substantial extra behavior: rate limit (10 free calls/min per IP), pricing, the x402 v2 PaymentRequired error shape with retry path, robots.txt compliance, a fixed User-Agent, and refusal of private/internal addresses. This is well beyond what the structured fields convey.

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

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

Front-loads the purpose sentence before pricing and error mechanics, and every subsequent sentence carries operational weight. It is dense and long, but for a tool with a non-obvious payment protocol the length is largely earned rather than padding.

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 exact signal categories returned (CMS, frameworks, analytics, CDN, hosting, email/DNS, security grade) and fully documents the payment/error/retry flow, rate limits, and fetch constraints. An agent has everything needed to call it and interpret a failure.

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, but the description adds genuine meaning about the payment parameter — that a paid call needs a signed PaymentPayload and that params._meta["x402/payment"] is preferred over the x402_payment field. It also clarifies the free-vs-paid split on the domains array (1 free, 2-3 paid).

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

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

States a concrete verb ("Detect what a website is built with") plus an enumerated resource set (CMS, frameworks, analytics, CDN, hosting, email/DNS providers, security-header grade) and the mechanism (one fetch of the homepage). It clearly separates from siblings like url_status_check or seo_meta_tags_check by naming the exact data categories it returns.

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 explicit operating conditions: 1 domain is free, 2-3 domains is a paid call, invalid input and total-failure calls are never charged, and how to respond to a PaymentRequired error. It does not, however, compare itself to sibling tools (e.g. domain_intel) or state exclusions, so it falls short of a full when/when-not treatment.

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 (readOnly, openWorld, idempotent, non-destructive) only cover the safety profile; the description adds unusually rich behavior beyond them: pricing ($0.002 USDC), pagination ceiling (pages 1-50), the exact failure shape (isError with an x402 v2 PaymentRequired object in USDC atomic units), and the no-charge guarantees for invalid input or all-failed items. It also discloses network behavior (robots.txt compliance, User-Agent AdamHaleTools/1.0, refusal of private/internal addresses).

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 tight sentences, front-loaded with what the tool does, then tiering/pricing, then error-and-retry behavior, then fetch/safety policy. Despite covering an unusually large surface, there is no filler and each sentence carries decision-relevant 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?

With no output schema, the description still conveys result shape (25 newest free, 100 per page paid, newest first) and all failure modes, so an agent can call it correctly. The only gap is that the fields returned per notice are not described, which is a minor omission given the no-output-schema constraint.

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 q, bulk, page, country, open_only and x402_payment, which sets the baseline at 3. The description nonetheless adds meaning: it frames q as keyword search with the optional country and open-deadline filters, ties bulk/page to the paid tier, and explains the _meta["x402/payment"] delivery path for the payment parameter.

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 (Search) plus the resource (EU public procurement notices: tenders, contract notices, awards) and the data source (TED official API v3). This is unambiguous and clearly separable from every sibling, all of which are unrelated web/content utilities.

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 explains when the free path applies ('the 25 newest matches') versus the paid path ('bulk=true or page: 100 notices per page, pages 1-50') and how to recover from a payment failure via the signed PaymentPayload retry. It does not need to route to a sibling since none overlap, but it stops short of spelling out exclusion cases beyond the payment/error flow.

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 the description goes well beyond them: charging rules (invalid input and all-fail calls are never charged), robots.txt compliance, the User-Agent string, and refusal of private/internal addresses. This is unusually rich behavioral disclosure.

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 limits, format support and the payment gate, and every clause carries information. Some sentences run long and pack multiple ideas, but nothing is pure 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 paid, open-world fetch-and-transcribe tool with no output schema, the description covers inputs, cost, error/payment protocol, and safety constraints in enough depth that an agent can invoke it correctly.

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

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

Schema coverage is 100% and the description largely echoes the schema (formats, language, task=translate, payment location). It adds only marginal value, such as emphasizing the payload is never a private key, 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 and resource (transcribe one short audio file) plus the backing model, supported formats, size/duration limits, and the second mode (translate to English). No sibling tool does transcription, so the 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?

Explicitly excludes YouTube and social media pages, states 'Paid only' with the price, and spells out the failure path (isError + PaymentRequired object) and the retry condition. An agent knows exactly when this tool applies and how to proceed after a payment failure.

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, idempotent, open-world, non-destructive behavior, and the description still adds substantial context: HEAD-then-GET confirmation strategy, robots.txt compliance, the exact User-Agent used, refusal of private/internal addresses, and the charge/no-charge rules. This is exactly the beyond-annotations detail that helps an agent predict outcomes.

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 purpose and result vocabulary, then mechanics, then payment rules in a logical order. It is dense but nearly every clause carries information an agent needs (cost limits, retry path, no-charge conditions); only the User-Agent brand string is arguably gratuitous.

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

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

There is no output schema, so the description carries the full burden of describing returns, and it does: status, redirect chain, final URL, and the classification enum. It also covers the failure mode (isError + PaymentRequired object) and the remediation path, so an agent can handle both success and payment-required outcomes.

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

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

Schema description coverage is 100% and both parameters are already well documented in the schema (bare-domain semantics, size limits, x402 payload vs. private key warning). The description restates the _meta['x402/payment'] preference and the URL count cap but adds no new parameter-level meaning, 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?

Specific verb+resource ('Check whether links are alive') with an enumerated output contract: HTTP status, every redirect hop, final URL, and a classification vocabulary. This clearly separates it from siblings such as robots_txt_check, page_to_markdown, or website_screenshot, which do different things to a URL.

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

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

Gives clear operational context: free for 1 URL when the free web tool is enabled, up to 10 URLs per paid call, and an explicit retry path when a paid call is rejected. It does not, however, route the agent away from siblings (e.g., 'use robots_txt_check to inspect robots rules in detail' or 'use website_screenshot for visual capture'), so 5 is not warranted.

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?

Far exceeds the annotations: discloses a 10s/global rate limit, robots.txt and User-Agent behavior, private/internal address refusal, the paid flow, the exact x402 PaymentRequired error shape, the retry mechanism via params._meta['x402/payment'], and that invalid or all-failed calls are never charged. This is exactly the behavioral context an agent needs and annotations alone would not supply.

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 and every clause carries information (constraints, pricing, error contract), but the second half is a dense semicolon-joined run-on that could be trimmed or bulleted for faster scanning.

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 paid, network-fetching screenshot tool with no output schema, the description covers capability limits, payment/error semantics, rate limiting, and safety guarantees. An agent has everything needed to call it correctly, including how to handle the payment challenge.

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 goes further by explaining the payment parameter's role ('Prefer params._meta["x402/payment"]', 'Never a private key or seed phrase') and confirming the viewport dimensions tied to the device enum, adding meaning beyond the schema text.

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

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

States a specific verb and resource ('Screenshot one public web page in a headless browser') plus the output medium ('returned as an image'), which cleanly separates it from text-extraction siblings like page_to_markdown and from url_status_check. An agent can tell what it produces 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?

Gives clear operating context and exclusions ('Viewport only, no logins or scripts', 'does not get past bot walls', paid-only at $0.01/page), so an agent knows when the tool applies. It does not explicitly name an alternative sibling to use instead, 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.