hostdefi-x402

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

With no annotations, the description carries full burden and discloses key behaviors: it's a paid operation ($5), one-time payment, key returned in response, no account/signup, batch enabled, and payment is conditional on receiving a result. Could mention error handling or idempotency, but current detail is strong for a purchase 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?

The description is front-loaded with the core purpose and cost, then efficiently explains the two-step process. Every sentence adds necessary information without redundancy. No wasted words.

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 mentions the key arrives in the paid response and the first response contains an 'accepts' array. It doesn't specify exact response shapes, but provides enough for an agent to extract the needed data. Slightly lacking in response structure detail, but still robust.

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 single parameter 'x402_payment' is described in schema as 'base64 X-PAYMENT payload'. The description adds crucial meaning: explains it's used only in the second call and that its value comes from the first call's response. This goes well beyond the schema definition.

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 mints a 30-day HostDeFi Agent-plan API key for $5, with specific call limits and batch capability. It distinguishes well from sibling tools (pricing, signals, alerts, etc.) which serve different purposes.

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?

Provides explicit two-step process: first call without x402_payment to get payment requirements, then pay and call again with x402_payment. It explains the payment flow and that you're only charged on success. Lacks an explicit note about alternatives (e.g., when to use get_x402_pricing instead), but the context is clear enough for an agent.

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

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

With no annotations provided, the description carries full burden. It discloses that the tool is free to call (FREE) and what it returns (prices and settlement rails). However, it does not mention any behavioral traits such as idempotency, caching, or rate limits, which would be helpful for a read-only catalog 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?

The description is a single sentence with no wasted words. It front-loads the cost indication ('FREE'), then clearly states the purpose and content. Every word earns its place.

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

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

For a simple parameterless tool, the description gives the high-level return content (catalog of prices and settlement rails). However, with no output schema, it lacks details on the structure (e.g., list vs object, field names, optional fields). It is sufficient for basic understanding but not fully comprehensive.

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

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

The input schema has zero parameters, so schema coverage is 100% by default. The description adds no parameter-specific information because there are none. Per rubric, baseline 3 is appropriate when the schema already covers the 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 states the tool returns 'the HostDeFi machine-payable price catalog: every paid resource, its USD price and settlement rails.' This is a specific verb-resource combination (get catalog) and distinguishes it from siblings like buy_api_key (purchase) or swap_evm_price (single swap price).

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

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

The description implies the tool is a reference catalog for prices, but it provides no explicit guidance on when to use it versus alternatives (e.g., before buying, to compare settlement rails). There is no when-not or exclusionary language.

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

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

No annotations are provided, so the description carries the full burden. It transparently discloses the cost ($0.02/call), the 404 behavior for untracked markets, the payment requirement, and the fact that charging only occurs on successful results. This is substantial behavioral context that goes beyond what the schema provides. It could be more explicit about rate limits or error handling, but the payment and cost transparency is excellent.

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 dense but well-structured: it front-loads the paid nature and core function, then details the data format and workflow. Every sentence adds critical information, and the payment flow is explained concisely but completely. No wasted words.

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

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

Given the complexity of the payment workflow and lack of annotations, the description is remarkably complete. It explains the cost, the data format, the error case (404), the two-call payment process, and the charging behavior. There's no output schema, but the description explicitly defines the return format ([ts, yesUsd, noUsd]). This covers everything an agent needs to call this 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 description coverage is 100%, so the schema already documents both parameters. However, the description adds critical meaning: it explains that marketId comes from predict_markets, and it details the exact format and usage of x402_payment (base64 X-PAYMENT payload). This adds value beyond the schema's basic descriptions, particularly for the payment workflow.

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

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

The description clearly states the tool fetches 24h odds history for a tracked Polymarket market, specifying the exact data format and sampling rate. It is distinct from siblings like predict_markets (which likely provides market metadata) and clearly describes its unique function.

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 explains when to use this tool (for historical odds data) and implicitly differentiates from siblings (e.g., predict_markets for other data). It also provides crucial usage instructions for the x402 payment workflow, including the two-call process. However, it doesn't explicitly mention when not to use it or name direct alternatives, but the payment flow guidance is strong.

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

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

With no annotations, the description carries the full burden and discloses the key behaviors: the $0.005/call cost, the two-step payment prerequisite, the charge-only-when-a-result-returns condition, and the data provenance from HostDeFi's recorded series. It does not cover failure/error behavior, but the critical payment and auth behaviors are explicit.

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 dense but economical: the first sentence establishes cost and scope, the second details the two-call payment workflow, and the third clarifies the billing trigger. There is no filler, and every sentence contributes to correct invocation.

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 data tool with no output schema and no annotations, the description covers the most important operational context: payment flow, billing behavior, data fields, and data source. It falls short of defining `limit` semantics or the exact response structure and error cases, which an autonomous agent might still need.

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 description adds real meaning to x402_payment by explaining how to obtain the payload and when to include it, going beyond the schema's one-line description. However, the `limit` parameter is never explained beyond its schema min/max, leaving its role as the market count implicit. With only 50% schema coverage, this is a partial but notable 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 clearly identifies the resource (Polymarket prediction markets tracked by HostDeFi), the scope (top ~100 by 24h volume), and the specific returned fields (market ids, questions, latest yes/no odds, sampling stats). This is precise enough to distinguish it from siblings like predict_history even without naming them explicitly.

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

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

The description provides an explicit invocation protocol: call without x402_payment to receive the `accepts` array, pay via any x402 client/wallet, then call again with the base64 payload. It also clarifies when charges occur. It does not compare against sibling tools, but the operational when-to-call flow is unambiguous.

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

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

Since no annotations are provided, the description carries the burden of behavioral disclosure. It transparently explains that the tool is paid, requires a preliminary call to obtain payment requirements, and that charges occur only when a result is returned. This is valuable context for an agent. It doesn't mention side effects like data mutation, but the tool appears read-only from its purpose.

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 moderately long but information-dense. It effectively communicates the necessary payment workflow without redundant wording. It is well-structured with semicolons and a clear sequence, making it easy to parse.

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, required input, payment handling, and charging behavior. It lacks an explicit description of the output format, but since no output schema is provided and the tool's purpose is clear, this is not a major omission. Overall, it provides enough context for an agent to use the 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?

The schema already describes both parameters (mint as Solana mint address, x402_payment as base64 payload). The description adds meaningful context by explaining the payment flow and how x402_payment is used (optional initially, required after payment), which goes beyond the schema's basic descriptions.

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

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

The description clearly states the tool's purpose: providing pre-graduation on-chain signals for a Solana mint, and enumerates specific signal types (bundled-launch detection, curve-aware holder concentration, Token-2022 traps, authority state). This distinguishes it from sibling tools like token_report or token_risk_deep.

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 clear usage instructions, including the two-step payment workflow (call without x402_payment first to get requirements, then pay and call again) and the charging condition. However, it does not explicitly compare to alternative tools or state when to prefer this over others, falling short of the full 'when/when-not' 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?

No annotations were provided, so the description carries full burden. It clearly discloses the tool is paid ($0.01/call), describes the x402 payment protocol requirements, explains when charges occur (only on success), and specifies the two-call workflow. This is exemplary transparency for a payment-gated 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?

Every sentence serves a purpose: states cost, what the tool returns, payment workflow in two clear steps, and billing policy. No wasted words. The structure is front-loaded with key details, and all information is 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?

Given the tool's complexity (paid, requires payment protocol, simple parameters, no output schema), the description completely covers the essential context. It explains the two-call dance, cost, charging policy, and data nature. No gaps remain for an agent to effectively invoke the 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 50%: the x402_payment parameter has a description in the schema ('base64 X-PAYLOAD payload'), and the description adds context about its role in the payment workflow. The limit parameter lacks a description in both schema and description, though its purpose is somewhat implied by 'alerts.' With moderate coverage and a simple integer parameter, a score of 3 is appropriate.

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

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

The description clearly states the tool returns 'Recent HostDeFi trend-radar alerts: big dated movers with real market cap, structured JSON.' It specifies a verb ('alerts') and a data source (trend-radar), distinguishing it from siblings like scan_token, token_risk_verdict, etc. The resource and return type are explicit.

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

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

The description provides an explicit two-step payment workflow: call once without x402_payment to get payment requirements, then pay and call again with x402_payment. It warns 'You are only charged when a result actually comes back.' This is high-quality guidance that explains exactly when and how to use the tool.

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

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

With no annotations, the description carries the full burden and does well: it discloses cost (FREE), auth requirements (none), rate limits (100/day), source (same as hostdefi.com/scan), and output behavior (concerning/legitimate signals). It does not cover error handling or exact return format, but these are secondary for a read-only scan 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?

The description is two well-structured sentences that pack in all essential details: input, output, cost, rate limit, and provenance. There is no fluff, and key value ('FREE.') is front-loaded.

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

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

For a simple one-parameter tool with no output schema, the description is thorough: it explains different input formats, what the risk report contains, and constraints like fair use and no signup. It lacks an explicit return schema or not-found behavior, but the overall context is sufficiently complete for an agent to use it effectively.

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

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

The schema already documents the single 'token' parameter with 100% coverage, so the baseline is 3. The description adds a bit of nuance by emphasizing 'exact token name/ticker' and specifying supported address types, but it largely mirrors the schema description rather than adding substantial new meaning.

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

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

The description uses a specific verb ('scan') and resource ('token-safety scan'), and clearly defines input types (Solana mint, EVM address, exact token name/ticker) and output (structured risk read with listed signals). However, it does not explicitly differentiate from the sibling tool token_risk_verdict, so it does not fully earn a 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?

It clearly states when to use the tool: for token-safety scanning by passing a contract address, Solana mint, or exact token name/ticker. It also provides practical usage context (free, no signup, 100 checks/day per IP) but does not explicitly mention alternatives or exclusionary cases, so it falls short of 5.

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

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

No annotations are provided, so the description fully carries the burden. It discloses payment requirements ($0.002/call, charged only when a result returns), the two-phase flow, and the x402 payment mechanism. This is comprehensive for a paid preview 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?

The description is three sentences long and front-loads the key purpose and cost. It could be slightly more structured (e.g., adding a separator between phases), but every sentence earns its place with essential information. Minor inefficiency in the second sentence's length.

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

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

Given there is no output schema, the description adequately covers the return values (expected and minimum output) and the two-phase process. It also explains when the cost is incurred. For a preview tool with a clear calling pattern, this is complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining how the optional x402_payment parameter is used in the two-phase flow, which is not apparent from the schema alone. No additional details on chain ID or token formats are needed.

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 specifies the tool is for previewing expected and minimum output for an EVM swap before committing to a firm quote, distinguishing it from siblings like swap_evm_quote, which likely provides a firm quote. The verb "preview" and resource "swap price" are clear.

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 explains the two-phase calling pattern: call once without x402_payment to get payment requirements, then pay a requirement and call again with x402_payment. It also states the tool is for looking before swapping, implying it should be used before requesting a firm quote from swap_evm_quote.

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

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

With no annotations, the description carries the full burden and does so thoroughly: discloses the $0.01/call cost, the 1% native-coin platform fee priced into the transaction, non-custodial execution, the two-step x402 payment requirement, and the charge-only-on-result policy. This is substantial behavior beyond what the schema reveals.

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?

Every sentence earns its place: cost, purpose, fee, two-call workflow, and charging condition are all necessary operational facts. The description is dense but logically ordered and contains no filler or redundant restatement of schema fields.

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, two-step swap tool with no output schema, the description covers the essential context: cost, fee, taker requirement, payment flow, and what comes back (a transaction and an accepts array). Exact quote/tx field details are not specified, but an agent has enough to invoke the 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?

The input schema already documents all 7 parameters at 100% coverage with detailed descriptions, so the tool description does not need to add per-parameter meaning. It reinforces that taker means the user's own wallet and that ref affects the fee, but it adds no new parameter semantics beyond the schema. Baseline 3 is appropriate.

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

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

States a specific action and deliverable: an executable KyberSwap-routed quote plus a ready-to-sign transaction for the taker's OWN wallet. The word 'Executable' and 'non-custodial' clearly separate it from a price-only tool like swap_evm_price, so an agent can distinguish 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?

Gives explicit when-to-call guidance: call once WITHOUT x402_payment to receive the x402 payment requirements, pay one of them, then call again with x402_payment set. It also warns the tool is PAID and only charges when a result returns. It does not name alternatives or exclusions, but the invocation context is clear.

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

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

Since no annotations are provided, the description carries full responsibility for behavioral disclosure. It discloses the paid nature ($0.02/call), the fail-closed flag logic, and the fact that charging only happens on successful result (not for the initial requirement-fetch call). However, it doesn't disclose rate limits, token consumption details, or what happens if the payment is invalid, which could be relevant for an agent. The core behavior is well covered, but a few gaps remain.

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, dense paragraph that front-loads the paid nature and safety pre-reads, then details the two-step payment flow. It's detailed but not bloated; every sentence adds necessary context. The structure could be improved by breaking into separate sentences for readability, but it's efficient and information-dense without redundancy.

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

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

For a tool with no output schema and no annotations, the description covers the payment workflow, the meaning of the returned safety flags, and the fail-closed logic. An agent can correctly call this tool in two steps and interpret the core result. It lacks details on error handling (e.g., what if payment is reject) and doesn't explain the exact structure of the accept array, but these are secondary. The essential context for usage is present.

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 67%, meaning two of three parameters (chain, x402_payment) have descriptions. The description adds value for x402_payment by explaining it's a base64 X-PAYMENT payload from the first call's accept array, which the schema partially conveys. It also implies chain is optional with a default. However, the limit parameter is well-defined by the schema, and the description doesn't add substantial new meaning beyond what the schema provides, so a 3 is appropriate.

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

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

The description clearly states the tool retrieves fresh token launches with safety pre-reads, specifying the resource (token launches) and the value-add (HostDeFi safety checks). It distinguishes itself from siblings by noting the baked-in safety annotations, though a direct sibling comparison is not made. The verb is implied but the purpose is unambiguous.

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

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

The description provides an explicit two-step workflow: first call without x402_payment to receive payment requirements, then pay and call again with the base64 payload. It also clarifies that charges only occur when a result is returned, which is a critical usage constraint. No alternative tools are mentioned, but the paid nature and payment flow are clearly explained.

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 transparently discloses the cost ($0.35/call), the two-step payment process, and the condition that billing occurs only when a result is returned. No annotations exist, so this transparency is crucial.

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 sentence with two main clauses—purpose and payment instructions. It is dense but efficient, front-loading the core purpose before explaining the workflow.

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

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

Despite having no output schema, the description outlines the components of the report and explains the payment flow. It gives a sufficient mental model of the tool's behavior and expected results.

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

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

The schema already provides descriptions for all parameters (chain, address, x402_payment). The tool description does not add new parameter semantics beyond what is in the schema, so it meets the baseline of 3 for high schema coverage.

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 provides a full due-diligence report with specific components (verdict, on-chain signals, history, trend radar, rug-ledger cross-check). It is distinct from siblings like token_risk_verdict or scan_token by emphasizing it as a comprehensive 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?

The description gives payment workflow instructions but does not provide any guidance on when to use this tool versus alternatives like token_risk_verdict or token_risk_deep. It lacks explicit selection criteria.

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

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

With no annotations provided, the description carries the full burden. It discloses the paid nature ($0.25/call), the payment mechanism, the data source ('computed from recorded rows — no projections'), the history depth start date, and the condition for being charged. This is exceptionally transparent for a tool with no 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 paragraph but well-structured: it starts with the core purpose and cost, then details the return contents, then the payment workflow. Every sentence adds value; it is compact given the complexity of the payment flow. Not excessively wordy.

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 what is returned (verdict, history, trend block), how to pay (two-step process), the pricing, the data source, and the charging condition. Since there is no output schema, the description adequately explains the return structure and usage conditions. Nothing critical 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 all four parameters. The description adds a small clarification for x402_payment ('omit on the first call to get payment requirements') but does not meaningfully enhance the semantics of chain, address, or limit beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states this is a paid deep report for a token: 'Deep HostDeFi report in one call' with a verdict, history, and trend block. It is visually distinct from the sibling token_risk_verdict, which likely returns a simpler verdict. The verb 'report' is specific, and the resource (token risk) is unambiguous.

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

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

The description explicitly explains the two-step payment flow: call once without x402_payment to receive requirements, then pay and call again. It also states the cost and that you are only charged when a result returns. This is precise usage guidance with no ambiguity.

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

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

Since no annotations are provided, the description must carry the full behavioral burden. It clearly discloses the cost, the payment requirement, the two-phase calling pattern, and that charges only occur when a result is returned. It also explains the output components (grade, score, prose, signals) which helps set expectations. This is comprehensive for a paid API 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?

The description is a single, well-structured paragraph that front-loads the most important information: cost and the two-step payment process. Every sentence adds critical operational detail (cost, output, payment flow, charge condition). There is no fluff or redundancy; it is appropriately sized for the complexity of a paid two-phase API.

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

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

Given the tool's complexity (paid, two-step, output composition) and lack of annotations or output schema, the description is remarkably complete. It covers the payment protocol, the exact parameters' usage, and the expected result. An agent has everything it needs to correctly call this tool without additional documentation, making this a top-tier definition.

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 covers 100% of parameters with descriptions, so the baseline is 3. The description adds significant value by explaining the special semantics of x402_payment (omit on first call to receive requirements, then set to the base64 payload). This goes beyond the schema's generic description, clarifying the workflow. It doesn't elaborate on chain/address formats, but the schema already lists examples, so this is a strong score.

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

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

The description clearly states the tool's purpose: it provides a paid token safety verdict (grade, score, prose) for a given chain and address. It distinguishes itself from siblings like token_report and token_risk_deep by specifying the A–F grading system and the specific signals (liquidity, holders, authority), making it a unique offering among the tool set.

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 outlines the two-step paid workflow: first call without x402_payment to receive payment requirements, then call with the payment payload. It mentions the cost ($0.02/call) and the use of any x402 client/wallet. It doesn't name alternatives, but the payment flow is the critical usage context, and the tool's uniqueness makes alternatives less relevant. However, it could have mentioned that for deeper risk analysis, one might use token_risk_deep, but the description's focus on the payment process is adequate for correct 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?

Annotations are none, so the description carries the full burden. It fully discloses the behavioral traits: it is PAID ($0.10/call), charges only when a result actually comes back, requires a two-step payment flow, and outputs a verdict path. This is a comprehensive disclosure of the tool's cost, payment mechanism, and output structure, which is essential for an agent to avoid unexpected charges.

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 reasonably concise for the complexity, but it front-loads the pricing and key differentiators early. Each sentence adds value: it states the purpose, cost, what it is not, and the payment flow. It could be slightly tighter, but it's efficient without waste.

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

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

Given the tool's complexity (payment flow, multiple risk checks, cost), the description is complete. It covers the purpose, the payment prerequisites, what is returned (verdict path, exposure counts, cross-check), and the cost. No output schema exists, but the description sufficiently describes the return format. An agent can call this 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 schema already documents both parameters. The description adds meaning beyond the schema: it explains that x402_payment is the base64 payload from the payment step and that the wallet is a Solana wallet address. However, it doesn't detail format specifics like that the wallet must be base58 (though schema says that), but the description does add the payment flow context for the 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 clearly states the specific verb (read) and resource (wallet risk-exposure), and details what it does: grading largest holdings, exposure counts by risk tier, and a rug-ledger symbol cross-check. It also distinguishes itself from AML attribution or sanctions screening, and the sibling list includes tools like token_risk_verdict and token_risk_deep, but this one is about wallet-level exposure, making it distinct.

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 provides explicit usage instructions: call once without x402_payment to receive payment requirements, then pay and call again with the payload. It also clarifies what it is NOT (not AML attribution or sanctions screening), which helps an agent decide when to use this tool vs alternatives. This is a clear when-to-use and how-to-use guide.

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

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

With no annotations provided, the description carries full burden. It discloses the two-step payment flow, that results are dated crawl snapshots, and that the user is only charged when a result returns. This is substantial behavioral context, though it omits details like error handling, rate limits, or what happens if the resource is invalid.

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

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

The description is three sentences, each packed with essential information. It front-loads the cost and urgency ('BEFORE paying it'), then provides clear step-by-step instructions. There is minimal verbosity, but the density of information could be slightly overwhelming. Still, it earns its place.

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

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

Without an output schema, the description fills the gap by explaining the return value: an A–F grade and an 'accepts' array. It also covers the payment flow. While it does not detail error scenarios or edge cases, it provides sufficient context for a specialized vetting tool with moderate complexity.

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

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

Schema description coverage is 100% (both parameters have descriptions in the schema). The description adds no new information about the parameters beyond what the schema already provides. It does clarify the two-step usage flow, but that is not parameter semantics per se. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Vet an x402 seller BEFORE paying it: A–F grade from observable signals'. It specifies the resource (x402 seller) and action (vet/grade), and distinguishes it from sibling tools like buy_api_key or get_x402_pricing by focusing on assessment before payment.

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 provides explicit instructions: call once without x402_payment to get payment requirements, then call again with the payload. It also notes the cost ($0.02/call) and that charges only occur on result. However, it does not explicitly compare to sibling tools or state when not to use this tool.

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