Agent Tools (x402 pay-per-call)

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

With no annotations provided, the description carries the full behavioral burden and adds useful context: deterministic search, no LLM, $0.002 USDC cost on Solana via x402. It does not explain payment failure behavior, auth requirements, rate limits, or the free-trial flow beyond what is implied by the schema.

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

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

The description is compact and front-loaded: the core purpose appears first, followed by the input shape, optional parameter guidance, and cost. Every sentence carries useful information and there is no wasted prose.

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

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

There is no output schema, but the description explicitly lists the returned operation details: method, path, parameters, request body fields, and auth. Given the absence of annotations, it also discloses determinism and cost, though it leaves some payment-flow and failure-mode details to the schema.

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 moderate at 60%, and the description maps the required `{api, query}` inputs plus optional `spec_url` with a useful condition: use it when you already know the spec. It does not add meaning for `free_trial` or `x402_payment`, and it does not clarify the expected format of `api` beyond the schema.

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

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

The description states a specific verb and resource: it finds the exact operation in a public API's OpenAPI spec for a task, and it enumerates the useful return fields (method, path, parameters, request body fields, auth). It also differentiates itself behaviorally as deterministic and non-LLM, but it does not explicitly distinguish itself from the sibling `api_lookup` 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?

The description gives the required input shape `{api, query}` and notes that `spec_url` is optional when the spec is already known, which provides some usage context. However, it does not state when to use this tool versus `api_lookup`, nor does it give explicit exclusions for when not to use it.

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

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

With no annotations, the description carries the behavioral burden and discloses important traits: output is LLM-condensed, cached for 7 days, costs $0.005 USDC via Solana/x402, and the schema exposes a free tier. It does not fully explain the payment flow or error behavior, but it provides substantial operational context.

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

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

The description is densely front-loaded and appropriately sized: purpose and output are stated first, followed by input, optional question, and cost. Every sentence carries useful information with no 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?

There is no output schema, so the description helpfully explains what is returned: base URL, auth scheme, rate-limit and error notes, key endpoints, and source links. It also mentions caching and cost, though it stops short of fully documenting payment failure or no-match behavior.

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 repeats the api input forms and optional question, but does not add meaning beyond the schema for free_trial or x402_payment.

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

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

The description states a specific verb and resource: it looks up a public API's OpenAPI spec, llms.txt/docs, and returns metadata such as base URL, auth scheme, and key endpoints. This is clear, but it does not explicitly distinguish itself from the sibling api_endpoint tool, so it falls short of the top score for sibling differentiation.

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

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

The description implies usage by explaining that it finds API specs and docs and accepts an optional focus question, but it never explicitly says when to choose this tool over api_endpoint or other alternatives. There are no exclusions or prerequisite guidance beyond the payment note.

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 reasonably well: it discloses crawl scope (homepage plus contact/about pages), output types, and the $0.005 USDC payment mechanism. It does not mention rate limits, failure behavior when no contacts are found, or crawl politeness, which leaves some behavioral gaps.

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

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

Two sentences with zero waste: purpose first, then input alternatives, then cost. Every clause carries distinct information and the pricing detail is placed at the end where it is easy to find.

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

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

No output schema exists, so the description appropriately enumerates return values, and it covers input shape and cost. It is nearly complete, but for a paid crawl tool with no annotations it could do more to set expectations around empty results, crawl depth limits, or rate-limiting behavior.

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 75%, with url and free_trial/x402_payment already documented in the schema. The description only adds the either/or relationship between url and domain ('Input: {url} or {domain}') and does not explain the undocumented domain parameter or the payment flow beyond its price, so it adds marginal value over the schema.

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

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

The description gives a precise verb and scope: crawl a domain's homepage plus contact/about pages and return specific enrichment fields (emails, phones, socials, title/description, tech). It is clear enough that an agent knows exactly what resource is produced, but it does not explicitly differentiate from the sibling url_to_markdown, which also operates on a URL.

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

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

Usage is implied by 'Company/website enrichment' and the contact-focused output, but there is no explicit statement of when to choose this over siblings like url_to_markdown or api_lookup, nor any exclusions. The 'Input: {url} or {domain}' note gives some invocation context but stops short of guidance.

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

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

With no annotations, the description carries the full burden and does disclose the key operational trait: the call costs $0.003 USDC on Solana via x402, which an agent must know before invoking. It stops short of explaining the x402 handshake, rate limits beyond the schema's free-tier field, or failure modes, so it is not a 5.

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

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

A single dense line that front-loads the capability and return fields before the input and cost. No sentence is wasted, though punctuation and the terse 'Input: {mint}' phrasing slightly reduce readability.

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 annotations and no output schema, the description does well to enumerate returned fields and payment cost. However, it doesn't explain the x402 payment flow, how free_trial relates to x402_payment, or how the rug-risk flags are derived/thresholded, leaving agents to infer key behavior.

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 defines mint, free_trial, and x402_payment. The description's 'Input: {mint}' adds no format or syntax detail beyond what the schema says, matching the baseline for full 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 uses a specific verb+resource ('Solana SPL token snapshot + rug-risk flags') and enumerates returned fields (name/symbol, supply, decimals, price, authority status, holder concentration, token program), so an agent knows exactly what data it yields. It does not differentiate from the sibling token_verdict, which likely overlaps, so it stops short of 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?

Usage is only implied by the snapshot purpose; there is no explicit when-to-use, when-not-to-use, or routing to token_verdict. The payment note hints at a precondition but doesn't frame it as guidance.

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

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

With no annotations, the description carries the full burden and does disclose non-obvious traits: the LLM backing it (Llama 3.1 8B fp8), a per-call cost of $0.003 USDC on Solana via x402, which is exactly the auth/payment context an agent needs before invoking. It stops short of describing failure modes, rate limits, or precedence when both inputs are provided.

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

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

Two compact sentences with the core purpose front-loaded and cost/model details trailing, so nothing is buried. The parenthetical model tag and terse 'Input: {text} or {url}' notation are slightly schematically worded, but no sentence is wasted.

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

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

For a paid, unannotated, no-output-schema tool, the description covers what an agent most needs: supported inputs, output form (bullet points), cost and payment protocol, and model choice. Remaining gaps are which input wins when both are passed and any output-length behavior tied to max_words.

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 75%, just below the high-coverage threshold; the undocumented parameter is max_words, which the description names but doesn't define (units, defaults, or bounds). The description adds the optionality and either/or nature of text vs url, but contributes little beyond the schema for x402_payment aside from flagging that payment is priced in USDC.

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 (summarize) with two concrete resource types (text or web page URL) and the output shape (concise bullet points), plus the backing model. It is clear but does not explicitly distinguish itself from the sibling url_to_markdown, so sibling differentiation is left implicit.

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 'Input: {text} or {url}' phrasing implies that either an inline document or a fetched page is acceptable, and the cost note hints at a paid-operation context. However, there is no explicit when-to-use guidance, no statement on which to prefer when both are supplied, and no routing hint toward alternatives such as url_to_markdown.

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 zero annotations the description carries the full burden and mostly does: it discloses the data sources (on-chain proxy/owner/bytecode/mint-authority checks plus DEX pool metrics), the cost ($0.008 USDC, x402 on Solana), and the non-advice disclaimer. It omits latency expectations, failure modes on unknown tokens, and whether payment is settled before or after a result is returned.

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

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

One dense scoped sentence plus a compact input signature; the scope and output format are front-loaded. The 'Not financial advice' clause is boilerplate but short enough to be tolerable.

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-chain analysis tool with no output schema and no annotations, the description covers purpose, inputs, data sources, and pricing — enough to call it correctly. The remaining gap is response shape and error/empty-data behavior, which nothing else in the structured fields supplies.

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 75%, so the schema already documents free_trial and x402_payment. The description adds one genuinely new fact — that chain is optional and auto-detected — but says nothing about the payment payload flow or when free_trial is honored, leaving the two most operationally tricky parameters to the schema alone.

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

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

The description names a specific verb+resource (token verdict) and enumerates the exact output grades (SAFE / CAUTION / RISKY / DANGER) plus the two supported chains. It stops short of differentiating from the sibling solana_token_check, which overlaps on the Solana half of this tool's scope.

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

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

The 'fast verdict' framing and the enumerated data sources imply when this tool fits (quick token risk screening), but there is no explicit when-not condition and no sibling is named as the alternative. The paid/free-trial distinction is only explained through the schema, not in the prose.

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

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

With no annotations, the description carries the burden and does disclose the non-obvious traits: it is a paid call ($0.002 USDC via Solana x402) and it only works on public pages. It does not mention rate limits, failure modes for private/blocked pages, or latency, so a small gap remains.

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

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

Two tight sentences: capability and return shape first, then the input and cost. Every clause carries information and nothing is padded.

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

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

No output schema exists, but the description enumerates what comes back (title, main text, links), which is the key missing piece. The payment flow is covered by the x402_payment parameter description rather than the description itself, which is acceptable.

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 url, max_chars, and x402_payment are fully documented in the schema. The description repeats only {url} and adds no semantics for max_chars truncation behavior beyond the schema. Baseline 3 applies when the schema does the work.

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

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

States a specific verb (fetch), resource (public web page) and output contract (clean Markdown with title, main text, links). An agent can tell this is a page-to-markdown extractor, distinct from summarize (condensation) or the API lookup siblings.

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 usage (fetch a public page) and explains the payment handshake implicitly via 'Costs $0.002 USDC', but never says when to prefer this over summarize or how to handle non-public pages. Usage is implied rather than stated.

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