agentforge

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

No annotations are provided, so the description must cover behavior. It explains chain-specific scanning details (EVM vs Solana) and states it returns a risk assessment. It does not explicitly declare read-only status, but scanning is inherently non-destructive. Overall, it provides sufficient behavioral insight.

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 concise sentences with no redundant information. The description is front-loaded with the core purpose and expands on chain-specific details efficiently.

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, the description mentions it returns a risk assessment but does not detail the structure. Given the tool's complexity, some additional output clarity would be beneficial, but it is still sufficiently complete for inference.

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 well-described parameters. The description adds no new parameter insights beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description specifies the verb 'scan', the target 'wallet', and the object 'risky token approvals'. It differentiates between EVM and Solana behaviors, and mentions the return type 'risk assessment'. This clearly distinguishes it from siblings like 'wallet_safety' or 'token_risk_metrics'.

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 for scanning approvals but does not explicitly state when to use this tool versus alternatives like 'wallet_safety' or 'token_risk_metrics'. No when-not-to-use or alternative guidance is provided.

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 provided, the description carries the full burden of behavioral disclosure. It describes what the tool does (finds vulnerabilities, etc.) but omits important operational details such as output format, limitations, required compilation, or side effects. This leaves gaps for an AI agent.

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 a single sentence that is concise and front-loaded with the core purpose. It contains no redundant information and every word adds value.

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 4 parameters, no output schema, and no annotations, the description covers the main functionality but lacks details on return values, error handling, and usage context. It is minimally adequate but not comprehensive for a tool with this 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?

The input schema has 100% description coverage, with each parameter already described (code, focus, language, previousCode). The description does not add any additional meaning or usage nuances beyond the schema. Baseline 3 applies as schema covers the parameters.

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 the tool performs smart contract security analysis, identifying vulnerabilities, gas optimizations, and best practice violations, and lists supported languages (Solidity, Rust, Move, TypeScript). This is specific and distinct from sibling tools like approval_scan or contract_docs.

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 the tool is for reviewing smart contract code, but it does not provide explicit guidance on when to use it versus alternatives, nor does it mention when not to use it. The context is clear but lacks explicit usage boundaries.

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 must convey behavior. It states the tool generates documentation and returns specific items, but omits safety implications (e.g., read-only) or constraints like requiring a verified contract. This is adequate 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?

The description is two sentences long, with the first sentence front-loading the purpose. The second sentence enumerates return items, which is efficient, though slightly verbose. It earns its place but could be more succinct.

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 should fully explain return values and constraints. It lists outputs but lacks details on error handling, optional parameter behavior, or default values. This leaves gaps, but the tool's simplicity keeps it minimally adequate.

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?

All parameters have descriptions in the input schema, covering chain, address, and focusFunctions. The description adds no additional insight beyond the schema, providing a baseline level of clarity.

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?

Description clearly identifies the tool as generating documentation for verified EVM smart contracts, listing specific outputs. This distinguishes it from siblings like code_review, which focuses on code analysis rather than documentation.

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: use when you need documentation for a smart contract. No explicit guidance on when not to use or comparisons against siblings, leaving the agent to infer appropriateness.

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 burden. It discloses what is monitored (admin ops, upgrades, etc.) but does not mention side effects (e.g., read-only), authentication needs, or rate limits. It is adequate but not comprehensive.

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 sentence, front-loaded with the verb 'Monitor', and efficiently lists key activities. No unnecessary words or structure issues.

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?

The description lacks detail about the return format or output, which is critical since no output schema is provided. It also does not specify whether results are real-time or aggregated, leaving ambiguity about what the agent will receive.

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?

Input schema has 100% description coverage, so each parameter is already documented. The description adds context about what the monitoring focuses on but does not enhance understanding of individual parameters beyond the schema. Baseline 3 is appropriate.

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

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

Description clearly states the tool monitors recent contract activity for specific suspicious events like admin operations, proxy upgrades, ownership changes, and pause events. The verb 'monitor' is precise, and the list of events distinguishes it from sibling tools like approval_scan or code_review.

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 for detecting suspicious contract activity but does not explicitly state when to use this tool versus alternatives like approval_scan or registry_lookup. No when-not-to-use guidance is provided.

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 provided; description lacks behavioral details such as whether it's read-only, rate limits, or what 'trend analysis' specifically means. It does not disclose limitations or side effects.

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 sentence, front-loaded with key information. Concise but could be slightly more structured (e.g., separate output format).

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, description should explain return values (e.g., gas units, trend format). It mentions 'trend analysis' but does not elaborate, leaving gaps for a simple 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?

Input schema covers 'chain' with enum and description; schema description coverage is 100%. Description adds 'trend analysis' which is about output, not parameter semantics. Baseline 3 is appropriate.

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

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

The description clearly states the tool provides current gas prices with trend analysis for EVM chains. It distinguishes from sibling tools like token_intel or pool_snapshot, but the phrase 'any supported EVM chain' is slightly broader than the explicit enum list.

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 guidance on when to use this tool versus alternatives. Sibling tools are unrelated, but the description does not mention context or exclusions.

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?

Without annotations, the description carries the burden and adds valuable context: refresh every 15 minutes, cached snapshot, and the specific return fields (TVL, APY, volume, IL risk, enrichment). It transparently describes the data freshness and scope beyond the schema.

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

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

Two sentences, front-loaded with purpose and filters, followed by returns and refresh rate. Every sentence adds value with no 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 8 parameters, no output schema, and no annotations, the description covers key aspects: purpose, filters, return fields, and data freshness. Missing details on error handling or explanation of 'IL risk' and 'enrichment', but still adequate.

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 baseline is 3. The description mentions filters ('protocol', 'chain', 'token symbol') which align with schema params but does not add new meaning beyond what the schema already provides. The output description (TVL, APY, etc.) is not parameter-specific.

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 the tool retrieves a cached snapshot of top DeFi liquidity pools, with specific filters by protocol, chain, or token symbol. It distinguishes well from sibling tools like token_intel or token_research which focus on individual tokens rather than pools.

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 for quick cached data but does not explicitly state when to use this tool versus alternatives like token_intel or registry_lookup. No when-not guidance or alternative names are provided.

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 discloses the operation is a read-only lookup and is free, but does not mention error handling (e.g., address not found), rate limits, or authorization needs. The behavioral disclosure is adequate for a simple lookup but lacks depth.

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, no unnecessary words. The purpose is front-loaded, and the benefit (free) is added in a single follow-up sentence.

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 tool's simplicity (2 params, no output schema), the description covers the purpose and return fields. However, it lacks details on optional parameters (chain), default behavior, and error cases. Still mostly complete for its 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 coverage is 100%, so the baseline is 3. The description adds that the address is '0x-prefixed', which repeats the schema's description. It does not clarify that chain is optional or provide additional context 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 clearly states the action (look up), resource (Known Contract Label Registry), and outputs (protocol name, category, risk level, tags). It distinguishes from siblings like approval_scan or token_intel, which have different purposes.

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 mentions it is free, implying no cost barrier to use. However, it does not explicitly state when to use this vs. alternatives (e.g., token_research for token-level info) or when not to use it.

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

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

No annotations provided, so description bears full burden. It discloses output fields: score range (-1 to 1), confidence, label (very_bearish to very_bullish), reasoning, and per-entity sentiment. This is comprehensive for a sentiment tool, though limitations or edge cases are not mentioned.

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 concise sentence front-loads the core action and enumerates return fields without waste. Every part serves a purpose, making it easily 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?

Despite no output schema, the description adequately covers return values and accepted contexts. Missing examples or constraints, but for a straightforward sentiment tool it is sufficiently 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 is 100%, with both 'text' and 'context' parameters described. The description adds value by detailing the return fields (not in output schema) and clarifying context values, going beyond 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?

Description clearly states it analyzes sentiment across specified contexts (crypto, finance, social media, general) and lists the return fields, differentiating it from sibling tools which are unrelated.

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?

Description implies use for sentiment analysis in listed contexts but does not explicitly state when to use vs alternatives or provide exclusions. However, no sibling tool performs similar function, so clarity is adequate.

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 provided, the description carries the full burden. It mentions return values (summary, key points, compression ratio) and configurable options, but does not disclose behavioral traits such as how long texts are processed, whether it is stateless, or if it relies on an AI model. Some additional context would be helpful.

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 two sentences, front-loaded with the core functionality and options, and includes return values. There is no wasted text.

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

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

Given no output schema and no annotations, the description covers the core purpose, all parameters, and the output. It is missing an explanation of 'compression ratio' or usage examples, but is largely complete for a summarization tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description summarizes the parameters (length, format, focus) but does not add meaning beyond what the schema already provides via descriptions and enums.

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 the tool's function (summarize text), the resource (text), and the configurable options (length, format, optional focus). It distinguishes itself from sibling tools like sentiment or translate, as no other tool offers summarization.

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 for text summarization but provides no explicit guidance on when to use or not use this tool over alternatives, nor any prerequisites or limitations.

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 provided, the description carries full burden for behavioral disclosure. It states the return includes full research on primary, abbreviated metrics on comparisons, and AI analysis, giving good insight into output. However, it doesn't mention side effects, authentication needs, or rate limits, which are minor gaps.

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

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

Two sentences, no unnecessary words. Action is front-loaded ('Compare...'). Every sentence adds value. Highly concise and well-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?

Given no output schema and no annotations, the description explains the return structure sufficiently (full research primary, abbreviated comparisons, AI analysis). It does not detail error handling or edge cases, but for a comparison tool with 3 parameters, it is reasonably 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 documentation covers all 3 parameters (100%). The description adds value by explaining that the primary token gets full research while comparison tokens get abbreviated metrics, which is beyond what the schema says. This improves semantic understanding.

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 the tool compares a primary token against up to 3 others, specifying the verb 'compare' and the resources (primary and comparison tokens). It distinguishes itself from sibling tools like token_research (likely single-token) by focusing on comparison and mentioning the output includes full research on primary and abbreviated metrics on comparisons.

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 use when comparing tokens, which is clear. However, it does not explicitly mention when not to use this tool or suggest alternatives among siblings. The context is sufficient for an agent to decide for comparison tasks, but lacks exclusion 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 present, so the description must fully disclose behavior. It mentions 'basic risk assessment' but does not detail what the assessment entails, what happens on missing tokens, or any side effects. The lack of behavioral context is a significant 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?

The description is a single sentence that front-loads the core functionality and supported chains. Every word adds value, with no wasted text.

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

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

Given the simple nature of the tool (2 params, no output schema), the description covers the returned data types and chain support. It lacks output format details but is adequate for a lightweight lookup. Minor gap: no mention of default chain behavior.

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

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

Schema description coverage is 100%; both parameters have descriptions. The tool description adds that tokens are 'EVM or Solana,' which aligns with the chain enum. However, it does not add semantic value beyond the schema, so baseline 3 is appropriate.

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

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

The description specifies the tool as a 'lightweight token lookup' returning price, market cap, volume, and basic risk assessment for EVM and Solana tokens. It clearly distinguishes itself from sibling tools like token_research or token_risk_metrics by emphasizing 'lightweight' and 'basic'.

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 term 'lightweight' implies quick lookups, but the description does not explicitly state when to use this tool versus alternatives (e.g., token_risk_metrics for deeper analysis). No when-not or alternative guidance is provided.

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 provided, the description bears the burden of behavioral disclosure. It describes the data sources and modules but does not mention whether the tool is read-only, if it requires authentication, or rate limits. It implies aggregation but lacks detail on potential delays or errors.

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 two sentences, front-loaded with the purpose, and every word adds value. It avoids redundancy or 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 the complexity (multiple sources, many modules) and no output schema, the description could be more complete. It does not explain the return format, whether results are aggregated into a single response, or any limitations (e.g., rate limits of underlying APIs). It covers the basics but leaves gaps for a complex tool.

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

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

Schema coverage is 100%, so the input schema already documents all parameters. The description adds value by explaining that the tool aggregates multiple sources and the relationship between the include array and specific data types, which goes beyond the schema's individual parameter descriptions.

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 'Multi-source token intelligence' and lists concrete data types (market data, DeFi metrics, etc.) and sources (CoinGecko, DeFiLlama, etc.). This distinguishes it from sibling tools like token_compare or token_risk_metrics, which likely have narrower focus.

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 what the tool does but does not provide explicit guidance on when to use it versus alternatives (e.g., token_compare for cross-token comparison, token_intel for deeper analysis). There is no mention of exclusions or preconditions.

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 full burden. It discloses that metrics are pre-computed for top tokens and live-computed for others, which is a useful behavioral trait. However, it omits details on required permissions, rate limits, or potential side effects, leaving gaps for a tool with no annotation support.

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 a single, efficient sentence that front-loads the purpose. It lists metrics concisely without redundancy. It could be slightly restructured for readability but earns its space without waste.

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 annotations or output schema, the description provides a solid overview of what the tool computes and its performance model (pre/live compute). It covers the key output elements (risk score range, metrics list). Minor gaps: no mention of error handling or data source, but adequate for the 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 coverage is 100% with descriptions for both parameters, so baseline is 3. The description adds context about the metrics computed but no additional format or syntax details beyond the schema. It reinforces that the address is for an ERC-20 token, which aligns with the schema's 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 specifies the tool provides quantitative risk metrics for any ERC-20 token, listing specific metrics (holder concentration, permissions, liquidity depth, deployer history, composite score). It clearly distinguishes from siblings like token_intel or token_compare by focusing on risk assessment.

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 the tool is for risk analysis but offers no explicit guidance on when to use it vs. alternatives like token_intel or token_compare. It lacks 'when-to-use' or 'when-not-to-use' instructions, leaving the agent to infer appropriate contexts.

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?

Description discloses key behaviors: auto-detects source language, preserves formatting and cultural nuances, and provides tone control. No annotations exist, so description carries burden adequately.

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

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

Two sentences, front-loaded with main purpose, no redundant words. Every sentence adds value.

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 or annotations, description covers purpose, parameters, and key behaviors. Could mention return format, but not a major 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 coverage is 100% (baseline 3). Description adds meaning by explaining the tone enum values, auto-detection behavior for sourceLanguage, and output quality. This goes beyond 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 clearly states the tool translates text with tone control, and mentions auto-detection and preservation. It is distinct from siblings which are unrelated.

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 or alternatives guidance. The description implies its use for translation, but does not exclude scenarios or compare to other tools.

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 full burden. It does not mention that decoding is a read-only operation, or any potential rate limits, prerequisites, or side effects. The description only lists what it outputs, not behavioral traits.

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 efficiently captures the tool's value. Every word is meaningful and there is no redundancy or unnecessary 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?

Given no output schema, the description provides an overview of return content but lacks details on structure or format. The tool is simple with only two parameters, so the description is minimally adequate but not comprehensive.

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 descriptions for both parameters. The description adds no additional meaning beyond 'any EVM transaction', which is a broad claim. Baseline 3 is appropriate as the schema already documents parameters well.

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 the tool's purpose: decoding any EVM transaction, listing specific output types (function call, parameters, token transfers, explanation). This is specific and distinguishes it from sibling tools which are different (e.g., token_intel, gas_oracle).

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 it should be used when you need to decode an EVM transaction, but provides no explicit guidance on when not to use it or alternative tools. Siblings are all different in purpose, so no direct competition, but the lack of exclusion criteria or context limits usability.

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 full burden. It describes the analysis actions and return values (risk score, etc.), but does not explicitly state it is read-only or mention side effects. It is fairly transparent for a safety check tool.

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

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

The description is two concise sentences that front-load the key actions and immediately explain the output and supported chains. Every sentence is valuable without 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 no output schema and no annotations, the description adequately covers return values and chains supported. However, it could add risk score interpretation and mention error handling for a more complete picture.

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 baseline is 3. The description does not add extra meaning beyond the parameter descriptions in the schema; it only summarizes the overall functionality.

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 performs a comprehensive wallet safety check including approvals, transaction activity, and contract risk assessment, and returns a risk score and other outputs. It distinguishes itself from siblings like approval_scan by offering a broader analysis.

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 this tool is for a full safety check but does not explicitly specify when to use it versus sibling tools like approval_scan or code_review. No when-not or alternative suggestions are provided.

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