ISA 비과세 한도 현황 계산

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

No annotations are provided, so the description carries full burden. It discloses the computation nature (net profit, realized/unrealized) and data sources (environment variable, manual inputs), but does not explicitly state read-only or side-effect-free behavior. The description is adequate but not explicit about safety.

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 concise (4 sentences) and front-loaded with the main purpose. Each sentence adds value without redundancy. No fluff or irrelevant details.

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?

The description covers the tool's purpose and parameters well, but lacks detail on output format or structure. Given no output schema, the agent may not fully understand the returned data (e.g., whether it's a single number, object). The description is sufficient for basic understanding but incomplete for precise invocation.

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?

All parameters have schema descriptions (100% coverage), but the description adds significant context: from_date defaults to environment variable, overrides correct auto-classification, dividends_received supplements detection. This enhances understanding beyond schema alone.

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 clearly states the tool calculates ISA tax exemption status, showing usage and remaining limit. It distinguishes from sibling tools (general account info, holdings, etc.) by focusing on tax status calculation. The verb '계산해' (calculates) and resource 'ISA 비과세 한도' make the purpose specific.

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 explains when to use parameters (e.g., dividends_received for manual input), but does not explicitly contrast with sibling tools or give when-to-use vs when-not-to-use guidance. It implies usage for ISA tax status but lacks direct alternatives.

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