Paid x402 pre-checks for agents: phishing links, Base tokens, EIP-712 permits, calldata, DNS.
Scored across 18 tools
Most tools have clearly distinct resource + action targets, and descriptions explicitly steer agents toward the right one. There is some overlap among domain/link vetting tools (domain_dns, domain_email_check, domain_whois, web_link_check) and between token/address safety tools (base_token_check, wallet_screen), but the boundaries are reasonably well explained.
All names use consistent snake_case with clear domain prefixes such as base_, domain_, evm_, web_, wallet_, ens_, and x402_. The pattern is predictable and readable even though it is namespace-first rather than strictly verb_noun.
Eighteen tools is on the heavy side and the server spans several loosely related areas: Base chain checks, domain checks, web extraction/branding, signature checks, and x402 payment preflight. Most tools are useful, but the surface feels broader than the stated link/token/signature pre-check focus.
The set covers a strong range of pre-flight checks: domain/DNS/WHOIS, token safety and price, transaction and calldata decoding, EIP-712 signature screening, wallet screening, link phishing checks, and x402 seller verification. Minor gaps remain, such as no general transaction simulation or explicit approval-revocation workflow, but core workflows are well supported.
Base wallet balances: native ETH and USDC for any address, with the block number they were read at. Price: $0.005 USDC on Base per call (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds meaningful context beyond that, namely that each call costs $0.005 USDC via x402 and that the response includes the block number the values were read at. It does not cover failure modes (invalid address, insufficient payment), but the paid-call disclosure is a genuinely valuable behavioral detail.
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: the resource and scope come first, the return contents second, and the cost last. Every clause, including the price, carries information the 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 single-parameter read tool with no output schema, the description covers what is returned (ETH, USDC, block number) and the payment requirement, which is enough to call it correctly. Minor gaps remain around address format expectations and error behavior when payment or address validation fails.
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?
There is one required parameter with 0% schema description coverage, so the description should carry the burden; 'for any address' adds only weak meaning beyond the schema's regex pattern. It does not say whether the address must be checksummed, which chain(s) beyond Base apply, or that EOA and contract addresses are both accepted.
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 specific verb-plus-resource ('Base wallet balances') and explicitly bounds the scope to 'native ETH and USDC', which implicitly separates it from the broader base_portfolio sibling. It stops short of naming an alternative outright, so it is clear but not fully differentiated.
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 can infer it should use this for a quick ETH/USDC balance read rather than a full portfolio, but there is no explicit when-to-use or when-not-to-use statement against base_portfolio or base_token_price. Nothing is misleading, but routing relies on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Base gas snapshot: gas price, base fee, priority fee, 10-block base-fee trend, ETH/USD (Chainlink) and estimated USD cost of an ETH transfer, ERC-20 transfer, swap and contract deploy right now. Price: $0.005 USDC on Base per call (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| gasLimit | No | optional: gas units of your own transaction; adds estimatedCost.custom (ETH + USD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely new behavioral facts beyond the annotations: the call is paid ($0.005 USDC on Base via x402), which materially affects invocation decisions, and it lists the returned fields for a tool with no output 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?
Two sentences, front-loaded with the payload contents and closing with the payment cost, which is the highest-risk fact for an agent. The long enumeration in sentence one is dense but every item earns its place by describing a return field.
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 carries the burden of describing return values and does so field by field, plus the payment requirement, and the sole parameter is fully documented in the schema. Nothing essential for correct invocation is missing for a simple read-only snapshot tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional gasLimit parameter, including its pattern and the note that it adds estimatedCost.custom in ETH and USD. The description adds no parameter meaning of its own, so baseline 3 is appropriate when the schema does the full job.
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 artifact ('Base gas snapshot') and enumerates exactly what it contains: gas price, base fee, priority fee, 10-block base-fee trend, ETH/USD, and estimated USD costs for four transaction types. That enumeration clearly separates it from siblings like base_token_price or base_balance, so an agent can pick it 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?
'right now' implies this is for current, point-in-time gas estimation rather than historical lookups, which is useful context. However, it never names an alternative or states when not to use it (e.g., use base_token_price for pure price data), so the routing guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Base wallet portfolio: ETH plus 12 major Base tokens (USDC, USDbC, DAI, EURC, WETH, cbETH, wstETH, cbBTC, AERO, DEGEN, VIRTUAL, BRETT) with non-zero balances, USD values from Chainlink ETH/USD and BTC/USD feeds, and a total. Price: $0.01 USDC on Base per call (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | wallet address on Base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description adds real value beyond them: it discloses the coverage ceiling (ETH + 12 tokens), the filtering rule (non-zero balances only), and the paid-call model ($0.01 USDC on Base per call via x402), which is a genuine auth/cost constraint. What it omits is failure behavior — e.g. what happens on a malformed address or when the x402 payment is not settled.
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 that is front-loaded with the resource and its contents, then the pricing caveat. Every clause carries information, though the full 12-token enumeration and the Chainlink feed detail are slightly verbose compared with simply stating the token set size and oracle source.
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 read tool with no output schema, the description does the necessary work: it sketches the return payload (ETH + tokens, USD values, total) and flags that the call is paid. Missing only are return-shape specifics such as ordering, zero-balance handling in the output, and error cases.
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?
There is a single parameter at 100% schema description coverage; the schema already states the address format, pattern, and that it is a Base wallet. The description adds no further semantics such as whether EOAs and contracts are both accepted or whether checksum casing matters. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource framing ("Base wallet portfolio") and enumerates exactly what is returned: ETH plus 12 named Base tokens with non-zero balances, USD valuations, and a total. That enumeration distinguishes it in practice from base_balance and base_token_check, but it never names those siblings or states the contrast explicitly, so it falls short of the top band.
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 can infer this is the right tool for a multi-token holdings snapshot rather than a single balance or price. There is no explicit when-to-use, when-not-to-use, or named alternative, and no note on whether a single-token query should go to base_balance/base_token_check instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Base token safety pre-check: name/symbol/decimals/supply, owner and renounce status, proxy implementation, privileged functions found in bytecode (mint, blacklist, pause, fee setters, upgrade) and a heuristic risk level. Call before buying or accepting an unknown token on Base. Price: $0.01 USDC on Base per call (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ERC-20 token contract on Base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely new context: a per-call price of $0.01 USDC via x402 and the honest caveat that the risk level is a heuristic, which tells the agent not to treat the output as authoritative. It does not mention latency, caching, or whether results are a point-in-time snapshot.
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: the capability list comes first, followed by the usage cue and the cost. Nothing is redundant with the title or schema, and every enumerated check carries decision value for an agent.
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 usefully enumerates what is returned so the agent knows what to expect. The remaining gap is that the shape of the 'heuristic risk level' is unspecified (scale, categories), so an agent cannot know how to interpret or threshold the result without calling it.
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?
Only one parameter, and the schema already documents it fully at 100% coverage ('ERC-20 token contract on Base' with an address pattern). The description's phrase 'unknown token on Base' merely reinforces the same constraint, adding no syntax, format, or validation 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+resource ('Base token safety pre-check') and then enumerates exactly what is inspected: name/symbol/decimals/supply, owner and renounce status, proxy implementation, privileged function detection, and a heuristic risk level. This enumeration clearly distinguishes it from sibling base_token_price, which covers only 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?
'Call before buying or accepting an unknown token on Base' gives a clear triggering condition. It stops short of naming alternatives (e.g., wallet_screen or base_token_price) or stating when-not to use it, so it is strong context but not full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live USD price of any ERC-20 token on Base from on-chain DEX quotes (Uniswap v3 0.05/0.3/1% pools and Aerodrome, against USDC and WETH; WETH converted with Chainlink ETH/USD). Returns the best executable route, every route's price, the price impact of selling $1,000, and flags for thin liquidity or disagreeing pools. Price: $0.005 USDC on Base per call (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ERC-20 token contract on Base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply readOnlyHint and openWorldHint; the description adds the material behavioral facts an agent needs: the exact price ($0.005 USDC per call via x402, an auth/payment requirement), the granularity of the response (best route, all route prices, $1,000 sell impact, thin-liquidity and pool-disagreement flags), and the quote methodology. It stops short of saying what happens when no pool exists or how stale quotes can be.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then supporting detail, then cost. Every clause carries information, though the deep parenthetical nesting (pool tiers inside the source list inside the price sentence) makes it dense enough to require a second read.
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 must describe returns, and it does so concretely (best route, every route's price, $1,000 price impact, liquidity/disagreement flags). Combined with explicit pricing and sourcing, this is nearly complete for a single-parameter read tool; only error/edge-case behavior is unaddressed.
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 there is only one parameter, so the schema already fully documents the address field, making 3 the baseline. The description adds only marginal meaning by scoping it to Base ERC-20 contracts and implying tokens must have a DEX pool to be priced.
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 ("Live USD price of any ERC-20 token on Base") and immediately identifies the data source (Uniswap v3 0.05/0.3/1% pools, Aerodrome, USDC/WETH pairs, Chainlink conversion). This is clearly distinguishable from siblings like base_token_check (safety) or base_portfolio (holdings) without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the description establishes this is a pricing lookup tool, so an agent can infer it should not be used for contract safety or balance queries. However, it never explicitly names an alternative sibling or states when-not to use it (e.g., unsupported tokens with no pool).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode a Base transaction: status, block time, from/to, ETH value, fee, method selector and every ERC-20 transfer with symbol and human amount. Flags fake look-alike tokens (address-poisoning, e.g. a fake USDC with homoglyph characters). Price: $0.005 USDC on Base per call (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely non-obvious behavior: a per-call charge of $0.005 USDC on Base via x402, and the fact that output includes forged-token detection (address-poisoning / homoglyph look-alikes). Neither of these is derivable from the schema or 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 output inventory is front-loaded in the first sentence and the cost and safety-flag details follow. It is efficient overall, though the single long sentence packs several clauses together and could be split for faster 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?
For a read-only, single-parameter decoder with no output schema, the description does the heavy lifting by enumerating return fields and disclosing the payment requirement and anti-spoofing behavior. Minor gaps remain around error handling for unknown or pending hashes, but nothing essential for correct invocation 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?
Only one parameter exists and schema description coverage is 0%, but the schema's regex (^0x[0-9a-fA-F]{64}$) is largely self-documenting as a 32-byte transaction hash. The description implies the input is a transaction but never explicitly names 'hash' or states whether a pending/unmined hash is acceptable, so it adds little beyond the pattern.
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 opens with a specific verb+resource ('Decode a Base transaction') and then enumerates exactly what is returned: status, block time, from/to, ETH value, fee, method selector, and ERC-20 transfers with symbol and human-readable amount. That level of specificity makes it clearly distinct from siblings like evm_decode_calldata or base_balance without needing to open any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance and no named alternatives (e.g., use evm_decode_calldata for raw calldata, base_balance for holdings). The only implicit signal is that the tool is scoped to Base-chain transactions. The pricing sentence tells an agent about cost but not about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DNS lookup in one call: A, AAAA, CNAME, MX, TXT, NS and CAA records with TTLs (or just the types you ask for), NXDOMAIN status, DNSSEC validation, plus parsed hints: SPF record, CAA certificate issuers and which services the domain is verified with (TXT verification tokens). Resolved via DNS-over-HTTPS. Price: $0.003 USDC on Base per call (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | domain or host name | |
| types | No | optional comma list of A,AAAA,CNAME,MX,TXT,NS,CAA,SOA (default: all but SOA) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint, so the description carries real weight here and does disclose important behavior: resolution happens via DNS-over-HTTPS, NXDOMAIN is reported, DNSSEC is validated, and a per-call price of $0.003 USDC on Base via x402 applies. That payment requirement is critical operational context absent from annotations. It stops short of rate limits or failure-mode details, so 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?
Content is front-loaded: record types and TTLs first, derived hints next, transport and pricing last. Every clause conveys something actionable and there is no filler. It is dense but readable, with only the enumerated record list bordering on overlong.
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 must describe return values itself, and it does: records with TTLs, NXDOMAIN status, DNSSEC results, plus parsed SPF, CAA issuers and TXT verification-token services. Combined with the payment disclosure, an agent has everything needed to decide to call it and interpret the result.
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 both parameters are documented inline, so the baseline of 3 applies. The description adds modest value by framing 'types' as a way to request only selected record types and by describing what the default set yields, but it omits SOA from the listed set even though the schema allows it, which slightly muddies rather than enriches parameter 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 opens with a specific verb+resource ('DNS lookup in one call') and enumerates exactly what is returned (A, AAAA, CNAME, MX, TXT, NS, CAA with TTLs, NXDOMAIN, DNSSEC). This clearly separates it from siblings like domain_whois, domain_email_check, and ens_resolve, which cover registration data, mail deliverability, and name resolution respectively.
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: it is obvious you reach for this when you need raw DNS records, and the 'just the types you ask for' phrasing hints at narrowing scope. However, it never says when NOT to use it or names a sibling alternative (e.g. domain_whois for registrant data or domain_email_check for deliverability), leaving the agent to infer routing from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Domain DNS and email-security check: A/AAAA, NS, MX (incl. null MX), SPF, DMARC policy, CAA, plus a list of issues and a 0-100 email security score. Use before sending email to or trusting a domain. Price: $0.005 USDC on Base per call (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | domain name, e.g. example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint/openWorldHint, it discloses return content (issues list plus 0-100 score) and the payment model ($0.005 USDC on Base via x402), which the annotations do not cover. It omits failure behavior for unresolvable domains, so it stops short of full disclosure.
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 capability and record types, then usage and pricing. No wasted phrasing.
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 one required parameter, readOnly annotations, and no output schema, it covers what the tool checks, what it returns in summary form, when to use it, and the cost. Only error/edge-case behavior is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'domain' parameter is documented with an example in the schema, so the description adds little parameter meaning. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Domain DNS and email-security check') and enumerates exactly the records examined (A/AAAA, NS, MX, SPF, DMARC, CAA). It is distinguishable from sibling domain_dns by its email-security focus and computed score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context: 'Use before sending email to or trusting a domain.' It does not explicitly name alternatives such as domain_dns or domain_whois, so the when-not/alternative routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Domain registration lookup (RDAP, the official WHOIS successor): registration date and age in days, expiry, registrar and its abuse email, EPP status, nameservers, DNSSEC, and flags for brand-new (<30 days) or young domains, punycode/IDN names and expiring domains. Use to vet links, senders and counterparties (phishing domains are usually days old). Price: $0.005 USDC on Base per call (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | domain or host name, e.g. github.com or www.github.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds material context beyond them: the RDAP data source, the flagging behavior for domains under 30 days old and expiring ones, punycode/IDN handling, and crucially the per-call cost of $0.005 USDC on Base via x402, which an agent must know before invoking. It does not explain what happens for unregistered or malformed domains, which keeps it at a 4.
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 purpose and the data source, then the field enumeration, then the vetting use case, then the price. Every sentence carries information a caller needs. The field list is a dense run-on that could be tightened, but no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of telling the agent what comes back, and it does so by enumerating the return fields and the risk flags. The payment requirement is also disclosed, which matters for a paid x402 tool. Missing only edge-case behavior for invalid or unregistered domains.
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?
There is a single required parameter with 100% schema description coverage, so the schema already tells the agent it accepts "domain or host name, e.g. github.com or www.github.com." The description mentions punycode/IDN names but does not clarify whether subdomains or bare hostnames are normalized, so it adds little meaning beyond the structured field. 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?
Names a specific verb+resource ("Domain registration lookup") and pins the data source (RDAP, WHOIS successor), then enumerates the returned fields: registration date, expiry, registrar, abuse email, EPP status, nameservers, DNSSEC, and derived flags. This clearly separates it from sibling tools like domain_dns, domain_email_check, and ens_resolve, which handle different facets of a domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit use case with rationale: "Use to vet links, senders and counterparties (phishing domains are usually days old)." That is a concrete trigger condition. It stops short of naming alternatives (e.g. domain_dns for records-only checks, web_link_check for URL-level vetting) or stating when not to bother, so it falls just shy of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve ENS and Basenames (name.eth, name.base.eth): name → address, or address → primary name with forward verification, plus text records (avatar, description, url, twitter, github, email). Price: $0.005 USDC on Base per call (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ENS/Basename (e.g. vitalik.eth, jesse.base.eth) or a 0x address for reverse lookup |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description's added value is real: it discloses that reverse lookups include forward verification, that avatar/description/url/social text records are returned, and that each call costs $0.005 USDC on Base via x402 — a payment/permission prerequisite no annotation covers. Left out are resolution chain/failure behavior and what happens if payment is not settled.
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 front-loaded sentence that leads with the capability and directions, then the returned fields, then the price. It is dense and slightly run-on, but every clause carries information an agent needs before calling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly covers what comes back (address, verified primary name, text records) and adds the cost model. Minor ambiguity remains about which chain resolution runs against versus the Base payment chain, and about failure/empty-result 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 100% and the single parameter 'q' is already documented with examples in the schema, so the baseline is 3. The description reinforces the dual input mode (name or 0x address) and names the accepted name suffixes, but adds no format or validation 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 (resolve) with the exact resources (ENS and Basenames, with concrete TLD examples) and enumerates both directions: name → address and address → primary name, plus text records. An agent can immediately tell this apart from provisioning/DNS siblings like domain_dns or domain_whois.
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 stated directions (forward lookup for a name, reverse lookup for a 0x address), so an agent can infer when to call it. But there is no explicit guidance on when to prefer this over siblings such as domain_dns or domain_whois, and no stated prerequisites for the paid x402 flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode EVM transaction calldata before signing: finds the function signature (signature DB, verified by re-encoding to reject selector collisions), decodes all arguments, expands multicall batches, and warns about unlimited token approvals, approve-all-NFTs, permits, ownership changes and upgrades. Works for any EVM chain. Price: $0.005 USDC on Base per call (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | hex calldata (selector + ABI-encoded args), max 16 KB |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnly and openWorld; the description adds substantial behavior on top: selector-collision rejection via re-encoding, multicall batch expansion, and a specific warning taxonomy (unlimited approvals, approve-all-NFTs, permits, ownership changes, upgrades). It also discloses the paid-call model and price ($0.005 USDC on Base via x402), which is critical pre-invocation information an agent cannot get from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is one dense sentence, but it is front-loaded with the action and ordered from core behavior to secondary warnings to price. Every clause carries information; the only minor cost is that the packed clause list slows scanning slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still conveys what comes back — decoded signature, argument values, expanded multicall calls, and warnings — and it discloses the paid x402 model and chain-agnostic scope. For a single-parameter, read-only decoding tool this covers everything an agent needs to decide and call 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?
There is a single required parameter with 100% schema description coverage that already states the hex format and 16 KB cap. The description adds no further parameter-level meaning, so the baseline 3 applies; no credit is warranted for restating what the schema covers.
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 opens with a specific verb+resource+stage: 'Decode EVM transaction calldata before signing.' It enumerates the concrete capabilities (signature DB lookup with re-encoding verification, argument decoding, multicall expansion, risk warnings), which clearly separates it from sibling tools like evm_typed_data_check and base_tx.
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?
'before signing' states the decision context in which to reach for this tool, and 'Works for any EVM chain' tells the agent it does not need to route by network (unlike base_* siblings). It stops short of naming an explicit alternative or when-not-to-use case, so it falls one step short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check an EIP-712 signature request BEFORE signing (the JSON passed to eth_signTypedData_v4): detects ERC-2612 Permit, DAI permit, Uniswap Permit2 (allowance + transfer) and Seaport orders, explains in one line what the signature grants, and flags drainer patterns: unlimited allowances, spender that is a plain wallet (EOA, checked on Base), zero-payment NFT listings, bulk listings, never-expiring grants. Returns risk (low/medium/high), grants, warnings and the EIP-712 digest. Price: $0.01 USDC on Base per call (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| types | Yes | EIP-712 type definitions | |
| domain | No | EIP-712 domain (name, version, chainId, verifyingContract) | |
| message | Yes | the message to be signed | |
| primaryType | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses that the EOA-spender check is only performed on Base (an honest scope limitation), lists the concrete drainer heuristics applied, spells out return fields (risk, grants, warnings, digest), and reveals the paid x402 access model ($0.01 USDC on Base per call) that an agent must satisfy before calling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded paragraph that leads with the action and the pre-signing timing, then moves through detections, output, and pricing with no filler sentences. It is dense and somewhat run-on with stacked enumerations, which slightly hurts scanability but wastes no content.
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 nested-object input with no output schema, the description supplies what the structured fields cannot: recognized signature schemes, the drainer patterns checked, the shape of the response, the chain-specific limitation, and the payment requirement. An agent has everything needed to decide to call it and to interpret the result.
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 carries most parameter meaning; the description adds the important framing that the whole object is the eth_signTypedData_v4 payload, which tells an agent how to source values. It does not individually clarify primaryType (undocumented in the schema) or the optional domain object, leaving a modest 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?
States a concrete verb and resource ('Check an EIP-712 signature request') plus the exact payload it accepts (the JSON passed to eth_signTypedData_v4), then enumerates the specific schemes it recognizes (ERC-2612, DAI permit, Permit2 allowance/transfer, Seaport). Its pre-signature safety role separates it cleanly from sibling evm_decode_calldata, which handles calldata rather than typed-data payloads.
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 'BEFORE signing' framing gives a clear point-of-use trigger, and the parenthetical ties it to the eth_signTypedData_v4 call an agent would be about to make. It stops short of naming sibling alternatives (evm_decode_calldata, wallet_screen) or stating what inputs it rejects, so 'when not to use' is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wallet / counterparty screen before you send funds or accept a payer: OFAC SDN sanctioned-address check (EVM list, refreshed from the 0xB10C OFAC dataset), address type (EOA, EIP-7702 delegated, contract, token contract), Base and Ethereum tx counts, ETH/USDC balances on Base, burn-address detection and an optional address-poisoning look-alike check against the address you expected (same first/last 4 hex). Verdict block/high_risk/caution/no_red_flags. Price: $0.005 USDC on Base per call (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | EVM address to screen | |
| expected | No | optional: the address you meant to use (detects address-poisoning look-alikes) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint; the description adds real substance on top: the data source and refresh origin (0xB10C OFAC dataset, EVM list), the cost and payment rail ($0.005 USDC on Base via x402), and the concrete output verdicts (block/high_risk/caution/no_red_flags). It does not cover failure modes, latency, or what happens when an address is unknown, 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?
Front-loads the action and trigger, then stacks the check list, verdicts, and pricing in a dense but scannable sequence with no filler. The single long sentence-pile is slightly crammed, which costs it a point versus a cleanly segmented version.
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 carries the burden of explaining returns, and it does so by naming the verdict values and the individual signals inspected. It explains cost and data provenance, leaving only edge-case behavior (unknown address, upstream dataset outage) unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining the mechanism of the optional 'expected' parameter (look-alike detection on matching first/last four hex characters). The 'address' parameter gains no extra semantics, but the one non-obvious parameter is clarified.
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?
Opens with a specific verb+resource ('Wallet / counterparty screen') and enumerates exactly what is checked: OFAC SDN list, address type, tx counts, balances, burn detection, look-alike check. It also states the contract for the required parameter ('address to screen') and the verdict taxonomy, so an agent can distinguish it from siblings like base_token_check or x402_preflight without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger condition ('before you send funds or accept a payer'), which is exactly the decision point an agent needs. It does not name competing tools or state when not to use it (e.g., for a plain token metadata lookup use base_token_check), so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brand kit from a website: site name, logo candidates (JSON-LD logo, header/home-link image, inline SVG logo, apple-touch-icon/favicons, og:image), theme-color, CSS brand variables (--primary/--brand/--accent), dominant colors ranked by CSS frequency (non-neutral first), fonts (Google Fonts + CSS font families, system fonts removed) and social profile links. No rendering; flags bot-protected pages. Price: $0.01 USDC on Base per call (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | http(s) URL of the site (home page works best) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations, the description discloses two traits annotations cannot carry: no JavaScript rendering (so client-rendered sites yield poor results) and that bot-protected pages are flagged rather than silently failed. It also discloses the cost model — $0.01 USDC on Base per call via x402 — which is critical pre-invocation context an agent would otherwise not know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single front-loaded sentence that opens with the resource and closes with the price, and nearly every clause earns its place by naming a returned field. The output enumeration is long but functional; only the parenthetical logo-source list borders on exhaustive 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?
For a read-only, single-input fetch tool with no output schema, describing the returned fields is exactly the right use of the description, and the payment and no-rendering caveats cover the key surprises. It stops short of describing failure modes beyond bot protection or the shape of the response.
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?
With a single parameter at 100% schema coverage, the schema already defines 'url'; the description adds the practical nuance that a home page works best, which the schema's own parenthetical corroborates. Little more is needed for one string 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 gives a specific verb+resource ('Brand kit from a website') and then enumerates exactly what is packaged: site name, logo candidates from five sources, theme-color, CSS brand variables, ranked dominant colors, fonts, and social links. That specificity makes it clearly distinct from generic extractors like web_extract, but it never names a sibling, so differentiation is inferred rather than stated.
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: 'home page works best' hints at the preferred input without stating when to choose this over web_extract or when it will fail. There are no explicit exclusions and no named alternatives among the 17 siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch any public web page and return clean Markdown of the main content plus title, meta description, word count and absolute links. Strips scripts, navigation and boilerplate. Good for feeding pages to an LLM. Price: $0.005 USDC on Base per call (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | http(s) URL of a public page | |
| maxChars | No | max markdown characters (default 20000, max 100000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly and openWorld, so the bar is lower, and the description still adds real value: it discloses content stripping of scripts/navigation/boilerplate, the exact payload fields, and a per-call price of $0.005 USDC on Base via x402 — cost and payment protocol are critical for an agent to know before invoking. What it omits is failure behavior (JS-only pages, non-HTML content, what happens if payment is not set up) and whether return size is truncated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences with no filler: what it does, what it returns, what it removes, why it is useful, and what it costs. The most decision-relevant facts (scope and output shape) are front-loaded, with pricing correctly deferred to the end.
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 properly compensates by enumerating returned fields, and it covers the payment model that annotations cannot express. It falls slightly short on error/edge-case behavior and how the x402 payment is actually settled, though the sibling x402_preflight may cover that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both url and maxChars, and the baseline of 3 applies. The description adds no detail on maxChars truncation behavior, and it does not flag that maxChars is typed as a string despite the documented default 20000 / max 100000.
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 and resource ('Fetch any public web page') and enumerates exactly what comes back (Markdown of main content, title, meta description, word count, absolute links), so the tool is instantly distinguishable in intent. It does not explicitly contrast itself with siblings such as web_link_check or web_security_headers, which keeps it 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?
'Good for feeding pages to an LLM' is a benefit statement that implies the use case but gives no explicit selection criteria against the many other web_* siblings. There is no when-not guidance (e.g., JS-rendered pages, paywalled/authenticated pages) and no named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Link / URL phishing pre-check before an agent opens, clicks or forwards a link: brand look-alikes (typosquats, homoglyphs, brand in subdomain), punycode and mixed-script hosts, credentials-in-URL tricks, high-abuse TLDs, domain age via RDAP (new domains flagged), DNS resolution and the full redirect chain. Returns a verdict, a 0-100 risk score and the flags. Price: $0.01 USDC on Base per call (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | the URL to check (http/https) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint; the description adds real behavioral context beyond them — that it performs live DNS resolution, RDAP lookups and follows the full redirect chain, and that each call costs $0.01 USDC on Base via x402. The cost and network-lookup disclosure are exactly what an agent needs before invoking it. It does not say whether page content is fetched or whether the URL is disclosed to third parties, so a 4 rather than 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?
Purpose is front-loaded in the opening clause, followed by the check list, the return values and the price — a sensible order with little wasted text. The middle clause is a dense, comma-stuffed list, which is efficient but requires the agent to parse one long sentence for the differentiating details.
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, the description covers what an agent needs: scope of checks, that it returns a verdict plus a 0-100 risk score and flags, plus the per-call cost. The only gap is interpretation guidance for the risk score (thresholds or what 'flagged' implies for proceeding), which a caller must infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage ('the URL to check (http/https)'), so the schema already carries parameter meaning. The description adds no input guidance beyond implying the same http/https scope and that all listed checks run against that one URL. 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?
Names a specific verb and resource ('Link / URL phishing pre-check') and then enumerates exactly what is checked: brand look-alikes, punycode/mixed-script hosts, credentials-in-URL, high-abuse TLDs, RDAP domain age, DNS resolution and the redirect chain. That enumeration makes it distinguishable from siblings like web_security_headers, domain_whois and web_brand without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit about when to use it: 'before an agent opens, clicks or forwards a link', which is a concrete decision point. It stops short of naming alternatives (e.g. domain_whois for registration history, web_security_headers for header posture) or stating when this check is unnecessary, so it is clear but not fully routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Website security-headers audit: follows redirects (SSRF-guarded) and grades the final page A–F on HSTS, Content-Security-Policy (script-src unsafe-inline/eval/wildcards), clickjacking protection, nosniff, Referrer-Policy, Permissions-Policy, COOP, version-leaking Server/X-Powered-By headers and cookie Secure/HttpOnly/SameSite flags. Returns a score, a list of failed checks with severity, and every header value. Price: $0.005 USDC on Base per call (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | http(s) URL of a public site |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint, so the description adds real value: it discloses SSRF-guarded redirect following, the exact grading rubric, the return payload (score, failed checks with severity, all header values), and per-call pricing ($0.005 USDC on Base via x402). The payment requirement is especially important behavioral context not in annotations. It stops short of noting rate limits or failure behavior for unreachable sites.
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 but front-loaded sentence that enumerates the graded checks, the outputs, and the price with no filler. Every clause maps to something an agent needs (scope, redirects, output, cost).
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 read tool with no output schema, the description fully compensates by naming the return payload (score, failed checks with severity, all header values) and the payment model. Combined with readOnly/openWorld annotations, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter with 100% schema description coverage ('http(s) URL of a public site'), so the schema already carries its meaning. The description reinforces that the target must be a public site with redirects followed, but adds no format or validation detail 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 verb and resource ('Website security-headers audit') plus the exact scope of the audit (HSTS, CSP, clickjacking, nosniff, Referrer-Policy, Permissions-Policy, COOP, version-leaking headers, cookie flags) and the output shape (A–F grade). This is clearly distinguishable from siblings like web_extract or web_brand, which do not grade headers.
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 narrow scope: audit a public site's security headers. It clarifies it follows redirects and that the URL must be a public http(s) site, but gives no explicit when-to-use versus alternatives and no when-not-to-use guidance (e.g. private/internal hosts).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
x402 seller preflight: check a paid endpoint BEFORE paying it. Fetches it unpaid, parses the 402 (v2 payment-required header or v1 body) and checks every payment option: scheme, network/testnet, asset is real native USDC on Base, EIP-712 extra.name/version match the token on-chain (prevents invalid_exact_evm_token_name_mismatch), payTo not a burn address (plus contract/tx-count/USDC balance), amount, maxTimeoutSeconds, discovery metadata. Plus seller reputation on-chain: incoming USDC transfers to payTo on Base over the last 3 days (1-7 via ?days=): distinct payers, total USDC, transfers at the advertised price, top-payer share, hours since last payment. Returns verdict ok/caution/fail, issues and the recommended option. Price: $0.005 USDC on Base per call (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | https URL of the x402-paid endpoint | |
| days | No | on-chain payer history window in days (default 3) | |
| method | No | HTTP method to probe (default GET) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations, the description discloses the unpaid fetch behavior, v1/v2 402 parsing, on-chain USDC and payTo checks, reputation window semantics, return verdict values, recommended option, and even the per-call price. This is unusually rich behavioral context for an agent deciding whether and how to call it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and every major clause is substantive, but the dense semicolon-separated list makes it harder to scan. Some jargon such as invalid_exact_evm_token_name_mismatch could be trimmed or clarified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, multi-check tool with no output schema, the description covers what is inspected, what the result verdict looks like, and what recommendation is returned. Important operational details such as cost, unpaid probing, and reputation timing are included.
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 url, method, and days. The description only slightly extends this by explaining that days controls the seller-reputation history window, but it adds little for url or method beyond what the schema provides.
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: preflight-check an x402-paid endpoint before paying it. It clearly distinguishes the tool from a payment action and from generic base_* blockchain tools by focusing on 402 parsing, payment-option validation, and seller reputation.
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 gives a clear timing instruction: use this before paying a paid endpoint. It does not name explicit alternatives or when-not-to-use conditions, but no direct sibling performs this same preflight function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
x402_preflight1 field changedInput schema / properties / daysAdded value: +{
+ "description": "on-chain payer history window in days (default 3)",
+ "maximum": 7,
+ "minimum": 1,
+ "type": "integer"
+}base_balancebase_gasbase_portfoliobase_token_checkbase_token_pricebase_txdomain_dnsdomain_email_checkdomain_whoisens_resolveevm_decode_calldataevm_typed_data_checkwallet_screenweb_brandweb_extractweb_link_checkweb_security_headersx402_preflightPaid x402 MCP utilities for Base-USDC balances, blocks, gas, HTTPS headers, and agent profile bios.
EVM address enrichment, counterparty risk and tx screening for agents, paid per call in USDC (x402)
Paid x402 crypto safety tools (Base/ETH/BSC): tx, approvals, contract risk, token deep scan.
Safety checks for AI agents paying on Base: free SpendGuard, paid x402 token risk and preflight.
Add one secure layer between your agents and this server.
