Genesis402 (x402 pay-per-call)

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

Annotations only say readOnlyHint=false and openWorldHint=true, which are thin. The description adds meaningful behavior: per-call pricing in USDC on Base and a quote-before-payment flow. This is valuable context beyond the annotationshare. It does not disclose post-payment side effects or response behavior in detail, but what it adds is substantive and not contradictory.

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

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

Two tight sentences with no filler. The purpose is front-loaded, then pricing and quote behavior are added in the second sentence. Every clause 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?

Captures the essential payment flow and the generic nature of the tool, but lacks explicit guidance on where to resolve endpoint names (genesis402_catalog exists as a sibling) and on how the params object relates to the chosen endpoint. Given the high complexity of a 360-endpoint generic caller and no output schema, this is a notable 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 description coverage is only 33%, so the description must compensate. It does clarify endpoint by saying 'by name' and payment_signature by explaining the quote-without-payment flow. However, the params object—which is the payload for actual endpoint execution—is left completely unexplained, and the free-form nature means the agent still has no direct guidance on how to structure it.

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: 'Calls any of the 360 Genesis402 endpoints by name.' The 'any' framing clearly identifies this as the generic dispatcher, and the category list (DeFi, SEC filings, research, etc.) reinforces that it covers the same domains as the dedicated siblings. It is easy to distinguish from the specific sibling tools like whois or token_brief.

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?

Implies usage: call this when you want to invoke a named Genesis402 endpoint. It gives price and quote behavior, which helps plan the call, but it never explicitly says to prefer dedicated siblings for known operations or to consult genesis402_catalog to discover endpoint names. 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?

Annotations already mark the tool as read-only and open-world, and the description adds meaningful context: it is free, reads from a live manifest, and returns endpoint metadata. No contradiction with annotations is present.

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 compact, front-loaded with the most important facts (free, what it lists), and has no wasted words. 'Call first' is placed at the end yet still clearly actionable.

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 read-only catalog with no output schema, the description covers price, source, returned fields, and usage order. The primary call path is clear. The only notable omission is the semantics of the optional 'filter' parameter, but that does not prevent a correct unfiltered 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?

The only parameter, 'filter', has no schema description and is not mentioned in the tool description. With 0% schema description coverage, the description needed to explain what filtering applies to or what format is expected, but it does not. The parameter name provides a weak hint, but this is a real gap.

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 clear action ('List') and a precise resource: every Genesis402 endpoint with price, title, path, and parameters from the live x402 manifest. It also distinguishes the tool from its siblings by framing it as the catalog that precedes individual endpoint calls. The 'Call first' instruction reinforces its unique role.

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 explicitly says 'Call first', giving agents clear temporal guidance to invoke this tool before other Genesis402 endpoints. It does not explicitly enumerate when not to use it or name alternatives, but for a catalog tool 'Call first' is a strong and sufficient usage 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?

Annotations indicate readOnlyHint=false, so the tool may have side effects, but the description only mentions a payment cost, not what exactly happens with payment_signature, whether it triggers a charge, or what the response contains. The description does not contradict annotations, but it fails to explain the payment mechanism or any behavioral implications beyond the price.

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 paid nature and core purpose, but it repeats the title almost verbatim and adds only one new piece of information (the $0.01 cost). It could be better structured to explain payment flow or usage context without being overly long.

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 8 parameters, no output schema, and only 13% schema coverage, the description leaves significant gaps: how payment works, what the response looks like, how to use the filters in combination, and what the 'sort' values mean. The description is too thin for an agent to confidently invoke this tool correctly, especially given the payment_signature parameter.

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 only 13%, so the description carries some burden for explaining parameters. The description explicitly mentions filters (chain, protocol, token, stablecoin-only, minimum TVL) which maps to several parameters, but does not explain the 'sort' enum, 'limit' semantics, or the crucial 'payment_signature' parameter's role. The schema has minimal descriptions, so the description only partially compensates.

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: retrieving best DeFi yields from 15,000+ pools with filters by chain, protocol, token, stablecoin-only, and minimum TVL. The verb is implicit ('get') and the title is nearly identical to the description, but the description adds specific filter details and the payment cost, making it distinct enough from siblings like genesis402_scan or genesis402_call.

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 says it is paid ($0.01 USDC) and suggests it is for querying yields, but provides no guidance on when to choose it over alternatives like genesis402_multi_chain_scan or genesis402_prove. There is no mention of when not to use it, no context about payment flow aside from the cost, and no comparison to sibling tools.

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

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

Annotations already signal non-read-only and open-world behavior, and the description adds a precise cost ($0.002 USDC), which is the most important behavioral trait: this is a paid call. It doesn't elaborate on rate limits or other external side effects, but it covers the key transaction detail.

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

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

Two short fragments with no filler; the payment cost is front-loaded, and every listed item adds signal. This is appropriately sized for a one-required-parameter tool.

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 paid lookup, the description plus schema covers the input and quote-first payment flow; the listed checks also hint at output fields even though no output schema exists. The main gap is the absence of any guidance about result interpretation or alternative choices.

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

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

The schema documents payment_signature well, and the description connects email_or_domain to deliverability checks, but it doesn't specify accepted formats (e.g., 'user@example.com' vs 'example.com') or response details. At 50% schema coverage, the description only partially compensates for the undocumented parameter.

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

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

The description lists concrete deliverability checks (MX, SPF, DMARC, disposable flag, trust score), so an agent can see what the tool computes. It lacks an explicit verb and does not differentiate from domain-related siblings like genesis402_whois, so it doesn't reach 5.

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 'Email/domain deliverability' implies the tool is for deliverability checks, but there is no when-to-use or when-not-to-use guidance and no mention of alternatives. Given the sibling tool list includes other domain/web tools, explicit routing would help.

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?

The description adds meaningful behavioral context beyond annotations: it discloses the $0.006 USDC cost, states that missing fields become null, and promises 'never invented', which is a strong anti-hallucination guarantee. It does not elaborate on payment mechanics or rate limits, but the payment_signature parameter is documented in 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?

The description is two short sentences with no filler, front-loading the cost and then stating the core operation and guarantee. It is appropriately compact, though it sacrifices some explanatory richness for brevity.

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 description plus schema provides a minimally viable picture: what goes in, what comes out, and the key null-behavior guarantee. However, there is no output schema, no explanation of how to encode `fields`, and no routing guidance relative to sibling tools, so the agent still has to infer several important details.

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 only 33%, so the description must compensate for the undocumented `text` and `fields` parameters. It relates 'any text' to `text` and 'YOUR fields' to `fields`, but it never explains how to structure the `fields` object (e.g., field names mapped to extraction instructions), leaving a meaningful ambiguity for the agent.

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: 'Extract YOUR fields from any text as JSON'. It clearly identifies the resource (arbitrary text), the customization (YOUR fields), and the output format (JSON). This is distinct enough from siblings like genesis402_web_extract because it targets any text rather than a specific source type.

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 guidance about when to use this tool versus the many siblings, nor any mention of when not to use it. The phrase 'any text' implies broad applicability, but no alternatives or selection criteria are 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?

The description discloses a key trait annotations do not: the call costs $0.008 USDC. It also emphasizes the batched 'one call' nature. However, with readOnlyHint=false and no further annotation, it does not disclose whether state changes occur, what happens after payment, or the quote-before-payment flow, which is left to 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?

Two short sentences carry only high-signal information: cost and scope. There is no fluff, redundancy, or buried detail; the most important facts are 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?

With no output schema, a non-read-only annotation, and no explanation of what the scan returns or which 10 chains are included, the description is insufficient for an agent to confidently select and invoke the tool. The payment flow is partially documented in the schema, but the overall operation still lacks necessary context.

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

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

The address parameter has no schema description, so 'single address' adds minimal semantic value beyond the pattern. The optional payment_signature parameter is well-described in the schema, so the description does not need to compensate. This is neutral: schema covers half the parameters, and the description adds little for the other half.

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 operation: a single address is scanned across 10 EVM chains, which defines the resource and separates it from siblings like wallet_brief or token_brief. However, it never says what 'scan' returns (balances, transactions, risk), so the outcome is inferred 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?

No guidance is given on when to pick this tool over sibling tools or what conditions call for it. The only usage cue is the payment requirement, which is a prerequisite rather than a selection criterion.

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

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description adds key behaviors: the call costs $0.25 USDC, the receipt signature verifies offline, and the receipt chain is not externally anchored. It does not detail other side effects like auth requirements, but for a paid receipt tool the monetary and anchoring disclosures are 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 compact and front-loaded: the cost warning appears first, followed by the core function and one important limitation, with no filler words. Every sentence conveys necessary selection or invocation 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?

The high-level behavior is clear, but with no output schema the description doesn't specify the receipt's shape or how the payment/quote flow works (aside from the input schema's payment_signature note). It is sufficient as a starting point, but an agent would still need the schema details and perhaps a call example to know exactly what to pass and what to expect 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?

With only 25% schema description coverage, the description compensates by explaining that either a SHA-256 digest or text is bound and that claim is optional and tied to the settled payment. It adds meaning beyond the schema for text, sha256, and claim, while payment_signature already has a useful schema description.

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 produces a signed Ed25519 receipt binding the caller's SHA-256 digest or text plus an optional claim to a settled payment, and it mentions the $0.25 USDC cost. It does not explicitly distinguish itself from sibling tools such as genesis402_receipt, so it stops short of full sibling differentiation.

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 should be used when a low-cost, offline-verifiable receipt for a digest/text with a claim is needed; the caveat that the receipt chain is not externally anchored hints at a limitation. It does not state when to prefer sibling tools or provide explicit when-not-to-use conditions, leaving usage mostly implicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context ('Free', 'public receipts feed') but does not disclose return format, pagination, or any errors or limitations. This is acceptable given the annotation coverage, but the description itself remains thin.

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 extremely short and front-loaded with the 'Free.' qualifier. Every phrase adds information about resource, cost, or source. The structure loses points for the awkward fragment after 'Free.' and for not forming a complete sentence that clearly states the action.

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 read-only tool with a single parameter and strong annotations, the description is minimally adequate: an agent knows it can fetch a receipt by id from a public feed. But it lacks any explanation of what a 'paid-call receipt' is, what output to expect, or whether any additional context such as currency or network is relevant.

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 0%, so the description must compensate. It does indicate that the tool operates 'by id', which maps to receipt_id, and clarifies the id refers to a paid-call receipt. However, it does not explain the parameter name, format expectations, or anything beyond the schema's min/max length constraints.

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 title states a clear verb and resource ('Look up a receipt') and the description narrows it to 'a paid-call receipt by id from the rail's public receipts feed.' This distinguishes the tool from its siblings (e.g., genesis402_call, genesis402_prove), though the sentence fragment 'A paid-call receipt by id' is grammatically awkward and lacks an explicit main verb.

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 little guidance on when to choose this tool over alternatives. It notes the receipt comes from a 'public receipts feed' and is free, but it does not state explicit conditions, exclusions, or mention any sibling tool that might be considered instead.

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?

The description adds valuable behavioral context beyond the sparse annotations: it discloses the cost (Paid $0.008 USDC), states that results are 'automated heuristic signals from public data', and explicitly disclaims KYC/compliance/legal status. This gives agents important caveats about reliability, though it does not comment on side effects or response shape.

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

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

Three dense sentences, front-loaded with the paid amount, then the core purpose, then critical limitations. Every sentence earns its place with no filler or repetition.

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 description conveys what the tool does and its limitations, but with no output schema it does not describe the result format or how the payment flow works (beyond 'Paid'). It is adequate for an agent to select the tool but somewhat thin for invocation details like expected output or address type.

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 50% (address has no description), so the description should compensate. It does tie the address parameter to its purpose (sanctions screening for one address) and the paid nature implies payment_signature's role. But it adds no format, chain, or usage details beyond what the schema already says for payment_signature, leaving partial gaps.

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

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

The description states the specific resource (public-data sanctions-list signal), the scope (one address), and the data sources (OFAC SDN digital-currency entries and community blocklists). This clearly differentiates it from sibling tools like wallet_brief or multi_chain_scan, though it uses a noun ('signal') rather than an explicit verb.

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: the description indicates this is for a single-address sanctions-list signal, so an agent can infer when to call it. However, it does not explicitly state when not to use it or mention any alternative tools, so guidance is implicit rather than direct.

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?

The description discloses the payment amount ($0.01 USDC), which is a key behavioral trait beyond the annotations' readOnlyHint=false and openWorldHint=true. However, it omits the payment flow (e.g., need to first get a quote) and any other side effects or limitations, leaving a gap in transparency.

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

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

The description is only two sentences with the cost information front-loaded. No filler words, and the core functionality is stated efficiently. It could be more informative, but for what it includes, it is concise and well-ordered.

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 tool with no output schema, this description is incomplete. It does not explain the payment workflow (getting a quote, then signing), nor whether cik or ticker is required or how they interact. The absence of output structure details and lack of parameter explanations make it hard for an agent to call correctly without external knowledge.

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?

With only 33% schema description coverage, the description should explain the undefined parameters (cik, ticker). It does not mention them at all, leaving the agent to infer their meaning from domain knowledge. The payment_signature param is described in the schema, but the description adds no extra clarity beyond the cost note.

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

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

The description states the resource ('US public company from SEC XBRL') and the data fields (revenue, net income, assets, cash, EPS) clearly. It distinguishes itself from siblings like genesis402_defi_yields or genesis402_token_brief by focusing on SEC filings, but does not explicitly name an alternative. The paid note is extra context, not a purpose statement.

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 guidance on when to use this tool versus the many siblings or when to prefer a different one. No exclusions or selection criteria are mentioned. The only context given is the paid nature, which doesn't help with tool choice.

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?

The description adds meaningful context by stating the tool is paid ($0.03 USDC) and that it consolidates multiple checks in one call. However, with readOnlyHint=false there is no disclosure of side effects, payment flow, or failure behavior; the cost warning is helpful but the behavioral profile is incomplete.

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 short sentences with no filler. The cost, one-call promise, and output categories are all front-loaded and each element adds 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?

The description gives a useful high-level picture of what the tool returns and that it costs money, which helps an agent decide whether to call it. But it lacks guidance on how to provide the required contract, what chain means, and how the payment_signature flow works, and there is no output schema to fill those 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 description coverage is only 33% (payment_signature only), and the description does not explain the semantics of chain or contract parameters. It lists output categories rather than input meaning, so it only partially compensates for the undocumented parameters.

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 a token pre-trade check as the resource and lists the specific checks it combines: metadata, price, holder concentration, verification, and sanctions. This is distinct enough from most siblings, though it does not explicitly name a sibling to differentiate from.

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?

No when-to-use or when-not-to-use guidance is given, and no alternative tools are mentioned. The phrase 'pre-trade' implies timing, but the description does not explain how this tool compares to or conflicts with related tools like genesis402_screen_sanctions or genesis402_wallet_brief.

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?

The description discloses the cost (Paid $0.03 USDC), the heuristic nature of signals, and disclaimers that it is not KYC, compliance, or legal advice. It also mentions an evidence hash. These go beyond the annotations (readOnlyHint=false, openWorldHint=true) and inform the agent of important behavioral aspects.

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 sentences with no redundancy. The cost is front-loaded, followed by the core function and a clear disclaimer. Every clause adds value and the structure is easy to scan.

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 description covers the tool's purpose and key disclaimers, but lacks details on return structure (no output schema), the meaning of 'evidence hash', and when to use this vs. individual sibling tools. For a paid, multi-faceted tool, more completeness would be expected, though it is not severely deficient.

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 low at 33% (only payment_signature has a description). The description does not explain what chain or address are for, nor how they relate to the listed components. It adds no meaning beyond the schema, so it fails to compensate for the sparse parameter documentation.

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 and resource: 'Wallet risk signals in ONE call' and enumerates components (sanctions-list check, 10-chain scan, activity, summary) with an evidence hash. It distinguishes from siblings by emphasizing the combined, single-call nature, setting it apart from individual tools like screen_sanctions or multi_chain_scan.

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 'in ONE call' implies a comprehensive alternative to making separate calls, providing clear context for when this tool is appropriate. However, it does not explicitly name alternative tools or state when not to use it, such as when only a specific check is needed, so it stops short of full exclusion 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?

The description adds that the tool is paid at a fixed $0.004 USDC, which is a meaningful behavioral disclosure beyond the annotations. However, readOnlyHint=false and openWorldHint=true are not expanded on; the description doesn't explain that a real web request occurs or clarify the payment-signature sequence. It doesn't contradict the annotations.

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 front-loaded sentence with no filler, and the cost is placed before the function. It earns its length, though it sacrifices substance for brevity. As a structure, it is clean.

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

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

For a paid, open-world tool with no output schema, the description is incomplete: it omits how payment is handled, what max_chars controls, and how output is structured beyond 'clean text, title, headings and links.' It also doesn't signal usage boundaries relative to sibling extraction tools. An agent would need to infer or discover too much before calling it correctly.

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

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

With only 33% schema description coverage, the description needed to explain url and max_chars, but it doesn't. 'Any public web page' loosely maps to url, and max_chars is not mentioned at all. payment_signature is documented in the schema, but the description doesn't explain the quote-then-pay flow implied by 'Paid.'

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

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

The description clearly communicates the tool turns any public web page into clean text, title, headings and links, which is a specific resource and output. It does not explicitly contrast itself with sibling genesis402_extract_json, and the wording mirrors the title rather than adding a verb phrase, but the purpose is not vague.

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?

No guidance is given about when to choose this over alternatives such as genesis402_extract_json or genesis402_email_check. The phrase 'any public web page' implies a broad applicability, but there are no stated conditions, exclusions, or alternative tool names. This leaves routing entirely to the agent's 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?

It prominently discloses the $0.002 USDC cost, which is material behavioral context beyond the annotations, and clarifies that the data source is RDAP. The readOnlyHint=false does not contradict the description; the paid nature is a plausible reason the tool is not marked read-only, and no side effects are claimed either way.

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 cost warning is front-loaded, and the whole description is one tight sentence plus a useful fraud-signal parenthetical. There is no redundant or filler text.

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 usefully lists the expected return fields and covers the practical cost and fraud use case. It omits small operational details like error or quote-flow semantics, but the payment_signature schema description fills the main remaining 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?

The payment_signature parameter is already well documented in the schema, but the required domain parameter has no schema description. The description only implies that a bare domain is the input, without examples or guidance about URL formats, IDNs, or punycode.

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 enumerates the return fields (registrar, age, expiry, status, nameservers) and identifies RDAP as the source. It does not use an explicit action verb or name sibling tools, so it is clear but not fully differentiated beyond the whois-specific name.

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 parenthetical 'young domains are a fraud signal' implies a fraud-assessment use case, giving some selection context. However, it does not state when to prefer this tool over related checks such as email_check, sanctions screening, or wallet_brief, nor does it mention exclusions.

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