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?

The description provides exceptional transparency about the tool's x402 payment mechanism, including the exact cost ($0.03/call), the two-step workflow (call without x402_payment to get requirements, then with x402_payment for results), and the billing guarantee ('only charged when a result actually comes back'), far exceeding what any annotation would 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?

The description is efficient and front-loaded, starting with the crucial paid nature and general purpose, then transitioning to the step-by-step workflow without waste. However, the phrasing could be slightly tighter (e.g., splitting the long second sentence).

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 lacking an output schema, the description perfectly covers all practical gaps: the payment protocol, the mint address, and the fact that the tool is specific to Solana. Given the sibling tools (buy_api_key, x402_provider_risk, scan_token), this description uniquely clarifies when and how this paid Solana signal tool fits in.

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 description doesn't add parameter-specific details beyond what the schema already defines. Baseline 3 is correct.

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 ('pregraduate signals') and resource ('Solana mint'), then lists four concrete signal categories (bundled-launch detection, curve-aware holder concentration, Token-2022 traps, authority state), fully distinguishing it from siblings like scan_token or radar_alerts.

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 explicit when-to-use context ('for a Solana mint'), a required two-step payment protocol, and implicitly distinguishes from other tools by naming its unique paid signal category. The sibling names (e.g., buy_api_key, x402_provider_risk) are handled by the payment workflow description specifically.

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 provided, the description carries full burden. It discloses the paid nature ($0.01/call), non-custodial execution, 3% platform fee, and the two-step x402 payment flow. While it does not cover failure modes or transaction validity, the behavior is transparent enough for an agent to use the tool safely.

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 purpose and then explains the flow in a logical order. It is not overly verbose but could be slightly tighter. Every sentence adds necessary information, and the structure aids comprehension.

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, no output schema), the description covers the calling pattern, payment requirements, fee, and indicates what the tool returns (payment requirements or a transaction). The lack of an output schema is a minor gap, but the description compensates reasonably well.

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 the `x402_payment` parameter's role in the two-step flow and the `taker` parameter's implication for signing. It also clarifies that `sellAmount` is in base units, though the schema already says that. The extra context justifies a 4.

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 with a specific verb-resource: 'Executable EVM swap: a firm KyberSwap-routed quote plus a ready-to-sign transaction.' It immediately distinguishes itself from the sibling `swap_evm_price` by emphasizing execution over mere price quoting.

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 outlines the required two-step process (call without `x402_payment` to get payment requirements, then pay and call again with the payload). It mentions charging only on success and the need for an x402 client/wallet. However, it does not explicitly tell the agent when to prefer this tool over `swap_evm_price` or other siblings, leaving some inference needed.

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

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

With no annotations provided, the description fully discloses behavioral traits: the cost ($0.01/call), the two-step x402 payment requirement, the fact that charges only occur on result, and the output includes grade, score, verdict prose, and signals. This is comprehensive and exceeds what annotations would typically 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?

The description is a single dense paragraph that front-loads the cost and purpose, then explains the payment workflow. Every sentence adds value, though it could be slightly restructured (e.g., separating payment instructions from output description) for easier scanning.

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

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

The tool has no output schema, but the description lists expected return fields (grade, score, verdict prose, liquidity/holders/authority signals). It also fully explains the complex two-step payment process and cost model. For a paid API with a custom payment protocol, this is exceptionally 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%, but the description adds critical context beyond the schema: it explains that x402_payment must be omitted on the first call to receive payment requirements, and that the payment payload is base64. It also elaborates on the domain of 'chain' and 'address'. This adds meaningful semantic value.

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 token safety verdict (grade, score, verdict prose, signals) by chain and address, using the specific verb 'call' to retrieve it. It distinguishes from sibling tools like scan_token by emphasizing the paid safety rating focus and two-step payment flow.

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 explicit usage guidelines for the payment protocol (call without x402_payment first, then with payment) and clarifies charging only on success. However, it does not provide any guidance on when to use this tool versus siblings such as scan_token or pregrad_signals, which could be suitable alternatives for token assessment.

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.