Genesis402 by UnyKorn (x402 pay-per-call)

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

Annotations only give readOnlyHint=false and openWorldHint=true; the description carries far more — the exact price ($0.006 USDC), the two-call payment handshake (first call returns a quote with nothing charged or signed, second call with the signed payment settles), and the quote-verification behavior ('the rail verifies appears in the text'). This is precisely the behavioral context annotations cannot supply.

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: price and core purpose lead, siblings follow, payment mechanics close. Every sentence carries load. Slightly over-packed — the payment flow could be one sentence shorter — but nothing is 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?

An output schema exists so return values needn't be re-explained, and the description still covers the two-step paid-call workflow, the verification guarantee, and routing to siblings. For a paid, open-world tool with non-read-only semantics, this is complete enough to invoke correctly on the first try.

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

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

Schema coverage is 100%, so the baseline would be 3, but the description adds real semantics beyond the schema: the meaning of omitting payment_signature (quote-only, no charge) and the fact that the returned quote is machine-verified against the supplied text. It doesn't cover text length limits, but the schema already does.

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 ('answer one question strictly from a document'), plus the distinctive output ('the verbatim quote that supports the answer'). It names the two closest siblings (genesis402_summarize, genesis402_extract_json) and the conditions that select them, so an agent can differentiate it 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?

Explicit when-to-use ('contract, policy, filing or email questions where the answer must be traceable to the source') and explicit alternatives with their selecting conditions ('For an overview... use genesis402_summarize; to pull many named fields... use genesis402_extract_json'). Nothing is left 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?

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true): it discloses the price band ($0.001-$0.25 USDC on Base), that parameters are validated for free before any quote, that omitting payment_signature returns only a quote and signs nothing, and that paying returns the result plus settlement details. This is exactly the cost/authorization context an agent needs for a payment-gated 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?

Four sentences, front-loaded with purpose, then usage, then payment behavior. Dense but every sentence carries operational information; no filler or restated title.

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 complex dispatcher spanning 373 endpoints with nested params and a payment flow, the description covers pricing, name lookup, free validation, and both paid/unpaid return behavior. With an output schema present, return-value details need not be repeated, so nothing essential 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%, so the baseline is 3, but the description adds meaningful semantics: where endpoint names come from (genesis402_catalog) and the behavioral consequence of the optional payment_signature (quote vs. settled call). Some of this overlaps the schema's own parameter descriptions, so it is not fully additive, but it clarifies the intended call flow.

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 (calls) plus the exact resource (any of the 373 Genesis402 endpoints by name) and enumerates the categories covered. It explicitly positions itself as the generic fallback ('for any endpoint without a dedicated tool'), which cleanly separates it from the many dedicated siblings like genesis402_defi_yields and genesis402_web_extract.

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 explicit when-to-use ('any endpoint without a dedicated tool') and names the required prerequisite step and its alternative: 'look up the name and parameters with genesis402_catalog first.' The free-validation and quote-first flow further tells the agent how to invoke it safely before committing payment.

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 readOnlyHint/openWorldHint it discloses cost ('Free, no payment'), data provenance and freshness ('live /.well-known/x402 manifest, refreshed every 10 minutes'), result ceiling ('up to 400'), and the payer-mode states returned (QUOTE_ONLY, HOSTED, LIVE with cap). These are operationally material facts the annotations do not carry.

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-loads the key constraints (free, read-only, source) and stays dense with useful detail, but it is long for a one-parameter listing tool and the return-value enumeration slightly overlaps the 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?

An output schema exists, yet the description still frames the shape of the result (origin, total count, matched count, payer mode, endpoints), and it covers cost, freshness, limits, and the follow-up tool. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds value: it explains the filter's matching fields, gives concrete examples ('defi', 'sec', 'wiki'), and notes the behavioral consequence of omitting it (returns everything, up to 400).

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 ('Lists Genesis402 endpoints with name, HTTP path, USD price, title and parameter schema') and positions itself as the discovery surface versus the dedicated genesis402_* tools. An agent can distinguish it from siblings like genesis402_call or genesis402_sec_financials immediately.

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?

Explicitly says when to use it ('find an endpoint that has no dedicated genesis402_* tool'), what to do next ('pass its exact name and parameters to genesis402_call'), and when to narrow results ('Filter by keyword to keep the list short... with no filter it returns every endpoint'). Both the use case and the alternative path are named.

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?

Discloses the two-step paid workflow precisely: call once without payment_signature to receive a quote (nothing charged or signed), then call again with the signed payment to get results and settlement details, plus the $0.01 USDC cost. This is behavioral context the annotations (readOnlyHint=false, openWorldHint=true) do not convey. No contradiction: the description frames it as a lookup, consistent with a paid read that isn't strictly read-only due to payment.

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, price, and registries before detail; every sentence carries information (inputs, outputs, exclusions, payment flow). It is dense but a touch long, with the final payment sentence repeating the 'nothing is charged' idea already implied.

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?

An output schema exists, so return values need not be detailed. Given the payment complexity and multi-registry scope, the description covers inputs, scope limits, cost, and the two-call payment protocol, leaving nothing material for an agent to infer.

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 baseline is 3, but the description adds real meaning by mapping each accepted query form to its return content (LEI to parents/addresses, name to ranked live registrations, CIK to filer profile and filings) and by explaining the quote-then-pay semantics of payment_signature.

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 (look up one company) and enumerates the exact registries queried (GLEIF, SEC EDGAR), plus the three supported key types. This distinguishes it clearly from siblings like genesis402_sec_financials or genesis402_counterparty_report.

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 on which input key yields which output shape (LEI vs name vs CIK) and an explicit scope exclusion: 'Registry data only: not KYC, not a compliance determination, not legal advice.' It does not, however, name when to prefer a sibling tool such as genesis402_sanctions_name_screen for compliance screening, so guidance stops short of explicit alternatives.

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 only give readOnlyHint=false and openWorldHint=true; the description carries the real behavioral load, disclosing the $0.25 USDC price, the two-step payment handshake, the possible verdicts (clear/review/stop), the signed receipt, the 7-day PDF link and the public verify page. It also explains how vague names behave (returns review and names the assumed entity).

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 does and its price, then the pipeline, then the outputs, then caveats, then payment mechanics. Dense but every sentence carries information; only marginal trimming would be possible.

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, multi-step, composite tool with an output schema and full annotation coverage, the description covers inputs, pipeline, outputs, limits and payment flow completely. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents query (legal name or 20-char LEI), type, and payment_signature. The description adds behavioral context (vague names, quote-first flow) but no syntax or format detail beyond the schema, so the baseline 3 is appropriate.

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

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

States a specific verb and resource ('Check one company', 'Resolves the company in the GLEIF register... follows its registered direct and ultimate parent, and screens every name in that group'). This is clearly distinguished from siblings like genesis402_sanctions_name_screen and genesis402_company_lookup because it is a composite registry+group-screening+verdict 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?

Gives a clear context ('Check one company before you deal with it') and explicit exclusions ('not KYC, not a compliance determination, not legal advice'), plus a precise payment call-flow (call once without payment_signature for a quote, then again with the signed payment). It does not name sibling alternatives explicitly, so it falls just 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?

Annotations only flag readOnlyHint=false and openWorldHint=true, so the description adds the real behavioral payload: a $0.01 USDC cost, the two-step x402 payment handshake (quote first with no charge, then sign), the DefiLlama source, and an explicit caveat that APYs are variable and backward-looking and not investment advice. That is meaningfully beyond what the annotations convey and is consistent with readOnlyHint=false.

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-loads purpose, cost, source and filters, then routing, return shape, caveats and payment flow. Dense but each sentence carries information; the return-field enumeration and payment mechanics make it longer than strictly minimal, though nothing is genuinely 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?

Covers cost, payment protocol, filter interaction, default behavior, routing to alternatives, and return contents. With an output schema present it did not need to enumerate return fields, so doing so is bonus rather than gap; nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3 and the schema already defines each filter, its enum, bounds, and defaults. The description still adds cross-parameter semantics the schema cannot express: filters are optional, combine with AND, and the no-filter behavior defaults to pools above $1M TVL.

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 (ranked DeFi yield pools from DefiLlama, 15,000+ pools) plus the filter dimensions and the target question 'where is the best yield for X'. It also explicitly names sibling tools (genesis402_catalog, genesis402_call) for the cases it does not cover, so an agent can route without opening other schemas.

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 a concrete intended question ('where is the best yield for X'), an explicit alternative path for other DeFi/market data (search genesis402_catalog and call via genesis402_call), and clarifies that all filters are optional and combine with AND, with a defined no-filter default ($1M TVL top pools). That covers when-to-use, when-not, and alternative.

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 only say readOnlyHint=false and openWorldHint=true; the description adds the cost ($0.003 USDC), the exact two-call payment handshake, and a clear safety boundary ('DNS-only: no SMTP probe, no email sent, the mailbox is never contacted'). This explains why readOnlyHint is false (payment settlement) rather than contradicting it.

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-loads the cost and purpose, then layers usage, return summary, safety boundary, and payment mechanics with no wasted sentences. Slightly dense in a single paragraph, and payment is split between the first and last sentence, but every sentence carries distinct 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?

An output schema exists, so return values need not be spelled out, yet the description still summarizes them (MX, hosting provider, SPF/DMARC policy, disposable flag, 0-5 trust score). Combined with the payment flow and safety disclosure, an agent has everything needed to invoke 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?

Schema coverage is 100%, so both parameters are already documented, which sets a baseline of 3. The description goes further by explaining the semantics of the optional payment_signature as a two-step quote-then-pay flow ('nothing is charged or signed' on the first call), adding real meaning beyond the schema text.

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 ('Deliverability and trust check for an email address or domain') and immediately names the sibling it is not ('For the domain's registration age and registrar use genesis402_whois'). An agent can distinguish it from the whois and sanctions-screen siblings without opening a 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 explicit when-to-use ('vet a signup email or an inbound sender') and an explicit alternative with the condition that selects it (genesis402_whois for registration age/registrar). Nothing is left to inference.

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

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

Annotations only cover readOnlyHint=false and openWorldHint=true. The description adds material behavior beyond that: the $0.006 USDC charge, the two-call quote-then-sign flow where nothing is charged without a signature, and the anti-hallucination guarantee that unstated fields return null. These are non-obvious traits that meaningfully affect how an agent calls the tool.

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

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

Front-loaded with price and purpose, then use cases, sibling routing, parameter guidance, return contract, and payment flow. Every sentence carries information, though the combined payment and return explanation makes it denser than strictly necessary.

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 high complexity (nested object param, payment protocol, output schema), the description covers purpose, prerequisites, parameter crafting, return shape, and the full payment handshake. With an output schema present, it does not need to restate return values and correctly avoids that.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes further by explaining that field descriptions steer extraction and should carry units/formats, and it names the exact output contract ('one JSON object with exactly your keys'). That is real guidance beyond the schema's structural definitions.

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 ('pull the fields you define out of unstructured text as JSON') and distinguishes itself from genesis402_web_extract by naming that sibling as the upstream step. An agent can tell this is a schema-driven extraction tool, not a generic text fetcher.

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 use cases (emails, invoices, contracts, listings) and explicitly routes to genesis402_web_extract when the source is a web page. It also prescribes the exact payment call sequence, so the agent knows the correct invocation pattern rather than guessing.

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?

Annotation coverage is thin (readOnlyHint=false, openWorldHint=true), and the description more than compensates: it discloses the paid cost ($0.004 USDC), the two-phase x402 payment flow (quote call charges nothing, second call with signed payment settles), the data source (DefiLlama) with a no-advice disclaimer, and the no-zero-pricing edge case for stale coins. This is exactly the kind of context annotations cannot carry.

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

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

Front-loaded with purpose, then guidance, then return shape, then payment mechanics, then disclaimer — a logical order with no padding sentences. It is slightly long, and the payment flow is repeated in both the body and the schema description, which keeps it from a 5.

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 an output schema, the description still summarizes the return shape (one row per coin with price, both changes, timestamp, pricing confidence, plus advance/decline counts) and covers the stale-coin edge case. For a paid, open-world tool with no destructive semantics this is complete enough for confident 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 baseline is 3; the description adds real meaning by framing payment_signature as a two-call workflow (omit to get the quote, include the signed payment to receive results) and by restating that coins accepts CoinGecko ids or major-coin tickers with a default of the twelve major coins. It stops short of adding new syntax beyond the schema, so it sits just above baseline.

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 verb+resource (single-call USD price with 24h and 7d change for major coins, or up to 25 named coins) and explicitly positions itself against siblings, routing single-coin and contract-address lookups to genesis402_catalog/genesis402_call. An agent can distinguish it from the other market/pricing tools 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?

States the exact triggering condition ('use when you need more than one price at once: one payment instead of one per coin') and the exclusion (single coin or token by contract address → catalog + call). Both the when and the when-not are explicit, which is rare.

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

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

Goes well beyond the annotations by disclosing the price ($0.008 USDC) and the full x402 flow (call once for a free quote, call again with the signed payment). It also pre-empts failure modes an agent would otherwise misread: unavailable RPCs are listed separately and never counted as inactive, and receive-only addresses can legitimately show a zero nonce. This is exactly the kind of behavioral context structured fields cannot carry.

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?

It is long, but front-loaded with the paid price and the one-line purpose before details. Nearly every sentence carries a distinct fact (scope, exclusions, return shape, caveats, payment protocol), though the caveat cluster in the middle could be tightened slightly.

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?

An output schema exists, yet the description still summarizes the per-chain return shape (native balance, tx count, bytecode presence) plus the partial-failure list, which is what an agent needs to reason about incomplete results. Payment mechanics, scope, alternatives and caveats are all covered for a paid, open-world read tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: it explains why payment_signature exists (the two-call quote-then-pay cycle) and how to interpret the address's results, since activity is inferred from nonce, balance and code. It clarifies the semantics of the output fields rather than the parameter syntax, which is a modest but real value-add.

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 ('Sweeps one address across 10 EVM chains at once and reports where it is actually active') with the exact scope of the sweep. It explicitly distinguishes itself from siblings by naming what it does NOT do ('No risk scoring or sanctions check') and naming the sibling that does it. An agent can route 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?

Gives a concrete when-to-use ('find which networks an address uses before drilling into one chain') and an explicit alternative with its condition ('for that use genesis402_wallet_brief'). The two-step payment protocol is also spelled out as a usage instruction, not left to inference.

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

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

Annotations only mark it non-read-only and open-world, which says nothing about the two-step payment handshake. The description adds the exact price ($0.003 USDC), the quote-then-sign flow, and the assurance that the first call charges and signs nothing — critical context an agent cannot infer from structured fields.

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?

Price and scope lead, alternatives follow, and the payment mechanics close the block. Four sentences, each carrying distinct information with no filler or repetition of the 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 full schema coverage, an output schema handling return values, and the non-obvious payment protocol spelled out, nothing needed to call this correctly is missing. The description is complete for a paid, open-world search tool.

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

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

Schema description coverage is 100%, so q, sort, limit, from_year and payment_signature are already fully documented, including enum values and ranges. The description only restates ranking and result count, adding no syntax or format detail 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?

States a specific verb and resource ('Search scholarly literature in OpenAlex') plus what comes back (citation counts, open-access links), and explicitly distinguishes itself from arxiv-search and crossref-doi by use case. An agent can select this over its siblings 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?

Gives positive routing ('Use to find research, prior art or the most-cited work on a topic') and explicit alternatives with their conditions ('For preprints by recency search arXiv… for one known DOI use crossref-doi'). When-to-use and when-not-to-use are both covered.

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 only supply readOnlyHint=false and openWorldHint=true, so the description carries the real burden and does: exact price ($0.25 USDC), the quote-then-pay flow, that the rail stores the receipt but never the bytes, that content is labelled OBSERVED vs ATTESTED, and the honest limitation that it is not yet anchored on a public blockchain. This is unusually rich disclosure for a paid write operation.

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 and core purpose are front-loaded in the first sentence, and each subsequent sentence carries distinct information (routing, input choice, offline verification, privacy guarantee, limitation, payment flow). It is dense and slightly long, but nothing is clearly 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?

With an output schema present, the description need not detail return values, yet it still summarizes that the response is bound to the payment transaction and carries truth labels and limitations. Combined with the payment protocol and privacy guarantees, an agent has everything needed to invoke this paid tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: text is hashed by the rail and labelled OBSERVED, whereas a caller-supplied sha256 is labelled ATTESTED and keeps the content private, and the two are mutually exclusive. That privacy/labelling distinction goes beyond the field descriptions.

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

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

States a specific verb and resource: issuing one Ed25519-signed, hash-chained receipt proving a SHA-256 digest existed at payment time. It also explicitly distinguishes itself from the sibling lookup tool ('To look the receipt up later use genesis402_receipt (free)'), so an agent can separate prove-now from look-up-later 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 both when-to-use ('cheap timestamped proof that you held a document or statement') and when-to-use-something-else (genesis402_receipt for retrieval). It further routes between the two input modes, text vs sha256, and states they are mutually exclusive, plus the two-call payment protocol for obtaining a quote first.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations: it declares the tool is free and charges nothing, is idempotent, that an unknown id produces an HTTP 404 error, and the external data source. That is exactly the kind of cost and failure-mode context an agent needs before calling.

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-loads the most decision-relevant fact (free, read-only, idempotent) and is otherwise tight. The sentence enumerating returned fields duplicates the output schema slightly and could be trimmed.

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?

Covers the id source, the error case, and the no-charge behavior, and an output schema already documents the return shape. Only minor redundancy in listing returned fields keeps it from being fully lean.

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 schema description already explains that receipt_id comes from a paid call result or genesis402_prove with a 4-80 character range. The description restates that source but adds no new format or syntax detail, so baseline 3 applies.

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

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

States a specific verb (fetches) and resource (one receipt by id) and explicitly delimits scope: it does not list or search, and requires an exact id. An agent can separate this from listing-style siblings 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?

Gives clear triggers ('use after any paid call, or to check a genesis402_prove receipt') and a negative rule ('need the exact id'). It stops short of naming the sibling to use for listing/searching receipts, so it is not fully routable.

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 only supply readOnlyHint=false and openWorldHint=true, which are too coarse to explain this tool. The description fills the gap richly: paid at $0.02 USDC, the first no-signature call is free and returns a price quote, the second call with a signed payment produces the result plus settlement details, and returns are tri-state (match/possible match/no match) accompanied by list versions and their SHA-256. That is exactly the kind of behavior an agent needs before invoking a paid, open-world tool.

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

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

Front-loads cost and the core action, then the return shape, then sibling routing, then scope caveat, then the payment protocol. Dense but every sentence carries decision-relevant information; nothing is restated from the schema or annotations.

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

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

An output schema exists, so return values need not be enumerated, yet the description still summarizes the match tiers and per-hit fields. Combined with the payment handshake and scope disclaimer, an agent has everything required to call this paid, open-world tool correctly on the first attempt.

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

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

Schema coverage is 100%, so the baseline would be 3, but the description adds genuine meaning: it notes matching includes aliases and transliterations, that results carry matched name and score per hit, and that dob_year is used to flag inconsistent birth years. It stops short of adding syntax guidance beyond the schema, hence 4 rather than 5.

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 (screen a name) and names the exact list set covered (UN, US OFAC SDN, EU, UK consolidated). It also explicitly distinguishes itself from the two nearest siblings, genesis402_counterparty_report and genesis402_screen_sanctions, so an agent can route without opening a 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 explicit when-to-use routing: 'For a company and its parents in one call use genesis402_counterparty_report; for a wallet address use genesis402_screen_sanctions.' It also states the scope boundary ('Screening signal only: not KYC, not a compliance determination, not legal advice') and the required two-call payment sequence.

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

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

Goes well beyond the sparse annotations (readOnlyHint=false, openWorldHint=true) by disclosing the price ($0.008 USDC), the two-call quote-then-pay flow, what 'nothing is charged or signed' means on the first call, settlement details on the second, and explicit limitations ('absence from every list is not a clearance', 'not a compliance decision'). It also describes the return contents (per-list dataset name, fetch URL, entry count, evidence hash), which the annotations do not cover.

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 price and the core purpose, then usage, returns, caveats and the payment protocol in a logical order. It is dense and fairly long, but nearly every clause carries decision-relevant information; only minor trimming is possible.

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 an output schema exists, return values need not be explained, yet the description still summarizes the shape (match flag, per-list metadata, evidence hash). For a paid, open-world lookup with caveats and a two-step payment handshake, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds real meaning on top by clarifying that the address can be on any chain, that the first call requires no payment_signature, and that the second call must carry the signed quote to obtain a result. It does not restate format details already in the schema.

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

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

States a specific verb and resource ('List lookup for one address on any chain') plus the exact data sources (OFAC SDN digital-currency entries, community scam blocklists, Blockchain Fraud registry). It explicitly names the sibling it is not ('For balances plus sanctions plus a summary on an EVM address use genesis402_wallet_brief'), so an agent can distinguish it 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 a clear when-to-use ('fast, cheap first gate on a counterparty address') and names the specific alternative plus the condition that selects it (genesis402_wallet_brief for EVM balances + summary). It also states the call protocol: once without payment_signature for a quote, again with the signed payment.

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?

Discloses the full payment protocol (first call for a quote with nothing charged, second call with signed payment for result and settlement), the exact price ($0.01 USDC), and data-integrity behavior ('missing tags are marked unavailable, never estimated'). This far exceeds what the readOnlyHint=false/openWorldHint=true annotations convey and does not contradict them.

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 price and purpose, and every sentence is substantive. Slightly penalized because the payment protocol is stated twice (top and bottom) and 'Not investment advice' is boilerplate.

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?

Complete for a paid, open-world data tool: purpose, alternatives, input requirements, enumerated return fields, missing-data policy, and payment mechanics are all covered, so nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds value by clarifying the either/or requirement ('give ticker or cik; one is required') and by explaining the payment_signature two-step flow, which the schema documents only briefly.

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: as-reported fundamentals for one SEC filer from XBRL company facts. It distinguishes itself from siblings by routing other SEC data needs to genesis402_catalog/genesis402_call, so an agent can pick it apart from the other genesis402_* tools.

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 explicit when-to-use ('quick fundamentals without a data vendor') and names the alternative path for other SEC data ('search genesis402_catalog for "sec" and use genesis402_call'). It also states the input requirement ('give ticker or cik; one is required').

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

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

Goes well beyond the sparse annotations, disclosing the paid price ($0.006 USDC), the quote-then-sign payment dance, that nothing is charged on the first call, that it works only from supplied text, and that it runs on the provider's own GPU. This is the kind of behavioral context annotations do not carry.

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-loads the price and core action, then routes and payment mechanics. Dense and every sentence carries information, though it runs long enough that the routing and payment instructions compete for attention.

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?

An output schema exists, so return values need not be explained, yet the description still notes JSON output. For a paid, single-shot transformation tool, purpose, routing, constraints and payment flow are all covered.

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 parameters are already documented; the description reinforces the style options and the word limit and clarifies the payment_signature omission semantics. It adds marginal but real meaning over the schema baseline.

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 (summarize supplied text) plus the output modes, and explicitly differentiates from the URL-summarization path and the question-answering sibling. An agent can route correctly 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?

Explicitly says when to use it ('when the text is in hand') and names both alternatives: summarize-url via genesis402_call and genesis402_answer_from_text for a single question. The two-step payment precondition is also spelled out.

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

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

Annotations only declare readOnlyHint=false and openWorldHint=true; the description adds substantial context beyond them: the $0.03 USDC cost, the two-call quote-then-pay handshake, that unreadable parts are marked unavailable rather than zeroed, and that an evidence hash is returned. This is exactly the behavioral disclosure a paid, state-mutating tool needs.

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

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

Front-loads price and scope, then routing, then behavior, then payment mechanics – a sensible order with almost no filler. It is dense and long, but each sentence carries distinct information an agent needs before calling.

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?

An output schema exists so return values need no explanation, and the description still covers the payment workflow, evidence hash and unavailable-vs-zero semantics. For a paid, open-world tool with three parameters this is complete enough to invoke correctly.

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

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

Schema description coverage is 100%, so chain, contract and payment_signature are already fully documented in the schema. The description restates the contract-vs-wallet constraint and the payment pattern but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('pre-trade check for one ERC-20 token contract in a single call') and enumerates the exact outputs. It explicitly contrasts itself with genesis402_wallet_brief, so an agent can route between the token and wallet variants without opening a 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 an explicit trigger ('Use before buying, listing or accepting an unfamiliar token') and names the alternative sibling plus the condition that selects it ('For a wallet rather than a token use genesis402_wallet_brief'). Nothing about when to pick this tool is left to inference.

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

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

Annotations only say readOnlyHint=false and openWorldHint=true, but the description discloses the price ($0.006 USDC), the two-step quote-then-pay flow, that the first call charges nothing, and that the second call returns result plus settlement details. This is substantial behavioral context beyond the structured fields.

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-loads price and purpose, then routing, then payment mechanics. Every sentence earns its place, though the payment-flow sentence is dense enough that it could be tightened slightly.

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?

An output schema exists, so return details need not be enumerated; the description nonetheless notes the JSON result and settlement details, and fully covers the non-obvious payment protocol. Nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100%, so all four parameters (including payment_signature and from/to semantics) are already documented in the schema. The description adds only a light gloss on target-language breadth; baseline 3 is correct when the schema carries the detail.

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 (translate text) plus the scope (any major language, preserving names/numbers/formatting). It also names the sibling it is not (language-detect via genesis402_call), letting an agent distinguish it without opening a 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 use cases (customer messages, documents, UI strings) and an explicit alternative plus the condition that selects it ('To only identify a text's language call the language-detect endpoint'). Nothing is left 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?

Goes well beyond the annotations by disclosing the paid nature ($0.03 USDC), the two-step quote-then-sign payment protocol, the failure semantics ('a part that cannot be read is marked unavailable with the reason, never zeroed'), the evidence hash output, and explicit non-goals (not KYC, not a compliance determination, not legal advice). The readOnlyHint=false annotation is consistent with the payment/settlement behavior described.

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 price; sentence order (what it is → when to use → alternatives → returns → disclaimers → payment) is logical. It is dense with several sentences, but essentially every one carries distinct information; only minor tightening is possible.

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 3-parameter paid tool with an output schema, the description covers everything an agent needs: cost, payment handshake, scope of chains, per-part sourcing and unavailability behavior, disclaimers, and sibling routing. Nothing material 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 already 100%, so the baseline is 3, but the description adds real meaning: it explains chains scope ('recent activity on the chosen chain') and, crucially, the operational contract for payment_signature — omit it first to obtain an uncharged quote, resend with the signed payment. The address parameter itself adds nothing 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 ('Full risk brief for one EVM wallet in a single call') and enumerates the constituent parts: sanctions check, native balance/activity across 10 chains, recent chain activity, and a summary. It also names the sibling tools it is not, so an agent can distinguish it 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?

Gives an explicit usage trigger ('Use before sending funds to, or accepting funds from, an unknown address') and routes to three named alternatives with the condition that selects each: screen_sanctions for sanctions alone, multi_chain_scan for balances without risk signals, token_brief for token contracts.

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

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

Goes well beyond the sparse annotations (readOnlyHint=false, openWorldHint=true): discloses that no JavaScript is executed so client-rendered pages come back thin, that private/internal addresses are refused, that login/paywall pages fail, and the two-call payment quote-then-pay flow. That is exactly the operational context an agent needs before spending money on a 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-loads the cost and the core action, then routes to siblings and enumerates return fields and caveats. Dense and mostly earning its sentences, though the return-field enumeration is long and the payment protocol sentence could be tighter.

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?

Even though an output schema exists, the description's caveats (no JS, address refusal, paywall, truncation) and the paid-call protocol cover the decision-relevant gaps. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3; the description adds value by explaining that text is 'capped at max_chars' and by spelling out the payment_signature protocol (omit to get a quote, nothing charged without it). It does not add much beyond the schema for url/include_links, so it is an add-on rather than a full compensation.

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 ('server-side fetch of one public web page, returned as clean readable text') and immediately distinguishes itself from genesis402_extract_json and genesis402_whois. An agent can identify the tool 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?

'Use when you need a page's actual content' sets the trigger, and two named alternatives with their own conditions (field extraction -> extract_json, domain registration -> whois) are given. Explicit routing rather than implied usage.

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?

Discloses pricing ($0.003 USDC), the two-step payment/auth flow (call once without payment_signature for a quote, then again with the signed payment), and what is returned (registrar, dates, domain age, expiry, status, nameservers, DNSSEC). This is rich behavioral context well beyond the readOnlyHint/openWorldHint annotations, and the payment-settlement mechanic explains why readOnlyHint is false without contradicting anything.

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, then usage, alternatives, return fields, and the payment flow. Every sentence earns its place — no redundancy, and the operational detail (payment) is placed after the routing guidance.

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 a 2-param schema, full schema coverage, an output schema, and annotations, the description covers purpose, alternatives, return contents, and the non-obvious payment flow. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so both parameters (domain and payment_signature) are already documented in the schema. The description reinforces the payment_signature usage flow but adds no syntax or format detail beyond what the schema provides; 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+resource+scope: 'Registry data for one domain via RDAP.' It clearly identifies what is being looked up and the data source, and the additional framing ('Young domains are a common phishing and fraud signal') explains the intent, distinguishing it from sibling tools.

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?

Explicitly names when to use it ('Use to vet a website or counterparty domain') and routes to alternatives by condition: 'For mail setup (MX, SPF, DMARC) use genesis402_email_check; for page content use genesis402_web_extract.' Both the when and the when-not are covered.

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