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

With no annotations, the description carries the full burden and does real work: it discloses that live-follow data must be read from Hyperliquid directly via clearinghouseState and userNonFundingLedgerUpdates using the address from GET /copy/wallet, and it defines the edge-case return shape for retired paper follows (result: null, retired.code = paper_copy_retired). It stops short of describing the normal success payload, which keeps it off a 5.

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?

Every sentence contains substantive information, but the middle sentence is a long run-on that packs the wallet definition, two Hyperliquid info endpoints, and an address source into one clause chain, and the opening is a sentence fragment. It is dense and front-loaded in intent, but readability suffers.

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 annotations and no output schema, the description must cover return behavior, and it only documents the retired-paper-follow case while leaving the shape of a live follow's status undefined. It compensates well on external-dependency context, but an agent still does not know what a normal successful response looks like.

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 tool takes zero parameters, so the baseline is 4. The description goes slightly beyond by explaining where the account address used for downstream reads comes from (GET /copy/wallet), which is useful context even though there is no parameter to clarify.

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 'What this agent is copying, per leader', which identifies the resource as copy-follow status keyed by leader, and explicitly separates it from get_positions by stating 'get_positions reads your agent wallet, not the copy wallet.' The opening fragment is terse rather than a clean verb+resource statement, but an agent can still tell what the tool returns and how it differs from the nearest sibling.

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?

It gives situational context — live follows versus a retired paper follow — and warns that get_positions is not a substitute, which implicitly steers usage. However, it never states plainly when to call this tool (e.g. 'call this to check follow state before/after follow_leader or unfollow_leader'), so the guidance must be inferred from the surrounding narrative.

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