base_token

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

With no annotations, the description carries the burden of behavioral disclosure. It does reveal the pay-per-call cost ($0.02 USDC) and the 'live' nature of data, which are useful behavioral traits. However, it does not disclose error handling, response format, or any potential side effects (though it is a read operation). The cost disclosure is a positive addition, but other aspects like rate limits or failure behavior are 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?

The description is two concise sentences. The first sentence front-loads the core data fields, and the second covers the cost. There is no fluff or repetition. Every sentence adds value, making it easy for an agent to parse quickly.

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 tool with no output schema, the description is fairly complete. It lists the returned data (price, liquidity, volume, pairs, metadata), specifies the token type (base ERC-20), and notes the cost. It could mention error cases (e.g., invalid address) or confirm that it's a read-only operation, but these are minor gaps given the simplicity of the tool. The description covers most essential 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?

Schema description coverage is 100%, as the schema itself describes the parameter as 'base ERC-20 token address'. The tool description adds no new semantic information about the parameter beyond that; it repeats the scope ('any base ERC-20 token') but doesn't clarify format, checks, or edge cases. Baseline of 3 is appropriate since the schema already documents the parameter adequately.

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: it provides live price, liquidity, 24h volume, DEX pairs, and onchain metadata (name/symbol/decimals) for a base ERC-20 token. The specific resource (token) and the scope ('any base ERC-20 token') distinguish it from sibling tools like base_balance or base_trending, which cover different data types.

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 by focusing on token-specific data, but it does not explicitly state when to use this tool over siblings, nor does it mention exclusions or alternatives. For instance, it doesn't say 'use base_balance for wallet balances' or 'use base_trending for trending tokens'. The purpose is clear enough that an agent could infer usage, but explicit guidance is absent.

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