toolvend - utility APIs for agents

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

With no annotations, the description carries full burden and discloses meaningful traits: bundled 2024–2030 calendars, inclusive ranges, explicit weekends/closures, source attribution, coverage warnings, and a per-call payment of $0.01 USDC via x402. The payment and coverage-limit disclosures are exactly the kind of behavior an agent cannot infer from schema alone. Missing only return/error behavior details.

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, front-loaded sentences with no filler: capabilities first, then calendar constraints, then the coverage pointer and pricing. Slightly list-like in the middle sentence but every clause 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?

For a 7-parameter tool with no annotations and no output schema, the description covers operations, date-range bounds, calendar coverage, weekends/closures, sourcing, and payment. It omits the mechanics of the paid call and any return-shape hint, but is otherwise complete enough to invoke 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 86%, so the schema already documents nearly every parameter (inclusive end, weekend default, additionalClosures). The description adds the 2024–2030 date window and the inclusive-range and weekend/closure semantics, but these largely restate what individual schema properties already say. 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 states specific verbs (add/subtract, count, find) and resources (business days, public holidays) with scope across countries and subdivisions. It largely distinguishes the tool's job, though 'find' does not map cleanly onto the enum operations 'next'/'intersection', leaving one operation slightly opaque.

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 listing operations and noting required date ranges, but there is no explicit when-to-use guidance, no prerequisites statement, and no exclusions. The sibling list (dns, extract, lei, etc.) is unrelated, so no routing guidance is strictly needed, but the definition never tells the agent which operation fits which scenario.

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 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?

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?

With no annotations, the description carries the burden of disclosing behavior. It fully discloses that it is paid per call ($0.009 USD via x402), processes at most 4 targets, does not fetch body content, and includes timestamps and partial-result warnings. This exceeds the minimal expectations and provides key operational details.

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 concise and front-loaded with the main purpose, followed by critical constraints and pricing. Each sentence adds value, covering scope, limitations, and costs 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?

For a single-parameter tool, the description is complete: it explains what is included (HEAD trace, DNS observations, security headers), what is not (page body, safety verdict), and the operational constraints (max targets, cost, timestamps). No output schema exists, but the description adequately sets expectations for the report contents.

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 parameter url is fully documented in the schema with a detailed description of constraints (e.g., public URL, standard port, rejects credentials). The tool description adds no additional parameter-specific semantics beyond what the schema already states, so the 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 clearly states the tool's purpose: inspecting a public URL and reporting on redirect trace, DNS observations, and security headers, explicitly excluding page body content and safety verdicts. It distinguishes itself from siblings like dns and extract by specifying the combined report nature.

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?

While it doesn't explicitly name alternative tools, it clearly describes what the tool does not do (no page body, no safety or reputation verdict), implying when not to use it. The context of what it inspects makes it distinct from siblings like dns or extract, providing practical guidance for selection.

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.

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

With no annotations, the description carries the full burden and does so: it discloses cost ($0.25 USDC per call), output volume caps (30 observations, 30 changes, 64 KiB), and explicit negative guarantees (no raw snapshots, descriptions, schemas, pay-to values, ranges, or pagination). This is unusually complete behavioral disclosure for a paid tool.

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

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

Three tight sentences, front-loaded with purpose and scope before constraints and price. Every clause carries information (window, caps, exclusions, cost) with 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?

There is no output schema, so the description must describe returns, and it does via volume caps, size limit, and exclusion list. It stops short of saying what a 'derived daily observation' or 'material change' contains, which is the one remaining gap for a no-output-schema 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 the schema already specifies a single canonical HTTP(S) URL with wildcards/bulk selectors rejected. The description echoes 'exact x402 resource' but adds no syntax, format, or validation 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 resource ('exact x402 resource history') plus the exact scope ('latest complete 30-day window'), which goes well beyond restating the name. Sibling tools are all unrelated utilities (dns, lei, rdap, vat), so no intra-family differentiation is required; the only missing element is any explicit contrast with a list/bulk variant.

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?

Use is implied by the scope statement: call this to get history for one resource. It never states when to use it versus an alternative, and the only constraint given (wildcards/bulk selectors rejected) is already framed as a per-call input rule rather than usage guidance.

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