toolvend - DNS, WHOIS & domain tools

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

With no annotations, the description carries the full burden and discloses key behaviors: it uses DoH, returns clean JSON, and costs $0.005 per call paid via x402. It does not mention error behavior (e.g., NXDOMAIN) or rate limits, but for a simple read-only lookup, the provided information is substantial.

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

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

The description is three concise sentences with no fluff. It front-loads the core purpose, then adds output format and pricing. Every sentence 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?

Given the tool's simplicity (2 parameters, no output schema), the description covers the essential aspects: what it does, how it returns data, and cost. It omits error handling and response structure details, but for a DNS lookup with clean JSON, this is a reasonable level of completeness.

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 baseline is 3. The description adds a general note about 'common record types' but does not enrich the parameter meanings beyond what the schema already provides. No extra syntax or format details are given.

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 ('DNS lookup over DoH') and distinguishes itself from sibling tools (erdap, lei, qr, etc.) by clearly stating it resolves DNS records. The mention of common record types and clean JSON further clarifies scope.

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

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

The description implies when to use the tool (for DNS resolution) and provides clear context about the output format and payment. It does not explicitly name alternatives or exclusions, but the tool is clearly differentiated by its DNS-specific function.

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?

With no annotations, the description carries full burden. It discloses that records are fetched, parsed, scored, and that recommendations are provided. Critically, it surfaces the paid-per-call cost ($0.01 USDC via x402), which is essential behavioral context. It doesn't mention rate limits or error handling, but for a simple one-parameter read tool, this is strong transparency.

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

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

The description is two sentences: the first explains the core function and outputs, the second discloses pricing. No filler or redundant details, and it is front-loaded with the main purpose. Every sentence contributes value.

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

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

Given the single parameter, no output schema, and no annotations, the description covers the essential behavior: input (domain), processing (fetch/parse), output (score/findings/recommendations), and cost. It doesn't specify exact response structure, but that is acceptable without an output schema. It's nearly complete, only lacking explicit mention of potential network failures or data freshness.

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 schema already provides 100% coverage for the single 'domain' parameter with a description. The tool description adds no new parameter-level information beyond confirming the domain is the subject, so it does not exceed the schema baseline. The parameter is simple and unambiguous.

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 clearly states a specific verb+resource: it fetches, parses, and scores DMARC + SPF records for a domain, producing a 0-100 score with findings and fix recommendations. This distinguishes it from sibling tools like dns, rdap, or robots, which serve different functions.

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 purpose is self-explanatory and implicitly signals when to use this tool (when email authentication posture is needed). It does not explicitly name alternatives or exclusion criteria, but the context is clear enough to avoid confusion with sibling tools. A 5 would require explicit 'when not to use' or alternative tool references.

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?

There are no annotations, so the description carries the transparency burden. It discloses the output shape, boilerplate stripping, and the enhanced cost for JS rendering, which is useful. However, it doesn't mention failure modes, rate limits, or authentication requirements, leaving some behavioral gaps.

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

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

The opening is clear and front-loaded, but the pricing section is repetitive and grammatically tangled ('Paid per call: $0.01 ($0.03 Execute JavaScript with Cloudflare Browser Run before extracting content.) in USDC via x402'). The redundancy and awkward structure reduce clarity, though the overall length is still short.

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 helpfully enumerates the return fields and notes the JS-rendering option and pricing. However, it doesn't cover error handling, URL constraints, or output truncation behavior, making it only moderately complete for a web-extraction 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%, so the schema fully documents all four parameters. The description adds little beyond the schema; it references render=true as a query parameter, which could confuse because render is an input schema property, and it doesn't enrich the meaning of url, includeLinks, or maxTextChars beyond what the schema provides.

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 clearly states the tool fetches a web page and returns a specific set of structured content types (title, meta/OpenGraph, canonical, headings, links, readable text). This is a specific verb+resource+scope that differentiates it from sibling tools like dns, robots, and sitemap.

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 provides clear context on when the tool applies (fetching web pages) and explicitly guides using render=true for JavaScript-rendered pages. It doesn't mention exclusions or alternatives to sibling tools, but the context is clear enough for an agent to select it for page extraction.

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?

With no annotations, the description carries the behavioral burden. It transparently discloses that the tool is paid per call ($0.008 USDC via x402), which is a critical behavioral trait. It also lists the data categories returned, giving context on what the call accomplishes. It does not mention rate limits or failure modes, but for a paid lookup tool, the cost disclosure is substantial.

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

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

The description is a single, information-dense sentence. It front-loads the purpose and then efficiently lists data types and pricing. Every clause adds value with no redundant wording.

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 simple one-parameter lookup with no output schema, the description provides a comprehensive list of data categories and cost information. It lacks response structure details, but the data category list offers adequate context for an agent to decide if the tool meets the user's need. The payment detail is also valuable.

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%; the parameter 'lei' is fully described in the schema (format, pattern, checksum verification). The tool description adds no additional parameter-level semantics beyond what the schema already provides, so baseline score 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 opens with 'Global legal-entity/KYB lookup by LEI' which clearly identifies the specific verb (lookup) and resource (legal-entity/KYB data). It distinguishes itself from siblings like dns, qr, and vat by focusing on LEI-based entity lookup and enumerates the returned data types (official identity, jurisdiction, addresses, registration status, risk flags, GLEIF freshness).

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 context: when you have an LEI and need legal-entity or KYB data. It does not explicitly state exclusions or alternative tools, but the clear scope and mention of payment may implicitly signal to use only when necessary. However, no explicit 'use X instead' guidance is 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?

With no annotations provided, the description carries full behavioral disclosure. It details output format (SVG), payload size limits, dependency on error-correction level, and the paid-per-call cost via x402. This is comprehensive for a simple generator.

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

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

The description is exactly two sentences. The first sentence states purpose, output, and constraints; the second adds cost. There is no redundant or filler content, and key information is front-loaded.

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 simple tool with a fully described schema, the description covers all necessary behavioral context: what it generates, payload limits, error-correction nuances, and cost. No output schema is needed since the output type is stated. It is 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?

The input schema covers 100% of parameters with descriptions, so the description does not need to add parameter details. It mentions the payload limit and error-correction dependency, but these are already in the schema. Baseline 3 is appropriate.

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

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

The description opens with 'QR code generator', clearly stating the tool's function and output format ('crisp SVG'). This unambiguously distinguishes it from all sibling tools (dns, sitemap, etc.), which are unrelated to QR code generation.

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 for encoding text or URL payloads into QR codes, and specifies a payload limit. It does not explicitly state when not to use it, but the absence of similar siblings makes alternatives less relevant. The cost note additionally informs usage decisions.

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?

Since no annotations are provided, the description carries the full burden. It discloses the paid per-call cost ($0.005 in USDC via x402) and the returned data categories, which are critical behavioral traits. It does not mention error conditions or rate limits, but for a read-only lookup tool, the key behaviors are addressed.

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

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

The description is a single, efficiently structured sentence with two parts: the tool's purpose and its pricing. It front-loads the main function and includes only essential additional information (cost), with no redundancy.

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

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

Given the simple input schema and absence of an output schema, the description supplies the necessary return-value context by listing the data fields (registrar, dates, status, nameservers, DNSSEC) and the cost. It does not explain the output format or potential errors, but these are minor gaps for a straightforward lookup 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?

The only parameter 'domain' is fully described in the schema as 'Domain to look up (path parameter)', providing 100% coverage. The description adds no additional parameter-specific context beyond what the schema already states, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies the tool as providing domain registration data via RDAP, with a specific list of data fields (registrar, created/expiry dates, status, nameservers, DNSSEC). This distinguishes it from sibling tools like dns or lei, which serve different domain-related lookups.

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 the tool is for fetching registration data, and 'modern WHOIS' signals its role relative to traditional tools. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select it when registration data is needed.

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?

With no annotations, the description carries the transparency burden. It reveals pricing and payment method ($0.005 in USDC via x402), and mentions that llms.txt is conditionally parsed ('if present'), giving insight into behavioral variation. However, it does not discuss error handling or missing robots.txt scenarios.

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 plus pricing information, front-loaded with the core action. Every word contributes to clarity, with no redundant phrases.

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 tool with one parameter and no output schema, the description covers the primary functionality, output type, and pricing. It is reasonably complete, though it could briefly mention failure behavior (e.g., if robots.txt is not found), but this is not a major gap.

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

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

Schema coverage is 100% for the single 'url' parameter, so the description doesn't need to add much parameter detail. The description repeats 'URL' without adding new meaning beyond the schema's 'Public HTTP(S) site origin or URL'.

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 clearly states a specific verb ('Fetch and parse') and resource ('robots.txt (+ llms.txt if present)'), and the output is structured JSON. It also differentiates from sibling tools like 'sitemap' by focusing on robots.txt and AI crawler blocking.

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 for checking robots.txt and AI crawler permissions, but it does not explicitly state when to use this tool versus alternatives (e.g., sitemap for sitemaps). No when-not-to-use guidance is provided.

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?

With no annotations, the description carries the full burden. It discloses key behaviors: parsing to JSON, index following via ?follow=N, the 500 URL cap, and per-call payment. It does not mention error handling or redirects, but covers the most essential operational traits.

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 concise sentences deliver all key information with no filler. The core action is front-loaded, followed by specific behaviors and pricing. Every word serves a purpose.

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

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

Given the tool's low complexity (2 params, no output schema, no annotations), the description covers the necessary essentials: input URL variants, follow parameter, output cap, and cost. It is complete enough for a straightforward utility.

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% for both parameters, but the description adds meaningful context: it explains how the 'follow' parameter affects index handling and how the cap relates to merged output. This goes beyond the schema's basic field descriptions.

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 clearly states 'Fetch and parse sitemap XML or gzip into JSON', specifying a distinct verb, resource, and output format. It differentiates from sibling tools which all target other domains (DNS, robots, etc.), making its purpose 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?

The description gives practical guidance for handling index sitemaps ('follow the first N children') and mentions the 500 URL cap, but it does not explicitly contrast with alternative tools or state when not to use it. Context 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.

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly mentions the return value (cleaned text plus stats) and the monetary cost ($0.003 via x402). It does not mention error behavior or idempotency, but for a pure text transformation this is sufficient. No contradictions with annotations (none exist).

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

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

The description is two sentences, front-loaded with the core purpose, and every word earns its place. It briefly covers operations, output, and cost without redundancy.

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

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

Given the tool's simplicity (no output schema, two parameters), the description is largely complete: it explains the return value, cost, and primary operations. The only notable gap is ambiguity about whether the listed operations are default behaviors or require enabling via the options object. Still, the schema's options object provides the necessary structure, so overall completeness is good.

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 50% (only 'text' has a description; 'options' does not). The description names three of the five options (stripHtml, normalizeUnicode, normalizeWhitespace, dedupeLines) but omits 'lowercase'. It adds some meaning beyond the schema by indicating which operations are available, but does not fully compensate for the missing option descriptions or clarify default behavior.

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 clearly states the tool's function with a specific verb ('Clean') and resource ('text'), and enumerates the key operations (strip HTML, normalise unicode/whitespace, dedupe lines). It also distinguishes itself from unrelated sibling tools by describing a unique text-processing capability.

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 context is implied by the description (e.g., use when text needs cleaning), but there is no explicit guidance on when to prefer this tool over alternatives or any exclusions. Since none of the sibling tools overlap in function, the lack of explicit differentiation is acceptable but still leaves room for improvement.

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?

No annotations are provided, so the description carries the burden. It discloses the per-call cost ($0.002 USDC via x402) and the rates table snapshot date, which are important behavioral traits. However, it does not mention error handling or the exact return format, which would be useful since there is no output schema.

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

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

The description is two sentences, front-loaded with the core functionality, followed by cost and data snapshot context. Every sentence earns its place with no fluff or redundancy.

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

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

The tool is simple, but since there is no output schema, the description does not state what the response looks like (e.g., whether it returns just the converted amount or both net and gross values). It also does not mention the actual snapshot date, which is referenced but not provided. These gaps make it slightly incomplete for fully autonomous invocation.

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 75%, and the description adds meaning by explaining the direction (net→gross or gross→net) and rate categories (standard or reduced), which clarifies the enum parameters. It also implies what 'amount' represents. This goes beyond just repeating schema field descriptions.

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 clearly states it is a VAT calculator for EU-27 + UK, with specific operations (net→gross or gross→net) and rate types (standard or reduced). It distinguishes itself from sibling tools, which are all in different domains (DNS, email, QR, etc.).

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

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

The description implies when to use the tool (when VAT conversion is needed for EU/UK), but it does not explicitly state alternatives or exclusion conditions. The sibling tools are unrelated, so no alternative is mentioned, but the usage context is not explicitly spelled out.

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