MyDART

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), but the description goes well beyond: documents[] carries metadata only unless all_docs=true, truncated=true means re-query rather than data loss, find returns bundles 'instead of content', 0 find matches does not mean absence (scanned tables need get_attachments mode=images), and filings without 원문 XML silently switch to source=viewer with a different index space. These are non-obvious behaviors an agent would otherwise get wrong.

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 a one-line purpose, then bracketed sections ([Purpose]/[Usage]/[Response]/[Rules]) that make a long, dense, bilingual block scannable. It is verbose and repeats a few points already in the schema (truncation clamps, viewer mode), but for a 10-parameter tool with many interaction rules almost every line carries actionable 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?

No output schema exists, yet the description explains the return shape (documents[] indexing, find bundles, clipped/truncated flags, viewer-section mapping) and the fallback path when a filing has no 원문 XML. For a complex 10-param retrieval tool this is complete enough to call correctly on the first attempt.

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 100%, so the schema already documents all 10 parameters and the baseline is 3. The description nonetheless adds cross-parameter meaning the schema cannot: role vs doc_index vs all_docs mutual exclusion, sections=[] returning an outline to then index into, and the truncate_at remedy for truncated results. It also warns against guessing doc_index 1~2 for audit reports.

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 (reads and searches 공시 원문 as markdown, preserving heading/table structure) and explicitly carves out scope against siblings: audit opinion/KAM analysis goes to get_audit_report, ZIP-external documents and scans to get_attachments, XBRL to get_financials. An agent can distinguish it from every relevant sibling 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?

The [Purpose] and [Usage] sections give explicit when-to-use conditions with three concrete worked examples (rcept_no lookup, role+sections, find terms), plus negative routing ('not get_attachments', audit opinion in _00760/_00761 pick by role). Exclusions and alternatives are named rather than implied.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real behavioral context beyond them: results are similarity-ranked (do not trust the first item), count is capped by limit rather than being the total, 0 hits adds notes, and preferred/ETF codes have specific mapping 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?

Well-structured with [Purpose]/[Usage]/[Response]/[Rules] sections and the critical 'first call' note front-loaded. It is on the long side, but each section carries distinct information (routing, examples, return shape, ranking caveat) rather than repetition.

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 no output schema, the description carries the full burden of explaining return values (stock_code semantics, count capped by limit, notes on zero hits) and the ranking caveat. Combined with the schema and annotations, an agent has everything needed to call and interpret this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: query accepts a Korean/English name, a 6-char ticker, or an 8-digit corp_code, and it shows limit in action (limit=20) and warns that common names may overflow the default. This goes beyond the schema's terse field 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?

States a specific verb+resource ('회사명·종목코드로 DART 법인 식별자(corp_code)의 후보를 확인') and explicitly distinguishes from siblings, routing 업종·data to get_company_profile and disclosure listings to search_disclosures. An agent can tell this apart from every sibling 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 names the trigger condition ('first call when a company's corp_code is unknown') plus a disambiguation use case, and gives four concrete input→workflow examples (e.g. '카카오' → get_financials). It also states what the tool is NOT for, pointing to the right alternatives.

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?

Beyond the readOnly/destructive/idempotent annotations, the description discloses real operational behavior: mass viewer calls trigger DART IP bans (rate-limit), partial:true surfaces section_errors[] and markdown may be truncated mid-content ('빈 곳 ≠ 사실 없음'), images are returned as raw pictures whose OCR is the client's job, and capped calls yield roughly one image per page. It also specifies the supported:false fallback contract to follow verbatim.

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 front-loaded with purpose before usage, response, and rules, and the bracketed headers make it scannable. It is somewhat verbose and repeats mode=text/mode=images cues across sections, but with no output schema the [Response] block 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?

With 11 parameters, no output schema, and mutation-free but costly remote calls, the description supplies the return shape ([Response]), the error/partial contract, and the fallback routing an agent needs. The remaining gap is minor: no explicit note on pagination or dcm_no-defaulted behavior for the list mode.

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 100%, so every one of the 11 parameters is already documented in the schema, which sets the baseline at 3. The description restates mode=text/mode=images and mentions sections/image_from routing, but adds no syntax or format detail not already present in the parameter descriptions themselves.

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 concrete verb+resource ('공시의 첨부파일 목록과 형제문서 본문·페이지 이미지를 다룹니다') and enumerates the three operating scopes (list/text/images). It also differentiates itself from a sibling by routing 감사보고서·주석 to download_document(role). However, the scope is dense and mixes three distinct retrieval modes, so the single-sentence purpose takes effort to parse.

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 [Usage] block gives stepwise conditions (list first to obtain dcm_no, then mode=text; mode=images only when the table exists purely as an image) and the [Rules] ladder (text → images → download_url) tells the agent exactly when to fall through to the alternative. It also names a sibling (download_document) as the route for 감사보고서·주석, so the when-to-use/when-not decision is explicit.

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?

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial behavioral context beyond them: data_available=false means the filing was not found (not 'confirmed absent'), audit_only=true makes fees structurally absent, 연결/별도 split must be read from kam.by_fs_div rather than kam.topics, applicability.guidance[] must always be read, and auditor rotation/연속연수 are not returned. This is exactly the value-add a description should provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with a one-line purpose, then cleanly sectioned into Purpose/Usage/Response/Rules, so an agent can scan to the relevant block. It is dense and long, but the sections carry non-redundant content (units, opinion domain, regime notes) 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?

There is no output schema, so the description carries the return-value burden and does so: it names the fields returned, explains the `_m` (백만원) unit, lists the opinion domain values, and discloses what is deliberately omitted (감사인 교체/연속연수). Combined with the rules on null semantics and cache refresh, an agent has everything needed to call and interpret the result.

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 100% and the year parameter is documented exhaustively in the schema itself, so the baseline is 3. The description adds intent-to-parameter mapping ('감사인·감사보수만 빠르게' → light=true) and explains what the light flag omits in outcome terms, giving meaning beyond the field definitions.

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 returns a one-table summary of external-audit execution details (감사인·감사의견·업무수행이사·감사보수·감사투입시간·실사·외부조회). It explicitly differentiates from siblings by routing full 의견근거·KAM to get_audit_report, ICFR to get_internal_control, 계속기업 to get_going_concern, and 모집단 lists to search_audit_findings. An agent can pick this tool without opening any sibling 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 concrete when-to-use examples with parameter mappings ('삼성전자 2024 감사보수·비감사보수' → corp/year) and a when-to-use-the-fast-path rule (light=true for 감사인·감사보수만). It also names the alternatives for adjacent needs, so both selection and invocation are covered.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description does not contradict them, so the safety profile is effectively transparent. The description adds genuine behavioral detail beyond annotations: body_omitted:true stubs are re-requestable rather than absent, refresh bypasses the cache, truncation is clamped and reportable via truncated=true, and fs_div=both can return up to two reports where reading only the first drops an axis. The omission is any statement of auth requirements or failure modes; with annotations carrying the safety burden, a 3 is fair.

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 a one-sentence purpose, then clean [Purpose]/[Usage]/[Response]/[Rules] blocks, so an agent can skim to the relevant block. It is dense, though — the Korean/English code-switching and long schema-side parentheticals mean some Rules entries (F 단독공시 caveat) restate what the parameter descriptions already cover, costing a little signal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 7 optional parameters and no output schema, the description carries the return-shape load and does so: sections[].key, the opinion enum (적정/한정/부적정/의견거절), fs_label, source_note, correction_note, and kam.count expectations are all explained. The one gap is that it never says what happens when corp+year resolve to nothing or how the corp fallback to F 단독공시 is signalled to the caller.

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 100%, so the baseline is 3, but the description adds real semantics on top: sections="summary" is defined as the finding-paragraph subset with a conditional basis rule, truncate_at is framed as a retry lever rather than a raw cap, and fs_div's 'reading only the first drops an axis' warning is operational advice absent from the schema. What it does not add is guidance on when to prefer rcept_no over corp+year beyond what the schema already states.

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 opening sentence states a specific verb and resource — it returns 감사보고서 body paragraphs structured section-by-section, listing the exact section keys (감사의견·감사의견근거·KAM·강조사항·기타사항·계속기업가정불확실성). It explicitly distinguishes itself from two siblings, routing structured fact summaries to get_audit_profile and ICFR detail to get_internal_control, so the agent can pick this tool 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?

The [Usage] block gives three concrete request-to-parameter mappings (KAM 문단 전문, 별도 의견거절 근거 원문 with fs_div="OFS", 발견사항만 with sections="summary"), plus the escalation path (truncate_at 상향) when results are cut. The [Purpose] block names the two alternatives and the conditions that select them, and [Rules] adds exclusion logic (재무제표·주석 수치는 download_document).

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?

Annotations already declare readOnly/idempotent/openWorld, so the bar is met for safety, yet the description adds substantial behavioral context beyond them: enumerated filing_tier outcomes and what each implies, the required follow-up route for audit_only and listed_konex, the anti-retry rule for empty financials on KONEX, and the provisional/no_disclosure_found caveat about never concluding 비외감. This is rare, decision-relevant 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?

Content is front-loaded with a one-line summary, then separated into [Purpose], [Usage], [Response], and [Rules] blocks. Despite its length, each block carries distinct decision-relevant information (routing, output shape, caveats) with no filler 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?

There is no output schema, so the description carries the return-value burden and does so by enumerating data_location.filing_tier values, company.corp_cls codes, and acc_mt. Combined with the routing rules and caveats, an agent has everything needed to call this and correctly interpret the result.

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 100% and both parameters (corp accepting 회사명/종목코드/corp_code, year's fiscal-period and provisional semantics) are already documented in the schema. The description's examples reinforce the accepted corp formats but add little meaning not present in the schema text, which is the expected baseline case.

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 opening line names a specific verb (조회) and resources (기업개황: 업종·대표자·결산월·상장구분 plus data_location), and the [Purpose] section explicitly routes agents elsewhere for adjacent needs (감사 → get_audit_profile, name ambiguity → find_corp_code). An agent can distinguish this from every sibling 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?

Three concrete natural-language usage examples map user phrasings to parameters, and the [Purpose]/[Rules] sections state when this tool is the right first step (basics + routing check before 재무·감사 calls on unfamiliar/비상장 companies) and name the alternatives explicitly. Both inclusions and exclusions are present.

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?

Annotations already cover safety (readOnly, non-destructive, openWorld), and the description adds substantial context beyond them: date axis is 최초 공시일 newest-first, fields come from the latest 정정본, total_count is all-time cumulative while filtered_count is client-side filtered because DART takes no dates, empty timeline ≠ no events, and event_type_counts is pre-truncation. This is exactly the extra behavioral layer annotations cannot supply.

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?

Dense but well-sectioned ([Purpose]/[Usage]/[Response]/[Rules]) and front-loaded with the one-line purpose before details. Slightly long and a few lines (e.g. the paper-price/investor note) sit close to redundancy, but every block carries operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must carry return semantics — and it does, explaining the date axis, correction handling, the two count fields, truncation flags and sections_meta per-endpoint errors. For a 6-param open-world query tool, an agent has everything needed to call it and interpret results.

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 100% so the baseline is 3, but the description adds real meaning on top: mode switching behavior when event_type is an array, the 'capital' default group and 'holdings' alias, the limit-vs-start/end tradeoff guidance, and that start/end match an event's first filing so later 정정 is excluded. These go beyond the schema's own text.

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?

Names a specific resource (주요사항보고서 자본·지배구조 이벤트 36종 plus 5%룰·임원 지분공시) and a clear retrieval verb, then explicitly differentiates from siblings get_registration_statement, search_disclosures and get_periodic_report. An agent can distinguish it from all 14 siblings without opening any 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?

Provides three concrete usage scenarios keyed to intent ('카카오 최근 3년 자본 조달 흐름', 'CB 발행한 적 있어?', '자사주 취득·처분 2020년부터') and names the alternative tool for each adjacent need. When-to-use and when-to-use-something-else are both explicit.

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?

Annotations already carry readOnly/idempotent/destructive hints, yet the description adds substantial non-obvious behavior: amounts are STRINGS, cumulative-vs-quarter semantics differ per statement type (IS/CIS CUMULATIVE = thstrm_add_amount, CF already YTD, BS single-period), CFS→OFS fallback with fs_div_note, and the 정정-반영 vs AS-FILED distinction between corp+year and rcept_no. These are exactly the traits an agent needs and none are in the 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?

Front-loaded with a one-line summary followed by labeled [Purpose]/[Usage]/[Response]/[Rules] sections that make it scannable despite its length. It is denser than necessary and repeats some schema content (sj_div expansions, format rejection), but every section carries usable information and there is no 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?

No output schema exists, and the description compensates fully by naming the row keys (sj_div, account_nm, thstrm_amount, frmtrm_*, bfefrmtrm_*, thstrm_add_amount) and explaining total_count vs count semantics. Combined with the routing rule for no_data and the period legend caveat, an agent has everything needed to call and interpret this 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 100%, so the baseline is 3, but the description earns above baseline by adding cross-parameter semantics the schema lacks: corp+year returns the LATEST filing with 정정 applied while rcept_no returns the filing AS FILED, year means 결산 사업연도 not filing year, and format is rejected outright. Much of the sj_div/scope text does restate schema enums, so it is not a full 5.

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 (재무수치 조회) and enumerates the exact figures covered (매출·영업이익·순이익·자산/부채/자본). It explicitly scopes itself against siblings by naming download_document for 사업보고서 prose and get_going_concern for 부실징후, so an agent can route without opening schemas.

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 three concrete query→parameter mappings (single corp+year, comparison via array, as-filed via rcept_no) and explicitly states that '재무 질문 대부분은 이걸로 충분합니다.' The [Rules] section adds the no_data-is-routing-not-error escape hatch, which is genuine when-to-use guidance.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower; the description nonetheless adds real behavior: grade banding semantics, cross_check code enumeration, the fact that consecutive_op_loss is a count not a bool, and null/False distinctions. It stops short of describing latency, caching depth, or pagination, 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?

Front-loads the one-line purpose and organizes the rest into [Purpose]/[Usage]/[Response]/[Rules], so an agent can scan to the section it needs. It is dense and long, and a few rules restate response fields already listed above, but no section is 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?

No output schema exists, so the description carries the return-value burden and does so: it enumerates flags, grade bands, cross_check codes, and text fields, and it documents the parser pitfall (going_concern_mentioned false vs null) that would otherwise cause misreads. For a 4-param analytical tool with a rich response, nothing material 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 100%, which normally sets the baseline at 3, but the description adds a semantic the schema omits: fs_div is post-fallback, so a CFS request may return OFS figures in the response. That is a genuine cross-field nuance beyond the schema text.

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 analytical action (judging going-concern risk by intersecting quantitative metrics with audit-report text) rather than a generic resource operation. It explicitly names the sibling tools it draws on (search_audit_findings, get_financials, get_audit_report), letting an agent place it among the 14 siblings without opening schemas.

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 [Usage] section gives concrete when-to-use examples ('이스타코 2024 계속기업 위험 있어?' → corp/year; 별도 기준 → fs_div=OFS) and the [Purpose] block routes the agent to alternatives for lists, figures, and report text. It also warns that a mismatch is a cue to read the 원문, not a finding — explicit guidance on interpretation, not just invocation.

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?

Annotations cover safety (readOnly/idempotent), but the description adds substantial behavioral context: the opinion domain (적정/부적정/의견거절, no 한정), the review-vs-audit 의견거절 distinction, reports-always-array semantics, and present=false out-of-scope note. Goes well beyond what annotations declare.

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?

Structured with [Purpose]/[Usage]/[Response]/[Rules] headers and front-loaded purpose. Somewhat dense – the nested routing in [Purpose] is compressed – but nearly every sentence carries actionable guidance.

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-only, 4-param tool with rich schema and strong annotations, the description covers opinion-value semantics, empty-array behavior, present=false meaning, and cross-tool routing. No output schema exists, yet return-shape cues (opinion domain, reports array, review_or_audit field) are provided.

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 100%, so baseline is 3, but the description still adds useful semantic notes: fs_div='CFS' selection example and 연결 ICFR only applying to 2조↑ filers; the schema carries the detailed year edge cases. Points to fs_div behavior that clarifies real-world interplay.

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 resource and verb: retrieving the auditor's ICFR audit/review report with 구분·의견·중요한 취약점. Explicitly distinguishes ICFR opinion from 재무제표 감사의견 and names sibling tools (search_audit_findings, get_attachments, get_audit_profile, get_audit_report) that cover adjacent needs.

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 worked examples ('카카오페이 2024 내부회계 의견', '연결 기준만'), names alternatives with the condition that routes to each (약점 lists → search_audit_findings, 자금부정통제 → get_attachments / management_operation_report). Explicit when-not and when-else.

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?

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavior beyond that: amounts returned as STRINGS, status codes (000 성공 / 013 무자료), per-element ARRAY status with all-013 flipping to mode:'no_data', [013] as legitimate absence rather than failure, fiscal_year_note offset for non-December closers, and automatic 구판↔V2 routing for the 개인별 보수 sections.

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?

Clearly sectioned into [Purpose]/[Usage]/[Response]/[Rules] with the core purpose front-loaded, so an agent can stop reading early. The density of edge-case rules makes it longer than ideal, but nearly every line carries operational value 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?

There is no output schema, so the description must carry return-value semantics — and it does: status codes, periods legend mapping 당기/전기/전전기 to fiscal years, the no_data mode shape, truncation signaling, and the V2 three-row-per-person compensation caveat. Complete for a 28-section, 5-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 100%, so the baseline is 3; the description nonetheless adds value by grouping the 28 report_type values into families, naming the group aliases 'shareholders' and 'executive_compensation', and explaining the year-defaulting behavior and fiscal_year_note interplay. It stops short of documenting max_items/truncation in prose, which the schema already handles.

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 (사업보고서 세부 섹션 28종), including scope (single or multiple sections), and explicitly delineates against siblings by naming get_financials for 재무제표 figures and get_audit_profile/get_audit_report for auditor opinion. An agent can distinguish this tool without opening any 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?

Provides two concrete worked examples mapping natural-language queries to arguments, states the year-omission default (최신), and routes agents to alternative tools for adjacent data (재무제표 → get_financials, KAM·내부회계 → get_audit_profile). When-to-use and when-to-use-something-else are both explicit.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true. Beyond that, the description discloses substantial behavior an agent could not infer: superseded_by semantics, withdrawn:true meaning a 철회신고서, version_check indicating incomplete checks, fetch_failed/truncated_note meaning 'unconfirmed' not 'none', and that 사모·일괄신고서·소액공모 are out of scope. This is rich, non-obvious operational context.

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 [Purpose]/[Usage]/[Response]/[Rules] headers and is front-loaded with the core purpose. It is dense and lengthy, but nearly every sentence carries behavioral detail (superseded, withdrawn, fetch_failed, out-of-scope types), so little is pure 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?

With no output schema, the description compensates by describing the return shape (filings[] per rcept_no, newest first, the named sections, date semantics, omitted '-' fields). Combined with edge-case rules for truncated, withdrawn, version_check, and out-of-scope types, an agent has everything it needs to interpret results correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents most parameters, giving a baseline of 3. The description adds value by reinforcing the window-widening advice ('keep the window wide') and clarifying that date = 접수일 and that 정정본 dates may fall outside the window, which informs how start/end should be set.

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 opening sentence names a specific verb (조회) and resource (증권신고서 주요정보 6종: 모집·매출 조건, 인수인, 자금 사용목적, 합병·분할 조건) returned as structured JSON. The [Purpose] block further distinguishes it from siblings by routing board decisions to get_corporate_event, listing scans to search_disclosures, and narrative risk factors to download_document. An agent can tell exactly what this tool returns and how it differs from neighbors.

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 [Usage] section gives a concrete trigger example ('대한항공 유상증자 조건' → corp/statement_type) and the [Purpose] block maps adjacent needs to specific alternative tools. It clearly frames the context for invoking this tool, though it stops short of explicitly stating exclusions like 'do not use for private placements' framed as guidance (that constraint appears later under [Rules]).

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?

Annotations already declare a safe read-only, idempotent surface, but the description adds substantial behavior beyond them: a daily cap on distinct targets per token (rate limit), flt_rt vs close-delta return semantics with the 액면분할 caveat, peer prefix relaxation with prefix_depth_used fallback, and the instruction to always read notes[] for 강등·폴백. These are exactly the operational traits 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?

Front-loaded with a one-line purpose, then Purpose/Usage/Response/Rules sections where nearly every line carries a rule an agent cannot infer. Dense but not padded; slight compression cost from the bilingual shorthand, which is understandable given 24 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?

No output schema exists, so the description compensates with a Response section on units and return provenance, plus Rules covering degradation, sourcing, and caps. For a 24-parameter, three-mode tool this is complete enough 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 100%, so the schema already establishes most parameter meaning (baseline 3). The description adds cross-parameter semantics not in the schema: the unit convention (*_pct = %, mrp/srp/tax_rate = decimals, flt_rt = 등락률 %) and the interlocking role of basis choices in the Hamada unlevering, which lift it above baseline.

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 ('가치평가 데이터를 kind 로 골라 조회') and enumerates the three retrievable domains (market 시계열, WACC build-up, peer comps). It explicitly distinguishes itself from siblings by naming get_financials for 재무수치 and get_company_profile for 업종·시장구분.

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 concrete when-to-use routing examples ('에스에프에이 최근 1년 주가' → kind=market; '반도체장비 업종 피어 멀티플' → kind=peers) and names the alternative tools for adjacent data. The kind enum also documents that passing an argument for the wrong kind errors, which is explicit 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description still adds substantial non-obvious behavior: coverage.note must be read before concluding a null result (empty ≠ nonexistent), fs_div=both yields up to two rows per company requiring corp_code dedupe, breakdown ignores non-baseline filters, and there is a daily row cap per token. These are exactly the traps that would cause a wrong answer, not restatements of the 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 [Purpose]/[Usage]/[Response]/[Rules] headers front-load the essential framing and there is little filler. However, the [Rules] section is compressed into pseudo-formulas ("kam=false+kam_required=true+kam_none_declared=false") that trade readability for density, and the bilingual prose adds some scanning cost.

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 19-parameter search tool with no output schema, the definition carries most of the necessary burden: filter semantics, the brief/full row contents, output market letters (Y/K/N/E), fs_div KOREAN labels, and the null-result interpretation rule. The remaining gap is that the overall response envelope (coverage, breakdown, count, truncated, applicability) is only alluded to rather than described, so an agent must infer the shape of the result.

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 100%, so the baseline is 3; the description earns above that by adding cross-parameter meaning the schema does not carry — fields="brief" is the list/count path while full is for a picked company, year accepts an array for multi-year with per-year coverage.years[], and fs_div=both is a row-multiplication caveat rather than a simple enum. A few rules (e.g. the kam/ kam_required / kam_none_declared triple) are stated so telegraphically that they are hard to apply without re-reading 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 opening sentence states a specific verb and resource: it finds listed/unlisted companies by audit-report conditions *without* naming a company. It also carves out the sibling boundary explicitly — detail via get_audit_profile/get_internal_control, original text via get_audit_report — so an agent can route correctly without opening any 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?

The [Usage] block gives four concrete natural-language-to-parameter mappings (opinion="disclaimer" + market="kospi", fields="brief" for list/count, year=[2024,2025] for multi-year, market="unlisted" for private filers), and [Purpose] names the alternatives for detail and full-text needs. When-to-use and when-to-go-elsewhere are both covered.

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?

Annotations already cover the read-only, non-destructive profile, but the description goes well beyond them: request budget (60 without corp, 1 with), latency expectations, incomplete=true when the budget is hit, the nested counter semantics (total_available ≥ total_fetched ≥ matched ≥ returned), and the crucial caveat that collected_periods are the ONLY ranges queried so unqueried ranges are unchecked rather than zero. It also discloses that preset batch drops 정정공시 while page mode and bare all_pages keep them. Only gap: it never states the tool actually returns rows vs. just receipt numbers in each mode beyond the response-field notes.

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 one-line purpose, then clearly sectioned [Purpose]/[Usage]/[Response]/[Rules], which makes it scannable despite length. It loses a point for duplicating schema content — the corp batch-vs-single-request tradeoff and the correction-handling rules are already spelled out in the corp and include_corrections parameter descriptions.

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 15 parameters, three enums, and no output schema, the description compensates by decoding return fields (corp_cls Y/K/N/E, report_nm [기재정정]/[발행조건확정]/[정정제출요구] prefixes) and by explaining how to interpret truncated or partial results via the counter nesting and incomplete_note. An agent has everything needed to call it and to reason about whether the result set is trustworthy.

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 100%, so the baseline is 3, but the description adds real semantics the schema does not: preset keys match the EXACT DART 보고 사유 rather than title substrings, one key per 사유, and which group aliases union several keys. It also explains the final_only/include_corrections interaction and the counter scoping rule that governs how to read limit-truncated results.

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 — finds rcept_no in the DART disclosure list — and immediately frames itself as the entry point to download_document and get_attachments. The [Purpose] block also names what it is NOT: get_periodic_report for periodic-report sections and find_corp_code for disambiguating company names, so an agent can pick it apart from siblings without opening schemas.

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?

Three concrete intent-to-parameter mappings ("삼성전자 최근 한 달" → corp + days=30, 작년 유상증자 → preset rights_offering with explicit dates, CB 발행만 → preset cb_issuance vs group alias cb) show exactly when to use which knob. Rules add a hard directive — always pass corp when a company is named — plus the cost consequence (60 requests, tens of seconds vs 1 request) that drives the choice.

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