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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety needs no restating. The description adds genuinely non-obvious behavior: the KRX/Financial Services Commission provenance, T+1 freshness (not intraday), and that splits/mergers are adjusted — the last being critical for interpreting historical returns. It loses a point for leaving the `realtime` flag's behavior unexplained while simultaneously asserting the data is not real-time.

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?

A single dense paragraph that front-loads the metrics produced, then tacks on index values, source/freshness caveats, and the adjustment note. Every clause carries information an agent needs; nothing is filler.

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 an 8-parameter tool with zero required parameters and no output schema, the description does well on return shape (it lists the output columns and metrics). However, it does not resolve the key ambiguities an agent faces: whether stock and index are mutually exclusive, what makes a valid call with no arguments, and how `realtime` interacts with the stated non-real-time guarantee.

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 coverage is 75%, so the schema already documents from/to/limit/interval/intraday and the index enum. The description reinforces the index values and enumerates the candle fields, but adds no syntax or selection logic for `stock` vs `index`, and says nothing about what `realtime: true` would do.

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 names a specific resource (stock/index price series) and enumerates the derived metrics it returns — period return, excess return vs index, MDD, volatility, high/low, and OHLCV candles. That is far more specific than the title '주가 흐름' alone. It falls short of a 5 because it never names or contrasts a sibling (e.g. financials, company, rank) that an agent might otherwise pick for price-adjacent questions.

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 context is implied rather than stated: '다음 영업일 반영(장중 실시간 아님)' tells the agent this is end-of-day data, which effectively rules out intraday use cases. But there is no explicit when-to-use / when-not-to-use routing, and no guidance on the stock-vs-index choice despite both parameters existing.

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