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

Annotations already show readOnlyHont true and destructiveHont false, and the description does not contradict them. It adds substantial behavioral and response semantics: *_pct are annual percentages while mrp·srp·tax_rate are decimals, close is unadjusted price, wacc_pct is null when credit rating is undisclosed, returns must be computed from flt_rt not close deltas, aggregates have varying n, and notes[] accumulate downgrades and fallacks. These are exactly the traits an agent needs beyond annotation flags.

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 description is long but tightly organized under [Purpose], [Usage], [Response], and [Rules] headings, with the core selection mechanism front-loaded. Every section carries operational information; examples are concise and rules are dense but each earns its place for a 24-parameter, multi-kind tool.

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 24-parameter tool with no output schema, the description covers argument routing, output units, null semantics, aggregation caveats, evidential citation, and note-readding. It stops short of enumerating the full response shape per kind, so an agent must infer some return fields, but the provided units and rules substantially compensate for the missing output schema.

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 input schema already provides 100% per-parameter coverage with kind-scoped descriptions, so the baseline is 3. The description adds value beyond the schema by turning natural-language intents into kind/corp/ksic mappings, explaining override semantics, and clarifying output-pfield units and null behavior like wacc_pct. It does not repeat the schema, but it does help select parameter values correctly.

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: it calls out that valuation data (market time series, WACC, peers) is selected by kind, and immediately differentiates from siblings by saying financials go to get_financials and KSIC/market classification to get_company_profile. This makes the tool's place among 15 siblings clear.

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?

The [Usage] section gives two explicit intent-to-parameter mappings (e.g., '에스에프에이 최근 1년 주가' → kind='market', corp='에스에프에이'), and the [Purpose] section explicitly routes financial figures to get_financials and industry/market classification to get_company_profile. It also tells agents the tool is evidence, not adoption, so they know not to treat outputs as final conclusions.

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