value_up

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

With no annotations provided, the description fully describes behavioral traits including data source fallback rules ('DART I value-up keyword → KIND 0184 fallback'), categorization of disclosures (plan/progress/meta_amendment), special handling for meta_amendment, and inclusion of 24-month treasury share cross-references in summary/commitments.

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 structured with labeled sections ('desc', 'when', 'rule', 'scope', 'ref'), but it is somewhat verbose and could be more concise. The first sentence is dense and could be clearer. Each section adds value, but the overall length could be reduced without losing essential information.

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 purpose, usage, behavioral rules, and output structure comprehensively. It references related tools and provides context for the agent. However, the lack of parameter descriptions leaves a gap in completeness for actually invoking the tool correctly.

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 0%, but the description does not explain the meaning or usage of most parameters such as 'scope', 'format', 'start_date', 'end_date', or 'year'. Only 'company' is implicitly understood as required. The description focuses on output structure, not parameter details, so it fails to compensate for the lack of schema documentation.

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 starts with a specific purpose: retrieving value-up disclosures (기업가치제고계획) and commitment text, including treasury share cancellation cross-references. It explicitly distinguishes from sibling tools like 'dividend' and 'treasury_share' by stating that actual dividends and treasury share facts are handled by those tools.

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 'when' section clearly states that this tool is for future promises like value-up plans, ROE/PBR/dividend payout targets, and treasury share cancellation plans. It explicitly names alternative tools ('dividend' for actual dividends, 'treasury_share' for treasury share facts) for different use cases.

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