AgentKit x402 - pay-per-call tools for agents

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description is consistent with a safe read. Beyond that, it discloses meaningful domain behavior the annotations cannot: which days are excluded (weekends, public holidays, midsommarafton, julafton, nyarsafton) and what the return payload contains.

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

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

Three tightly packed sentences, front-loaded with the core operation and immediately followed by the mode variant and the return summary. No filler, though the parenthetical holiday list is dense enough that it slightly taxes 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 compensates by summarizing the return value (result date with weekday, ISO week, and holiday names for both dates). Combined with full parameter coverage and the mode explanation, an agent has everything needed to call and interpret this tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real meaning beyond the enum labels by defining mode=work as 'counts only weekends and red days', clarifying how it differs from the default. The 'add' sign/max semantics are left to the schema, which already documents them.

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 (adds/subtracts) plus the exact resource (Swedish bank days) and the input it operates on (a date). The definition is unambiguous and, unlike every sibling tool (dns, email, iban, url, etc.), covers a distinct domain so there is no risk of confusion.

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

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

It explains the two operating modes (default 'bank' vs mode=work) and what each counts, giving the agent clear context for when each applies. It does not give explicit when-not-to-use guidance, but no sibling tool offers an overlapping capability, so that omission 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 already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully adds that the output is 'static' (a canned sample rather than live data), which is genuine behavioral context, but it omits whether it counts against quotas or is rate-limited.

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 short sentences, front-loaded with the tool's nature and followed immediately by the one input instruction. No wasted words, though terseness is approaching under-specification rather than tight editing.

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 carry more about what the sample output contains or its format, since previewing output is the tool's whole point. It covers the input concept adequately for a 1-param tool but leaves the return shape entirely unspecified.

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 required 'slug' param is an undocumented enum of 10 values. The phrase 'paid route slug' adds the key meaning that each enum value maps to a paid route, but the individual slugs (e.g. 'se-validate', 'url-markdown') carry no explanation beyond what sibling names hint at.

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 the tool returns a 'static sample output' and takes a 'paid route slug', so the resource is identifiable but the verb is implicit and 'demo' gives no standalone signal. It loosely distinguishes itself as the free preview counterpart to the paid route tools, but an agent must infer that 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?

'Free static sample output. Pass a paid route slug' implies usage (call this to preview a route's output without paying), and the 'paid' qualifier hints at the sibling pricing tools. However, it never explicitly says when to prefer this over the real sibling tool or what happens after previewing, leaving usage 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 cover the safety profile (readOnlyHint, openWorldHint), and the description adds real context beyond them: the DNS-over-HTTPS transport, TTL inclusion, DNSSEC presence via DNSKEY/DS, and the resolver validation flag. It does not mention rate limits or failure behavior (e.g. NXDOMAIN handling), which keeps it short of a 5.

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

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

Two tight sentences, front-loaded with the capability and record types before the audience note. The final 'for domain research, due diligence and infrastructure agents' phrase is mild positioning rather than load-bearing information, but nothing is redundant or bloated.

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

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

With no output schema, the description does the work of describing returns by naming record types, TTLs and DNSSEC artifacts, which is sufficient for a single-parameter lookup. Error cases (nonexistent domain, timeout) are the only notable 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?

Only one parameter exists and schema coverage is 100%, with the schema already documenting 'Domain name without scheme.' The description adds no syntax, IDN, or subdomain guidance beyond that, so this is the baseline case where the schema carries the meaning.

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 (DNS lookup) and resource (a domain's DNS records), and enumerates exactly what is returned: A, AAAA, NS, MX, TXT, CAA, SOA, CNAME with TTLs, plus DNSSEC (DNSKEY, DS) and the resolver validation flag. No sibling tool overlaps this capability, so an agent can select it 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?

The closing clause 'for domain research, due diligence and infrastructure agents' implies when the tool is useful, but there is no explicit when-to-use rule, no prerequisites, and no named alternative or exclusion relative to siblings like email_auth or site_audit. Usage is inferred 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 readOnlyHint and openWorldHint, and the description adds meaningful operational context beyond them: it is DNS-based, it does not expand nested SPF includes, and it returns prioritised findings with fix hints and a 0-100 score. It does not discuss rate limits, cache/TTL behavior, or failure modes, so it falls short of a 5.

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

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

A single dense sentence front-loads the purpose and then packs the parsed record types, return shape, and the include-expansion limitation without filler. It is long, but every clause carries distinct 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 compensates by stating the return shape (prioritised findings, fix hints, 0-100 score) and the key limitation (nested includes not expanded). For a read-only, one-parameter audit tool, nothing an agent needs in order to call it correctly is missing.

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

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

Schema description coverage is 100% and there is only one parameter, so the baseline is 3. The description adds nothing about the domain argument (e.g. apex vs subdomain, IDN handling) beyond what the schema already states.

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

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

The description uses a specific verb+resource pair ("Email deliverability and spoofing-protection audit for a domain") and then enumerates exactly what is parsed (SPF mechanisms, DMARC policy, DKIM selectors, MX, BIMI, MTA-STS, TLS-RPT), which clearly separates it from siblings like domain_dns or email_check.

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?

Scope is implied through the content list and the note that nested SPF includes are not expanded, but there is no explicit when-to-use statement and no routing to alternatives (e.g. domain_dns for raw records or email_check for mailbox validation). The agent must infer the boundary from the sibling names.

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 carry readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely useful behavior beyond that: the negative guarantee that no SMTP probing occurs and mailbox existence is unverified, plus the discrete verdict vocabulary. It does not discuss rate limits or DNS lookup failure modes.

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, then the check list, then the return contract, then the key limitation. Dense and mostly functional, though the long enumeration sentence could be tightened; every clause still carries 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?

No output schema exists, so the description carries the return-value burden and does so by naming all four verdicts and the score range. Combined with the explicit non-coverage of SMTP probing, an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100% and there is a single required 'email' parameter, so the schema fully documents input semantics. The description adds no format details (single address vs list, normalization) beyond the schema, so baseline 3 applies.

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

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

States a specific verb (verify) and resource (email address) and enumerates exactly which checks run: syntax, disposable-domain, role-account, free-provider flag, typo suggestion, and DNS MX/A. The return contract (valid/risky/invalid/unknown plus 0-100 score) is specified, so an agent knows precisely what this tool produces.

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?

Frames the intended context ('AI agents and lead-qualification pipelines') and explicitly rules out an important alternative method: 'No SMTP probing, so mailbox existence is not confirmed.' That exclusion tells the agent when this tool is insufficient. It stops short of naming a sibling or stating when to prefer e.g. email_auth for SPF/DKIM/DMARC, so no explicit alternative routing.

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 and openWorldHint, so the safety profile is covered. The description still adds real value: the validation is offline against a bundled country table, output is normalised/formatted, and account existence is explicitly not verified.

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 leading with the verb and resource, with each clause (length table, checksum, output form, BBAN, limitation) carrying distinct information. 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, no-output-schema tool, the description covers the validation semantics, output normalisation, and the key limitation. It stops short of describing the actual return shape or failure behavior, but is largely sufficient.

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 description coverage is 100% ('IBAN, spaces allowed'). The description adds nothing about the iban argument beyond the schema, so the baseline 3 for full schema coverage 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 ('IBAN validation') and enumerates the exact checks performed (country length, mod-97 checksum, BBAN/check digits). An agent can distinguish it from siblings like se_validate or se_account_to_iban, though it never names or routes to 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?

Gives one explicit exclusion ('Does not check that the account exists'), which is genuinely useful scope-setting, but offers no when-to-use framing or alternatives (e.g. se_account_to_iban for conversion). Usage is implied 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 readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely useful context that the lookup is free and that it also surfaces x402 payment instructions, but it says nothing about authentication, rate limits, or how the pricing data is scoped.

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 no filler; the core resource (price table) leads and the secondary payload (payment instructions) follows.

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 describing the return value, and it only gestures at a 'price table' and 'x402 payment instructions' without indicating what is priced or the shape of the response. 'x402' is niche jargon an agent may not resolve, leaving a real gap for a tool whose entire value is its output.

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?

The tool takes zero parameters, so the baseline is 4 and there is no parameter semantics for the description to compensate for. It correctly avoids inventing parameters that do not exist.

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 concrete resource ('price table') and an additional payload ('x402 payment instructions'), so an agent can tell what the tool returns. It lacks an explicit verb (get/retrieve), but none of the siblings (bank_days, domain_dns, iban_check, etc.) overlap with pricing, so differentiation is trivially satisfied.

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 statement or named alternative, but the zero-parameter, read-only nature and the fact that no sibling deals with pricing makes the intended usage self-evident. Guidance is implied 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 readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond that: the clearing table is dated 2026-10-16, checksum validation follows bank-specific rules, and the tool deliberately does not verify account existence — all material caveats for interpreting 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 dense sentences with zero filler. The primary conversion action is front-loaded, and the limitations sentence follows immediately; the clearing-table date earns its place by telling the agent how current the mapping is.

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 enumerates what comes back (IBAN, BIC, bank identity, checksum result) and clearly states the boundary of the check. Nothing an agent needs to call and interpret this tool correctly is missing.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema, including the 4-digit (5 for Swedbank 8xxx) clearing format. The description adds no syntax, format, or constraint detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource (converts Swedish clearing + account number to IBAN/BIC) plus three additional capabilities: bank identification and checksum validation. An agent can distinguish it from siblings like iban_check or se_validate, which handle the reverse or broader validation concerns.

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 note 'does not check that the account exists' usefully bounds expectations, but the description never names an alternative tool or states the condition that should route an agent to iban_check or se_validate instead. Usage is implied rather than guided.

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 declare readOnlyHint and openWorldHint, and the description adds two things beyond that: the validation logic used (checksum and date logic) and the explicit statement 'No application-level storage', which reassures about data handling. It also notes the return of normalised forms and error codes, though it does not enumerate error codes or failure behaviour.

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 dense, front-loaded sentences: the first carries purpose and scope, the second carries behaviour and the storage disclaimer. Every clause earns its place, including the orgnr sub-forms, which map to the enum.

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 correctly compensates by stating it returns normalised forms and error codes. It stops short of describing the response shape or how invalid input is signalled, but for a stateless read-only validator 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 100% with a documented enum for 'type', so the baseline is 3. The description lists the identifier types but adds only marginal semantics beyond the enum values, with the useful exception of expanding orgnr to include sole-trader and VAT forms — which is not visible in the schema.

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

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

States a specific verb (validates) and resource (Swedish identifiers) and enumerates exactly which identifier families are covered (personnummer, samordningsnummer, orgnr, bankgiro, plusgiro, OCR). This clearly separates it from siblings like iban_check or email_check, which handle non-Swedish/non-identifier domains.

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 identifier list — an agent can infer it should call this for Swedish ID validation. However, there is no explicit when-to-use/when-not guidance and no alternatives named (e.g. iban_check for IBANs, se_account_to_iban for account conversion).

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 and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavioral context beyond them: the audit is static-HTML-only (no JS rendering) and respects robots.txt, which materially affects expectations of 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?

A single dense sentence, front-loaded with the core purpose before the checklist of checks. The long enumeration earns its place by telling the agent exactly what output to expect, though it pushes toward run-on length.

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 summarizing the return payload (issue list and 0-100 score) and states key limitations. Coverage is strong for a one-parameter tool, though it never mentions error cases for unreachable URLs.

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% with a single, self-explanatory 'url' parameter, so baseline is 3. The description adds value by clarifying that only one page is audited per call, which shapes how the agent uses the 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+resource ('Technical SEO audit of one page') and enumerates the exact dimensions checked, so an agent can immediately distinguish it from siblings like site_contacts or url_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?

Usage is implied by 'of one page' and the constraint 'Static HTML only; honours robots.txt', but there is no explicit statement of when to pick this over sibling tools or what prerequisites exist. The agent must infer scope from context.

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

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

Beyond the annotations, it discloses non-obvious behavior: robots.txt compliance, a 403 blocked_by_robots response that is explicitly not charged, same-host-only crawling, and a capped fan-out of 3 contact pages. These are exactly the operational traits an agent needs to predict cost and failure modes.

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

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

Three dense sentences with zero filler: output types first, then fetch scope, then robots handling. Every clause contributes information and nothing is repeated from the schema or annotations.

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

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

With no output schema, the description compensates by specifying what is returned (emails including mailto and [at] obfuscation, E.164 phones, social links, address hints, Swedish org numbers) and the network behavior. Nothing needed to call it correctly is missing.

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

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

Only one parameter exists and schema description coverage is 100%, so the schema already carries the definition. The description adds a mild clarification ('usually the homepage'), but no format or syntax beyond the schema, meeting the baseline 3.

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

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

The description names a specific verb (fetches) and a precisely scoped resource (public contact details on a website), enumerating the extracted types (emails, phone numbers, social links, address hints, org numbers). It is clearly distinguishable from siblings like site_audit or url_markdown, which do not target contact extraction.

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 defines the operating envelope: it fetches the given page plus up to 3 contact-like paths on the same host only, honouring robots.txt. An agent can infer when this tool is appropriate, but no sibling alternative is named or explicitly excluded.

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 annotations: states the 1.5 MB size cap, the 8 s timeout, the exact content it removes (navigation, footers), and the robots.txt compliance constraint. Annotations only say read-only/open-world; the description adds all the operational limits an agent needs.

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 the highest-value fact (what it returns), then limits, then constraints. Every clause carries decision-relevant information; nothing is 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?

For a single-param, read-only fetch tool with no output schema and only open-world/read-only annotations, the description supplies all the missing operational detail — output shape, size/time limits, JS and robots.txt constraints.

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?

One parameter with 100% schema coverage, so baseline is 3. The description adds that the URL must point at a static HTML page (robots.txt-respecting, no JS), which gives the URL argument real acceptability semantics beyond the schema's terse 'Page URL to convert.'

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 (fetches) plus resource (web page), and it names the concrete output (clean Markdown) along with exactly what it strips. It is trivially distinguishable from every sibling (bank_days, domain_dns, iban_check, site_audit), none of which fetch-and-convert web pages.

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?

Clear operational context: static HTML only, no JS rendering, honours robots.txt — an agent can tell when the page is in scope. It stops short of naming alternatives (e.g. a browser-rendering or site_audit sibling) for JS-heavy pages.

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