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

Annotations already carry readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new context: prices are USD, data is public market-wide rather than user-scoped, and period has a default. It does not address the idempotentHint=false signal or error/rate-limit behavior, so it stops just short of fully exploiting the low annotation bar.

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?

Well front-loaded: the core behavior leads, the sibling routing follows, and the scope caveat closes. The get_my_* disambiguation is two sentences where one would do, which is the only padding in an otherwise dense definition.

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?

An output schema exists, so return values need no explanation, and the chart-vs-candles routing covers the main selection risk. The remaining gap is input-side: acceptable period strings and the token address format are not stated anywhere given 0% schema coverage.

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%, so the description must compensate. It explains `period` semantically (selects the window, defaults to 1d) and clarifies units for the returned prices, but never enumerates valid period values, and says nothing about `token_address` format or that `network` is fixed to solana. Coverage of 3 undocumented params is partial.

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?

States a specific resource and shape: 'Price history for one token as a series of points, for describing or plotting a trend.' It explicitly names the sibling it could be confused with (get_token_ohlcv) and characterizes the difference (line vs. OHLCV candles), so an agent can discriminate without opening either 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?

Gives an explicit decision rule – 'Prefer the chart unless you need per-candle numbers' – with the condition that selects the alternative. It also pre-empts a second, larger confusion class by contrasting with the get_my_* family. When-to-use and when-not-to-use are both stated.

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