Safe or Scam

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

With no annotations provided, the description carries the full burden and does disclose the outcome taxonomy ('valid / risky / invalid with reasons') and the breadth of checks, including network-dependent ones (domain/MX, SPF/DMARC). It does not mention auth needs, rate limits, or that lookups hit DNS, so a small amount of behavioral context is still missing.

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 the timing cue, followed by the return contract. Every listed check earns its place by telling the agent what signal it will get back.

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

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

There is no output schema, so the description must describe returns, and it does so concisely with the three-way verdict plus 'reasons'. For a one-parameter, read-only lookup tool, nothing material is left out.

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

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

There is a single parameter at 100% schema coverage, so the schema already defines it; the baseline would be 4. The description adds meaning by implying the many dimensions analyzed from that one input (domain reputation, typos, role type), which helps the agent understand the input is more than a regex check.

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 ('check') and resource ('an email address'), then enumerates exactly what is verified (format, MX, disposable domains, typo suggestions, role addresses, SPF/DMARC). It is trivially distinguishable from siblings like check_website, check_token, and check_wallet.

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

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

It states the usage context clearly: 'before sending or signing someone up', which tells the agent when this check belongs in a workflow. It does not explicitly name an alternative or a when-not-to-use case, but the sibling tools operate on entirely different resources, so no exclusion is needed.

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

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

With no annotations, the description carries the disclosure burden and does so reasonably: it names the checks (including an on-chain honeypot buy/sell simulation, which signals a heavier/possibly slower operation), states the output shape as red/yellow/green with reasons, and defines chain coverage. It omits cost/latency expectations and any caveats about simulation accuracy, which keeps it from a 5.

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

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

Three tight fragments: the core question first, then the checklist of signals, then the return format and chain support. Every element earns its place and 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?

For a two-parameter, fully schema-documented tool with no output schema, the description supplies the one thing structured data lacks: what the verdict means (red/yellow/green with reasons) and which signals drive it. Only performance/cost expectations for the simulation step are missing.

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

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

Schema coverage is 100%, with the chain enum and address format already documented in the schema, so the baseline of 3 applies. The description's 'EVM chains + Solana' only restates the enum scope and adds no new meaning about address handling or chain-specific behavior.

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 concrete question ('Is this crypto token a scam?') and then enumerates the specific analyses performed: honeypot buy/sell simulation, hidden taxes, mint/freeze authority, owner, blacklist, whale concentration, liquidity lock. That scope is clearly distinct from siblings like get_token_info (metadata) or check_wallet, so an agent can select it without opening the schema.

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

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

Usage is only implied — the risk-check framing suggests running it before interacting with or buying a token, and 'EVM chains + Solana' hints at coverage boundaries. No explicit when-to-use, when-not-to-use, or pointer to an alternative (e.g. get_token_info for neutral metadata) is given.

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

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

With no annotations, the description carries the full burden and does well: it discloses the exact checks performed, the output format (red/yellow/green with reasons), and chain coverage (EVM + Solana). It does not mention rate limits, data freshness, or authentication requirements, but for a read-only risk check these are secondary.

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 question, followed by a compact list of checks, the return format, and chain support. Every sentence earns its place, with no redundant or vague phrasing.

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

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

For a two-parameter read-only check with no output schema, the description is largely complete: it explains what is checked, what the output looks like, and which chains are supported. Minor gaps like data recency or rate limits remain, but an agent has enough 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 description coverage is 100%, so the schema already documents both parameters (chain enum and address format). The description adds only the phrase 'EVM chains + Solana', which broadly maps to the chain enum but does not add syntax or format details beyond the schema.

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

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

The description opens with a specific question that defines the tool's job: assess a wallet address for safety and exposure. It enumerates the exact risk categories checked (scam, phishing, theft, sanctions, mixer links, malicious approvals, contract vs personal, poisoned look-alikes), making it unmistakably distinct from siblings like check_token or get_wallet_balances.

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 first sentence gives a clear use case: deciding whether it is safe to send crypto to an address and whether the wallet is exposed. It does not explicitly name when to use alternatives (e.g., check_token for token contracts) or any exclusions, but the context is strong enough for an agent to route correctly.

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 transparency burden and does well by naming the checks performed (phishing databases, domain age, brand look-alikes, seed-phrase requests, wallet-drainer code) and the red/yellow/green with reasons return format. It does not explicitly state side-effect, auth, or rate-limit behavior, so it falls 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 compact sentences front-load the purpose, then list the checks and the return shape. No filler; the dense brand list is functional context 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?

For a one-parameter check with no output schema, the description explains the return categories and the kinds of evidence behind them. It is nearly complete, though it could clarify read-only behavior and when to use this over read_webpage.

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

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

Schema coverage is 100% for the single url parameter, so the schema already defines the expected address format. The description adds no parameter-specific syntax or constraints beyond what the schema states, making 3 the baseline.

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

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

The description opens with a direct question that identifies the resource (website) and the exact judgment being made (crypto scam/phishing), and it lists concrete signals it evaluates. It clearly distinguishes this security-check purpose from sibling tools like read_webpage, though it does not explicitly name alternatives.

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 phishing/scam question, but there is no explicit when-to-use statement, no exclusions, and no mention of when to choose read_webpage or another sibling. The agent must infer that this is the website security-check tool.

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

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

No annotations are present, so the description carries the burden; 'Read' implies a non-mutating operation and the second sentence usefully discloses that Solana results include mint and freeze authority fields, which other chains do not. It does not say how invalid addresses, unsupported mints, or rate limits are handled, so the behavioral picture is only partly filled in.

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 short sentences with the core purpose front-loaded and no filler. The second sentence could be tightened into a chain-qualified clause, 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?

With no output schema, the description compensates by naming the returned fields, which is exactly what an agent needs to know before calling. The main omission is sibling disambiguation against check_token, which is a routing rather than completeness 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 100% and the chain enum is fully documented, so the schema already carries parameter meaning. The description adds a small amount by implying that return fields vary by chain, but it does not map that variation onto the required parameters explicitly.

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 ('Read a token's on-chain details') and enumerates exactly which fields are returned, including Solana-specific ones. It does not, however, distinguish itself from the sibling check_token, which an agent could easily mistake for this tool.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of the sibling check_token (presumably a risk/safety check). The description reads as a definition rather than a routing rule, leaving the agent to infer which of the two token-related tools to 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?

With no annotations, the description carries the disclosure burden and does well by enumerating the returned statuses, confirmations, parties, value, fee, method, transfers, approvals, unlimited-approval flag, and Solana balance changes. It omits error/not-found behavior and permission or rate-limit context, which keeps 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?

The description is front-loaded with the core action and then lists return details compactly. Despite being a single dense sentence, every clause adds useful information for interpreting the result.

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 explain the return contents, and it does so thoroughly for a simple two-parameter lookup: status, confirmations, parties, value, fee, method, token/NFT transfers, approvals, and Solana account balance changes. Nothing critical is missing for this tool's complexity.

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

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

Schema description coverage is 100%, so both hash and chain are already documented in the schema. The description adds no syntax or semantic detail beyond the schema for these parameters; its Solana note concerns return behavior rather than parameter meaning.

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

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

The description uses a specific verb and resource: "Look up a transaction by hash." That clearly separates it from all sibling tools, which handle wallets, tokens, email, websites, or pages, and it immediately identifies the required hash lookup.

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

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

It implies use when a transaction hash is available, but gives no explicit when-to-use guidance, prerequisites, exclusions, or direct comparison with siblings such as check_wallet or check_token. An agent must infer the calling context from the purpose alone.

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 well by disclosing that Solana returns every SPL token held, EVM returns popular tokens plus passed addresses, and the result also includes transactions sent and a contract flag. It does not cover permissions, rate limits, pagination, or error behavior, which keeps it from a 5.

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

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

The description is tight and front-loaded, leading with the primary action and then adding chain-specific return details without filler. Every sentence contributes useful scope 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?

There is no output schema, so the description appropriately explains key return contents: balances, transactions, and contract status. It is complete enough for an agent to call the tool correctly, though it could say more about response shape or read-only/rate-limit behavior.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics: it explains that EVM results include popular tokens by default and that the tokens parameter adds extra EVM token addresses. It also clarifies chain-specific return behavior beyond the enum description.

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 and resource ("Get a wallet's balances") and enumerates exactly what is returned: native coin, tokens, transactions, and contract status. It is clear enough to distinguish the tool from a generic wallet check, but it does not explicitly name or contrast with the sibling check_wallet tool.

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

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

The description explains chain-specific token behavior, but it does not say when to use this tool instead of check_wallet, get_token_info, or get_transaction. There are no explicit usage conditions, 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 behavioral burden and does well: it discloses output format, that menus/footers/ads/scripts are stripped, and a billing trait ('Not charged if the page can't be fetched'). It omits rate limits, authentication needs, and handling of JS-rendered or truncated pages, which keeps it from a 5.

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

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

Two tight sentences, front-loaded with the action and return value, followed by a useful billing note. 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?

For a two-parameter, no-output-schema tool, the description explains the return value well (Markdown with headings/lists/links/code plus title and description). Minor gaps remain around truncation behavior and unsupported page types, but nothing critical 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 100%, so both url and max_chars are already documented in the schema. The description adds no syntax, format, or behavioral detail about parameters beyond what the schema provides, making the baseline 3 appropriate.

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

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

States a specific verb and resource ('Fetch any public web page') plus the exact return shape (clean Markdown of main content, title, description). This is clearly distinguishable from sibling check_website, which is an availability check, not content retrieval.

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, use this when you need page content rather than just a status check, but the description never names check_website or states when not to use this tool. No prerequisites or alternative routing are given.

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