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

Even without annotations, the description covers critical behavioral traits: it warns about low-reliability segment data falling back to raw markdown, explains context_mode behavior with candidate mode, cautions against misreading fixed asset tables, instructs to verify report name, and details parameter interactions (bsns_year+reprt_code overriding period). This goes well beyond basic disclosure.

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 very long but well-structured with clear sections (desc, when, rule, period, fields, etc.) and front-loads the core purpose. While verbose, every part adds necessary detail for a complex tool. A more concise organization could improve readability, but it remains serviceable.

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 tool's complexity (8 parameters, multiple conditional behaviors, interaction with siblings), the description is remarkably complete. It covers purpose, usage context, parameter semantics, behavioral nuances, and warnings. The presence of an output schema reduces the need to detail return values, allowing the description to focus on input and behavior.

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?

With 0% schema coverage, the description takes full responsibility for parameter meaning. It explains each parameter in detail: fields as comma-separated list with standard vs financial options, period with 'latest'/'annual'/'quarterly' and interaction with bsns_year/reprt_code, bsns_year and reprt_code with explicit DART codes and usage, context_mode and context_chars with behavior. All parameters are adequately described.

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's purpose: extracting business segment details (sales, profit, production, R&D, orders, customers) from a specific Korean regulatory report (DART). It distinguishes itself from sibling tools like financial_metrics (for company-wide financials) and valuation, making its unique role evident.

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 explicit when-to-use guidance ('회사의 사업부문·생산·수주·고객 구조가 필요할 때'), when-not-to-use (for financials use financial_metrics, for valuation use valuation, for financial institutions use other tools), and how to handle historical data via repeated calls. It also mentions alternative tools explicitly.

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

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

No annotations present, so description carries full burden. Discloses automatic exclusion of unlisted companies, name matching logic, and parameter constraints. Lacks rate limit or auth details but still good.

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?

Very concise with purpose, usage, rules, and parameters all in a few lines. No wasted words.

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 tool's complexity (6 parameters, many siblings) and presence of output schema, the description provides sufficient guidance for an AI agent to use it effectively.

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 description adds context for max_recent_filings (range 1-20), date format YYYYMMDD, and language options. However, it omits the 'format' parameter and doesn't explain the 'query' parameter's expected input.

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?

Clearly states the tool identifies companies and provides recent filing index, and it's the common entry point for all data tools. Distinguishes from siblings by being the entry tool.

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?

Explicitly tells when to use (start of search, to get identifiers for subsequent tools, to browse recent filings) and provides a rule about excluding unlisted companies and name matching priority.

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

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

Despite no annotations, the description reveals behavioral aspects: it uses DART list.json with keyword filtering, defaults to 24-month lookback, and explains that include_details triggers additional DART calls. It does not cover destructive behavior (likely read-only) but is transparent about data sourcing and processing.

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 into labeled sections (desc, when, rule, etc.) and front-loads the purpose. It is somewhat lengthy but well-organized, allowing quick scanning.

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, no annotations, and 0% schema coverage, the description provides substantial context: data source, rules, parameter behavior, and cross-references to sibling tools. It lacks detail on output structure but is sufficient for an agent to understand 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 description explains scope, include_details, and details_limit with defaults and limits, but does not cover company, start_date, end_date, or format. Since schema coverage is 0%, the description partially compensates but leaves gaps.

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 explicitly states it handles corporate deals such as equity acquisitions/disposals and subsidiary investments, and distinguishes from siblings like order_contracts and corporate_restructuring. The verb '공시' (disclose) and the listed scenarios clarify the tool's purpose.

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 a clear 'when' section listing use cases and explicitly points to alternative tools (order_contracts, corporate_restructuring) for different transaction types, helping the agent choose correctly.

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

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

No annotations provided. The description mentions it uses 4 APIs in parallel and default 24-month lookback, which gives some insight. However, it does not explicitly state if the tool is read-only, authentication requirements, or any side effects. The term '결정 통합' implies data gathering, but behavioral constraints are not fully disclosed.

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 compact with sections (desc, when, rule, ref). It mixes Korean and English, which may reduce clarity. It is relatively efficient but could be more readable with better structure and separation of concerns.

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?

Covers purpose, usage, and API references. However, it does not describe the output schema (which exists) or parameter details. Given the tool has 4 parameters and references multiple APIs, more detail on inputs and outputs would improve completeness.

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 coverage is 0%, meaning no parameter descriptions in the schema. The tool description does not explain each parameter individually. 'company' is implied, 'start_date' and 'end_date' are likely date range but not explained, 'format' defaults to 'md' but its meaning is unclear. The description adds minimal value beyond the parameter names.

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 it integrates 4 types of governance restructuring decisions (merger/division/divisional merger/stock exchange). It lists specific outputs like merger ratio, counterparty financials, etc. It distinguishes from sibling tool corporate_deals for simple equity transactions.

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 explicitly describes when to use (M&A restructuring, holding company conversion) and when not to (simple equity acquisition/sale, which should use corporate_deals). It provides clear context and alternative.

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

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

With no annotations, the description fully discloses behavioral traits: it uses 6 standardized APIs, employs a 2-pass matching algorithm for roster changes, marks partial attendance data with quality flags, resolves footnotes by fetching 8MB documents, and caches results. It also states that no value judgments are made, only numerical data and 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 lengthy but well-structured with sections (desc, when, rule, scope, year, etc.). It front-loads the core purpose, and every section adds necessary detail for a complex tool. While some technical details could be trimmed, the structure earns a 4 for clarity and organization.

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 tool's complexity, the description is remarkably complete. It covers all scopes, explains data sources, matching algorithms, quality flags, and footnote resolution. It even references companion tools for context. The presence of an output schema (not shown) further reduces the need to describe return values. No gaps are apparent.

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%, so the description must add meaning. It does so extensively: it defines all scope values (compensation, roster, individual, etc.), explains year and lookback_years, and describes the resolve_footnotes parameter. Each parameter's purpose and behavior is clearly explained beyond the schema.

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 that the tool provides individual director-level information including compensation, utilization rates, roster changes, and pay gaps. It differentiates from sibling tools by focusing on detailed board compensation and membership data, as opposed to corporate governance reports or meeting notices.

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 explicitly lists use cases under 'when', such as evaluating director compensation, stewardship engagement, and analyzing pay gaps. It references related tools like corp_gov_report and director_evaluation, but does not explicitly state when not to use this tool versus all siblings. The examples provide strong guidance.

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

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

Discloses data sources (business report alotMatter, cash/stock decisions), fallback logic, handling of corrective disclosures (is_superseded flag), and rules against adding future promises. This is comprehensive beyond what annotations typically provide.

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?

Well-structured with tags (desc, when, rule, scope, ref) and front-loaded with key information. A bit dense but every sentence adds value. Could be slightly more concise.

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 (7 params, no annotations, output schema exists), the description covers data sources, behavioral rules, scope options, and references to related tools. It is fully adequate for an agent to understand usage and constraints.

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?

With 0% schema description coverage, the description carries the burden. It explains the scope parameter well (summary, detail, history) but does not clarify year, years, start_date, end_date, or format. Overall adds partial value but not complete.

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 provides actual paid dividend facts (DPS, total amount, payout ratio, etc.) and explicitly distinguishes it from sibling tools like value_up for future policies. The verb 'check' and resource 'dividend facts' are 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?

Explicitly states when to use (check actual paid dividends) and when not to (use value_up for future policies). Also provides guidance for quarterly companies to use history scope. No ambiguity.

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

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

With no annotations provided, the description fully covers behavioral details: data sources, unit handling (raw KRW, percentages, ratios), edge cases (financial companies with no revenue, bankruptcy situations), period semantics (quarterly vs cumulative vs balance), automatic warnings, and calculation specifics (EBITDA, interest coverage). This is exhaustive.

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 very long and dense, mixing technical details with usage guidance in a single paragraph. It uses sections (desc, when, rule, period, scope, ref) but without clear structure or line breaks, making parsing difficult. It could be restructured for clarity and brevity.

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?

Despite the complexity (6 parameters, 0% schema coverage, no annotations), the description provides comprehensive context: data sources, unit conventions, edge cases, period handling, scope definitions, and cross-references to related tools. It adequately supports correct invocation and interpretation.

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%, so the description must compensate. The description explains the 'scope' parameter in detail with all options (summary, yearly, quarterly, yoy, qoq, audit_opinion) and their behavior. Other parameters like year, consolidated, years are implicitly addressed (e.g., year default and meaning). The format parameter is not discussed, and mapping to schema could be clearer.

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 integrates four financial endpoints and provides profitability, stability, cash flow, and accounting risk metrics. While it lacks a concise verb like 'retrieve' or 'get', the purpose is well-defined and distinguishes from siblings by specifying Korean standard and metrics computed.

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 includes a 'when' section listing three specific use cases (fundamental and accounting risk diagnosis, alerts for net loss/turnaround/interest coverage, cross-check on outside director service) and references other tools. However, it does not explicitly state when not to use this tool or provide direct comparisons to siblings.

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

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

No annotations provided, but description fully carries the burden: discloses data source (DART list.json I001), parsing logic, dedup mechanism, lookback period (24 months), and max_documents limit. No contradictions.

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?

Description is long but well-structured with sections (desc, when, rule, ref). Every sentence adds value, though slightly verbose.

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 complexity and presence of output schema, description covers purpose, usage, behavioral details, and references sibling tools. No major gaps.

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%, so description must compensate. It explains 'max_documents' and implicitly covers date parameters via lookback. However, 'company' and 'format' are not explicitly described, leaving a minor gap.

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?

Description clearly states it tracks contracts (수주) with specific details. It distinguishes from sibling tool 'corporate_deals' which covers equity investments.

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 lists explicit usage scenarios, and contraindications are provided (e.g., equity investments use 'corporate_deals'). Provides clear guidance on when to use.

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

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

No annotations are provided, so the description fully discloses behavioral traits: it explains data source prioritization (DART API, KIND fallback), the meaning of ownership_pct as combined with special relations, the co_holders_verified flag indicating need for manual verification, and scope options. This is comprehensive.

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 headers (desc, when, rule, scope, ref) and is front-loaded with the core purpose. While it is verbose, each sentence adds value. It could be slightly more concise but is well-organized.

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 tool's complexity (multiple scope options, data source rules, verification details) and the existence of an output schema, the description is comprehensive. It covers all critical aspects for correct usage, including caveats about data verification.

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%, so the description must add meaning. It explains the 'scope' parameter with detailed options (summary, major_holders, blocks, etc.), but other parameters like year, format, dates are not described. The partial coverage compensates somewhat but not fully.

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 provides ownership structure for major shareholders, special relations, and 5% blockholders, with co-holder decomposition. It distinguishes itself from the sibling tool 'treasury_share' by noting treasury stock details are separate. The resource and action are 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 'when:' section explicitly describes use cases such as controlling share structure and co-holder decomposition. It references related tools but does not explicitly state when not to use this tool. However, the guidance is clear and context-rich.

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

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

With no annotations, the description fully covers behavioral traits: integrates multiple sources, warns about not altering decisions, explains hard-fail/soft-fail distinction, and notes the time impact of check_audit_history. No contradictions.

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?

Relatively long but well-organized with labeled sections (desc, when, rule, etc.). Every sentence adds value; could be slightly more concise but appropriate for complexity.

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?

Covers purpose, usage, behavioral details, parameter explanations, and references related tools. Output schema exists, so return values are not needed. Complete for a complex tool.

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%, so description must compensate. It explains vote_style (default open_proxy), check_audit_history (timing), and meeting_type (options). However, year (default 0 meaning unclear) and format (md not explained) are insufficiently described.

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?

Clearly states the tool provides pre-meeting voting recommendations per agenda item. Differentiates from post-meeting tool and siblings by specifying the timing ('소집 전').

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?

Explicitly states when to use: after notice but before the meeting, for voting decisions and internal reporting. Provides alternative 'shareholder_meeting_results' for post-meeting results and includes rules about hard-fail vs soft-fail items.

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

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

No annotations are provided, so the description must fully disclose behavior. It explains that auto-classification is not performed, hints are provided instead, and that vote_math is conservative and not predictive. It also describes the 3-way filer classification and signal logic. This comprehensively covers behavioral traits.

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 well-structured with labeled sections (desc, when, rule, scope, ref) but is somewhat verbose and includes redundant information (e.g., repeating '위임장' multiple times). It is adequately concise given the complexity, but could be streamlined slightly.

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 7 parameters, no schema coverage, and no annotations, the description is fairly complete in covering purpose, usage, behavioral rules, and output scopes. However, it does not explain all parameters, and the output schema is present but not referenced. Still, it provides sufficient context for an agent to use 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 coverage is 0%, and the description does not describe individual parameters such as 'year', 'format', 'end_date', 'start_date', or 'lookback_months'. It mentions scope values in the context of the description, but does not explain the other parameters, leaving the agent to rely on parameter names 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's purpose: aggregating signals for proxy contests, litigation, and 5% active ownership. It provides a specific verb ('integrate' implied) and resource, and distinguishes from sibling tools like 'ownership_structure' and 'proxy_advise_before_meeting' by focusing on contest signals and litigation.

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?

Explicitly lists when to use ('경영권 분쟁, 주주 캠페인, 소송...') and provides a rule ('DART D/B/I만 (KIND false match 위험)') that warns against using with KIND data. Also specifies scope options, giving clear guidance on selecting the appropriate output.

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

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

The description thoroughly discloses behavioral traits: it combines data from value_up, corp_gov_report, dividend, and treasury_share; it computes a book-value-based P&L by comparing actual treasury share buy price against BPS; it explicitly states it does not assess intrinsic value; it uses a sanity filter for false positives and notes a known data issue (treasury_share _link_cycles bug fix).

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 moderately verbose but front-loads key purpose and usage information. Each sentence adds value, covering purpose, usage, behavior, and parameters. Minor improvement could be structuring parameter details more clearly.

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 presence of an output schema (not shown but indicated), the description provides comprehensive context: it explains the tool's rationale, distinguishes from siblings, details data sources and calculations, addresses data quality, and covers usage. The description is complete for an agent to use 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%, so the description must compensate. It explains lookback_years (period, default 3) but does not clarify the 'company' parameter (e.g., identifier format) or the 'format' parameter (default 'md'). While the description adds some value, it leaves two of three parameters partially explained.

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's purpose: tracking whether a company has fulfilled its commitments (value-up plans, dividends, treasury share actions) on an ongoing basis. It contrasts with proxy_advise_before_meeting, which is one-time at AGM, thereby distinguishing its role.

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 explicitly provides usage context: stewardship engagement, institutional investor interactions, annual portfolio reviews, and answering 'did the company keep its promise?'. It also explains when not to use the sibling tool proxy_advise_before_meeting, offering clear when-to-use vs. when-not-to-use guidance.

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

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 that include_coverage can slow things down, that it automatically selects the latest corrected filing, and that providing rcept_no skips searches. However, it does not explicitly state read-only behavior, authentication needs, or rate limits. Adequate but not exhaustive.

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 clearly labeled sections (desc, when, rule, parameter details, ref). It front-loads the purpose. While somewhat verbose, it efficiently conveys necessary information for a tool with many parameters.

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 presence of an output schema, the description does not need to detail return values. It covers purpose, usage context, key parameter behaviors, and relationships with sibling tools. Missing parameter explanations for 6 out of 10 parameters is a gap, but the explained ones are thorough.

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 coverage is 0% per context, but the description explains semantics for meeting_type, scope, include_coverage, and rcept_no, adding value beyond the schema. However, it misses explanations for year, format, end_date, start_date, lookback_months, and company, which are important for date ranges and input validation.

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 retrieves shareholder meeting notices (소집공고) including agenda, director candidates, compensation limits, and articles changes. It distinguishes from siblings by mentioning that results feed into shareholder_meeting_results and proxy_advise_before_meeting, but does not explicitly contrast with all siblings.

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 includes a 'when' section indicating when to use ('주총 일정·안건·후보·보수·정관 확인') and directs to sibling tools for results and comprehensive analysis. It also provides rules (exact company identification, automatic latest corrected filing selection). This gives clear context but lacks explicit exclusions.

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

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

Without annotations, the description discloses the tool's behavior: it integrates 9 source types, splits by common/preferred shares, performs cycle matching, and offers two scopes. It does not mention rate limits or auth needs, but covers key behavioral traits.

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 and detailed, mixing languages and some redundancy. It is front-loaded with the purpose but includes extensive technical detail that could be streamlined for clarity.

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 (7 params, no annotations, output schema exists), the description covers the tool's data sources and scope but lacks parameter-specific guidance and interaction details, leaving some gaps for effective use.

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%, so the description must compensate. Only the 'scope' parameter is explained ('summary' vs 'annual'). Other parameters (year, dates, lookback_months, format) are not described, leaving significant gaps.

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 integrates treasury share events, listing 5 decisions and 4 executions with cross-checking. It distinguishes from siblings like dividend, ownership_structure, and value_up by mentioning them as references.

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 specifies use cases: treasury stock acquisition, disposal, cancellation, trust history, and cycle matching for execution verification. However, it does not explicitly state when not to use the tool or suggest alternative tools.

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

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

No annotations provided, but the description fully reveals computation methodology, data sources, handling of edge cases (e.g., negative equity, preferred shares), status codes, and limitations (v1.1 features omitted).

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 lengthy but well-organized with clear sections (desc, when, rule, status, note, ref). Every sentence adds value, though some redundancy could be trimmed.

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 tool's complexity and lack of annotations, the description is highly comprehensive, covering purpose, usage, behavior, parameters (except format), status codes, limitations, and sibling references. Only minor gap is the missing format explanation.

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 coverage is 0%, so description must explain all parameters. It explains 'scope' values (firm, market, sector, etc.) and 'company's role, but fails to describe 'format' (e.g., md vs json). Partial compensation.

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?

Description explicitly states it covers relative valuation metrics (PER, PBR, dividend yield) for firms, markets, sectors, and history. It distinguishes from sibling tools like financial_metrics and dividend, clearly setting it apart.

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 maps specific queries (e.g., 'PER/PBR 얼마', '코스피 전체 밸류') to appropriate scopes. It explicitly tells when to use siblings: financial_metrics for fundamentals, dividend for detailed dividends.

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

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.