x402 Agent Tools

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

No annotations exist, so the description carries the full burden and does meaningful work: it discloses cost ($0.01 USDC on Base via x402), that results are one-shot (not streamed/paged), and that the content is informational data rather than advice. It omits latency/freshness of 'latest' and what happens with limit, keeping it from 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?

Front-loaded with the core purpose, the field list is compact, and payment/disclaimer details follow. Every sentence adds something, though the inline field enumeration is dense and could be tightened.

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, listing the return fields is valuable, and cost disclosure is important for a paid x402 endpoint. However, the description leaves 'latest' undefined (how fresh), gives no guidance on limit, and does not contrast with alerts_sample, so an agent still has gaps.

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

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

The single parameter 'limit' has 0% schema description coverage, so the description is responsible for explaining it, but it never mentions limit at all. The agent must infer its meaning and the 1-50 range purely from the schema constraints.

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

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

States a specific verb+resource ('latest factual market alerts') and enumerates the returned fields (symbol, time, signal type, price, % move, timeframe, source), which tells an agent exactly what it gets. It doesn't explicitly distinguish itself from the sibling alerts_sample, 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?

'One-shot' implies a single call with no pagination loop, which hints at usage context, but there is no explicit statement of when to call this versus alerts_sample, nor any prerequisite or exclusion. Usage is only implied.

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 real behavioral traits: result cardinality (3 alerts), latency (delayed 60+ minutes), cost tier (FREE), and the nature of the data (automated factual price/volume observations, no recommendation). It omits rate limits and error behavior, which keeps it below 5 for an unannotated 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 lead sentence is front-loaded and informative ('FREE: 3 ... delayed 60+ minutes'). However, the disclaimer is stated twice in near-identical terms ('not investment advice' / 'no buy/sell recommendation is made or implied'), so the final sentence does not fully earn 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?

No output schema exists, so the description should sketch the return shape; it only says alerts are 'price/volume moves' without indicating fields, timestamps, or ordering. For a trivial zero-parameter sample endpoint this is adequate but leaves an agent guessing at the response structure.

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 tool takes zero parameters and the schema is an empty object, so there is no parameter meaning to convey. Baseline of 4 applies; the description correctly implies a parameterless call with no filtering options.

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 exactly what the tool yields: 3 factual crypto/market alerts that are delayed 60+ minutes, free tier. It never names a verb or explicitly contrasts with the sibling alerts_latest, though the 'sample'/'delayed 60+ minutes' framing implicitly separates it from a latest-alerts tool. Clear resource and scope, but sibling differentiation is left to inference.

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?

Mentions FREE and a 60+ minute delay, which implies preview/testing use rather than live monitoring, but never says when to choose this over alerts_latest or what to do if fresher data is needed. Usage is implied rather than stated, and no exclusions or alternatives are given.

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 still discloses a lot: the data source and its fallback chain (GeckoTerminal, then DefiLlama), the payment mechanism and price, and the per-caller free quota. What it omits is behavior on failure or missing tokens (unknown token, no liquidity, stale data), which matters for an agent relying on a price.

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

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

Two sentences, front-loaded with the resource and returned fields, then a compact second sentence covering source fallback, cost, and quota. No filler and nothing restated from the schema.

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

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

For a no-output-schema read tool it covers what comes back (including the 'where available' caveat on liquidity/FDV), where the data comes from, and what it costs to call. The remaining gap is error/no-data behavior, which is minor but not zero for a paid lookup.

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 0% for the single required 'address' parameter, so the description must carry the load. 'By contract address' does useful work — it tells the agent this is a token contract on Base, not a wallet or symbol — but nothing is said about format, checksumming, or whether the chain must be specified.

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?

Specific verb+resource: 'Current USD price of a Base token by contract address', with the returned fields enumerated (24h change, volume, liquidity/FDV). It is clearly distinguishable from sibling base_token_risk by what it returns, though it never names that sibling 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?

Usage is implied (call it when you need a live token price) and the cost model — $0.005 USDC via x402 with 3 free calls/day — gives practical guidance about when calling is cheap versus expensive. There is no explicit when-to-use / when-not-to-use statement or routing to base_token_risk or fx_rates.

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 meaningful traits: the data source (public RPC), the read-only inspection surface, and a paid invocation at $0.04 USDC on Base via x402 — payment terms are valuable context no annotation provides. It omits what happens on invalid/non-contract addresses, the scale or meaning of the 'heuristic risk score', and latency or failure behavior.

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 sentence with zero filler; the operation, its scope, the inspected signals, and the cost are all front-loaded. Nothing repeated from the name or 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 low-complexity one-parameter tool with no output schema, the description covers the chain, method, inspected surface, and pricing. The main residual gap is that return values (structure of the risk score and metadata) are not sketched, which matters somewhat given there is no output 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?

One parameter with 100% schema description coverage ('0x contract address on Base'), so the schema already does the work and baseline is 3. The description reinforces the Base-only, contract-address constraint but adds no format, validation, or edge-case detail beyond the schema.

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

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

States a specific verb and resource: a risk check for a Base mainnet token/contract, enumerating exactly what is inspected (ERC-20 metadata, owner, EIP-1967 proxy, risky bytecode selectors) plus a heuristic score. This distinguishes it implicitly from base_token_price (valuation) and base_wallet_profile (wallet activity), though no sibling is named.

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 the scope ('token/contract risk check'), so an agent can infer it applies when assessing a token's safety rather than its price. However, there is no explicit when-to-use statement, no exclusions (e.g. EOAs vs contracts, non-Base addresses), and no named alternative among siblings.

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 it does add real value: the data source (public RPC), the freshness window for transfers (~last 10k blocks), and the $0.02 USDC x402 cost, which signals a paid call. It omits address format requirements, failure behavior for invalid/non-existent addresses, and any latency or rate-limit expectations.

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 tight sentence-pair with the resource and payload front-loaded and the pricing constraint stated compactly at the end. Nothing 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?

No output schema exists, and the description compensates by enumerating the returned fields, their source, and transfer recency. Only the input-side contract (address format/validity) is left uncovered.

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?

One required parameter at 0% schema coverage, so the description must compensate. It implies the input is a Base wallet address but never states the EVM hex format, checksum expectations, or what happens on a malformed 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?

Names a concrete resource (Base wallet profile) and enumerates exactly what it returns: ETH/USDC balances, nonce, contract-vs-EOA, recent USDC transfers. This is clearly distinct from the token-level siblings base_token_price and base_token_risk, though it never names 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?

Usage is only implied — an agent infers you call this when you need a profile for a Base address. There is no statement of when to prefer it over a sibling or of any prerequisites, aside from the incidental cost 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?

No annotations are provided, so the description carries the full burden. It usefully discloses the data source, x402 pricing, and a free-call limit, but does not describe return format, error behavior, or payment auth details beyond the price.

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

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

Two sentences, front-loaded with the purpose and then the payment/rate-limit details. No wasted text.

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

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

With no annotations, no output schema, and no parameter descriptions, the definition is too thin for an agent to invoke confidently. It explains source and cost but not parameter behavior or returned data.

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

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

Schema description coverage is 0%, so the description must compensate for four undocumented parameters. It only hints at date via 'historical' and from/to via 'fiat exchange rates'; amount and defaults are not addressed.

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 as fiat exchange rates from ECB reference rates via frankfurter.app and notes latest or historical coverage. It lacks an explicit action verb and does not differentiate from any sibling, but no sibling appears to offer comparable fiat FX data.

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

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

The phrase 'latest or historical' implies two usage modes but does not state when to choose one over the other, nor any alternatives. It gives basic context but leaves selection logic to the 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, the description carries the full burden and delivers key traits: same-origin restriction, a hard 10-page cap, breadth-first traversal order, per-page Markdown output, and — critically — that this is a paid call costing $0.16 USDC on Base via x402. It omits failure modes (timeouts, non-same-origin link handling) and how the x402 payment handshake must be performed, which keeps it below 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?

Two tight sentences with zero filler: scope and output come first, then the cost. Every clause carries information an agent needs before invoking.

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-parameter crawl tool with no annotations and no output schema, the description covers scope, traversal order, return format, and price — the essentials. The gap is the x402 payment flow itself (what happens on an unpaid request) and the default page count, which an agent would still have to discover empirically.

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

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

Schema description coverage is 0%, so the description must compensate. 'Up to 10 pages' clarifies the max_pages ceiling, but the default value when max_pages is omitted is never stated, and the url parameter's role is only indirectly conveyed via 'same-origin' (the seed URL). Partial compensation, not full.

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

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

States a specific verb and resource (multi-page same-origin crawl) plus concrete scope (up to 10 pages, breadth-first) and output format (Markdown per page). It implicitly separates itself from single-page siblings like web_markdown and web_extract, but never names them, so differentiation relies on inference.

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 'multi-page, same-origin' framing implies this is for crawling a site section rather than extracting one page, which hints at when to prefer it over web_markdown/web_extract. However, no explicit when-to-use/when-not-to-use statement or sibling reference is given, so the agent must infer the routing.

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 behavioral burden. It usefully discloses the output fields and the payment requirement ('Price $0.04 USDC on Base via x402'), but it omits constraints such as URL accessibility, JavaScript rendering, rate limits, or error behavior.

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 tightly written sentences with zero waste. The core extraction purpose and output fields are front-loaded, followed by the pricing detail.

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 appropriately enumerates the return fields (title, meta/OpenGraph, JSON-LD, headings, links, tables, emails, Markdown body) and states the cost. It is largely complete for a simple one-parameter extraction tool, though it could mention error or URL constraint 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 0% for the single required 'url' parameter. The description only implies that the URL points to a web page, adding no format, validation, or constraint details beyond the schema's type.

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

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

States a specific verb and resource: 'Structured JSON extraction from a web page,' and enumerates the extracted fields. It is clear what the tool does, but it does not explicitly differentiate itself from siblings like web_markdown or web_crawl.

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 no guidance on when to use this tool versus alternatives such as web_markdown or web_crawl. The purpose implies structured extraction, but there are no explicit when/when-not conditions or named alternatives.

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

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

With no annotations, the description carries the full burden and does real work: it discloses the pricing model ($0.01 USDC on Base via x402) and a free-tier rate limit (3 calls/day per caller), which an agent must know before calling. It also enumerates the return fields, though it says nothing about JS-rendered pages, redirects, or failure behavior.

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 dense sentences, front-loaded with the input->output contract before the return shape and cost. Every clause (pipeline, return fields, price, free quota) carries information an agent needs.

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 one-parameter tool with no output schema, listing the return object keys compensates well, and the payment/rate-limit disclosure is essential context. Gaps remain around page eligibility (JS-heavy sites) and error responses, which matter for a paid call.

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% for the single url parameter, so the baseline is already high. The description adds the 'public' qualifier, reinforcing that non-public URLs are out of scope, but adds no format or syntax detail beyond the schema's 'Public http(s) URL'.

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 transformation: an input URL becomes clean Markdown, and even names the pipeline (Readability + Turndown). It does not explicitly contrast itself with siblings like web_crawl or web_extract, so the agent must infer that this is the single-page conversion 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?

'Any public web page URL' bounds the input scope to public pages, which implicitly excludes authenticated or private content. However, it never says when to pick this over web_crawl or web_extract, leaving the routing decision to inference from the names alone.

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