Agent Tools

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

With no annotations, the description carries the behavioral burden and adds meaningful details: weekend and holiday skipping, ISO country code for holidays, pricing via x402, and an example output. It still leaves gaps around the optional country default and the meaning of the 'inclusive' field shown in the example.

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 purpose is front-loaded, the use cases are compact, pricing is stated in one sentence, and the example output is a concise illustration of the return value. There is no evident 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 simple three-parameter calculator with no output schema and no annotations, the description covers the core calculation, holiday behavior, cost, and a sample result. Minor gaps remain around default country behavior and the inclusive flag, but the definition is largely sufficient for correct 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 100%, so the input schema already documents start, end, and country formats. The description adds that country relates to national public holidays, but it does not further explain parameter behavior or defaults beyond 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?

The description states a specific action and resource: counting working days between two dates while skipping weekends and national public holidays. It is clear what the tool does, but it does not explicitly contrast itself with the sibling public_holidays tool.

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 names concrete use cases such as SLAs, invoice due dates, shipping, and legal deadlines, which gives clear context for when to use it. It does not provide explicit exclusions or point to alternatives like public_holidays for listing holidays.

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 and does: it discloses that images and scans go through OCR, that access requires a $0.012 USDC payment via x402 per call, and what the response looks like. Cost and payment mechanism are exactly the kind of trait an agent cannot infer from an empty annotation set.

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 contract-first sentence is front-loaded and every clause about field types earns its place. The trailing example output is truncated mid-object ('"Date'), which weakens an otherwise tight structure.

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, yet the description supplies an illustrative response payload, the extraction categories, the OCR caveat, and the per-call price. An agent has everything needed to decide to call it and to interpret what comes back.

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?

A single required parameter with 100% schema description coverage, so the schema already documents it fully. The description only restates the accepted input types ('PDF or image URL in'), matching the baseline for a well-covered single-param tool.

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 ('One call document parsing') plus an explicit input/output contract: 'PDF or image URL in, full text plus extracted fields out'. The enumerated document types and extracted field list separate it from narrow siblings like pdf_to_text and image_ocr.

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 'one call' framing and the breadth of covered document types (invoices, receipts, statements, forms, scans) imply when to reach for this over a single-purpose extractor. It never names pdf_to_text or image_ocr as alternatives or states exclusions, so the routing still requires 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?

With no annotations, the description carries the burden and does real work: it discloses the paid model ('$0.003 USDC per call via x402'), a critical behavioral fact an agent must know before invoking, plus the aggregate nature of the call (all checks in one request). It omits latency, rate limits, error/refund behavior for unregistered or invalid domains, and the truncated example cutting off at 'https':{'reac' fails to show whether reachability/status codes are returned.

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 capabilities and use cases, then pricing, then example – a sensible order. The embedded example JSON is a reasonable payload but is visibly truncated mid-string ('https':{'reac'), which costs a bit of clarity and wastes characters on an incomplete object.

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, moderate-complexity tool with no output schema, the description largely supplies the missing return-value context via the sample payload and states the cost. The truncation of that sample, plus no word on unregistered-domain or failure responses, leaves minor gaps that an agent might need to probe.

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 at 100% schema coverage, so the schema already fully documents 'domain' with an example. The description adds only an indirect format hint through the sample output domain. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description opens with a precise verb+resource: domain intelligence covering registrar, creation/expiry dates (RDAP/WHOIS), A/AAAA/MX/NS/TXT records, SPF, DMARC and HTTPS reachability 'in one call'. It enumerates the exact payload, so an agent knows what it gets. However, it never names the obvious sibling domain_lookup_batch (or ip_lookup/url_dossier), so single-vs-batch differentiation is left to inference.

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 names three concrete use cases – due diligence, phishing checks, lead research – which gives clear context for when to reach for it. There are no explicit exclusions or pointers to alternatives, so an agent must infer that bulk work belongs to domain_lookup_batch.

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 well: it discloses pricing ($0.012 USDC via x402 per call), partial-failure semantics ("bad items return per-item errors"), and the fields each item returns (registrar, dates, DNS, SPF, DMARC, HTTPS reachability). It omits operational traits like rate limits, retry/idempotency behavior, and what happens on payment failure, keeping it below 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?

Dense but front-loaded: batch scope and cost advantage come first, then body format, returns, and error behavior. The literal example-output JSON is somewhat long, though it usefully conveys the response envelope in the absence of an output schema.

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

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

For a paid batch endpoint with no annotations and no output schema, the description covers cost, request shape, return fields, error handling, and an example response shape. What is left out — rate limits and payment failure modes — is minor but non-zero for a monetized tool.

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

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

Schema coverage is 100% and the single `domains` array is already documented as "1 to 10 domain names". The description restates the JSON body shape `{domains:[...]}` and the max of 10, adding no syntax or format detail the schema lacks. A 3 baseline is correct when the schema does the work.

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

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

States a specific verb/resource combination (batch domain intelligence) and the exact scope: up to 10 domains per call. It distinguishes itself from the single-domain sibling by explicitly claiming to be "60% cheaper than singles", so an agent can choose between domain_lookup and domain_lookup_batch without opening either schema.

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

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

Gives concrete context ("due diligence and lead lists"), a hard batching limit (10 per call) and an economic reason to prefer it over the singles tool. It stops short of explicitly saying "for a single domain use domain_lookup instead", so the routing 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?

With no annotations present, the description carries the full behavioral burden and does so: it discloses the absence of an SMTP probe, that no data is stored, the exact per-call price and payment rail (x402, $0.001 USDC), and the deliverable_guess nature of the verdict. This is unusually complete side-effect and cost disclosure.

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

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

The first sentence front-loads purpose and scope, with cost and caveats appended afterwards. The inline example output is long but earns its space since no output schema exists; the run-on first sentence is the only minor bloat.

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 with no output schema, the description supplies the return-field shape via an example, the pricing model, and the safety profile. The one gap is explicit routing guidance against email_check_full, which the sibling list makes a realistic confusion.

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 'email' parameter, so the baseline is 3. The description adds context about what happens to the input (syntax, MX, domain classification) but nothing about input format or constraints beyond the schema's 'Email address to validate'.

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 (validation) and resource (email addresses) and enumerates exactly which checks run: syntax, MX, disposable domains, role addresses, free providers. It only implicitly differentiates from the sibling email_check_full via 'No SMTP probe', rather than naming it as the heavier alternative.

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

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

Gives concrete scenarios (signup forms, lead lists, CRM cleanup) plus an explicit exclusion ('No SMTP probe'), which tells the agent this is the lightweight path. It never names email_check_full or states the condition that should route an agent there.

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 at all, the description carries the full burden and does it well: it discloses the payment model and exact cost ($0.006 USDC per call via x402), the partial-failure contract ('bad items return per-item errors, not a failed call'), the item cap, and the per-item check list. These are exactly the traits an agent cannot infer from the 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?

Front-loaded with the core purpose, cost, and cap before the mechanics. Every clause carries information (checks, failure mode, price, example). The inline JSON example output is long but justifies itself by substituting for the missing output schema; only the label 'Example output:' feels slightly tacked on at the end.

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, yet the description supplies a concrete response example showing count/succeeded/failed and the per-item result shape including deliverable_guess values. Combined with the cost, cap, and error semantics, an agent has everything needed to call this correctly and interpret the response.

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

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

Schema coverage is 100% and the single parameter already documents '1 to 10 email addresses' with maxItems. The description adds the request envelope shape ({emails:[...]}) and the semantics of the response items (ok, result, deliverable_guess), which is modestly useful, but parameter meaning itself is fully covered by the schema. Baseline 3 applies.

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

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

Opens with a specific verb+resource+scope: 'Batch email validation for list cleaning: up to 10 addresses per call'. It enumerates the exact checks performed, so an agent knows precisely what it gets. It mentions '10 single calls' generically but never names the actual siblings email_check / email_check_full, so differentiation is implied rather than explicit.

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

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

The '40% cheaper than 10 single calls' framing implies the batch-vs-single tradeoff, and 'list cleaning' implies the use case. But there is no explicit 'use this instead of X when Y' statement, and no guidance on which of email_check, email_check_full or this tool to pick for a one-off address. Usage is inferable, not 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?

With no annotations, the description carries the full burden, and it does substantial work: it discloses the payment/auth requirement and unit cost ('$0.004 USDC per call via x402'), the verdict taxonomy (accept/review/reject), and the risk-score range. Gaps remain around failure modes, invalid-email handling, and latency/rate limits, which matters for a paid call.

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

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

Front-loaded with the differentiator and scope, then use cases, then price, then a concrete return example — no filler sentences. The example JSON is long but earns its place because there is no output schema.

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 annotations and no output schema, so the description must cover behavior and returns; it does so via the risk-score/verdict explanation and a full example response. It stops short of error behavior, timeouts, and what happens on malformed input, which an agent about to spend $0.004 per call would want.

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

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

Only one parameter and schema coverage is 100%, so the schema already documents 'email'. The description adds no format or validation detail for the address (e.g., whether role addresses or unicode domains are acceptable), so it does not exceed the baseline for a single fully-documented param.

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 ('email risk check') and explicitly scopes it as a superset of the sibling: 'everything in email_check plus sender domain health... and a 0-100 risk score'. The included signals (domain age, registrar, SPF, DMARC, website reachability) and outputs (risk score, verdict) let an agent distinguish it from email_check without opening the schema.

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

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

Names concrete use cases: 'fraud screening, lead qualification and signup gating', which tells the agent the decision context this tool serves. It implies when to prefer email_check (basic check) by framing this as the fuller version, but never states an explicit exclusion or cost-sensitive trade-off rule.

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 well: it discloses live mainnet reads, forward verification of resolutions, the exact cost ($0.002 USDC per call via x402), and an example return payload. It stops short of covering failure modes such as unresolvable or unregistered names and whether results are cached.

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

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

Dense but front-loaded: purpose and directionality come first, then usage, pricing, and an output sample. The example JSON is compact and earns its space as the only output documentation, though the run-on colon-separated phrasing is slightly harder to parse than clean sentences.

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, including a sample response is the right compensation, and pricing plus data-source disclosure covers the economics an agent needs before calling. The one gap is that neither parameter is marked required yet the tool needs exactly one; the description hints at this only through 'or' rather than stating the constraint explicitly.

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 both parameters already described as name vs. reverse-lookup address. The description's examples ('name=vitalik.eth or address=0x...') add minor clarity about the either-or usage but no new semantics 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 the specific verb and both directions of the resource: 'ENS lookup: name to address (with avatar) or address to primary name, with forward verification.' It also pins the data source ('live Ethereum mainnet'), which cleanly separates it from generic siblings like domain_lookup or url_dossier.

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 before sending funds to a human readable name' gives a concrete decision trigger an agent can act on. It lacks explicit exclusion guidance (e.g., when to prefer domain_lookup or token_preflight), so it falls short of a 5.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses cost ($0.003 USDC per call via x402) and gives an example return payload, which are real behavioral facts not in the schema. However it says nothing about input size limits, failure modes, or whether conversions are lossy (e.g., HTML→text dropping structure).

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, front-loaded sentence covering capability, invocation shape, pricing, and an output sample. Every clause earns its place; it is only slightly cramped by packing four distinct concerns into one line.

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 inline example output compensates well, and payment mechanics are stated. For a 3-required-param converter this is nearly sufficient; the main gap is absence of size/limit guidance for a content-passing 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 33% (only 'input' is documented), so the description should compensate. It restates the body shape {from, to, input} and the enum pairs are fairly self-evident from the schema's enum values, but it adds no per-parameter semantics beyond that repetition, and the example output only loosely illustrates field handling.

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 ('Format conversion') and enumerates concrete conversion pairs (CSV→JSON, HTML→markdown, etc.), so an agent can immediately tell what the tool does. It stops short of differentiating from overlapping siblings like web_to_markdown or pdf_to_text, leaving the agent to infer that this handles arbitrary supplied content rather than fetched/paged sources.

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 phrase 'for data pipelines and publishing' suggests a usage context, but there is no explicit when-to-use/when-not, no prerequisites, and no named alternative among the 14 siblings. Usage must be inferred from the conversion list.

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 load and does well: it discloses the metered cost model ($0.001 USDC per call via x402) and identifies the upstream data source, both of which affect whether an agent calls it. It omits rate limits, failure modes, and any caching/refresh cadence, 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?

Three tight sentences with purpose, mode, and pricing front-loaded. The example output is slightly long but is doing real work in the absence of an output schema, so it earns its place.

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

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

For a no-annotation, no-output-schema tool, this covers purpose, cost, source, and return shape via the example payload. The remaining gaps are minor: no error/empty-result behavior and no explanation of the symbols filtering.

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 base/date/symbols are already documented, giving a baseline of 3. The description adds only the implied semantic that omitting date yields the latest rate and that the result is base-relative; it says nothing about the symbols parameter's effect.

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

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

Names a specific resource (European Central Bank currency exchange rates) with concrete use cases (price conversion, invoicing, travel budgets) and states the two modes (latest or historical by date). None of the unrelated sibling utilities (ip_lookup, pdf_to_text, etc.) could be confused with 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?

'Latest or historical by date' tells the agent how to select the two operational modes, and the use cases give context for when it's appropriate. It stops short of explicit when-not-to-use guidance, but no sibling tool overlaps in function so there is little ambiguity to resolve.

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 well: it discloses supported chains, the exact estimation method, fallback behavior, fee tiers, L1 data fee on OP-stack chains, USD conversion via Chainlink, revert reporting instead of failure, and the $0.002 USDC x402 cost. It also provides a concrete output example, making behavior fully transparent.

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 front-loaded with the core purpose and usage, then layers on behavioral details and an example. It is appropriately sized for a multi-chain fee tool, though the example output is truncated mid-JSON, which slightly undercuts its 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 five optional parameters, no annotations, and no output schema, the description is complete enough for an agent to call the tool correctly. It covers chains, inputs, fallback behavior, fee components, error handling, cost, and return shape via the example.

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 reinforces the meaning of 'to, from, value, data' and the no-'to' plain transfer case, but it does not add syntax, format, or constraints beyond what the schema already documents.

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

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

The description states a precise verb and resource: 'Gas estimate and fee quote' across five named chains. It specifies the exact method (eth_estimateGas) and the fallback behavior (plain transfer if no 'to'), so an agent knows exactly what the tool does without opening the schema.

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

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

It gives explicit usage guidance: 'Use before signing or to budget agent transactions.' This tells the agent when to invoke it. It does not name alternatives or when-not to use it, but no sibling tool overlaps in function, so the condition is clear enough.

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 and does well: it discloses accepted formats (PNG/JPEG), a 10 MB size ceiling, that line breaks are preserved, and — critically — a paid x402 flow at $0.005 USDC per call, which is a behavioral fact an agent cannot get elsewhere. It does not cover failure modes (invalid URL, oversized file, unsupported language) or whether retries are billed, 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?

One dense sentence front-loads the operation and accepted inputs, followed by the behavioral facts and a concrete output example. No filler, and nothing important is buried at the end.

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

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

For a one-parameter tool with no annotations and no output schema, the description covers input constraints, cost/payment mechanism, and an example return shape — enough to call it correctly. Error behavior and language coverage are the remaining gaps, but they are not required to invoke it.

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

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

Schema coverage is 100% and there is a single required parameter, so the baseline would be 3. The description adds real meaning to that parameter, constraining it to public URLs of PNG/JPEG images under 10 MB, which the schema ('Public image URL') does not state.

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 ('read all text') plus resource ('screenshot, photo, receipt, sign, scanned page or chart image at a URL'), which clearly separates it from text-extraction siblings aimed at documents or web pages. It does not explicitly name pdf_to_text or document_extract as the alternative for non-image inputs, so differentiation is implied rather than stated.

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 enumerated image types imply when to use it, but there is no explicit when-not guidance and no routing to sibling tools such as pdf_to_text (PDFs) or document_extract (structured document fields). An agent must infer the boundary itself.

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 well: it discloses the full pipeline, enum-like outcomes (accept/review/reject with reasons), a pricing model ($0.012 USDC per call via x402), and a critical caveat that this is heuristic triage, not verification. It omits failure modes (unreadable PDF, unreachable URL) and auth/payment flow details, keeping it at 4 rather than 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?

The description is front-loaded with purpose and output, and the example output is dense with information that would otherwise be missing (no output schema). It is slightly dense and packs pricing, caveats, and example into a short block, but no sentence is wasted.

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

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

For a one-parameter tool with no output schema, the description supplies the missing return shape via a concrete JSON example, explains the decision semantics, and discloses cost and limitations. It stops short of describing error behavior or latency, which prevents a perfect score but leaves an agent well-equipped to call it.

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

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

Schema coverage is 100% and the single 'url' parameter is already documented as 'Public PDF or image URL of the invoice.' The description restates that the URL must be a PDF or image but adds no new format, size, or accessibility constraints beyond the schema. 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?

The description states a specific verb and resource ('Invoice intake... PDF or image URL in, one decision-ready JSON out') and makes the composite nature explicit by naming the sub-steps (text extraction, email risk check, domain lookup). This clearly distinguishes it from atomic siblings like document_extract, email_check, and domain_lookup.

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 targets 'AP agents' and adds a useful when-not caveat: 'Heuristic triage, not bank verification.' It does not explicitly route to or exclude sibling tools (e.g., 'use document_extract for non-invoice documents'), but the invoice-specific framing is strong enough for most selection 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?

With no annotations, the description carries the full burden and does well: it discloses the underlying data source (RDAP registry), states the price ($0.003 USDC per call via x402), and shows a full example response including reverse_dns formatting. It omits failure modes (invalid IP, no RDAP record) and rate limits, 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?

Purpose and data sources come first, pricing next, example last — a sensible front-loaded order with no filler prose. The inline JSON example is dense but earns its space by defining the return shape in the absence of an output schema.

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, and the sample output compensates by naming every returned field and its types. A paid tool also needs the per-call price, which is stated; only error behavior and the single-vs-batch routing are left unaddressed.

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 with 100% schema description coverage ('IPv4 or IPv6 address'), so the schema already does the work and the baseline of 3 applies. The example implicitly reinforces the expected format but adds no syntax or constraint detail beyond 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?

Specific verb+resource with the returned fields enumerated (owning network, allocation range, RDAP country, reverse DNS), so the agent knows exactly what data comes back. It does not explicitly distinguish itself from the sibling ip_lookup_batch, though the singular 'IP address lookup' implies single-address 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?

Three concrete use cases (security triage, log analysis, fraud checks) give clear context for when to reach for this tool. No exclusions or named alternatives are offered, so the agent must infer that batch lookups belong in ip_lookup_batch.

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 to lean on, the description carries the burden well: it discloses partial-failure semantics ('bad items return per-item errors'), the payment/auth mechanism (x402, $0.012 USDC per call), and the result shape via a worked example. It does not mention latency, rate limits, or whether a failed lookup is still billed, which keeps it out of the top band.

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

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

Front-loaded with purpose and cost before mechanics, and each sentence carries useful information. The embedded example output is long but justified since there is no output schema; the remaining text is tight.

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

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

For a one-parameter batch tool with no annotations and no output schema, the description covers input format, limits, failure semantics, pricing, and return shape. Minor gaps remain around billing on partial failure and any rate limits, but nothing essential to correct invocation is missing.

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

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

Schema coverage is 100% for the single ips parameter, so the baseline is 3. The description adds real value beyond the schema by specifying IPv4 or IPv6 acceptance and the JSON body shape {ips:[...]}, neither of which the schema 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?

States a specific verb+resource (batch IP lookup) plus the concrete use cases of log analysis and fraud review. It differentiates implicitly from single lookups with '40% cheaper than singles', but never names the ip_lookup sibling directly, so the agent must infer the routing rule.

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

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

Gives clear context for when this applies (multiple IPs in logs, fraud review, cost savings vs singles) and enforces the batch limit of 10. It stops short of an explicit exclusion such as 'use ip_lookup for a single address', leaving that inference to the agent.

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 most of it: 20 MB size cap, per-page return structure, non-persistence ('Not stored'), and an explicit per-call price ($0.006 USDC via x402). It omits error behavior, timeouts, and what happens if payment fails, 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?

Purpose and constraints are front-loaded in the first sentences, and every clause (size limit, persistence, price, format) adds information. The inline example output is bulky but justified because no output schema exists, so it earns most of its 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?

For a 2-parameter conversion tool with no annotations and no output schema, the description supplies the essentials: input constraints, output structure via example, cost, and storage behavior. Missing failure modes and format default are minor residual gaps.

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 only 50% (the format enum is undocumented in the schema), but the description compensates: it explains the two format values and adds a 20 MB constraint on the URL that the schema does not state. It does not specify a default for format, leaving one small ambiguity.

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

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

States a concrete verb+resource (PDF -> text/markdown) plus the output shape ('text per page') and primary use cases (RAG, summarizing, indexing, reading documents). It does not explicitly distinguish itself from plausible siblings like file_convert, web_to_markdown, or image_ocr, so an agent must infer the boundary from the input type alone.

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

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

Gives clear situational context — RAG ingestion, summarization, search indexing, and reading reports/papers/contracts/invoices — which tells an agent when this tool fits. However, it never states when not to use it or names the alternative (e.g. use web_to_markdown for HTML, image_ocr for scanned images), so the routing decision is left partly 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?

With no annotations, the description carries the full burden and does meaningful work: it discloses a per-call cost of $0.001 USDC via x402, which is critical behavioral information an agent must know before invoking. It also shows a concrete example response, revealing the return shape despite no output schema. It stops short of covering error behavior or country/year limits.

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

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

Front-loaded with purpose and scope, then cost, then a compact example. The inline JSON example is somewhat dense but earns its place by substituting for a missing output schema. No filler sentences.

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 two-parameter lookup with no output schema and no annotations, the definition supplies purpose, cost model, and a sample return value — enough to call it correctly. Remaining gaps (invalid-country handling, supported year range, whether sub-national holidays are included) are modest for a tool of this complexity.

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, and the baseline is 3. The description reinforces that the lookup is keyed by year and implies country codes via the 'US' value in the example output, but adds no syntax or constraint detail beyond 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 resource and scope: a public holiday calendar covering 100+ countries, keyed by year. An agent can immediately tell this returns holiday dates rather than the working-day calculations implied by the sibling business_days, though the description never names that sibling explicitly.

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

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

The phrase 'for scheduling, payroll and delivery planning' gives plausible use contexts, which is more than nothing. But it offers no exclusions or routing guidance — it does not say to use business_days when the agent needs working-day counts rather than holiday dates, leaving the closest alternative ambiguous.

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 disclose the most consequential hidden trait: a per-call charge of $0.001 USDC via x402, which an agent must know before invoking. It also states DST correctness and shows a concrete output shape. It stops short of rate limits, failure behavior, or what 'now' resolves to (server clock vs. UTC).

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

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

Purpose is front-loaded in the first clause, followed by cost and then a compact output example that substitutes for the missing output schema. The inline JSON example is long for a one-line description but every element of it (utc, per-zone local and offset) conveys information an agent would otherwise guess at.

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 three-parameter conversion tool with no output schema, the description covers purpose, cost, DST behavior, and return shape via example. The only meaningful gaps are the default when 'time' is absent and error behavior for malformed zones.

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 all three parameters are already documented with IANA examples. The description's 'time=ISO local time or now' merely restates the schema property text and adds no format or edge-case semantics. 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 (timezone conversion between IANA zones) plus the key qualifier 'DST-correct UTC offsets', which is exactly the differentiator an agent cares about. None of the siblings do time conversion, so an agent can select this without ambiguity.

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?

'For scheduling meetings and deadlines' implies the use case, and the 'time=ISO local time or now' note hints at the common call pattern. However, there is no explicit when-to-use versus alternatives, no note on what happens when 'time' is omitted, and no guidance on invalid-zone handling.

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 well: it states data is read live from public RPC (read-only, no state change), discloses cost ($0.002 USDC per call via x402), and shows a sample response so return shape is predictable. It omits rate limits and what happens on failure/non-contract input beyond the is_contract flag.

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

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

Front-loaded with purpose and supported capabilities, then usage, then pricing, then an example — a sensible priority order with little filler. The example output is truncated mid-object ("type":"zeppelin" with no closing braces), which undercuts an otherwise dense, efficient description.

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, and the description compensates by enumerating every field returned and including a sample payload, which is the right call for a no-output-schema tool. Combined with the pricing and RPC-source disclosure, an agent has enough to call it correctly; only failure modes and rate limits are absent.

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

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

Schema coverage is 100% and both parameters are documented there, including the chain enum and default. The description restates the supported chains and shows an address in the example, but adds no syntax, casing, or address-validation guidance beyond 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?

Opens with a precise verb+resource ('Token contract inspector') and enumerates exactly what is resolved: contract check, ERC standard detection, metadata, supply, owner, and EIP-1967/beacon/1167/zeppelinos proxy detection. An agent can tell this is a read-only token introspection tool without opening the schema. It never names the closest sibling (token_preflight), so full sibling differentiation is missing.

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 before quoting, swapping, listing or paying with a token' gives a concrete trigger context for invocation. However, it offers no exclusions and does not point to the obvious alternative, token_preflight, which likely overlaps heavily — an agent choosing between the two gets no routing signal.

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 well: it discloses the paid x402 model ($0.004 USDC per call), the exact chain coverage, the meaning of the risk score, and a sample response showing field shapes. It stops short of stating rate limits, failure/error behavior, or what happens for unverified/unrecognized contracts.

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 capability statement, limitation, and pricing are front-loaded in the first two sentences, with the example last. The example JSON is illustrative but is cut off mid-object ('est_cost_usd':0) and adds bulk that a tightened, complete snippet would justify better.

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

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

With no output schema and no annotations, the description supplies the missing structure via a concrete example output, states pricing and supported chains, and bounds the tool's scope. Enough to call it correctly; only edge-case behavior (unsupported contract, invalid address) is unstated.

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 all three parameters are already documented, including the chain enum and 'from' as an optional holder address for realistic transfer simulation. The description only reinforces this indirectly by mentioning the simulated transfer gas cost; it adds no syntax, format, or address-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?

The description opens with a concrete verb-plus-resource framing ('Token preflight for agents about to swap, list or pay with a token') and enumerates exactly what is checked: contract/standard, name, symbol, supply, proxy/owner flags, a 0-100 risk score with reasons, and simulated transfer gas. It also pre-empts confusion with the nearest misread ('Not a honeypot audit'), so an agent can distinguish it from token_info and honeypot-style scanners without opening the schema.

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

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

It gives clear triggering context ('about to swap, list or pay with a token') and an explicit exclusion ('Not a honeypot audit'), plus the x402 payment precondition. The gap is that it names no alternative to route to when honeypot coverage is actually needed (e.g., token_info or a dedicated audit), leaving that inference to the agent.

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 well: it discloses supported chains, pricing ($0.003 USDC per call via x402), the exact return shape, and an example output. It does not cover rate limits or error behavior, but otherwise provides strong behavioral context.

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 front-loaded with the core purpose and return fields, then adds usage, pricing, and an example. The example output is lengthy but earns its place by concretely showing the return shape; no sentence is purely redundant.

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 two-parameter read-only tool with no output schema, the description is complete: it covers supported chains, returned fields, cost, intended use, and a concrete output example. An agent has everything needed to decide and 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 100%, so both the hash format and chain enum are already documented. The description's chain list and example output add marginal value but do not provide syntax or format details beyond the schema, making baseline 3 appropriate.

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

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

The description names a specific verb and resource ('Transaction decoder') and enumerates the exact fields returned (status, from, to, value, gas used, fee, method, transfers, approvals). This clearly distinguishes it from siblings such as wallet_balance, token_info, and gas_estimate.

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 gives a clear use case: 'Use to confirm a payment landed or explain what a transaction did.' It does not name alternative tools or state when not to use it, so it falls short of explicit routing guidance.

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

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

With no annotations, the description carries the full burden and does a decent job: it discloses the composite nature of the call, the exact price ($0.007 USDC via x402), and shows an example response emboldening the shape. It does not cover auth flow beyond pricing, rate limits, or failure behavior, which is a gap for a paid multi-source aggregation call.

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

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

The purpose is front-loaded, which is good, but the trailing example JSON is truncated mid-string ('https_reachable":') and bloats the definition without completing the illustration. The price sentence could be shorter. Overall readable but not tight.

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, and the example output covers the key returned sections (page, domain, ip, summary), which is the right compensation. For a composite paid tool, error handling and partial-failure semantics (e.g., what if DNS fails) are unaddressed, keeping it below a 5.

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 the schema already describes it as 'Public page URL' at 100% coverage. The description implies the URL is a public page (matching 'Public page URL') but adds no format rules, scheme constraints, or redirect handling. Baseline 3 is appropriate since the schema does the work.

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

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

The description states a concrete resource (a web page and its host) and enumerates exactly what the dossier contains: markdown, metadata, outbound links, extracted fields, domain intelligence, IP network lookup, and a trust summary. The verb is light ('one call dossier'), but the content list is specific enough that an agent immediately knows the payload. It does not name the sibling tools it supersedes, only 'replaces three calls'.

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?

'Replaces three calls' implies when this should be preferred over smaller siblings, but the three are never named (plausibly url_metadata, domain_lookup, ip_lookup). There are no exclusions or prerequisites beyond the payment note. The agent must infer when to use this versus the granular siblings.

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 bears the full burden, but it does add genuinely useful behavioral context: the $0.001 USDC per-call price via x402 and the fact that redirects are followed (final_url). The example output also reveals a status field and overall return shape. It does not cover error handling, JS rendering, or explicit read-only semantics, so it is partial rather than complete.

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 what the tool returns, then price, then a concrete example output. No wasted sentences. The example is verbose but earns its place by standing in for a missing output schema.

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 example output is a strong substitute, showing exact fields and shape an agent can expect. Combined with cost disclosure and redirect behavior, an agent has enough to call it correctly. Missing only explicit guidance on sibling selection and failure modes.

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

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

There is a single parameter with 100% schema description coverage ("Page URL"), so the schema already documents it. The description adds no URL format constraints or edge-case notes, matching the baseline 3 for high-coverage schemas.

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 enumerates exactly what the tool returns (title, description, OG image, site name, canonical URL, favicon, final URL after redirects), which makes the purpose specific and clearly distinct in output from content-fetching siblings like web_read_full and web_to_markdown. It lacks a verb ("fetch/unfurl metadata for a URL") and never names a sibling, but the field list does the differentiation work.

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 or when-to-avoid guidance. It does not tell the agent to prefer this over web_read_full or web_to_markdown when only preview metadata is needed, leaving the choice between the three web tools 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?

With no annotations, the description carries the full burden and does well: it discloses the data source (public RPC), the price oracle (Chainlink), the hard cap of 10 tokens, and the pay-per-call cost ($0.002 USDC via x402), which is the key operational constraint. It does not cover error behavior for unsupported addresses or RPC failures, keeping 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?

Content is front-loaded: what it returns comes first, then how to pass tokens, then when to use, then cost, then a sample response. It is dense in one paragraph but nearly every clause carries information; the example output is long yet justified because no output schema exists.

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?

Despite having no output schema and no annotations, the description supplies the return shape via a concrete JSON example, the payment model, the chain coverage, and the token limit. An agent has everything needed to call and interpret it.

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 chain enum, address, and the tokens list are already documented in the schema. The description adds only the concrete call syntax "tokens=0xA,0xB", which is a minor format hint rather than new semantic meaning. Baseline 3 applies.

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

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

The opening sentence names the exact resource (wallet balance), the supported chains, and the returned contents (native coin with USD value plus up to 10 ERC20 balances). An agent can distinguish this from token_info, token_preflight and gas_estimate without opening any schema.

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

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

"Use before funding, swapping or paying from a wallet" gives a concrete trigger context for calling it. It stops short of naming alternatives (e.g. token_info for token metadata, gas_estimate for fee planning) or stating when not to call it.

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 well: it discloses that the tool is paid ($0.004 USDC via x402), limited to public pages, and returns a single aggregated payload. It does not cover rate limits, error behavior, or JavaScript-rendering limits.

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 front-loaded with the key capability and then adds use cases, pricing, and an example output. Every element earns its place, and the example is especially useful because no output schema is present.

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 page reader, the description covers purpose, intended uses, cost, public-page scope, and return shape via an example. No output schema exists, so the example output is important and 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?

There is only one parameter, and the schema already documents it fully as a public page URL. The description adds little beyond reaffirming that the page must be public, 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?

The description states a specific verb and resource: a page reader returning clean markdown, metadata, links, word count, and extracted fields. It implies differentiation from sibling readers like web_to_markdown and url_dossier through its enriched extraction, but does not name those alternatives explicitly.

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

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

It gives clear use cases: research agents, price checks, and lead enrichment from public pages. However, it does not state when not to use this tool or name sibling alternatives such as web_to_markdown or url_dossier.

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 disclosure itself and does well: it notes robots.txt compliance and the paid x402 model at $0.0015 USDC per call, which is critical pre-invocation context. It omits failure behavior (paywalls, non-200 handling) and rate limits.

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 core capability is front-loaded in the first clause, followed by cost and a concrete output example. The embedded JSON example is somewhat bulky but earns its place as the only return-shape documentation, since no output schema exists.

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 fetch tool with no output schema, the description is nearly self-sufficient: it covers what is returned, content filtering, legal constraint, cost, and an example response. The main gap is the absence of any sibling differentiation against web_read_full.

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 the schema already documents it as 'Public page URL' at 100% coverage, so the baseline is 3. The description reinforces that the URL must be a public page but adds no format or edge-case detail (redirects, auth-gated pages) beyond 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 and resource: reads a web page and returns clean LLM-ready markdown, explicitly noting main content with nav/scripts stripped. It does not distinguish itself from plausible siblings like web_read_full or url_metadata, so an agent must infer the difference.

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 use-case context (research, RAG, summarization) which implies when the tool is appropriate. It never states when NOT to use it or names the obvious alternatives (web_read_full, url_metadata), leaving the routing decision 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?

With no annotations, the description carries the full load and does well: it states the probe is non-paying ("Never pays"), discloses the price ($0.005 USDC via x402), the default GET-then-POST fallback on 404/405, and the ready/needs_fixes scoring output. It omits failure modes such as behavior on network timeouts or non-402 responses beyond the verdict.

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 purpose and usage are front-loaded, which is good, but the description then crams every reported field into a long comma list and appends an example output that is truncated mid-token ("amou"), which is dead weight rather than illustrative.

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 correctly takes on the burden of describing the return value: verdict, 0-100 score, issue list, and per-field report contents. The truncated example and missing detail on error/timeout responses keep it just short of complete.

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

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

Schema coverage is 100% and both parameters are already documented in the schema, so the baseline is 3. The description reinforces the probing semantics but adds no syntax or format detail (e.g., URL normalization, allowed redirect counts) beyond what the schema 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?

States a specific action (probe a paid API URL for x402 readiness) plus the exact artifact returned: a valid 402, requirement location, network, asset, price, payTo, and a ready/needs_fixes verdict. An agent can immediately distinguish this from siblings like x402_seller_audit or url_dossier.

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 before listing an endpoint or paying it" gives clear triggering contexts and implicitly contrasts with actually paying. It does not explicitly route the agent to the closest alternative (x402_seller_audit) when a seller-side audit is what's wanted, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden and does it well: it declares a non-destructive read-only audit ('Never sends a payment'), discloses the per-call cost and payment mechanism ('$0.01 USDC per call via x402'), and describes the return shape (score, verdict, ordered fix list).

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 core statement is front-loaded and dense with useful specifics, but the appended example output JSON is truncated mid-object ('"severity"'), which wastes space and gives an incomplete illustration rather than a clean one.

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 no output schema, the description supplies the output structure and an example, plus cost and side-effect disclosure — nearly everything an agent needs. The truncated example is the only shortfall.

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 only two parameters, both fully described in the schema (url purpose, method enum), so the schema does the heavy lifting. The description adds no syntax or format detail beyond restating that it audits an x402 endpoint 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?

States a specific verb and resource ('Audits any x402 endpoint URL') and enumerates exactly what the audit covers: readiness check, 500-char description limit, Bazaar listing, OpenAPI x-payment-info, 402 Index, favicon, llms.txt, /.well-known/x402. This is clearly differentiated from the narrower sibling x402_endpoint_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?

The opening question 'Will my paid API get listed?' frames the use case precisely, and 'Never sends a payment' removes a likely hesitation. It does not, however, explicitly name x402_endpoint_check as the lighter-weight alternative when only a readiness check is needed.

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