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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantially more: the upstream data source (Blockscout), a concrete scope limit (most recent 50 transactions only), known blind spots (no SDN screening because the list is 78 MB, no mixer checks, no full wallet age), and the full payment/auth mechanic (x402, USDC, Base/Solana/Arc, charged only on success). Those are exactly the operational facts an agent needs and none are derivable from the annotations.

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

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

Three sentences with a clear information hierarchy: what you get, what you don't get, what it costs. Every clause carries signal — even the seemingly incidental '78 MB, too large per request' explains why a commonly expected check is absent, pre-empting a false-negative assumption.

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?

An output schema exists, yet the description still front-loads the returned fields, and it covers scope limits, data source, cost, and payment rails. For a single-parameter read-only lookup, nothing an agent needs in order to decide or call correctly is missing.

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

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

There is a single required parameter with 100% schema description coverage, including the '0x... 40 hex characters' format, so the schema already carries the semantics. The description adds no address-specific guidance (no checksum requirement, no contract-vs-wallet distinction for the input), so the baseline 3 applies.

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

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

The description opens with a specific verb+resource ('Ethereum wallet profile from Blockscout') and enumerates exactly what fields are returned: ETH balance, EOA vs contract, ENS, scam flag/reputation, tags, and recent-50-tx activity. It then explicitly separates itself from sibling capabilities by naming what it does not do (OFAC screening, mixer checks, wallet age), so an agent can distinguish it from agent_intel_ofac_sanctions_preflight and agent_intel_deployer_rug_forensics without reading 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 'NOT included' sentence gives clear exclusion conditions that effectively route the agent to the specialized siblings (OFAC preflight, mixer/Tornado tooling) when those are required. It also discloses the pricing model, which is a real selection criterion at $0.003/call. What it lacks is an explicit positive trigger ('use this first when you need a quick identity snapshot of an address') or a named alternative tool, so it stops short of full when-to-use/when-not guidance.

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