Automaton Onchain Tools

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

With no annotations, the description carries the full burden and does: it discloses data provenance ('GoPlus + explorer event logs, each re-read onchain'), the ranking heuristics (unlimited, unknown spender, unverified or non-contract spender, flagged), the exact return payload shape (to, data, chainId, value 0), and degradation behavior ('partial results if a chain fails'). It also states cost ($0.02), which is the kind of operational detail agents need and rarely get.

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 key verb and scope, and the two trailing sentences (per-chain status, partial results, cost) earn their place as distinct facts. The main sentence is long and packs a nested parenthetical about data sources, which slightly hurts scannability but contains no filler.

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

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

No output schema and no annotations exist, so the description has to do the work — and it largely does, enumerating the risk categories and the revoke-transaction fields returned. What's left underspecified is the exact result envelope (how per-chain status is structured, whether approvals are nested per chain, ordering guarantees) for what is clearly a multi-object 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?

Schema coverage is 0% and the single parameter is an unlabeled 'address' with only a regex pattern. The description compensates partially by establishing that the address is an EVM wallet swept across seven EVM chains, which usefully rules out Solana-style addresses given the solana_* siblings. It does not say whether checksummed or lowercase input is expected, but the schema pattern covers that 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?

Starts with a specific verb and resource ('One call sweeps a wallet') and enumerates the exact chains, the two approval classes covered (ERC-20 allowances, NFT setApprovalForAll), and the output (ready-to-sign revoke tx). This clearly distinguishes it from the many single-chain siblings like base_token_approvals or ethereum_token_approvals without any schema inspection.

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 'One call sweeps a wallet on Base, Ethereum, BNB...' establishes the aggregate multi-chain context, which implicitly frames when to pick this over the per-chain *_token_approvals siblings. However, it never names an alternative or states a when-not condition (e.g. 'use base_token_approvals for a single chain'), and the $0.02 cost is stated without guidance on when that trade-off is worth it.

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

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

With no annotations present, the description carries the full behavioral burden. It does well to disclose the hard cost ($0.005) and the exact data surface covered, which tells the agent this is a single read-only lookup. However it says nothing about behavior on an address with no code, unverified contracts, partial-failure cases, or whether results are cached/fresh, so important behavioral gaps remain for a zero-annotation 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?

It is a single dense sentence that front-loads the action and chain, then lists capabilities in roughly priority order with the price tacked on at the end. Slight cost for being a run-on list rather than a structured sentence, but there is essentially no wasted wording.

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 and no annotations, the description must carry the return-shape burden, and it does so by naming every field group returned (type, balance, nonce, proxy standard, token metadata, copycat flag) plus the price. Missing only edge-case behavior and a note on how it relates to the deeper sibling tools.

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 exactly one parameter, and schema coverage is 0% — the regex pattern in the schema conveys the 0x+40-hex format but has no description. The description contributes only that the address must be an Arbitrum address ("Inspect any Arbitrum address"), which adds real but minimal meaning, leaving it squarely at the minimum-viable level.

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 and resource ("Inspect any Arbitrum address") and then enumerates exactly what is resolved: EOA/contract/EIP-7702 status, ETH balance, nonce, proxy implementation standards, and ERC-20 metadata plus a copycat flag. The Arbitrum chain qualifier separates it from the many sibling *_address_inspect tools, though it never distinguishes itself from overlapping siblings like arbitrum_contract_risk or token_deep_scan.

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 or when-not-to-use guidance and no named alternative. Usage is only implied by the breadth of the enumeration, which signals this is the general-purpose first-pass address overview tool, but an agent must infer that from content rather than being told.

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 does real work: it names the data source (free public data / Sourcify), discloses the cost ($0.005), and bounds expectations ('heuristic', 'not an audit or financial advice'). Missing details are minor — no mention of caching, rate limits, or freshness of the data.

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, front-loaded with the tool's purpose and followed by the check list, disclaimer, and price. Every clause carries information, though the long comma-delimited enumeration is slightly harder to scan than a structured list would be.

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 and no annotations, so the description must carry the burden — and it largely does by listing exactly which risk signals are returned and adding the cost and disclaimer. What's absent is any indication of return shape (field names, score scale, pass/fail semantics), which an agent would still need to guess.

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 schema description coverage is 0%, though the schema supplies type and a 0x-address regex. The description implies the input must be an Arbitrum contract address but adds no format, casing, or checksum guidance beyond what the schema pattern already enforces.

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 ('heuristic risk flags for an Arbitrum contract') and enumerates the exact checks performed (Sourcify verification, proxy/admin, owner type, mint/pause/blacklist/fee selectors, bytecode size, copycat detection). This clearly separates it from arbitrum_address_inspect (general address) and token_deep_scan, and the chain is explicit.

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

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

Use is implied by the enumerated checks and the disclaimer 'Not an audit or financial advice', which tells the agent this is a lightweight pre-screen. However, there is no explicit guidance on when to prefer this over the sibling arbitrum_address_inspect or token_deep_scan, nor any stated prerequisites.

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. It does add real value: it discloses the cost ($0.005) and the important coverage limit (only 8 tokens, only common spenders), which tells the agent results can be incomplete. However it never states read-only/no-side-effects, latency, or how the 'unlimited' flag is surfaced in the response.

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

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

One front-loaded sentence naming the resource first, then scope, then behavior, then price — all content earns its place. Slightly dense with parentheticals and an ellipsized list, but well within a reasonable size.

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 annotations and no output schema, so the description should explain what comes back. It covers what is checked and the cost, but not the shape of the result (per token-spender pairs? a list of flagged approvals? a boolean?). For a security-check tool with no output schema, that is a meaningful gap.

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 'address' with 0% schema description coverage, but the description's phrase 'a Arbitrum wallet's' makes its meaning obvious. Nothing is said about chain scoping assumptions or whether checksummed/lowercase addresses are accepted (the regex covers format only), so it neither fully compensates nor misleads.

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 ('Check a Arbitrum wallet's ERC-20 approvals') with the exact scope (8 major tokens, named spenders) and the key output behavior (flags unlimited approvals). An agent can tell it apart from arbitrum_address_inspect or wallet_report, and from the identically-shaped other-chain siblings, 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?

The enumerated token/spender coverage hints at the security-audit use case, and it implicitly excludes non-listed tokens/spenders. But there is no explicit when-to-use, no alternative named (e.g. use address_inspect for balance history, token_approvals per-chain for other networks), and no prerequisites. Usage is inferable rather than stated.

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 must carry the behavioral burden. It discloses the cost ($0.005), the enrichment source (openchain signature DB), and what the response contains. However, it is silent on failure behavior for unknown or non-Arbitrum hashes, latency, and whether decoding is best-effort when no signature match exists.

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 enumerates outputs and ends with the price. Every clause adds usable information; nothing is repeated from structured fields.

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

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

There is no output schema, so the description is the only source of return-value information. It names the key return facets, which is enough for selection, but it omits the response shape and edge-case behavior for tools that return decoded calldata and token transfer lists.

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 parameter at 0% schema description coverage, so the description should compensate. It implies the input is a transaction hash but adds no format, length, or chain-relevance detail beyond the schema's regex 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 pairs a specific verb ("Explain") with a specific resource ("a Arbitrum transaction") and enumerates the returned facets: status, fee, decoded method + args, and ERC-20 transfers. The chain qualifier cleanly separates it from the avalanche_/base_/bsc_/ethereum_tx_explain siblings, so an agent can pick the right chain variant 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?

This description provides no clear usage guidance. There is no indication of when to prefer this tool over calldata_decode, address_inspect, or contract_risk, nor any prerequisites such as needing a valid Arbitrum transaction hash. The only guidance is implied by the tool's name.

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 behavioural burden. It does add genuine context by disclosing the $0.005 cost and the full data surface returned, which the structured fields do not provide. It still omits read-only confirmation, error behaviour for invalid or non-existent addresses, and output format, so the disclosure is helpful but incomplete.

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 verb and scope before listing the returned data, with no wasted preamble. The parenthetical lists (EIP-1967/1167/zos, USDC/USDT/WETH) make it dense but every clause carries information; the only slight cost is that the run-on sentence is harder to parse at a glance.

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-address, read-only inspection tool with no output schema and no annotations, the description does the necessary heavy lifting: it enumerates the return surface and the cost. An agent knows what it will get and what it pays. What is missing is secondary: no return-shape detail, no mention of what happens when the address is not a contract or does not exist.

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 has 0% schema description coverage, so the description must compensate. It does state that the address is an Avalanche C-Chain address and that 'any' address works, which adds chain-scoping meaning. But it never specifies the required format or hex form; the agent must rely on the schema's regex pattern for that, which is only partial compensation.

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 (inspect) and resource (Avalanche C-Chain address) and enumerates exactly what is returned: address type, AVAX balance, nonce, proxy implementation, ERC-20 metadata, and copycat flags. It is clear what the tool does, but it never distinguishes itself from siblings like avalanche_contract_risk or ethereum_address_inspect; the chain is only signalled by the name and the phrase 'Avalanche C-Chain'.

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 'Inspect any Avalanche C-Chain address' and the output enumeration imply usage for address reconnaissance before interacting with a contract or token. However, there is no explicit when-to-use/when-not guidance, no mention of when to prefer avalanche_contract_risk, avalanche_token_approvals, or token_deep_scan, and no stated prerequisites.

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

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

With no annotations, the description carries the burden and does real work: it discloses the data source (free public data, i.e. no privileged indexing), the cost ($0.005), and the epistemic limits (heuristic, not an audit, not financial advice). It stops short of stating read-only behavior explicitly or describing failure modes for non-contract addresses.

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 opens with what the tool returns and closes with the disclaimer and price. The mid-sentence list is dense but every item is a concrete signal, so little is wasted; only slight readability loss from packing six checks into one clause.

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 carry the return shape. The enumerated signals hint at the flags returned, and cost/disclaimer are covered, but nothing says how flags are presented (booleans, severities, aggregated score) or how an address with no contract code is handled.

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% and the description never mentions the sole parameter. The regex in the schema documents the 0x+40-hex format, but the description adds no meaning about whether an EOA or a non-C-Chain address is acceptable, nor what happens if the address has no bytecode.

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 resource (Avalanche C-Chain contract) and a specific output (heuristic risk flags), then enumerates the exact signals checked: Sourcify verification, proxy/admin, owner type, mint/pause/blacklist/fee selectors, bytecode size, copycat detection. This clearly separates it from avalanche_address_inspect or token_deep_scan without the agent needing to open 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 by the enumerated checks — an agent can infer it is for pre-interaction contract due diligence. But there is no explicit when-to-use/when-not guidance and no routing to alternatives such as avalanche_address_inspect, token_deep_scan, or avalanche_token_approvals. The only boundary given is the 'not an audit' caveat, which limits claims rather than directing tool choice.

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 must carry behavioral context. It usefully discloses cost ($0.005), the limited set of tokens/spenders checked, and that unlimited approvals are flagged. However, it does not explicitly state that the operation is read-only, what the response looks like, or any rate-limit/auth requirements, leaving meaningful gaps.

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

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

The description is front-loaded with the core action and chain, then adds scope and cost efficiently in one compact block. The parenthetical token/spender lists are slightly dense but still earn their place by bounding the check.

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 approval scanner with no output schema and no annotations, the definition covers what is checked and the cost. It is incomplete on return value shape and safety semantics (e.g., read-only confirmation), which an agent would need to interpret results confidently.

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 should compensate for the lone address parameter. It implies a wallet address via 'wallet's' but gives no syntax, format, or required-status details beyond what the JSON schema pattern already 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+resource+chain: 'Check a Avalanche C-Chain wallet's ERC-20 approvals.' It also scopes the check to 8 major tokens and common spenders and mentions flagging unlimited approvals, which distinguishes it from chain-specific siblings like ethereum_token_approvals or avalanche_address_inspect.

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 chain-specific scope ('Avalanche C-Chain') makes clear it is the Avalanche variant among token-approval siblings, and the limited token/spender set tells the agent when this is useful. It does not explicitly say when not to use it or name alternatives, so it falls 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.

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

No annotations are supplied, so the description carries the full burden. It usefully discloses the $0.005 cost and that method decoding uses the openchain signature DB, but says nothing about failure modes (unconfirmed or unknown hash), rate limits, or what an undecodable method returns.

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 packs the return contents, the decoding source, and the price with no filler. Nothing is repeated from the schema and no sentence is wasted.

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

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

With one required parameter, no annotations and no output schema, the description does the needed work by listing the returned fields and the cost. The main remaining gap is how errors or unsuccessful/undecodable transactions are reported.

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%, but there is a single obvious parameter whose meaning is clear from the tool name and the regex pattern (0x + 64 hex chars). The description adds no explicit statement that 'hash' is the transaction hash, so it neither compensates for nor worsens the coverage 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?

Specific verb (Explain) plus specific resource (Avalanche C-Chain transaction), with the chain name distinguishing it from the eight sibling *_tx_explain tools. It further enumerates what the explanation contains: status, fee, decoded method + args, and ERC-20 transfers with symbols and human amounts.

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 this is the tool for a C-Chain tx hash rather than a raw calldata blob. There is no explicit routing guidance against calldata_decode or avalanche_address_inspect, and no stated preconditions (e.g. whether the hash must be confirmed/mined).

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 behavioral burden. It helpfully discloses cost ($0.005) and the fact that it is a read-only inspection surface, but says nothing about failure modes (e.g. non-Base or malformed addresses), rate limits, or whether results are cached.

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 front-loads the verb and resource, then lists the returned data points and the price. Every clause carries information; nothing is padding.

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 takes on the job of enumerating returned fields, and it adds the cost. For a one-parameter read tool this is nearly complete; only error/edge-case behavior is left 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?

One parameter with 0% schema description coverage; the regex pattern in the schema conveys format but nothing else. The description implies the argument is an address on Base ("any Base address") but adds no detail about required format, checksum handling, or whether a contract address is required.

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 ("Inspect") and resource ("any Base address") and enumerates exactly what is reported: account type, ETH balance, nonce, proxy standard, and ERC-20 metadata. This implicitly separates it from base_contract_risk, base_token_approvals and base_tx_explain, though it never names a sibling to route against.

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 when-to-use guidance, no stated prerequisites, and no mention of when to prefer base_contract_risk or base_tx_explain instead. The only conditional information is the price, which is not usage guidance.

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

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

No annotations, so description carries full burden. It discloses data sources ('free public data'), what it checks (Sourcify verification, proxy/admin, owner type, selectors, bytecode size), and importantly states it's 'Not an audit or financial advice' – setting expectations. Also mentions cost ($0.01). Missing: rate limits, timeouts, or output format 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?

One sentence plus two short clauses, front-loaded with the main purpose. No wasted words.

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

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

For a heuristic check tool with no output schema, the description lists the heuristics and sets expectations (not an audit). Missing: output format or structure, but since no output schema, the description could say more about what the flags look like. Still fairly complete.

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

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

Schema coverage 0%, but only 1 parameter. The description doesn't explain the 'address' parameter format (0x-prefixed 40 hex chars). However, the parameter is self-evident from the schema pattern. Baseline for 0 params is 4, but here 1 param with no description. Description doesn't add semantics beyond schema, but schema is self-explanatory. Score 4.

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

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

States a specific verb+resource: 'Heuristic risk flags for a Base contract from free public data'. The scope is clear and it's distinguishable from sibling tools like bsc_contract_risk and ethereum_contract_risk by chain (Base).

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?

Implicitly indicates usage: risk assessment for a contract. But no explicit when-to-use vs alternatives (e.g., vs base_address_inspect). No exclusions or conditions stated.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the data source (GeckoTerminal), the 20-result cap, cost ($0.01), that checks are heuristics and not an audit, and the important limitation that B20 native tokens cannot be checked by bytecode. It also enumerates exactly which risk signals are computed (Sourcify verification, proxy, owner type, mint/pause/blacklist/fee functions, copycat flag).

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?

Dense but front-loaded: what it is, what's risk-checked, what's returned, then cost. The risk-signal list is long yet each item is a distinct decision-relevant field, so little 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 and no annotations, so the description must describe the payload — which it does by listing pool DEX, age, liquidity, FDV, 1h buys/sells and the risk flags. It stops short of stating the response envelope or ordering guarantee, a minor gap for a single-parameter listing 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?

The single 'limit' parameter has 0% schema description coverage and no enum, so the schema provides only a pattern. The description compensates with 'up to 20', which explains the legal range and the default behavior implicitly; it does not clarify what happens if limit is omitted, keeping it short of a 5.

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 ('newest token launches on Base') plus the venues covered (Uniswap, Aerodrome, Bankr, launchpads), which cleanly separates it from launch_feed, bsc_launch_feed and solana_launch_feed. An agent can pick this one for Base 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?

The chain scoping and 'risk-checked at request time' implicitly tell you when this is the right feed, and the copycat/B20 caveats hint at what it can and can't answer. However, there is no explicit routing to token_deep_scan, token_report or base_contract_risk when an agent needs a deeper per-token audit.

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. 'Check' strongly implies a read-only operation and it usefully discloses the $0.005 cost and that unlimited approvals are flagged, but it does not state whether results are cached/live, rate limits, or failure modes for unapproved or non-wallet addresses.

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 front-loads the action and resource, with the token/spender lists and cost as useful supporting detail. Slightly packed with parenthetical enumerations, but 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?

There is no output schema, but the description summarizes what is returned (allowances for covered tokens/spenders, unlimited-approval flags), and there is only one simple required parameter. It is close to complete for this tool's low complexity, though the exact response shape remains unstated.

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 0% schema description coverage; the only structural hint is the 0x-prefixed 40-hex pattern. The description supplies context that the address is a Base wallet (implying a user wallet, not a contract), but does not explain format, chain, or validation beyond that.

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 (Check) and resource (ERC-20 approvals for a Base wallet), enumerating the token and spender coverage and the unlimited-approval flagging behavior. It is immediately distinguishable from the ethereum_ and bsc_ token_approvals siblings by chaining scope.

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

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

The chain-specific name and description make the usage context clear (auditing a Base wallet's approval exposure), and naming the covered tokens/spenders bounds expectations. However, it never states when to prefer or avoid it relative to siblings, nor any prerequisites such as wallet-vs-contract input.

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 behavioral burden. It helpfully discloses the $0.01 cost and the openchain signature DB source for decoded methods, but it does not state whether the operation is read-only, what permissions are required, or what happens on failure.

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 packs purpose, output fields, data source, and cost with no wasted words. It is appropriately sized for a one-parameter read tool.

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 no output schema and no annotations, the description adequately previews the returned fields and discloses cost. However, it omits parameter format details and safety/read-only context that would make the definition fully self-contained.

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

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

The description does not mention the single required parameter 'hash' or its 0x-prefixed 64-hex format. Schema description coverage is 0%, so the description was expected to compensate but provides no parameter-level 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?

States a specific verb ('Explain') and resource ('a Base transaction'), then enumerates the exact outputs: status, fee, decoded method and args, and ERC-20 transfers. The chain name distinguishes it from sibling tools such as ethereum_tx_explain and bsc_tx_explain.

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?

No explicit guidance on when to use this tool versus the other chain-specific tx explainers, and no prerequisites or exclusions are stated. Usage is only implied by the tool name and chain prefix.

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 does disclose the cost ($0.005) and enumerates the returned data categories, which is valuable behavioral context. It does not state whether it requires a specific API key, rate limits, or failure modes for invalid/non-existent addresses.

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

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

One dense sentence that front-loads the core purpose and then lists returned artifacts, ending with the cost. No filler.

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

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

For a single-parameter read tool with no output schema, the description is nearly complete: it enumerates return categories and cost. The only missing pieces are explicit usage guidance versus risk/approvals siblings and any authentication or failure-mode notes.

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% and the description does not describe the single 'address' parameter's format. However, the schema itself enforces a 0x-prefixed 40-hex pattern, so the agent can infer format. The description does not add syntax detail, so baseline applies with a slight 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?

Specific verb 'inspect' paired with a precise resource 'BNB Smart Chain address', and it enumerates exactly what is returned (EOA vs contract vs delegated, balance, nonce, proxy impl, ERC-20 metadata). This clearly distinguishes it from sibling chain variants and from bsc_contract_risk / bsc_token_approvals.

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

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

The description implies usage ('inspect any address') but provides no explicit when-to-use guidance versus siblings like bsc_contract_risk or bsc_token_approvals. Chain-variant siblings are distinguishable by name alone, but the tool specific to risk/approvals has no routing explanation.

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 disclose meaningful traits: the data source is free public data, the output is heuristic rather than authoritative, and there is a $0.01 cost. It does not cover auth requirements, rate limits, or the shape of the returned risk flags.

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 listing the checks, followed by a short disclaimer and cost clause; the value proposition is front-loaded. No filler text, though the disclaimer and price could be consolidated 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?

For a one-parameter, no-annotation, no-output-schema tool, the description supplies the checks performed, the data provenance, the cost, and the non-audit caveat. The main missing piece is any indication of the result format (score vs. flag list), which the agent must infer from the enumerated checks.

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 0% schema description coverage; the schema only supplies a hex-address regex. The description implicitly tells the agent the address must be a BNB Smart Chain contract, which adds a little meaning, but does not explain the address format or constraints beyond what the pattern already enforces.

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 (heuristic risk flags for a BNB Smart Chain contract) and enumerates exactly which checks are performed: Sourcify verification, proxy/admin, owner type, mint/pause/blacklist/fee selectors, bytecode size. The BSC scoping cleanly distinguishes it from ethereum_contract_risk and base_contract_risk siblings.

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

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

The 'Not an audit or financial advice' line establishes a boundary on what the tool should be used for, and the cost note gives a decision factor. However, there is no explicit guidance on when to prefer this over bsc_address_inspect or the other BSC siblings, leaving the routing to inference.

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 succeeds: it discloses the risk checks performed (Sourcify verification, proxy, owner type, mint/pause/blacklist/fee functions), the copycat flag, the upstream source (GeckoTerminal), freshness ('at request time'), and an honest caveat ('Heuristics, not an audit'). That caveat is exactly the kind of limitation an agent needs before relying on results.

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 resource and chain, followed by a compact feature/data/safety/cost ordering with no filler sentences. It runs long as a single dense sentence, but nearly every clause adds a distinct useful fact.

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 and no annotations, the description still tells the agent what fields come back (pool DEX, age, liquidity, FDV, 1h buys/sells), the result cap, the data provenance, the cost and the reliability caveat. Nothing material is missing for correct invocation.

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 20' conveys the ceiling for the single limit parameter. But it never clarifies the parameter's type (string) or that values are 1-20, and it does not say the parameter is optional or what the default is.

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?

A specific verb+resource ('newest token launches on BNB Chain') with named DEX sources (four.meme, PancakeSwap v2/v3/Infinity, Uniswap v4). The chain scoping makes it trivially distinguishable from base_launch_feed, solana_launch_feed and launch_feed.

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 clear from the chain and 'newest launches' framing, so an agent knows to pick this for BNB Chain token discovery rather than the base/solana siblings. It also prices itself ('Costs $0.01'), which helps routing decisions. No explicit when-not or named alternative, which keeps it below 5.

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

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

With no annotations, the description carries the full burden. It does disclose genuinely useful behavioral traits: the token/spender coverage set, that it flags unlimited approvals, and a cost of $0.005. However, it never states whether the address is validated, whether a missing/invalid address errors or returns empty, or what the response looks like beyond the unlimited flag.

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?

Single dense sentence, front-loaded with the verb and resource. The token and spender lists are long but informative examples rather than filler; the '$0.005' cost is tacked on at the end, which is fine but could be its own clause.

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?

It is a simple read-only lookup with one param and no output schema, so the description is close to sufficient. Still, for a paid, chain-specific security-check tool, it leaves open the coverage boundary (only 8 tokens, only common spenders) and the failure mode for unknown/invalid addresses.

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 (address) with 0% schema description coverage, but the name and regex pattern make the format self-evident (0x-prefixed 40-hex address). The description doesn't add format or validation detail, but with a single obvious parameter the baseline for near-zero param complexity is 3-4; the missing description on the address type keeps it at 3 rather than 4.

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

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

Names a specific verb (Check), resource (ERC-20 approvals), chain (BNB Smart Chain wallet), and scope (allowances for 8 major tokens to common spenders, flags unlimited). Sibling tools follow the same chain_x_tool convention, so the chain prefix lets an agent pick the BSC variant over base_token_approvals or ethereum_token_approvals without opening schemas.

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 specificity of the check (ERC-20 allowances), and the sibling namespace makes the chain choice obvious. But there is no explicit when-to-use or when-not-to-use guidance, and no note that this covers only 8 tokens and known spenders rather than all approvals or all chains.

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 discloses that it costs $0.01, which is important context for an agent making a paid call, but doesn't describe authentication requirements, rate limits, or whether the data is cached. The cost disclosure is a useful addition that annotations would not cover.

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

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

A single, dense sentence that front-loads the purpose, then lists the key outputs in a compact prose list. Every clause earns its place, and the cost is stated at the end without disrupting readability.

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

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

For a single-input tool with no output schema, the description covers purpose, output contents, and cost, which is sufficient to call it correctly. It does not mention error handling or edge cases, but the core requirements for an agent to invoke it are present.

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

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

Schema coverage is 0%, but there is only one parameter (hash), and the schema defines a precise regex pattern (^0x[0-9a-fA-F]{64}$) which is self-explanatory. The description does not add any meaning about the hash parameter beyond what the schema provides, but with a single well-constrained parameter, minimal compensation is needed.

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

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

The description names a specific verb (Explain) and resource (BNB Smart Chain transaction), then enumerates exactly what is returned: status, fee, decoded method with args, and ERC-20 transfers. The BSC chain is explicitly stated, which cleanly distinguishes it from the sibling ethereum_tx_explain and base_tx_explain tools.

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

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

The description implies when to use it (to decode/explain a transaction) but gives no explicit guidance on when-not-to-use or alternatives. Since the only other tx_explain tools are for different chains, the implicit routing is sufficient, but no exclusions or prerequisites are stated.

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 present, the description carries the full burden and delivers meaningful behavior: it discloses the signature source (openchain DB), warns about specific risky functions (approve/setApprovalForAll/permit/unlimited amounts), and states a per-call cost of $0.005. It omits auth requirements, rate limits, and behavior on undecodable data, keeping it below 5.

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

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

A single front-loaded sentence that packs purpose, output contents, and cost with no filler. Every clause earns its place.

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

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

With no output schema, the description must describe return values, and it does so explicitly (signature candidates, decoded args, warnings). For a one-param decode tool, this covers everything an agent needs to invoke 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?

Schema coverage is 0% and the single required param has no description, but the schema's regex pattern does constrain the format to hex calldata. The description implies the input is EVM calldata to be decoded but adds no syntax, length, or edge-case detail beyond that.

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 (decode) plus resource (EVM calldata) with explicit scope and intent (before signing), and it enumerates the outputs: signature candidates, decoded args, plain-English warnings. It is clearly distinguishable from siblings like ethereum_tx_explain and ethereum_token_approvals.

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" gives a clear situational trigger that tells the agent when this tool applies. It stops short of naming an alternative tool or stating exclusions, so it is context-rich 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.

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 $0.005 cost and the extra text records returned, but says nothing about read-only nature, required network/chain, rate limits, or error behavior when a name is unregistered.

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

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

Two compact sentences, front-loaded with the primary action and followed by the cost. Every clause carries information; nothing is redundant with the tool name.

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 and no annotations, the description does a fair job covering both input modes and summarizing the return payload (address, text records, or primary name). It stops short of describing the response structure or not-found behavior an agent might need to handle results.

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

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

Schema description coverage is 0%, so the description must compensate. It does so by naming the accepted input forms (ENS name, Basename, or address) that the regex pattern encodes only structurally, clarifying that both forward and reverse inputs are valid for the single 'name' 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?

States a precise verb (resolve/reverse-resolve) and resource (ENS name, Basename, address) with the exact transformation performed in each direction. This is clearly distinguishable from sibling address-inspection tools, which take an address and inspect chain state rather than mapping names to addresses.

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

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

The description implicitly tells the agent when each mode applies (name in → forward resolution, address in → primary name), but gives no explicit guidance about when to prefer this over siblings like ethereum_address_inspect, nor any exclusions or failure conditions.

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 a strong job enumerating the behavioral outputs: account type detection, balance, nonce, proxy implementation standards, and ERC-20 metadata. It also transparently states the cost ($0.005). It stops short of stating read-only/no-side-effects explicitly, but 'Inspect' strongly implies it, and the rich output disclosure is well above average.

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 opens with the verb and resource, then lists inspected attributes and closes with cost. Every clause carries information; there is no filler or redundancy.

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

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

Given a one-parameter tool with no output schema and no annotations, the description covers the essential return categories so an agent knows what to expect. It does not cover error/edge-case behavior (e.g., invalid address handling), but for this complexity level it is nearly complete.

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

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

Schema description coverage is 0% and there is one required 'address' parameter, so the description must compensate. It adds meaningful semantics by stating it accepts any Ethereum address and clarifying the recognized address types (EOA, contract, EIP-7702 delegated). It does not add format details like checksum expectations, leaving that to the schema 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 uses a specific verb ('Inspect') and resource ('any Ethereum address'), then enumerates exactly what it inspects: EOA vs contract vs EIP-7702 delegation, balance, nonce, proxy implementation, and ERC-20 metadata. This makes it readily distinguishable from siblings like ethereum_contract_risk or ethereum_tx_explain, which focus on risk or transactions rather than raw address-level introspection.

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?

No explicit when-to-use guidance, no alternatives, and no exclusions are provided. The description implies you call it to inspect an Ethereum address, but it never says when to prefer it over ethereum_contract_risk, ethereum_token_approvals, or base_address_inspect. The only usage-related note is the $0.005 cost, which is helpful but does not route 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 does well: it discloses the heuristic (non-authoritative) nature, the data source ('free public data'), and the cost per call. It still omits what happens on unverified or non-contract addresses, but the scope and limitations are honestly stated.

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 enumerating the checked signals, followed by two short qualifiers (disclaimer, cost). No padding; every clause adds information.

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 and no annotations exist, so the description must stand in for both — and it usefully enumerates the returned risk categories. It stops short of describing failure modes for unverified contracts or invalid-address 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?

One parameter at 0% schema description coverage, so the description must compensate. 'for a Ethereum contract' implicitly tells the agent the address must be a contract rather than an EOA, but no format, chain, or required-address detail is added beyond the schema's 0x 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?

Specific verb and resource: heuristic risk flags for an Ethereum contract, with an enumerated list of the signals checked (Sourcify verification, proxy/admin, owner type, selectors, bytecode size). It is clearly distinct from ethereum_tx_explain and url_safety_check, though it never explicitly contrasts itself with the sibling ethereum_address_inspect.

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 naming the resource type (a contract) and by the exclusions 'Not an audit or financial advice', but there is no explicit when-to-use statement or routing against ethereum_address_inspect / base_contract_risk / bsc_contract_risk. The cost note ($0.01) is a useful selection input but not guidance.

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

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

With no annotations, the description must carry the behavioral burden, and it does add real value: coverage scope (8 major tokens, named spenders), a notable behavior ('flags unlimited approvals'), and a cost signal ('$0.005'). It omits whether the call is read-only, whether auth/API keys are needed, and any rate limits.

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 sentence with the verb front-loaded and the two list-based scopes kept compact. The '...' ellipses leave the enumerations slightly open-ended, but 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?

For a one-parameter read tool with no output schema, the description covers scope, cost, and a key output behavior (unlimited-approval flagging). It is close to sufficient; return format and read-only status are the only meaningful omissions.

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% and the sole 'address' parameter has no description. The description never explains it, but a wallet address is self-evident and the schema pattern enforces the 0x+40-hex format, so the practical gap is small.

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 and resource ('Check a Ethereum wallet's ERC-20 approvals') and scopes it precisely: 8 named tokens and named spenders. The chain prefix in the name implicitly separates it from base_token_approvals and bsc_token_approvals, but it never states that differentiation 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?

There is no when-to-use guidance or mention of alternatives. The description implies a use case (auditing approvals for unlimited allowances) but never tells the agent when to pick this over ethereum_address_inspect or the base/bsc approval 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?

No annotations are supplied, so the description carries the full burden; it does add two useful behavioral facts the schema cannot convey (a $0.01 per-call cost and that method decoding uses the openchain signature DB). It says nothing about auth requirements, how failed/pending/unrecognized transactions are handled, or rate limits, which is a notable gap for a zero-annotation 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?

One dense sentence, front-loaded with the verb and resource, then the payload contents, then the cost. Nothing is padded and every clause carries information.

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 takes on the job of describing returns and does so concretely (status, fee, decoded method/args, ERC-20 transfers). Cost is disclosed as well. What is missing is only edge-case behavior for invalid or unindexed hashes.

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% and the sole parameter is documented only by a regex pattern. The description implies the input is a transaction but never states that the argument is a 0x-prefixed transaction hash or what happens for a non-transaction hash. It adds almost no semantics 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 (Explain) and resource (Ethereum transaction) and enumerates exactly what is produced: status, fee, decoded method + args, ERC-20 transfers with symbols/amounts. The chain-specific framing, plus the ethereum_ prefix and the presence of base_/bsc_ siblings, lets an agent pick it apart from base_tx_explain/bsc_tx_explain 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?

No when-to-use condition, no prerequisites, and no reference to the sibling chain variants (base_tx_explain, bsc_tx_explain). Usage is only implied by the tool name and the word 'Ethereum'. It reads as documentation of output rather than guidance on selection.

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 behavioral burden, and it does disclose two non-obvious traits: the call is live/real-time and it costs $0.005, which matters for an agent deciding whether to spend on the call. It still omits permission/auth requirements, caching/freshness semantics, and explicitly confirming it is read-only (implied by "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?

One sentence, zero filler, front-loaded with the resource and its covered chains, with the pricing fact appended where it is easy to find. Every clause earns its place.

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

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

No output schema exists, and the description does list the returned metrics, so an agent knows what it gets back; it also states chains and cost. The only meaningful omission is the "all" option on the chain parameter, which is not recoverable from the schema's pattern alone.

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 a single required parameter, so the description must compensate. It names the three chains covered, which implies the chain selector, but never mentions the parameter by name and omits that the accepted value "all" is valid, leaving a real gap for a 0%-coverage param.

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 gas snapshot") and enumerates exactly what the snapshot contains: gas price, base fee, block utilization, and estimated native cost for transfer, ERC-20 transfer and swap. The three covered chains are named, so an agent can tell immediately that this is a multi-chain gas tool and not any of the per-chain inspection/tx-explain siblings.

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

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

Usage is implied rather than stated: the agent can infer you call this when you need current gas conditions or a cost estimate on Base/Ethereum/BSC. No condition, prerequisite, or alternative is named (though no sibling competes on gas data), so the guidance is only implicit.

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

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

With no annotations, the description carries the full burden and does well: it discloses data source (GeckoTerminal), that risk checks happen at request time, that results are heuristics rather than an audit, and the $0.02 cost. It does not explicitly state that the operation is read-only or describe rate limiting/pagination, which keeps it short of 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?

The description is dense but front-loaded: purpose and scope come first, then risk-check details per chain, then shared flags, metrics, data source, caveat, and cost. Every sentence adds useful decision-relevant information with no filler.

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

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

Given no output schema, no annotations, and 0% parameter coverage, the description is substantially complete: it explains what is returned, the data source, the heuristic caveat, and cost. It is missing explicit read-only confirmation, the 'all' chain value, and any hint about output shape or pagination, but those are relatively minor.

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. It explains the limit cap ('up to 20 per chain') and the chain scope by naming Base, BNB Chain and Solana, but it never documents the accepted 'all' value or clarifies that 'bsc' is the schema value for BNB Chain, leaving a meaningful 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 specific resource and scope: newest token launches across Base, BNB Chain and Solana, up to 20 per chain, risk-checked. This implicitly distinguishes it from the per-chain siblings (base_launch_feed, bsc_launch_feed, solana_launch_feed), but it never names them or explicitly frames itself as the aggregate alternative.

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 multi-chain scope and the cost disclosure, but there is no explicit when-to-use or when-not-to-use guidance, and the per-chain sibling tools are never mentioned as alternatives. An agent must infer that this tool is the cross-chain option.

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 exist, so the description carries the full burden. It does disclose a real behavioral trait the schema cannot: a per-call cost of $0.005, plus the implicit read-only nature of 'inspect.' It does not state behavior on malformed/non-existent addresses, rate limits, or whether failure to detect a proxy is silently reported, which leaves gaps 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?

A single sentence, front-loaded with the verb and scope, then a tight enumerated list of returned fields, closing with the cost. Every clause carries information; the only mild cost is that the long field list reads as a run-on rather than being broken into a scannable structure.

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 one simple parameter, no output schema, and no annotations, the description does the heavy lifting by fully enumerating return contents, including the copycat-spoofing flag that an agent would otherwise not anticipate. It falls short only on error/edge-case behavior and confirmation that the operation is non-mutating.

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% and the description says nothing about the single 'address' parameter. The schema does enforce format via the regex ^0x[0-9a-fA-F]{40}$, so an agent can still construct a valid call, but the description adds no meaning (e.g., that the address must be an Optimism-chain address, not L1) beyond the structural constraint.

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 ('Inspect') plus the exact resource ('any Optimism address') and then enumerates the concrete outputs: account type (EOA/contract/EIP-7702), ETH balance, nonce, proxy standard, ERC-20 metadata, and a copycat flag. This is far more specific than the chain-prefixed siblings and lets an agent distinguish it from optimism_contract_risk or optimism_tx_explain 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 only implied: the enumerated output fields suggest 'use this when you need a broad profile of an address.' There is no explicit statement of when to prefer optimism_contract_risk, optimism_token_approvals, or optimism_tx_explain instead, and no prerequisites. The price note is helpful context but is not routing guidance.

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

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

With no annotations, the description carries the full burden and does well: it discloses the data source (free public data), the heuristic nature of the results, an explicit limitation ('Not an audit or financial advice'), and even the cost ($0.005). It stops short of stating read-only status explicitly or describing latency/rate-limit behaviour, keeping 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?

A single dense sentence plus two short caveat clauses, front-loaded with the core purpose before the signal enumeration. Every listed check is informative rather than filler, though the enumeration is long enough to push slightly past ideal length.

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

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

There is no output schema, but the enumerated checks effectively map to what the agent should expect back, and the cost and disclaimer cover the remaining decision-relevant facts. The main gap is return structure (e.g., how flags are presented or scored), which the agent 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?

One parameter at 0% schema description coverage, so the description must compensate. 'for a Optimism contract' establishes that the address is a contract on Optimism, but it does not clarify whether EOAs are valid input or how invalid/non-contract addresses are handled beyond the regex pattern in 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 ('Heuristic risk flags for a Optimism contract') and enumerates the exact signals checked (Sourcify verification, proxy/admin, owner type, mint/pause/blacklist/fee selectors, bytecode size, copycat detection). This clearly separates it from siblings like optimism_address_inspect and optimism_token_approvals, which do not assess contract risk.

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 phrase 'from free public data' and the caveat 'Not an audit or financial advice', which tells the agent this is a preliminary screening tool. However, there is no explicit guidance on when to pick this over optimism_address_inspect or token_deep_scan, nor any prerequisite or exclusion statement.

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

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

With no annotations, the description carries the burden and does disclose useful behavior: it is a read-only 'check', it only covers a curated set of 8 tokens and common spenders, it flags unlimited approvals, and it states a $0.005 cost. It stops short of saying what happens for tokens/spenders outside that set.

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 with the scope and cost stated up front; the parenthetical token/spender lists add useful specificity without bloat, though the trailing ellipses make the coverage feel loosely bounded.

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-only lookup with no output schema, the description covers what is inspected, the fixed coverage set, the flagging behavior, and the price. The main remaining gap is return shape and how non-covered tokens are reported.

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% and the single parameter is only constrained by a regex pattern with no description. The description implies 'address' is the wallet whose approvals are inspected, which adds some meaning, but it never confirms the format or that it must be an Optimism address.

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 (Check), resource (ERC-20 approvals / allowances), and chain (Optimism), then enumerates the exact token and spender coverage. This clearly separates it from siblings like optimism_address_inspect and optimism_contract_risk.

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 enumerated scope (8 major tokens against common spenders) and the 'flags unlimited approvals' note, but there is no explicit when-to-use or when-not-to-use guidance, nor a pointer to alternatives such as optimism_address_inspect or token_deep_scan.

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, and it only partially meets it. It usefully discloses the data source for decoding (openchain signature DB) and the per-call price ($0.005), which are real value-adds. But it says nothing about failure modes (unknown hash, pending tx, non-Optimism hash), whether results are cached, rate limits, or what the decoded output looks like when the signature DB has no match.

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, both front-loaded: the capability and its decoded outputs come first, the price last. No filler, no restatement of the tool name, and the output enumeration is compact and scannable.

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 and no annotations, the description does the right thing by enumerating the returned fields (status, fee, decoded method/args, ERC-20 transfers) and naming the decoding source. For a one-parameter read-style tool this is nearly complete; the residual gap is error/edge-case behavior, which matters given the 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?

The single `hash` parameter is documented in the schema only by a 0x+64-hex regex pattern; the description implies it is a transaction hash on Optimism but adds no format, casing, or validity guidance beyond the pattern. With one self-evident required parameter the schema does most of the work, so this sits at baseline adequacy rather than being a 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?

A specific verb ("Explain") plus resource ("a Optimism transaction") followed by an enumeration of what is returned: status, fee, decoded method + args, ERC-20 transfers with symbols and human amounts. The chain prefix in the name plus the enumerated fields distinguish it from arbitrum_tx_explain, ethereum_tx_explain and the other per-chain siblings. What is missing is an explicit statement that this is Optimism-only, leaving cross-chain routing to the naming convention alone.

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 that you call this with a transaction hash to understand what a tx did. There is no statement of when to prefer this over calldata_decode or optimism_contract_risk, nor any preconditions such as the tx needing to be mined or on Optimism specifically. The cost note adds practical context but is not usage guidance.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that the call is free (no cost/credits) and 'health check' implies a non-mutating probe, but it says nothing about what is returned, 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 short sentence with zero filler, and the key fact (free) is front-loaded. Nothing could be trimmed without losing meaning.

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 trivial zero-parameter probe with no output schema, the description is adequate to call the tool, but it never indicates what a successful or failed result looks like, which would be the one piece of added value worth including.

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, so there is nothing for the description to disambiguate. Baseline of 4 applies for a no-argument tool.

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 clear, specific function (a health check) and adds the useful qualifier that it is free. It does not need sibling differentiation because no sibling tool performs a health/connectivity check, though the phrase lacks an explicit verb like 'check' or 'verify'.

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 statement of when to call this tool, no prerequisites, and no mention of alternatives. Only the term 'health check' weakly implies its use for verifying service availability.

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 useful work: it discloses the cost ($0.005), implies a read-only inspection, and pre-announces the notable output — proxy standards detected and a copycat-token flag. It does not cover failure behavior for malformed addresses or whether results are cached, which keeps it short of a 5.

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

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

A single dense sentence with no filler, and the highest-value facts (what is inspected, what comes back, the cost) are front-loaded. The facet list is long but each item earns its place by signaling 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?

There is no output schema, so the description must enumerate return contents — which it does across account type, balance, nonce, proxy implementation, token metadata, and copycat flag. For a one-parameter read tool this is close to sufficient; only error/invalid-address handling 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?

Only one parameter and the schema pattern (^0x[0-9a-fA-F]{40}$) already pins the format precisely, so the baseline is high. The description adds the meaningful constraint that the address is a Polygon-chain address, which the schema itself cannot express. That is a small but real addition 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?

Specific verb ('Inspect') plus a specific resource ('any Polygon address'), followed by an enumeration of exactly what is resolved: account type (EOA/contract/EIP-7702), POL balance, nonce, proxy standard, and ERC-20 metadata. The chain prefix plus the facet list make it cleanly distinguishable from siblings like polygon_contract_risk, polygon_token_approvals and polygon_tx_explain.

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: 'Inspect any Polygon address' tells the agent the input domain but not when to prefer this over polygon_contract_risk or token_deep_scan, which overlap on contract/token facets. No exclusions or routing conditions are given, so the agent must infer the boundary.

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 does real work: it discloses the data source (free public data, implying coverage gaps for unverified contracts), frames results as heuristic flags rather than verdicts, and surfaces a per-call cost. It does not cover behavior on non-contract addresses or reporting confidence thresholds.

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

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

One dense but well-ordered sentence that front-loads the core purpose and then the check list, followed by a short disclaimer and cost note. Every clause carries information; nothing is redundant.

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 one required parameter, no output schema, and no annotations, the enumeration of checks effectively doubles as a description of what is returned. A brief note on result shape or edge-case handling for non-contract addresses would close the remaining gap.

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 carry the burden; it implies the address is a Polygon contract address but never explicitly describes the parameter, its chain constraint, or what happens for EOAs/non-contract addresses. The regex pattern in the schema at least enforces 0x + 40 hex format.

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 resource (a Polygon contract) and enumerates the exact checks performed: Sourcify verification, proxy/admin, owner type, mint/pause/blacklist/fee selectors, bytecode size, and copycat detection. That enumeration makes it clearly distinct from polygon_address_inspect and polygon_token_approvals, which operate on different subjects.

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 useful usage context: data comes from free public sources, output is heuristic rather than an audit, and each call costs $0.005 — enough for an agent to judge appropriateness and budget. It never names an alternative tool or states when another sibling (e.g. token_deep_scan for token-level concerns) should be preferred instead.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses the coverage boundary (only 8 major tokens and 'common spenders', with named examples), states a distinguishing output behavior (unlimited-approval flagging), and volunteers the price ($0.005). It does not state that it is read-only or describe response shape, 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?

One tight sentence front-loads the operation and scope, with the coverage caveat and price appended in a compact order. No filler or repeated information 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 one-parameter, no-annotation, no-output-schema tool, the description supplies the essentials: what is measured, which tokens/spenders are in scope, what the headline output is, and the cost. Remaining gaps (result structure, whether non-listed spenders are ignored entirely) are minor but not negligible.

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 'address' parameter has 0% schema description coverage (only a hex pattern), so the description must compensate — and it does by making clear the address is a Polygon wallet address whose ERC-20 allowances are read. Format/chain expectations are implied rather than spelled out, keeping it below a 5.

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 ('Check a Polygon wallet's ERC-20 approvals') and enumerates the token/spender scope plus the key output behavior ('flags unlimited approvals'). This distinguishes it from chain-siblings like polygon_address_inspect, polygon_contract_risk and polygon_tx_explain by the resource examined, though it never names an alternative 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?

Use case is implied by 'Check ... approvals' (an allowance-exposure/security check on a Polygon wallet), but there is no explicit when-to-use, no when-not-to-use, and no routing to or away from the other Polygon tools. The agent must infer that this is the approval-audit call rather than the risk or address-inspect call.

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 exist, so the description carries the whole burden. It does add real value: it discloses the reliance on the openchain signature DB for method decoding and that a price of $0.005 is charged, which is important for agent budgeting. It doesn't state read-only semantics, behavior on pending/unknown hashes, or error/rate-limit 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?

One sentence, front-loaded with the operation and its output breakdown, with the cost disclosure clipped onto the end. No filler.

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

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

No output schema, so the description must describe the return value — and it does, listing status, fee, decoded method/args, and ERC-20 transfers with symbols and human-readable amounts. Missing only edge-case coverage (pending or failed transactions, unknown signatures).

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, 'hash', documented only by a regex pattern in the schema (0% description coverage). The description never says it must be a Polygon transaction hash, though the sentence context makes that inferable. Some compensation, but 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?

Specific verb 'Explain' plus resource 'a Polygon transaction', and the description enumerates exactly what is returned (status, fee, decoded method + args, ERC-20 transfers). The chain name in the tool title and description cleanly separates it from the ~10 other *_tx_explain siblings.

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

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

Usage is only implied by the chain prefix — an agent can infer this is the Polygon variant of the tx_explain family. There is no explicit when-to-use framing or a pointer to alternatives like calldata_decode for raw calldata decoding.

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

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

With no annotations, the description carries the full burden and does well: it discloses the data source (public RPC), the cost ($0.005), an important accuracy caveat ("wallet age ... lower bound for very busy wallets"), and what it will not return (no USD prices). It omits how many recent transactions are returned and behavior for invalid or nonexistent addresses.

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, front-loaded with the verb and resource, then the payload list. The long enumeration is justified because there is no output schema, but the trailing "Costs $0.005" is buried at the end rather than surfaced earlier.

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 and no annotations, so the description must supply the return shape, which it does exhaustively, and it flags the age-lower-bound caveat. Gaps remain around result volume (recent tx count), pagination, and error handling for unparseable addresses.

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 0% schema description coverage, so the description must compensate; it only implies the input is a base58 Solana address via "any Solana address," adding no format, chain-prefix, or edge-case guidance beyond the regex already in 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?

Specific verb and resource ("Look up any Solana address") plus a fully enumerated return payload: account type, SOL/SPL balances, wallet age, activity counts, recent txs, and risk flags. The Solana scope and address-centric framing cleanly separate it from the many `*_address_inspect` siblings on other chains and from `solana_token_check`.

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 enumerated payload rather than stated, and there is one useful scoping hint: "No USD prices," which signals the pricing concern belongs to another tool. But it never names an alternative (e.g. `wallet_portfolio`, `solana_token_check`, `solana_token_delegates`) or states when-not to call it.

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

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

With no annotations, the description does substantial work: it discloses the data source (GeckoTerminal), cost ($0.01), return cap, request-time enrichment, and an important reliability caveat ('Heuristics, not an audit'). It does not state read-only behavior, authentication needs, rate limits, or error handling, but the safety profile is strongly implied by the feed nature.

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

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

The description is front-loaded with purpose and cap, then enumerates return fields, source, caveat, and cost. It is dense but every clause is informative; the length is justified given there is no output schema, though it could be slightly more structured.

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

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

For a tool with no output schema and no annotations, the description is fairly complete: it explains what each result contains, the data source, cost, and heuristic limitation. It still leaves gaps around parameter defaults and how to choose between this and related token-inspection tools.

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

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

The schema has 0% description coverage for the single optional `limit` parameter, so the description must compensate. It adds the maximum value ('up to 20'), but does not explain the parameter name, default behavior when omitted, or the string pattern constraint.

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

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

The description clearly states it returns the newest token launches on Solana, with specific sources and a cap of 20. It distinguishes itself from other-chain launch feeds by naming Solana, but does not explicitly differentiate from the generic `launch_feed` or clarify the boundary with `solana_token_check`.

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 'Newest token launches on Solana' and the caveat 'Heuristics, not an audit,' which signals a discovery use case rather than a security audit. However, it does not explicitly say when to use this instead of `solana_token_check` or `launch_feed`, nor does it state exclusions or 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 so well: it discloses the data source ('public RPC data'), lists what it can and cannot determine ('Lists what it couldn't determine'), clarifies it is 'Not an audit', and states the cost ($0.005). These are exactly the behavioral details an agent needs.

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 front-loads the main purpose and packs a lot of specific detail into a single long sentence, followed by two short clarifying sentences. It is efficient and every clause contributes, though the dense list format could be harder to parse than a bulleted structure.

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

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

Given the complexity of the checks, the absence of an output schema, and no annotations, the description is remarkably complete: it explains what is checked, what the limitations are, the data source, and the cost. An agent has enough context to call it correctly and set expectations.

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 parameter (address) with 0% schema description coverage. The description implies the address is the token mint address but never explicitly says so, leaving the agent to infer the mapping from the context and the base58 pattern in the schema. It adds some meaning but not enough to fully compensate for the missing schema documentation.

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 ('rug-check') and resource ('Solana token mint'), and enumerates many concrete checks (authorities, metadata mutability, Token-2022 extensions, holder concentration, etc.). It implicitly distinguishes from siblings by specifying Solana and a security-check focus, but does not explicitly name alternatives like token_deep_scan or token_report, leaving some ambiguity for an agent choosing between them.

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 usage is implied by the description ('Rug-check a Solana token mint'), but the tool provides no explicit guidance on when to use it versus alternatives, nor any conditions for exclusion. It does state 'Not an audit', which sets a boundary but is not a usage directive.

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 at all, the description carries the full burden and does so well: it discloses the live on-chain read, the exact output categories, the delegate-type classification scheme (plain wallet vs known program like Jupiter/Raydium/Orca vs unknown), and even the $0.005 cost. It stops short of explicitly stating the operation is read-only/no-side-effects or noting latency/rate limits, which is the only remaining gap.

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 and scope are front-loaded in the opening clause, and the cost note is a compact closer. The first sentence is long and heavily parenthetical, but the parentheticals (approvals analogy, program examples) genuinely aid an agent's routing decision rather than padding.

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 and no annotations, so the description must cover both behavior and returns — it does, enumerating result categories, the risk-level summary, revoke guidance, and pricing. An agent has enough to decide and call it correctly without further context.

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% — the schema gives just a regex pattern with no textual description. The description implies the input is a Solana wallet address ('Check a Solana wallet's ... delegates') but never names or explains the address argument, its base58 format, or whether non-wallet addresses are 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?

States a specific verb and resource — checking a Solana wallet's live SPL and Token-2022 delegates — and enumerates exactly what the result contains (delegate, allowance, UNLIMITED flag, delegate classification, permanent delegate, close authorities, risk level, revoke guidance). This is clearly distinguishable from siblings like solana_token_check or solana_address_lookup, which cover broader token/address inspection.

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 framing ('Solana's version of token approvals, the way drainers move funds') implies the security-audit use case, but the description never explicitly says when to pick this over solana_token_check or solana_address_lookup, nor does it state any preconditions (e.g. the wallet must be on Solana mainnet). Usage is inferable rather than stated.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the simulation uses eth_call and trades nothing, that results cost $1.50, that holder data has a Blockscout partial fallback, and that undetermined items are listed. It omits auth/credit mechanics and response shape, keeping 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-loaded with purpose and chain scope, then dense feature list in parentheses; every clause is informative. It is long but earns its length given the tool's breadth, with only slight density overrun.

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 annotations or output schema, so the description must stand alone; it covers what is measured, the partial-fallback limitation, undetermined-result disclosure, and cost. Only the return format and chain-optionality default are unaddressed, minor 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?

Schema coverage is 0%, so the description must compensate. It names the three chains (base/ethereum/bsc), giving human meaning to the chain pattern, but it never clarifies that chain is optional (only address is required) or what happens if omitted, and it adds nothing about the address 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?

States a specific verb and resource (deep token scan) and enumerates exactly what it covers: simulated buy/sell honeypot and tax detection, liquidity, LP lock/burn, holder concentration, owner powers. The multi-chain scope distinguishes it implicitly from the chain-specific contract_risk siblings, but it never names an alternative, so it falls short of the explicit sibling differentiation required for 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?

Words like 'Premium' and 'Costs $1.50' imply this is the expensive, thorough option and hint that cheaper tools exist, but the description never says when to prefer it over token_report or the per-chain contract_risk tools. Usage is only inferable, not stated.

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. It does add genuinely useful behavioral context — the $0.25 cost and the breadth of the scan — but it omits whether the call is read-only, whether results are cached, latency, and failure behavior for unverified/unlisted tokens. Cost disclosure is a meaningful plus for an annotation-free 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?

A single dense sentence with the value proposition front-loaded and the price at the end where it belongs. Long but every clause names a concrete capability; no filler.

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

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

No output schema and no annotations exist, so the description must preview returns — and it does, listing metadata, ownership, verification, and flag categories plus a plain-English summary. The main residual gap is that it never states this is a read-only report versus anything stateful.

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. It does supply the valid chain values implicitly ('Base, Ethereum or BNB Smart Chain'), which maps to the base|ethereum|bsc enum, but says nothing about the address parameter's format or required-ness, leaving the regex pattern in the schema to do the work.

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

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

States a concrete verb+resource ('one-call token due-diligence') and enumerates the exact checks performed (proxy/upgradeability, owner balances, mint/pause flags), which is far more informative than the bare name. It does not, however, differentiate itself from sibling token_deep_scan or solana_token_check, so an agent must still infer which one wins.

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

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

Usage is only implied by 'due-diligence' and the chain list; there is no explicit when-to-use, no exclusion, and no pointer to the obvious alternative (token_deep_scan) or to the per-chain base_contract_risk tools. An agent can guess the context but is not guided.

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

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

With no annotations, the description carries the full burden and does well: it names the exact data sources, discloses that results are heuristic, warns it is not security advice, and states the $0.005 cost. It omits rate-limit/auth behavior but adds substantial context beyond a bare verb.

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 action and detection list, followed by a compact caveat and cost. Every clause earns its place with no filler.

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

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

For a 1-param tool with no output schema and no annotations, the description covers inputs and methodology but says nothing about the shape of the result (score, boolean, matched-signal list), leaving the agent guessing at return semantics.

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 'url' parameter, so the description must compensate. It only names the resource as 'URL' without adding format or validation detail (e.g., punycode tolerance), though the lone parameter is largely self-evident.

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 (check a URL for phishing/scam signals) and enumerates the concrete detection methods (blocklists, RDAP domain age, punycode, HTTPS reachability). This is unmistakably distinct from the address/contract/tx inspection siblings.

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

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

Usage is implied by the description — check a URL when you suspect phishing — but there is no explicit when/when-not guidance. Since no sibling overlaps in function, there is little alternative-routing to specify, so 3 is fair.

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 must carry the behavioral burden, and it does disclose meaningful traits: exact chain coverage, token coverage, absence of USD valuation, and an atypical cost of $0.01. It omits failure modes (invalid/empty address, unsupported chains) and any rate-limit or auth context, keeping it short of 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?

Three short sentences, scope front-loaded, with the two most decision-relevant caveats (no USD pricing, $0.01 cost) trailing as punchy fragments. No padding.

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 characterize returns, and it does so at the right altitude: chains, native plus 8 tokens, and the absence of USD prices. It does not cover partial-coverage cases (e.g., unlisted tokens, chains with no activity), which is the only notable gap.

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 is expected to compensate, but it never mentions the single address parameter or its format. The schema's 0x{40} pattern does convey the required format on its own, so the gap is real but not severe.

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 (wallet snapshot) and immediately bounds it: three named chains, native balance plus 8 major tokens per chain with examples. The cross-chain portfolio scope implicitly distinguishes it from the per-chain siblings like ethereum_address_inspect and bsc_address_inspect.

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 is for portfolio overview across chains, and the 'No USD pricing' note usefully sets expectations, but there is no explicit when-to-use vs. the per-chain inspect tools and no stated prerequisites.

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 present, the description carries the full burden, and it does disclose genuinely useful behavioral facts: the $0.25 cost (a paid call), the three-chain scope in one invocation, and that unlimited approvals are flagged. It still omits whether the call is read-only, latency/rate-limit expectations, and data freshness, so it is not fully self-sufficient.

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 front-loads the scope ('Premium one-call wallet report across...') and then lists payoff contents, with the cost appended last. Every clause carries information; nothing is padding.

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 must convey what comes back, and the enumerated sections (balances, approvals, address type, risk summary) do that reasonably well. Missing a statement about read-only safety and about how the three chains are returned in aggregate keeps it short of full completeness.

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 `address` parameter, and the description never mentions it at all. The parameter is self-evident from the tool's purpose and the schema's 0x+40-hex pattern, but the description adds no explicit meaning (e.g. which chains an address applies to) 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 resource ('wallet report') and enumerates its actual contents (balances, token approvals, address type/EIP-7702 delegation, risk summary), which is far more informative than the name alone. The 'across Base, Ethereum and BNB Smart Chain' / 'one-call' framing implicitly separates it from the per-chain siblings like base_token_approvals or ethereum_address_inspect, but no sibling is named directly.

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-call' and the cost line imply this is the tool to reach for when a single consolidated multi-chain view is wanted rather than several single-chain calls. However, it never states when NOT to use it or names the obvious alternative (wallet_portfolio), so the routing decision 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.