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

With no annotations, the description carries the full burden of disclosing behavioral traits. It reveals determinism, the paid two-step flow (call without x_payment → receive terms → sign → call again), and the evidence shape. It does not cover edge cases like what happens if both contract and wallet are provided, but it gives substantial behavioral context for a paid 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?

Four sentences cover the purpose, two usage modes, payment workflow, and an alternative pricing tool. Each sentence earns its place; there is no fluff or repetition. The structure is front-loaded with the core purpose and then layers operational details.

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 tool is moderately complex (4 params, payment flow, two modes, no output schema), yet the description covers all necessary aspects: what it returns (verdict/evidence), when to use each param, the payment protocol, and an alternative for pricing. It gives agents enough to decide and invoke correctly without requiring extra research.

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 baseline is 3. The description adds minimal extra semantic value: it clarifies the either/or relationship between contract and wallet ('or a wallet to check...') and adds 'holding by holding' detail, but the schema already describes each parameter well. No need to compensate for missing schema info.

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 'Deterministic scam checklist with a verdict and evidence' — a specific verb+resource statement that clearly identifies the tool's function. It further distinguishes itself from siblings by naming NFT-specific outputs (spam flags, copymint collisions, holder concentration) and by describing two operate modes (contract vs wallet). This is more than a generic 'check NFTs' statement.

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 explicit: 'Pass a collection contract to check the collection, or a wallet to check that wallet's whole scam exposure holding by holding.' It also points to an alternative: 'The free `pricing` tool lists every price at once,' which tells the agent when NOT to use this tool for pricing. This meets the bar for explicit when/when-not/alternatives.

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