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

Beyond the annotations, it discloses that metadata JSON is fetched SSRF-safe via target_fetch with public-IP pinning, that the call is billed at $0.01 USDC per successful call via x402 on Solana, and that an HTTPS equivalent exists. That is real behavioral context (cost, payment auth, safety posture) an agent cannot get from readOnlyHint/idempotentHint alone.

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?

Dense but front-loaded: the core capability leads, then return fields, then safety, then price and the HTTPS mirror. Every clause carries information, though the packed run-on style makes the schema-relevant gaps harder to spot.

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 return-field list (name, description, image + gateway URL, attributes) usefully covers the response. But for a 2-required-param tool at 0% schema coverage, the missing chain specification and parameter formats are material omissions an agent must guess at.

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 0% and the description says nothing about either required parameter: it never states whether 'contract' is an EVM address, which chain is queried (no chain parameter exists at all), or whether tokenId is decimal or hex. With zero schema help, the description should have compensated and does not.

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 names the exact resource (ERC-721/ERC-1155 token metadata) and enumerates the specific fields resolved (tokenURI/uri, ownerOf, collection supply, EIP-2981 royalty), so the agent knows precisely what it gets back. It does not explicitly differentiate itself from adjacent siblings such as evm_contract_info or sol_token_meta, which keeps it just short of a 5.

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 resource description (call it when you need NFT metadata), and the HTTPS/x402 alternative endpoint is given, but there is no explicit when-to-use-versus-siblings guidance or statement of the chain scope that would tell the agent when this tool is the wrong choice.

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