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

Beyond the readOnly/idempotent annotations, the description discloses a lot the agent could not otherwise know: a $0.009 USDC x402 charge, that unpaid calls return 402 even for invalid queries, that signed-but-invalid calls are rejected before settlement and uncharged, and the cached/stale/cacheAgeMs semantics of the response. It also states history depth is reported in the response. This is exactly the kind of behavioral context annotations cannot carry.

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?

The what-it-does and when-to-use clauses are front-loaded and earn their place, but the payment section is redundant: cost, the 402-on-unpaid rule, the not-charged-on-invalid-args rule, and "charged only when the tool result is not an error" restate the same policy three times. Trimming to one billing sentence would lose no 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?

For a two-parameter read tool with no output schema, the description enumerates the returned series (official open/close, overnight, session, close-to-close), the summary stats, the on-chain prior-close/open basis fields, and the cache flags — enough to decide to call it. The residual ambiguity is the exact response shape for a single ticker versus the no-ticker summary mode.

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?

With 0% schema description coverage, the description carries the burden and mostly does: ticker is optional and its omission yields a one-line summary per ticker, and days is bounded 1 to 90 with a default of 20. It stops short of specifying the expected ticker format (symbol case, whether an issuer mint address is accepted), which is the one gap an agent could stumble on.

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 a specific verb+resource+scope: the overnight versus regular-session return split for US stocks trading as Solana tokens (xStocks, Ondo, Backpack). It names concrete use cases (pricing or studying isolated-exposure/overnight tokens) and the tracked universe (SPY, QQQ, AAPL, NVDA, TSLA), so an agent can tell exactly what data this returns without opening the schema.

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?

"Use this when your agent needs the overnight ... versus regular-session return split" plus the e.g. clause gives clear triggering context. It does not state when not to use it or name an alternative, but none of the sibling tools (wallet_*, payee_check, swap_build, token_check_demo) overlap with this dataset, so exclusions would add little.

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