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

The annotations already declare this as a read-only, idempotent, closed-world operation, so the safety profile is fully covered. The description adds real context on provenance (DART periodic reports) and on how the company-stated causes are returned as original sentences with [S#] source markers and DART links. It does not cover behavior when a quarter lacks segment data or stated reasons, or any limits on history depth.

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?

It is front-loaded with the core question ('실적이 왜 바뀌었나') and then compactly lists the returned content in one dense sentence. Nothing is redundant, though the list of metrics and citation mechanics is packed tightly enough that a reader has to parse carefully.

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 carries the burden of describing return values, and it does so concretely: the metrics, the period-over-period comparisons, the segment breakdowns, and the citation format with source tags and links. The data source is also disclosed. Only edge-case behavior (no data, missing segment disclosure, non-periodic filers) is 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?

Schema description coverage is 100%; both 'stock' and 'period' are documented in the schema with concrete format examples ('005930', '2026Q2', '2026.06'). The description adds only the implicit notion of '한 분기' granularity and the default-to-latest behavior is stated in the schema, not the description, so this is the baseline case where the schema does the work.

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 verb and resource: a single-quarter earnings analysis based on DART periodic reports, and it enumerates the concrete contents (consolidated revenue, operating profit, net income, YoY/QoQ, segment breakdowns, stated change reasons). The scope is unambiguous, but it never names or contrasts itself with the closest sibling, 'financials', so an agent must infer the boundary on its own.

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 a concrete triggering question ('영업이익이 왜 늘었어?') that maps directly to the tool's intent, which is strong context for selection. It stops short of explicit exclusions, saying nothing about when to prefer 'financials' for raw statement figures or 'filing'/'search_filings' for the underlying document.

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