get_dividend_info

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only analysis operation ('분석'), but doesn't specify if it's a query, calculation, or report generation, nor does it detail potential side effects, authentication needs, rate limits, or error conditions. This leaves significant gaps in understanding how the tool behaves in practice.

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 a single, efficient sentence in Korean that directly states the tool's analytical focus. It's front-loaded with key terms ('배당금 총액 및 배당성향') and avoids unnecessary fluff, making it appropriately concise for its purpose.

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?

Given the complexity implied by financial analysis, lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., raw data, calculated metrics, or a risk assessment), how results are structured, or any limitations (e.g., data availability by year or report type). This makes it inadequate for an agent to fully understand the tool's context and usage.

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 has 100% description coverage, clearly documenting each parameter (corp_code, bsns_year, reprt_code) with types and examples. The description adds no additional semantic context about these parameters, such as how they influence the analysis or typical values. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.

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 the tool analyzes dividend-related financial metrics ('배당금 총액 및 배당성향을 통한 이익 분배 정책과 재무 건전성 리스크 분석'), which translates to analyzing dividend policy and financial health risk through total dividends and payout ratios. However, it's somewhat vague about the exact operation—it doesn't specify if it retrieves, calculates, or generates a report on this data, and it doesn't clearly distinguish from sibling tools like get_stock_total or get_equity that might relate to corporate finance.

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 description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing specific financial reports), exclusions, or comparisons to other tools in the sibling list, such as get_corporation_info or search_financial_notes, which might overlap in financial analysis contexts.

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