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

Annotations already cover the safety profile (readOnly=true, destructive=false, openWorld=false), so the description is free to add the behavioral payload: that the response is a research-only limitation notice and that no wallet/money/order side effects occur. This is genuinely useful context beyond the annotations. It does not describe the response shape, but for a fixed refusal-style return that is a minor omission.

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, front-loaded with the trigger condition and followed by the limitation list. Every sentence carries information; the negative enumeration is long but earns its place by defining scope precisely.

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 description does the necessary work of stating the return semantics ('supports research only'), and it fully frames the guardrail behavior. The remaining gap is the undocumented 'address' parameter, which an agent may need to populate without any guidance.

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 never names the parameters. The request enum values (copy_trading, alerts) map loosely to the described triggers, but the required 'address' parameter with its 0x-pattern constraint is entirely unexplained in both schema and description. With zero coverage 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 states a specific trigger and outcome: it is invoked for copy-trading or alerts requests and returns that only research is supported. This distinguishes it from the sibling hyperliquid/equity data tools, which all return analysis rather than a capability refusal. It is slightly indirect in phrasing (defined by trigger rather than by what it returns), but an agent can tell what it does.

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 an explicit when-to-use condition: 'requests to start copy trading or subscribe to alerts.' It also enumerates what the tool will NOT do (no wallet connection, funding, signing, ordering, copying, or scheduled tasks), which effectively steers the agent away from expecting those actions. No sibling alternative is named, but the negative list covers the practical guidance gap.

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