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

No annotations are provided, so the description carries the full behavioral disclosure burden. It discloses conditional behavior (registry opt-in section), output mode changes (map without original fact blocks), and date-override semantics. It does not cover errors or side effects, but the disclosed behaviors are substantive.

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?

Opens with the core purpose, isolates the conditional registry behavior, and structures the parameter details in a compact Args block. Every sentence adds meaningful information without repeating schema defaults.

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 no annotations and zero schema descriptions, the description covers most operational details well and can rely on the output schema for return values. The main gaps are the undocumented lookback_days parameter and lack of guidance on choosing among risk-analysis sibling tools.

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%, and the description compensates by explaining company_name, lookback_years, from_date, and to_date with examples, formats, defaults, and precedence. However, lookback_days appears in the schema but is completely undocumented, leaving a 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?

States a clear and specific action: analyze disclosure-based unfair trading risk signals for a company name or stock code. The resource and verb are concrete, but it does not explicitly differentiate itself from the similarly named sibling tool check_disclosure_risk.

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?

Provides concrete usage conditions: lookback_years range and default, the map mode when exceeding one year, and the recommendation to narrow with from_date/to_date for deeper sections. No explicit when-not-to-use or sibling exclusions are given, so it stops short of a 5.

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 carries the full behavioral burden. It discloses not only the sorting behavior but also the automated stage classification, crisis-pattern matching, and a conditional public-record reference section that appears only under specific opt-in and tagging conditions. This adds meaningful behavioral detail beyond the schema.

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 front-loaded with the primary purpose, followed by behavioral detail and parameter semantics. Each sentence adds useful information, and the Args section is organized. The formatting appears slightly cramped or truncated around lookback_years and from_date, which slightly hurts readability but not substance.

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, behavior, conditional output sections, and most parameters. Because output schema exists, not describing return values is acceptable. However, the undocumented lookback_days parameter, missing date format, and lack of any sibling differentiation prevent the description from being fully complete for correct tool selection and 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?

Schema description coverage is 0%, so the description must compensate. It does document company_name (accepts name or six-digit code), lookback_years (default 1, range 1–5), and from_date/to_date behavior (including default ranges when only one is given). However, lookback_days is omitted entirely and no date format is specified, leaving a real gap for an agent attempting correct invocation.

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 function with a specific verb and resource: it sorts a company's disclosure events chronologically to build a manipulation-flow narrative. It goes beyond the name by describing the three-stage classification (entry, deepening, exit) and matching against known crisis patterns, which distinguishes it from raw disclosure-listing 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 provides clear context for when this tool is useful: when an agent needs a chronological, pattern-matched narrative of events rather than a simple list of disclosures. It does not explicitly name alternatives or when-not-to-use cases, which prevents a 5, but the intended use case is clear.

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 carries the full burden. It transparently lists the 5 indicators, states return format (counts and basis disclosure names, no scores/grades), and mentions the version. It does not mention read-only or side effects, but given the tool is likely read-only, the disclosure is adequate.

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: purpose, indicator list, and Args section. It is front-loaded and has minimal waste. However, the indicator list could be more structured (e.g., bullet points) 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 tool has an output schema covering return values, the description sufficiently explains inputs for company_name and lookback_years, but misses lookback_days and does not elaborate on the meaning of each indicator. This leaves some context gaps for the agent.

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 describes company_name (accepts name or stock code) and lookback_years (range 1-5, default 1), but does not mention the lookback_days parameter at all, leaving one parameter undocumented.

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 aggregates 5 specific disclosure anomaly indicators and returns a factual summary. It explicitly differentiates by stating it does not quantify or grade risk (v0.8.5 principle), distinguishing it from siblings like check_disclosure_risk.

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 states when to use (to get factual summary of anomaly indicators) and what it does not do (no risk quantification). While it does not name alternatives, the negative statement provides clear usage boundaries.

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 the full burden. It only states the purpose and input parameters, but fails to disclose what 'risk' entails, whether the operation is read-only, any side effects, or limitations. There is no mention of what happens if both parameters are provided or neither.

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, with a single main sentence followed by a clean parameter list with examples. There is no wasted text, and the structure is easy to scan.

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 tool has two optional parameters and an output schema, so the description does not need to explain return values. However, it leaves out important context such as what risk criteria are used, how to handle missing inputs, and precedence when both parameters are provided (though 'used when no receipt number' implies rcept_no takes precedence). These gaps make it adequate but not fully complete.

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 schema has no descriptions (0% coverage), but the description's Args section clearly explains both parameters: rcept_no is a 14-digit DART receipt number, and report_name is the disclosure title used when no receipt number is provided. This adds meaningful context beyond the minimal 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 uses a specific verb 'analyzes' and resource 'risk of the disclosure', making it clear that the tool assesses risk for a DART disclosure. However, it does not explicitly distinguish itself from sibling tools like check_disclosure_anomaly or analyze_company_risk, which may also involve risk assessment.

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 gives no guidance on when to choose this tool over alternatives. It only states that the tool uses a receipt number or title, but that's parameter usage, not tool-selection criteria. No exclusions or when-not-to-use conditions are provided.

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 carries the burden and does so well: it discloses the API call-count model (calls scale with years, not companies), the underlying endpoint fnlttMultiAcnt, and even an empirical observation (20 companies = 1 call, 606 rows, 0 missing). It doesn't cover error behavior or return schema details, but has an output schema so that's acceptable.

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?

Front-loads the core purpose, then adds operational detail and parameter semantics. The call-count paragraph and empirical evidence are valuable but slightly verbose; still every line earns its place for a complex 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?

Covers purpose, scope limits, parameter meanings, defaults, the call/performance model, and constrains behavior. Output schema exists so return format is covered. Missing only explicit sibling routing and error/permission notes.

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, and it does: it defines each parameter (company_names count range, year default = prior year, year_to as range end, report_type with enum values, accounts as partial-match list) plus the default accounts returned.

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?

States a specific verb (비교한다 / compare) and resource (재무제표 / financial statements) with explicit scope limits (max 20 companies, max 10 years). Clearly distinguished from siblings like get_financial_summary (single company) and get_financial_statements_full by the multi-company comparison framing.

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?

Implies usage through limits (2-20 companies) and the year_to timeseries mode, and contrasts with the single-call design vs per-year calls. Does not explicitly name sibling alternatives (e.g., get_financial_summary for one company), but context is clear enough to select 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?

With no annotations, the description carries the full behavioral burden and does so richly: it discloses that executive overlap is the real primary output, that the acquirer side is capped at 3 CB + 3 rights issues per company (with the 'N건 중 3건 조회' denominator convention), that executive rosters are uncapped multi-year unions, that registered and unregistered executives are both included, and that source tags are attached. This is exactly the kind of limitation and output-composition detail an agent needs.

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?

It is long, but front-loaded with the core purpose and a warning about the actual primary output, and each subsequent paragraph discloses a distinct behavioral trait rather than restating. Only mildly verbose, and the structure (warning, mechanism, args) is easy to scan.

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 an output schema exists, return values need no explanation, and the description still covers mechanism, caps, source tagging, the DART targeting constraint, and lookback semantics. An agent has everything needed to call this 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, and it documents all three parameters: company_names (2-5 company names or ticker codes), lookback_years (default 1 year, 1-5 range, and why to widen it), and watchlist (saved person names unioned with company_names, managed by manage_watchlist). Nothing in the Args block is left ambiguous.

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?

States a specific verb (compare/detect) and concrete resources (executive concurrent positions and CB/BW/EB-rights-issue acquirers) across 2-5 companies. An agent can immediately tell this apart from sibling tools like lookup_known_actor or get_executive_compensation.

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?

Gives clear context for when to use it (comparing a 2-5 company group to surface common actors/forces), when to widen lookback_years, and how watchlist interacts via manage_watchlist. It also states a hard usage constraint — that DART requires specifying target companies and reverse search by actor name is impossible — but does not explicitly name a sibling to use instead for reverse lookups.

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. Description mentions lookback_days is not used, which is a behavioral trait, but fails to disclose return structure, side effects, or permissions. Output schema exists but unmentioned.

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?

Short and front-loaded sentence. Could benefit from clearer bullet formatting, but no unnecessary content.

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 output schema present and 2 parameters, description is sparse. Lacks details on return value, risk interpretation meaning, or example use case.

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%. Description adds examples for signal_types and notes lookback_days is unused, partially compensating. However, lacks full semantics like valid formats or constraints.

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 returns characteristics and risk interpretation of signals based on signal types. The verb 'returns' is specific, but 'find_risk_precedents' implies precedents, while description focuses on interpretation. Slightly misaligned but still 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?

No guidance on when to use this tool versus siblings like 'analyze_company_risk' or 'check_disclosure_risk'. Description does not provide context or 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?

No annotations, so the description carries the full burden, and it does meaningful work: it explains that 기초 and 증감 must be read together or a fully-divested case shows only '-', and it describes the return composition and the exclusion of total rows. It does not cover permissions or rate limits, but the interpretative nuance is valuable.

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?

Front-loads the purpose, then fields, then use cases, with Args and Returns sections. Efficient and readable, though the field enumeration and interpretation aside make it slightly long for two 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?

An output schema already exists, so return values need not be fully specified, yet the description still summarizes the return (top-30 table plus summary facts and a unit notice). Args, behavior, and use case are all covered for a simple two-parameter read 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 coverage is 0%, so the description must document the parameters itself, and it does: company_name accepts a name or 6-digit ticker, and year is a business year that defaults to the prior year when empty. Both parameters are clarified with format and default semantics, compensating for the bare 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?

States a specific verb and resource ('타법인 출자현황을 조회합니다 — 이 회사가 어떤 법인들에 돈을 넣었는지') and enumerates the exact fields returned, so the agent knows precisely what this retrieves. It is clearly distinct from siblings like get_shareholder_info or track_capital_structure, but never names an alternative to confirm the boundary.

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?

Provides concrete usage contexts — tracking SPC/subsidiary networks of shell-company M&A and detecting related-party asset tunneling. This tells the agent when the tool is relevant, but offers no exclusions or explicit pointers to sibling tools for adjacent questions.

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 carries the full behavioral burden. It helpfully discloses a data-availability boundary (the auditor's reasoning is not in the structured response but in the original text) and mentions it aggregates three DART endpoints and emits warning signals. However, it says nothing about auth/permissions, rate limits, or read-only status, so disclosure is incomplete for an unannotated tool.

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?

Front-loaded with the purpose and the sibling distinction, then the endpoint/behavior note, then args. The explicit 'Returns:' section is mildly redundant given an output schema exists, but overall the text is tight and each part earns its place.

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 2-parameter tool with an output schema, the definition covers both parameters fully and explains the behavioral scope. The only gaps are unannotated operational details (safety/limits), which are minor given the output schema and clear param documentation.

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, and it does: company_name is documented as accepting either a company name or a 6-digit ticker, and lookback_years as a 1–10 range that is clamped to 5 when out of bounds. This adds real semantics (accepted formats and clamping behavior) beyond the bare 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?

States a specific verb (조회) and a precise set of resources (감사의견·감사인 교체·비감사용역 이력), then explicitly distinguishes itself from the sibling get_audit_opinion_text by noting that tool quotes the auditor's narrative reasoning from the original text. An agent can pick between the two without opening either schema.

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?

It clearly routes the agent: use this for the year-by-year opinion/auditor-change table, and use get_audit_opinion_text when the auditor's written reasoning (opinion basis, going-concern uncertainty, emphasis, key audit matters) is needed. Context for use is explicit, though there is no stated 'when not to use' beyond the sibling routing.

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 the full burden, and it discloses an important behavioral trait: no judgment/score/grade is attached, only the fact that a section exists plus the paragraph. It also documents the empty-year default. It omits auth requirements or pagination/truncation behavior, but for a read-and-quote tool the disclosure is strong.

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?

Front-loaded with the core purpose, then Args/Returns sections, so it scans well. The sibling-differentiation point is restated twice ('이력·교체는 그쪽… 이 도구' paraphrases the preceding sentence), a mild redundancy that keeps it below a 5.

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?

An output schema exists, yet the description still clarifies the return shape (per-section presence table + verbatim quotes) and, crucially, what is NOT returned (no judgment/score/grade). Combined with the fully documented inputs, an agent has everything needed to call and interpret it.

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%, yet the description documents all three parameters: company_name (name or 6-digit code), year (4-digit fiscal year, empty = prior year), and scope with its two valid values ('consolidated' | 'separate'). It even supplies enum-like values the schema itself lacks, fully compensating for the coverage 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?

States a specific verb ('원문에서 그대로 읽는다' / '원문 그대로 인용한다') and a precise resource (the auditor's own sentences across opinion, basis, going-concern, KAM, etc.). It explicitly draws the boundary with sibling get_audit_opinion_history ('이력·교체는 그쪽, 감사인이 뭐라고 썼는지는 이 도구'), so an agent can pick between them without opening either schema.

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?

Names the alternative tool and the exact condition that selects it (year-by-year opinions and auditor-change history go to get_audit_opinion_history; verbatim wording goes here). Also states the default behavior when year is empty ('직전 연도'), removing a common 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?

No annotations are provided, so the description bears the full burden. It states the tool retrieves an overview but discloses no behavioral traits such as side effects, authentication needs, rate limits, or error handling. The minimal disclosure is inadequate for a read tool.

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: one sentence stating purpose and a short Args section. It is front-loaded and efficient, though the structure could be improved (e.g., separate English translation).

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 presence of an output schema alleviates the need to describe return values. However, with no annotations and 22 sibling tools, the description lacks contextual guidance on when to choose this tool, making it only moderately complete.

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 schema lacks any description for company_name. The description adds crucial meaning by specifying that it accepts either a company name or a 6-digit stock code, with an example. This significantly aids correct parameter usage.

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 uses the specific verb '조회한다' (retrieve) and resource '기업 개요' (company overview), listing example fields (representative, industry, etc.). This clearly distinguishes it from sibling tools like get_financial_summary or get_shareholder_info, which focus on different aspects.

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 only explains the input format (company name or stock code) but does not provide guidance on when to use this tool versus its many siblings. No explicit when-to-use, when-not-to-use, or alternative tools are mentioned.

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 bears full responsibility. It discloses that the tool returns the full document text and a list of attached files, and that it truncates long documents with a notice. It does not mention any potential side effects or authentication requirements, but for a read-only retrieval tool, this is adequate.

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 a clear purpose statement, a list of behaviors, and parameter details. It is somewhat lengthy but each sentence adds value. The front-loaded format aids quick understanding.

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 that an output schema exists (so return values are documented elsewhere) and the tool has only two parameters, the description is complete. It covers all essential aspects: what the tool does, input format, truncation behavior, and alternatives for longer documents.

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 provides no descriptions for parameters (0% coverage), so the description must add meaning. It explains rcept_no as a 14-digit DART receipt number with an example, and max_chars with default and maximum values. This fully compensates for the schema 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 retrieves the full disclosure document by receipt number (DART 접수번호로 공시 원문 전체를 조회). It distinguishes itself from sibling tools list_disclosure_sections and view_disclosure by explicitly mentioning them as alternatives for longer documents or specific sections.

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 guidance on when to use the tool (when you have the receipt number and want the full text) and when to use alternatives (for longer documents, use list_disclosure_sections/view_disclosure). It also mentions the max_chars limitation and the resulting truncation notice.

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 carry the behavioral disclosure burden. It does describe output sections and parameter defaults, but it contradicts itself: the first paragraph says '5개 섹션을 반환합니다' while the Returns section says '임원 보수 4섹션 텍스트'. This makes the actual return behavior unreliable, and it does not state read-only semantics, data source, or error behavior.

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 reasonably short and organized with Args/Returns sections. However, it is not fully polished: the Returns line is redundant with the first paragraph, and the 5-section vs 4-section discrepancy creates confusion. The structure is acceptable but not tightly edited.

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 3-parameter read-style tool, the description is mostly complete: it covers all parameters, defaults, allowed report types, and output content. Yet the contradictory section count and the absence of guidance on when to choose this tool over siblings such as track_insider_trading leave gaps. The presence of an output schema reduces the need to explain return values, but the description's own return statement is inconsistent.

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%, and the description compensates by explaining all three parameters: company_name accepts company name or stock code, year is the business year with a previous-year default, and report_type is enumerated as annual/half/q1/q3. This is substantial added meaning beyond the bare schema. Minor ambiguity remains around the exact year format and the mismatch between the schema's empty-string default and the described previous-year default.

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 a specific action with a clear resource: '임원 보수 현황을 조회합니다' (query executive compensation status) and adds investigative context as reference material for unfair-trade detection. It is distinguishable from siblings by the resource, but it does not explicitly contrast it with overlapping tools like track_insider_trading.

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 phrase '(불공정거래 탐지 참고 자료)' implies the tool is intended for unfair-trade detection investigations, giving some context for when to call it. However, it does not provide explicit when-to-use/when-not-to-use conditions or name sibling alternatives, so selection guidance is mostly left to inference.

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 carries the full burden and does so well: it discloses the fs_div fallback (if CFS is empty it retries OFS and reveals which was used) and the 'IS' quirk that selects both IS and CIS, yielding 0 rows for CIS-only companies. It omits auth/permission and rate-limit behavior, so not a full 5.

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 front-loaded (the core behavior is stated first, then the sibling comparison, then Args and Returns headings). Given five parameters and two behavioral caveats, the length is justified, though the Args block is dense enough to be 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?

For a complex five-parameter tool with no annotations, the description covers purpose, alternative routing, parameter meaning, fallback behavior, and output shape (per-statement tables, original account names/order, no grades). An output schema exists, yet the extra return context still adds value rather than repeating structured data.

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, and it documents all five parameters: company_name accepts name or 6-digit ticker, year defaults to the prior year, report_type enumerates annual/half/q1/q3, fs_div enumerates CFS/OFS plus fallback, and statement enumerates BS/IS/CIS/CF/SCE with the IS caveat.

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?

States a specific verb+resource with scope: returns ALL accounts of the financial statements in original order and original names. It explicitly differentiates from the sibling get_financial_summary ('returns only key accounts'), so an agent can route without opening either schema.

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?

Names the alternative (get_financial_summary) and the exact condition that selects this tool: when you need lines absent from the summary, listing concrete examples (COGS, SG&A, financial income/costs, other gains/losses, equity-method P/L). It also says the summary side is better for skimming, giving both when-to-use and when-not.

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 carry behavioral disclosure. It mentions that the API returns only key accounts (14 types) and specifies the source API, which is useful context, but it does not disclose rate limits, authentication requirements, or error behavior.

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 front-loaded with the tool's purpose, then usage guidance, then parameter definitions. It is efficient and avoids waste, though the bilingual format may be slightly verbose for some audiences.

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 an output schema present, the description need not explain return values. It covers the key accounts available, the distinction from the full-statements tool, and all three parameters. The lack of annotations is mitigated by the description's explicit scope note, but it could still say more about data freshness or limitations.

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 defines the three parameters well: company_name (name or 6-digit code), year (4-digit year, default last year), and report_type (annual, half, q1, q3). However, it does not add syntax details beyond what might be inferred, and the enum-like values are not present in 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?

States a specific verb+resource (retrieve a company's key financial statements) and lists the exact accounts covered. It partially differentiates from the sibling get_financial_statements_full, but the primary purpose could be sharper about summary vs. detail distinction.

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 says when to use this tool ('훑어볼 때 쓴다') and names the alternative (get_financial_statements_full) with the condition that selects it (full account list needed). It does not state when-not to use this tool beyond that, so it falls short of a 5.

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 carries full burden and discloses fallback behavior and potential failure modes (empty results) when corp_code is omitted. It also implies read-only operation. However, it does not explicitly state safety or idempotency.

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 concise but includes a mix of Korean and English, and the parameter explanations are embedded inline, making it slightly verbose. The main purpose is front-loaded, but the structure could be tighter.

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 an output schema exists, return values need not be explained. The description covers purpose, specific use cases, parameter details, and failure modes. It lacks general context about the data source (DART) but is otherwise complete for a 3-parameter 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 coverage is 0%, so the description must compensate. It provides detailed explanations for all three parameters, including format (14자리, 8자리), a list of enum values for decision_type, and behavioral notes about corpc_code recommendation and fallback. This thoroughly adds meaning 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 it retrieves 12 types of major decision disclosures as structured fields, and mentions specific use cases like related party hollowing. However, it does not explicitly differentiate from sibling tools, though the structured field aspect implies distinction.

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 specific use case (tracking patterns) but lacks explicit guidance on when not to use this tool versus alternatives. No exclusions or comparisons with sibling tools are given.

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 carries the full burden and largely meets it: it discloses that values are read directly from the structured disclosure response, that EB forms have no repricing item at all (distinguished from 'no provision'), and that no judgment/score/grade is attached. It does not explicitly state read-only behavior or error handling, which keeps it short of a 5.

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 front-loaded with the purpose, then cleanly sectioned into Args and Returns, with bolding on the key scope signal. It runs a little long, but every line (field list, edge-case warning, param caveats) contributes to correct invocation.

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 read/extraction tool with an output schema, the description supplies everything an agent needs: the scope, the extracted fields, the required vs recommended params, and the EB edge case. No output-schema explanation is owed, and the corp_code caveat closes the practical gap in the sparse input 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?

Schema description coverage is 0%, so the description must compensate and does: rcept_no is defined as a 14-digit DART receipt number for an issuance-decision disclosure, and corp_code as an 8-digit code that is 'effectively required' for DS005 series and reverse-resolved from the receipt number when empty. This adds substantial meaning beyond the bare schema field 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?

States a specific verb and resource: outputs a terms table for a single CB/BW/EB issuance decision, then enumerates exactly which fields (conversion price, repricing floor, dilution, interest rate, claim period, fund usage) it extracts. It explicitly distinguishes itself from track_capital_structure and analyze_company_risk by scope: one receipt number versus whole-company scanning.

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?

Names the alternatives (track_capital_structure, analyze_company_risk) and the condition that selects this tool over them ('looks at just one receipt number' and 'more often needed in reporting'). The one-receipt scope is the decisive routing signal, so the agent can pick correctly without opening sibling schemas.

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, so description bears full burden. It discloses that the tool retrieves shareholder data but does not detail behavior like authentication, rate limits, or error handling. The default year behavior is noted but overall transparency is minimal.

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?

Extremely concise: two-line description plus parameter details. No redundancies. Main purpose is front-loaded. Every sentence adds value.

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?

Output schema exists, so return values need not be explained. The description covers both parameters adequately, given the tool's simplicity. However, it does not mention that company_name accepts both name and code, which is a slight omission.

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 has 0% description coverage, but the description adds meaningful semantics: company_name can be name or 6-digit code, year is 4-digit with default previous year. This exceeds what the schema provides (only type and default).

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 the tool retrieves the largest shareholder and holders of 5% or more (주주 현황 조회). The verb '조회한다' (retrieves) and resource '기업의 최대주주 및 5% 이상 대량보유자 현황' are specific. Among siblings like analyze_company_risk or get_financial_summary, this tool uniquely addresses shareholder information.

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?

No explicit when-to-use or when-not-to-use guidance. The description implies usage for querying shareholder info but does not mention alternatives or context where other sibling tools (e.g., track_insider_trading) would be more appropriate.

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 carries the full burden and does well: it discloses that data comes from audit report originals, that note reference numbers are preserved to allow number-to-note navigation, and that no judgment/score/rating is attached. It omits auth/permission needs and rate limits, but the read-only nature and output behavior are well covered.

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?

Front-loaded with the tool's purpose and the sibling routing note before the Args/Returns blocks; each paragraph earns its place. The Args section is somewhat verbose but the detail is functional rather than filler.

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?

An output schema exists, so return values needn't be explained, yet the Returns block still clarifies source provenance and note-reference preservation. Combined with full parameter and usage coverage, an agent has everything needed to call this 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%, yet the description fully compensates: company_name documents the same-name disambiguation flow and corp_code fallback, year documents format plus the fiscal-year-vs-filing-date pitfall, and scope/section enumerate and gloss all their allowed values.

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?

States a specific verb (reads/extracts) and resource (financial statements and notes from audit report originals) scoped to non-listed audited corporations. It explicitly distinguishes itself from the sibling get_financial_summary by the listed/non-listed dimension, so an agent can route correctly without opening a schema.

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 it (non-listed companies have no data in the OpenDART periodic-report API) and when not to (listed companies should use get_financial_summary for structured data). It even explains the underlying reason, leaving nothing to inference.

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 the full burden. It discloses the main behavioral outcome (returns a list of rcept_no) and notes downstream compatability. However, it does not mention sorting, result limits, exact date-boundary behavior, or potential side effects—though '조회한다' implies a read operation. No contradiction with annotations.

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 and front-loaded, with the core purpose stated first and an Args section that is easy to scan. Every sentence adds value, and there is no redundant explanation of the schema.

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 5 parameters, no annotations, and 0% schema description coverage, the description is incomplete because it documents only two of them. The presence of an output schema mitigates the return-value gap, but the undocumented date-related parameters leave a material hole in the tool contract.

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 does well for stock_code (6-digit example) and lookback_years (default 1 year, range 1-5), but it ignores three schema parameters: to_date, from_date, and lookback_days. These may be important for date filtering, and their absence leaves the tool hard to use correctly for exact-range queries.

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?

States a specific verb and resource: it lists disclosure receipt numbers (rcept_no) for a stock code. This distinguishes it from siblings like get_disclosure_document (fetches a single document) and search_market_disclosures (searches broadly), and the integration note reinforces its role as a discovery/index step.

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?

Clear context: use this tool when you need a stock-code-driven list of recent disclosure receipt numbers, which can then be passed to downstream tools such as get_disclosure_document, view_disclosure, or check_disclosure_risk. It does not explicitly state when not to use it or name alternatives, but the intended workflow is evident.

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 indicates a read-like operation retrieving section structure, but does not explicitly state safety, idempotency, or potential side effects. For a simple list tool, this is adequate but not exemplary.

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 with two sentences plus a parameter description, well-structured. Every sentence adds value with 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 single required parameter and presence of an output schema, the description is fairly complete. It explains what the tool does and how to use it in conjunction with view_disclosure, though it could mention the output schema's role.

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 compensates by explaining the rcept_no format (14-digit DART receipt number) with an example, adding meaning beyond the 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 it queries the table of contents (section structure) of DART disclosure documents, effectively distinguishing it from the sibling tool view_disclosure by advising to call this first to check section IDs and volume.

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 advises using this tool before view_disclosure to check section IDs and volume, providing a clear use case. However, it does not mention when not to use it or 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?

With no annotations, the description carries the burden and does disclose meaningful traits: it refuses to judge which version is correct, states it reveals the tool/server's default version rule, and returns items in filing-date order. It omits auth/permission and rate-limit context, but for a read-style enumeration those are minor.

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?

Front-loaded with the core action, then labeled Args/Returns sections; the ⚠ warning paragraph is somewhat long but earns its place by preventing misreading of 'amendment' as 'error'. Efficient overall, minor verbosity in the rationale sentences.

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 all three parameters despite zero schema coverage, explains the non-judgment/default-rule behavior, and the existing output schema covers return values. A small gap remains around what the returned 'version mark' precisely means, but nothing essential to invoking it is missing.

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 and it does fully: company_name accepts a name or 6-digit stock code, year is a 4-digit fiscal year defaulting to the prior year when empty, and report_type enumerates annual/half/q1/q3. This adds meaning the bare schema entirely lacks.

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?

States a specific verb and resource — enumerating the revisions/versions (원본 + 정정본) of a fiscal year's periodic report — which is a distinct activity from the sibling list/search/analyze tools. An agent can immediately tell this is a version-enumeration tool rather than a content reader.

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?

Gives clear usage context: it exists because the same report is filed multiple times and you need to know whether figures came from the original or the final amendment. No explicit when-not or named alternative is given, so it stops short of a 5.

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 discloses scope: returns only facts, no risk scores, and sources (DART, etc.). Notes need for original verification. Could mention rate limits or auth, but appropriate for a read-only lookup tool.

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?

Front-loaded with purpose, then caveats, then argument. Some redundancy in emphasizing no risk judgment twice, but overall efficient. Could be slightly more streamlined.

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?

Simple tool with one param and output schema exists. Covers what it does, what it doesn't do, and caveats. Missing maybe whether it supports partial names, but output schema likely covers return structure.

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?

Only parameter is 'name'. Description restates it as '조회할 인물명' without adding format, encoding, or types. With 0% schema coverage, it should provide more (e.g., how to handle multiple names, language).

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 queries a public record registry by person name for factual company appearances, explicitly distinguishing from risk judgment tools. The phrase '사실 표기 — 판정 아님' sets it apart from siblings like analyze_company_risk.

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 (factual registry lookup) and when not (if risk judgment needed). Mentions caveats of same-name possibility and need to verify original source, guiding proper usage.

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, description discloses key behaviors: 'add' performs a union merge (합집합 병합) with existing companies. It also notes that companies are manually populated. This adds significant transparency beyond the schema.

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 structured with an initial purpose statement, background context, and an Args section. It is slightly verbose but each sentence adds value, and it front-loads the core functionality.

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 simplicity (4 params, one required, output schema exists), the description provides sufficient context including action semantics and parameter dependencies. It covers the essential aspects for correct 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?

Schema coverage is 0%, but description fully explains each parameter: action enum values, person required for show/add/remove, companies needed for add with merge behavior, and note as optional. This compensates entirely for missing schema descriptions.

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 the tool manages a watchlist of person-company groups with specific actions (list/show/add/remove). It distinguishes itself from sibling tools like find_actor_overlap by being a management tool versus an analysis 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?

Description explains when to use: to save frequently watched person's associated companies for quick re-query via find_actor_overlap, due to DART's lack of reverse lookup. It provides clear context but does not explicitly exclude 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 are provided, so the description bears full responsibility for behavioral disclosure. It explains the calculations (four indicators plus accrual ratio and comparison) and flags specific conditions (reverse net income). However, it does not explicitly state it is a read-only scan with no side effects, which would be ideal.

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 and well-structured: a brief purpose paragraph followed by a clear Args section. Every sentence adds value, with no repetition or unnecessary text. Front-loaded with the core function.

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 existence of an output schema, the description provides a high-level overview of returns (indicators and explanations) without needing to detail the schema. All parameters are documented, and the tool's behavior is well explained. Could mention that output schema gives detailed structure, but overall complete.

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 fully compensates by detailing each parameter: company_name (name or code), year (fiscal year, blank=previous), report_type (annual/half/q1/q3). This adds significant meaning beyond the schema's type and default values.

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: scanning financial statements for anomalies by comparing four key indicators year-over-year and detecting early signs of fraud or distress. It lists specific metrics and additional comparisons, distinguishing it from siblings like 'compare_financials' which likely does general comparison.

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 does not explicitly guide when to use this tool versus alternatives. While the purpose is clear, there is no mention of specific contexts (e.g., 'use for early warning') or exclusions. The sibling list is provided but the description itself lacks usage 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?

With no annotations, the description carries the disclosure burden. It covers non-obvious behavior such as confirm_long: an unconfirmed long-window request returns only guidance with estimated cost instead of executing. It also documents that days is ignored when from_date/to_date is provided and caps days at 90. It does not describe output contents or rate limits, but the output schema covers the return shape.

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 organized into a one-line purpose, a rationale sentence, three usage examples, and a compact Args list. Each section earns its place; the long preset enum is necessary and the date and confirmation details are behaviorally important. There is no fluff.

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 definition is self-contained for invocation: required preset, optional time windows, result caps, date formats, and the confirmation contract are all covered. Since an output schema exists, return-value detail is not needed here. The market-wide scope also resolves the primary ambiguity among sibling tools.

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 fully compensates. It enumerates all preset values, defaults and caps for days and max_results, the accepted date formats for from_date/to_date, and the interaction between days and explicit dates. This is more parameter guidance than most structured schemas provide.

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 and resource: market-wide disclosures are scanned in batch for risk signals matching a preset. It also distinguishes itself from company-specific siblings by explicitly stating that it queries all listed companies without a company name. As a market-level early-warning scan, its purpose is unmistakable.

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?

It gives clear context and concrete examples: '최근 7일 동안 CB/BW 발행 공시 전수' and the analogy of an early warning for how widely a risk signal has spread. It notes the contrast with company-specific queries, but it does not explicitly name sibling alternatives or state when-not-to-use, so it stops short of a 5.

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 exist, so the description carries the full burden, and it does well: it discloses the single-report scoping limit and that results carry no verdict/score/grade. It still omits error behavior, truncation/pagination, and rate limits, so it falls short of a full behavioral 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?

Front-loaded with the critical scoping warning and then the workflow, with per-parameter detail in a labeled Args block. It is long, but nearly every sentence adds operative information; the empirical aside ('8곳 → 15곳') is the only mildly expendable clause.

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 4-parameter, 0%-schema-coverage search tool with no annotations, the description supplies the scope, the workflow, every parameter's semantics, and the nature of the output (hit note number/title/excerpt, no scoring). Nothing an agent needs to invoke it correctly is missing.

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 the description must compensate, and it does for all four params: rcept_no format (14-digit DART number) plus how to obtain it per firm type, terms (whitespace-insensitive matching, the '|' OR operator, and that it is not a regex), mode's all/any semantics, and context_chars default of 600.

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?

States a specific verb+resource+scope: find note text by keyword within ONE disclosure report. It explicitly contrasts itself with a cross-company index search, so an agent can distinguish it from the many sibling discovery tools without opening the schema.

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?

Gives explicit when-not ('전 상장사에서 이런 주석이 있는 회사를 찾아줘'는 안 된다) and the required ordering (select a company first, then call with its rcept_no). It names concrete alternative entry points — get_unlisted_financials for unlisted firms and list_disclosures_by_stock for listed ones.

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 should fully disclose behavior. It explains that it aggregates events and returns totals, concentration, yearly data, time series, and flags. However, it does not mention whether it modifies data, permissions needed, or rate limits. The output description provides some transparency but is 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 concise with a clear purpose statement, followed by bullet-pointed Args and Returns. It is front-loaded and every sentence adds value without redundancy.

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, parameters, and return values, which is sufficient for a tool with 2 parameters and an existing output schema. However, an example of output or more detail on the 'rhythm detection' could enhance 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?

The description includes an Args section explaining both parameters: company_name (company name or 6-digit stock code) and lookback_years (1-5, defaults to 3). This adds significant meaning beyond the schema, which had 0% description coverage.

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 aggregates capital events (증자·감자·자사주·CB/BW/EB/RCPS 등) chronologically and detects capital manipulation rhythm. It uses specific verbs and resource, distinguishing it from sibling tools like 'analyze_company_risk' or 'build_event_timeline'.

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 does not explicitly state when to use this tool versus alternatives. It lacks guidance on prerequisites, context, or scenarios where this tool is preferred over others, such as 'track_debt_balance' or 'track_insider_trading'.

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, so description carries full burden. It communicates return format but does not disclose side effects (e.g., is it read-only?), authentication needs, or rate limits. The description is minimal beyond the function's results.

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 concise and front-loaded with purpose. The Args/Returns section is somewhat redundant with schema but adds value. Minor improvement could remove duplication.

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 no annotations, simple parameters (2, one optional), and existence of output schema, description adequately covers purpose, parameter formats, and return structure. Could mention output schema's structure briefly.

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?

Zero schema coverage, yet description provides clear meaning: company_name accepts either name or 6-digit code, year is optional YYYY format. This adds essential context far beyond the raw 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?

Description clearly states the tool queries balances of 5 specific debt security types and aggregates maturity weight, using Korean narrative. Distinct from siblings like 'track_capital_structure' which focuses on equity.

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?

Implied usage for debt balance tracking, but no explicit when-to-use or comparison with siblings. The description does not guide the agent on when to choose this over alternatives like 'get_financial_summary'.

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 mentions detecting signals but does not describe the return format, whether it is read-only, or any side effects. The output schema exists but is not summarized, leaving the agent uninformed about response structure.

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?

Two clear sentences plus an Args block. Front-loaded with purpose, no redundant words. Efficient for the information conveyed, though could be slightly more structured (e.g., separating purpose from args).

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 an output schema exists but is not described, the description is adequate for simple parameters. However, it lacks information on what the returned signals look like, pagination, or error handling. For a pattern-detection tool, more detail on the output 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 has 0% description coverage. The description's Args section adds meaning: company_name accepts a name or 6-digit stock code, lookback_years range 1-5 with default 3. This compensates for the schema's lack of detail, though additional constraints (e.g., format of stock code) could be added.

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 queries fund usage (plan vs actual) to detect misuse signals, specifically for zombie_ma/fake_new_biz patterns. It distinguishes from sibling tools by mentioning these specific fraud patterns, though could be more explicit about when to use over alternatives.

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?

No explicit guidance on when to use this tool vs siblings like check_disclosure_risk or find_risk_precedents. The description implies diagnostic use for fund misuse but lacks prerequisites, when-not-to-use, or alternative recommendations.

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 carries full burden for behavioral disclosure. It does not state whether the tool is read-only, requires authentication, or has side effects. The return is mentioned but not the behavioral traits (e.g., no mention of rate limits or data freshness).

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 with two main parts and bullet-style Args. It is front-loaded with the core purpose. Slight room for improvement in structural clarity (e.g., separating return description).

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 fully shown), the description need not detail returns extensively, but it does mention 'stakeholder table + cluster alerts'. For a tool with two parameters and no annotations, this is adequate but could cover more behavioral context.

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 clarify parameters. It explains company_name as 'company name or stock code' and lookback_years with default and max, adding meaning beyond the schema. However, it could specify input format for company_name (e.g., exact ticker or Korean name).

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 analyzes time series of major shareholder stake changes and detects buy/sell clusters. It is specific about the resource (insider trading) and action (track), distinguishing it from sibling tools like get_shareholder_info or track_capital_structure.

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?

No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or when not to use it. The description assumes the agent knows to use it for insider trading analysis but offers no comparative context.

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 carries full behavioral burden and does disclose genuine traits: a facts-only policy with no thresholds/judgments (v0.8.5), the period-end balance basis, and the exact output components including observed facts (monotonic trends, sign changes, numerator-denominator divergence). However, it stays silent on failure modes for invalid company names, data staleness/coverage, and any operational constraints, so it is helpful but partial.

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 — a front-loaded core purpose sentence followed by dedicated Args and Returns sections — and every section earns its place. Minor redundancy exists: the first paragraph already mentions CCC and fact reporting that the Returns section repeats, and the cryptic '(v0.8.5 원칙)' parenthetical could be clearer.

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 2-parameter analysis tool with an output schema present, it is largely complete: metrics, time basis, no-judgment policy, parameter formats, and return components are all covered. The remaining gaps are integration guidance (how it relates to siblings like compare_financials or track_debt_balance) and data-availability caveats, neither of which is critical for correct 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?

Schema description coverage is 0%, yet the description fully compensates: it defines company_name as either a company name or a 6-digit stock code, and documents lookback_years' valid range (1–5) and its clamping behavior (forced to 3 when out of range). This adds real semantic meaning beyond the bare schema titles and default; only minor gaps like duplicate-name resolution remain.

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 names a specific verb ('tracks') and a precise resource — five distinct turnover ratios (receivables, inventory, payables, working capital, total assets) over multiple years on a period-end balance basis — plus the companion numerator/denominator deltas and CCC. This metric list differentiates it from sibling trackers like track_debt_balance and track_capital_structure, though it never explicitly names a sibling.

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?

Usage context is implied by the detailed metric list — an agent can infer this is the tool for turnover and cash-conversion-cycle analysis — but there is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. Among siblings like compare_financials and get_financial_summary, the selection rationale is left to inference.

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, and the description does not disclose behavioral traits like idempotency, side effects, or required permissions. As a read tool, it's likely safe, but the description does not confirm this.

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 informative but could be more concise. It includes a usage section and parameter list, but the structure is somewhat verbose. Not tightly 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?

Covers all parameters and usage workflow. Since output schema exists, return values need not be described. Minor gaps: no error handling or prerequisites beyond list_disclosure_sections.

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 has 0% description coverage, but the description explains all parameters in detail: rcept_no format, section_id source, page default, page_size range. Adds essential meaning beyond 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?

Description clearly states the tool views DART disclosure original text and explains section/page reading. However, it doesn't explicitly differentiate from sibling get_disclosure_document, leaving minor ambiguity.

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?

Provides a step-by-step usage pattern showing how to combine with list_disclosure_sections, and explains when to use section_id vs. page. Lacks explicit when-not-to-use or alternatives.

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