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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds genuinely useful behavioral context beyond them: it is free, measured against real on-chain prices since chain genesis, and calls are 'preserved as captured, so deletion does not scrub the record' — a meaningful data-provenance and immutability guarantee.

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?

Purpose and data provenance are front-loaded, followed by the field enumeration and the call-to-action. The field list is dense but earns its place by previewing the return shape in the absence of an output schema; a minor amount of phrasing could be tightened.

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 compensates by enumerating the returned metrics, and annotations cover the safety profile. For a single-parameter read tool this is nearly complete; only the contrast with sibling caller tools and any rate/cost caveats are left unstated.

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 parameter with 100% schema description coverage ('X handle, with or without @'), so the schema already carries the semantics. The description implies any X account is accepted but adds no formatting or edge-case detail beyond the schema, which is the expected baseline.

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 resource (a measured track record for an X account that calls Robinhood Chain tokens) and enumerates the exact outputs (early_rate, momentum_rate, median 1h return, cluster flag, recent calls). This clearly distinguishes it from siblings like robinx_caller_calls (raw call list) and robinx_callers (caller roster).

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 one implied usage condition — 'Use before trusting any "alpha caller"' — which tells the agent when this is valuable. However, it never names an alternative or exclusion, e.g. it doesn't say to use robinx_caller_calls for the raw list versus this for the aggregate verdict, so routing between siblings is left to inference.

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