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

Annotations cover safety (readOnlyHint, destructiveHint, idempotentHint, openWorldHint), but the description adds substantial operational context they cannot: ~15-min refresh cadence, 24/7 operation, and the full auth model (subscription with 7-day trial, connector sign-in, x402 pay-per-call). Critically, it discloses the failure mode: without subscription or x402 wallet it returns a PaymentRequired object and no data.

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?

Front-loaded with the content inventory and then the access model, so the agent gets the essential picture on the first read. It is dense and relies on somewhat opaque jargon ('session-momentum coins,' 'registered rule + study receipts'), but nearly every clause carries distinct information.

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 and no parameters, the description carries the burden and does so well: it describes the payload contents, the refresh cadence, and the payment/auth gating including the PaymentRequired fallback. It stops short of explicitly naming the non-live sibling for disambiguation, which is the only meaningful gap.

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 correctly adds no parameter detail because none exist, and the empty schema is self-explanatory.

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?

Names a specific resource and enumerates its exact contents: top-5 session-momentum coins into the 20:00 UTC signal, BTC 200-day regime gate state, phase clock, eligibility counts, and rule/study receipts. It also self-identifies as the 'Live intraday version,' which implicitly separates it from the non-live get_crypto_night sibling, but it never names that alternative outright.

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 only implied: calling this for live data versus the non-live night read is left to inference from the phrase 'Live intraday version.' There is no explicit when-to-use or when-not-to-use against get_crypto_night, get_crypto_day_live, or the other crypto reads. Adequate but with a clear routing gap.

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