MyDART

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

Beyond readOnlyHint/destructiveHint annotations, the description discloses non-obvious behavior: a ZIP contains multiple documents and audit sub-docs are not index 0, all_docs=true is required for content, find returns excerpts rather than full text, out-of-range doc_index silently falls back, and truncation clamps. These caveats materially affect how an agent interprets 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?

The description is long but organized into Purpose/Usage/Response/Rules with dense, front-loaded information. A few statements overlap with schema descriptions, but the structure keeps the length justified for an 8-parameter tool with no output 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?

Given no output schema, it provides the response roles, the metadata-only behavior of documents[], the truncation signal, and the find-result semantics including excerpts, locations, byte budgets, and clipped flag. It also covers failure/fallback notes, making the tool callable correctly by an agent without needing to guess.

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 strong; the description adds value with query-to-parameter examples, role→doc_index selection, and cross-parameter caveats such as find ignoring truncate_at and all_docs dividing the budget. It does not need to restate schema details because those are already complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a clear verb+resource statement: reads and searches disclosure full text in markdown while preserving headings/tables, and explicitly includes choosing the audit report inside a business-report ZIP. It names sibling tools like get_audit_report, get_attachments, and get_financials so an agent can distinguish this full-text reader from report-specific tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Has a dedicated Purpose section routing each alternative: audit opinions/KAM → get_audit_report, HWP/PDF attachments → get_attachments, XBRL → get_financials. Usage examples translate natural-language requests into concrete parameter values, and Rules state when not to rely on this tool (scanned-image tables → get_attachments(mode=images)).

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/idempotent annotations, the description discloses that results are similarity-ranked candidates, that the first result is not necessarily correct, that stock_code presence indicates listed common shares, that count is capped by limit and not total matches, and that preferred/ETF/ETN codes have no mapping. This is significant behavioral context that an agent needs for correct interpretation.

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 longer than average, but it is well-structured into Purpose, Usage, Response, and Rules sections, and front-loads the most critical usage directive. Each section earns its place, though some content slightly overlaps between Purpose and Rules.

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 explaining key result fields (stock_code, count, notes), the candidate-array nature of results, and caveats around matching and limits. Given the tool's simple input but subtle output semantics, this is complete enough for correct invocation and interpretation.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds value by clarifying accepted query formats (Korean/English name, 6-digit stock code, 8-digit corp_code) and practical limit behavior ('raise it when candidates look truncated'). This goes beyond the schema's basic 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?

The description explicitly states the tool resolves DART corp_code candidates from a company name or stock code, and clearly scopes it as ID resolution only. It names sibling tools (get_company_profile, search_disclosures) to distinguish what this tool does not do. This removes any ambiguity about its role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says this is the 'first call' when a corp_code is unknown, gives concrete query examples, and tells when to use alternatives such as get_company_profile for company data or search_disclosures for filings. It also advises raising the limit when candidates appear truncated. Usage guidance is explicit and actionable.

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 only indicate read-only/idempotent behavior, so the description carries the transparency burden and succeeds. It discloses IP-ban risk, that attachment files are never parsed server-side, that OCR is the client's job, and that partial:true means empty sections are not evidence of absence.

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 Purpose/Usage/Response/Rules headers and front-loaded scope. It is long, but the tool is complex; it earns a 4 rather than 5 because some content overlaps with the already-detailed 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?

Given the complexity of a multi-mode tool with 11 parameters and no output schema, the description covers modes, response formats, fallback behavior, and operational guardrails. The only minor gap is that the exact shape of the list response is not spelled out in one place, though it is inferable from schema and usage examples.

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 routing semantics beyond the schema: mode=text for body text, mode=images for scans, dcm_no acquisition from list results, and image_from/pages selection guidance. It stops short of fully re-documenting each parameter because the schema is already exhaustive.

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 the tool's scope: '공시의 첨부파일 목록과 형제문서 본문·페이지 이미지를 다룹니다' and immediately distinguishes itself by stating '구조 보존은 download_document'. It clearly identifies the resource, the modes, and how this tool differs from 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?

There is an explicit 'Usage' section with numbered steps: get dcm_no from list, then call with dcm_no and mode='text'; use mode='images' when tables are image-only; and route structure-preservation needs to download_document. It also gives an exclusion warning — 'No bulk sweeps — mass viewer calls bring DART IP bans'.

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 profile (readOnlyHint=true, idempotentHint=true). The description adds substantial context beyond that: data_available=false means the filing was not found (null fields must not be read as 'confirmed absent'), audit_only=true (F 단독공시) means fees are structurally absent rather than a defect, the kam.by_fs_div field routing for 연결/별도 splits, the mandate to ALWAYS read applicability.guidance[] for next-tool routing, and the explicit note that 감사인 교체/연속연수 are NOT returned. It also defines response semantics: fees `_m` suffix = 백만원 and the opinion domain (적정/한정/부적정/의견거절). This is exactly the behavioral nuance annotations cannot carry.

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?

Long, but densely organized into labeled sections ([Purpose], [Usage], [Response], [Rules]) that each carry distinct information — scope routing, call examples, response format, and edge cases. The main purpose is front-loaded in the opening sentence, and the Rules section is terse bullet-style guidance. Every section earns its place; the length is justified by the tool's complexity.

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

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

For a complex tool with no output schema, the description carries the full burden of explaining response interpretation and edge cases, and it succeeds: response format (_m suffix, opinion domain), data-availability semantics (data_available=false), structural absence (audit_only=true), field routing (kam.by_fs_div vs kam.topics), next-tool routing (applicability.guidance[]), and explicitly what is NOT returned (auditor change/consecutive years). Nothing an agent needs to call it correctly and interpret results 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 100% and the schema itself is unusually detailed (especially the year parameter covering fiscal-year vs disclosure-year conversion and relative-date counting). The description adds value above the baseline by mapping natural-language queries to parameter values (corp/year/light usage examples) and by explaining the practical trade-off of light=true (fast, omits 실사). That exceeds the baseline-3 for high coverage but doesn't need to compensate for 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 first sentence states a specific verb (반환/return), resource (감사 개요/audit profile), and precise scope (감사인·감사의견·업무수행이사·감사보수·감사투입시간·실사수행내역·외부조회 실시여부 summarized in one table). It also names the sibling tools it is not — get_audit_report (full opinion basis, KAM, emphasis text), get_internal_control (ICFR), get_going_concern (going concern quant), search_audit_findings (company lists) — so an agent can differentiate without opening other 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?

Explicit usage examples map real user queries to parameter values: '"삼성전자 2024 감사보수·비감사보수" → corp="삼성전자", year=2024' and '"재고실사 입회했는지 빠르게만" → corp="…", year=2024, light=true'. Alternatives are named explicitly with routing conditions (full text → get_audit_report, ICFR → get_internal_control, company lists → search_audit_findings). Nothing 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?

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description meaningfully adds behavioral context beyond those: it explains the 'body_omitted:true' semantics (section exists but body not requested, not absent), disclosure rules about unlisted F 단독공시 legitimately lacking KAM, and the behavior of 'kam.count=0 with none_declared' (declared 없음 normal vs undeclared suspect). It also reveals cache behavior via refresh and rcept_no annotations, which is beyond the basic annotation hints. A small gap: it doesn't describe pagination or network failure behavior, but the added detail is substantial, so 4 is appropriate.

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 a model of structured front-loading: it opens with a one-sentence purpose summary with a bullet list, then uses labeled sections ([Purpose], [Usage], [Response], [Rules]) that each contain dense but relevant information. Every sentence earns its place — e.g., the rules section bundles the most decision-relevant operational caveats (body_omitted, none_declared, internal_control verdict-only) in compact form. There is no padding or 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?

Given the tool's complexity (7 params, 10 section keys, conditional behaviors) and the fact that there is no output schema, the description is remarkably complete. It covers: what the response structure looks like (sections[].key, fs_label, source_note, correction_note), edge-case interpretations (kam.count=0 with none_declared), unlisted-company caveats, the body_omitted contract, and where to route other needs (download_document, get_internal_control). No output schema exists, so the description's response-structure coverage is essential and well done.

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 per rubric. The description adds meaningful semantic value beyond the schema: it maps natural-language intent to parameters ('삼부토건 FY2024 별도 의견거절 근거 원문' → corp='삼부토건', year=2024, fs_div='OFS'), explains the sections argument's selection and body_omitted mechanics, and gives truncate_at usage guidance ('잘리면 truncate_at 상향'). It also clarifies the years semantics in the schema itself. This lifts it above baseline 3, though not to 5 because the schema already carries detailed per-parameter 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?

The description states a specific verb ('returns'), a precise resource ('audit report body structured by paragraph'), and explicitly lists the section types ('감사의견·감사의견근거·KAM·강조사항·기타사항·계속기업가정불확실성'). It distinguishes itself from sibling tools by name ('get_audit_profile', 'get_internal_control'), so an agent can identify this tool as the verbatim-paragraph audit report 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?

The description provides detailed, explicit when-to-use guidance: it contrasts with 'structured fact summaries' (get_audit_profile) and ICFR detail (get_internal_control), gives concrete query-to-parameter examples ('LG에너지솔루션 2024 KAM 문단 전문' → corp='LG에너지솔루션', year=2024), and includes conditional advice such as '발견사항만 → sections="summary"; 잘리면 truncate_at 상향'. This exceeds the bar for 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?

Beyond the readOnly/idempotent annotations, the description discloses the provisional-year caveat, that listed_konex can legitimately return empty financial results, and that audit_only data must be fetched via download_document rather than get_financials. It also explains how data_location values map to data sources, which materially affects follow-up 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?

Although long, the description is organized into Purpose, Usage, Response, and Rules sections with bullet-style entries, making it easy to parse. Every block earns its place: routing rules, taxonomy, and examples are all decision-relevant, and the one-sentence summary is front-loaded before the detailed sections.

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 compensates by enumerating the key data_location and corp_cls values and their meanings. It also covers edge cases (year omitted, 비상장 vs 상장, listed_konex empty results) and names the follow-up tools, making the tool safely invocable without external knowledge.

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 already documents both parameters comprehensively (100% coverage), and the description adds value with concrete usage examples and the year-sensitive routing nuance (year matters only for 비상장사). It does not invent new semantics, but it reinforces and contextualizes the schema rather than merely repeating it.

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 the specific resource (기업개황) and two concrete outputs (basic company profile fields and data_location), using a clear verb (조회). It also explicitly distinguishes itself from get_audit_profile and find_corp_code, so an agent can separate it from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The [Purpose] section states the intended context ('routing check before 재무·감사 calls on unfamiliar, especially 비상장, companies') and [Rules] gives explicit routing decisions based on data_location, including when not to retry. The three usage examples translate natural language questions into concrete parameter settings, leaving no ambiguity about when and how to call it.

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, but the description adds significant behavioral context beyond that: date is the filing date while event dates are in raw row fields; holdings counts distinguish all-time cumulative from in-period values; DART accepts no dates and filters client-side; an empty timeline does not mean no events; and event_type_counts is pre-truncation. These are exactly the kind of non-obvious behaviors an agent needs to interpret results correctly.

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

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

The description is long, but the Purpose/Usage/Response/Rules structure front-loads selection guidance and each section contributes non-redundant caveats. Some content overlaps with the already-detailed schema, and the Korean/English mixing adds length, but the density of operational guidance warrants the size.

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 well by covering response date semantics, holdings count semantics, per-endpoint error indicators, truncation behavior, and default event-type selection. It does not fully enumerate response shapes for all 38 event types, but for a tool of this complexity the critical invocation and interpretation context is present.

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 event_type parameter description is already very rich, including enums, aliases, automatic mode switching, and array behavior. The description adds practical value through usage examples that show valid parameter combinations, such as event_type arrays with start dates, and it clarifies how defaults behave in timeline mode. This justifies slightly above the baseline 3 for fully-schema-documented parameters.

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: it queries 주요사항보고서 capital/governance events (36 types) plus 5% rule and executive equity disclosures. It also explicitly names sibling tools for adjacent use cases, such as get_registration_statement and search_disclosures, so an agent can distinguish this tool from alternatives without inferring.

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 section gives concrete routing rules: for subsequent issuance/merger conditions use get_registration_statement, for list skims use search_disclosures, and for annual report snapshots use get_periodic_report. The Usage section provides three example user intents mapped directly to corp, mode, event_type, and start, making when-to-use guidance explicit 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?

Even though annotations already mark readOnly=true and idempotent=true, the description adds substantial behavioral context: the LATEST-versus-AS-FILED distinction, cumulatve vs single-quarter semantics, the half-value trap, fs_div auto-fallback, and the fact that no_data is routing not an error. 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 long but well-structured with Purpose/Usage/Response/Rules sections, and the density of information is justified for an 8-parameter financial tool. It is front-loaded with the most important 'start here' message, though the length slightly exceeds true minimalism.

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 tool with 8 parameters, 3 enums, no output schema, and several subtle period/consolidation behaviors, the description covers invocation, response meaning, edge cases, and routing. Nothing an agent needs to call 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 100%, but the description also enriches every key parameter: corp accepts singe/array/comma-list and explains the multi-company drop; year explains auto-defaulting and year_defaulted; scope explains row counts; rcept_no explains exclusivity and the AS-FILED behavior. This is value well 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 opens with a specific verb and resource: it 조회계 data for 매출·영업이익·순이익·자산/부채/자본. It also distinguishes itself from sibling tools (get_periodic_report, get_going_concern, legacy get_xbrl), so an agent can tell exactly what this tool is 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?

Usage guidance is explicit and actionable: it states that most financial questions are answered here, gives concrete query examples mapping natural language to parameters, and names alternatives for prose reports and going-concern signals. It also clarifies when to use rcept_no vs corp+year and warns about pointless retries on no_data.

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 readOnlyHint/openWorldHint/idempotentHint/destructiveHint, lowering the bar. The description goes well beyond them: flags.consecutive_op_loss is a NUMBER not a bool, exact grade tiers, cross_check.code enumeration, null-vs-false semantics for going_concern_mentioned, and the post-fallback fs_div behavior. No contradiction with annotations (read-only judgment tool matches readOnlyHint=true; open-world null handling matches openWorldHint).

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-organized with [Purpose], [Usage], [Response], and [Rules] headers, with the purpose front-loaded. It is long, but every section earns its place — the Rules section delivers essential null/boolean and fallback semantics that materially affect correct invocation. Dense yet scannable.

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

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

Given the tool's complexity (a cross-analysis of financial figures and audit text) and the absence of an output schema, the description documents return semantics thoroughly: flag types, grade tiers, cross_check codes, null handling, and fallback behavior. Nearly everything an agent needs to call it and interpret results is present; only exhaustive flag enumeration is left implicit.

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 the schema fully documents all four parameters — baseline is 3. The description adds little beyond usage examples mapping natural-language queries to corp/year/fs_div and reiterating the fs_div fallback already stated in the schema. It reinforces usage but does not add meaning the schema already provides.

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 precise purpose: judging going-concern risk via the cross of quantitative financial indicators and audit-report mention. It also explicitly maps sibling tools to their niches (search_audit_findings for lists, get_financials for figures, get_audit_report for paragraph text), so an agent can tell this tool apart without opening other 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?

Provides concrete example queries with direct parameter mappings ('이스타코 2024 계속기업 위험 있어?' → corp, year; '별도 기준 정량 점검' → fs_div="OFS"). The Purpose section names the alternative tools and their distinct functions, giving explicit routing guidance for when this tool vs. others applies.

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/openWorldHint/destructiveHint=false, so the safety profile is covered. The description adds substantial behavior beyond that: response opinion domain (적정/부적정/의견거절, explicitly NO '한정'), that a review's 의견거절 means a scope-limited conclusion non-statement, that reports is an ARRAY yielding up to 2 entries, that present=false is usually out-of-scope not missing data, and a warning never to conflate review vs audit 의견거절. Rich behavioral context on top of good 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?

Purpose is front-loaded in the first sentence, and the [Purpose]/[Usage]/[Response]/[Rules] section headers make a dense document scannable. Every section earns its place for a complex domain. It is long and somewhat dense — the deep reference to management_operation_report.steps and the applicable=false note could be trimmed — but it is organized efficiently rather than padded.

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, and the domain is complex (연결 vs 별도, review vs audit, 의견거절 vs 한정, present=false, applicable=false). The description carries the full burden of response semantics and does so completely: opinion domain, array behavior, empty-CFS-is-normal, and the review/audit conflation warning. Nothing an agent needs to invoke and interpret the tool 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 100% and the schema itself is extremely thorough (year's fiscal-year conversion rules and floor, fs_div's CFS/OFS fallback semantics). The description adds marginal value via usage examples (corp/year mapping, fs_div='CFS' for 연결 기준만) but does not substantially expand parameter meaning beyond the schema, which already does the heavy lifting. Baseline 3 is appropriate.

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?

Opening sentence states a specific verb+resource: it queries the 'auditor's' ICFR audit/review reports (구분·의견·중요한 취약점 여부). It explicitly differentiates from siblings, routing 취약점 lists to search_audit_findings, 자금부정통제/운영실태 reports to get_attachments, structured facts to get_audit_profile, and full text to get_audit_report. An agent can tell exactly what this tool is and is not.

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/when-not guidance: 'not here → get_attachments', 'Structured facts: get_audit_profile', 'full text: get_audit_report'. Two concrete usage examples map natural-language queries to parameters (corp='카카오페이', year=2024; '연결 기준만' → fs_div='CFS'). The Rules section adds interpretation guardrails (present=false semantics, review/audit distinction) that dictate correct use.

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

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

Annotations already mark the operation as readOnly, idempotent, and non-destructive, and the description builds on that rather than repeating it. It adds rich runtime behavior beyond annotations: amounts are strings, status codes 000/013, full-array 013 flips to no_data mode, 013 can be a legitimate absence, fiscal-year alignment can differ for non-December clorders, and V2 routing is automatic for comp 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?

The content is well organized into Purpose/Usage/Response/Rules and front-loads the main action. It is dense and uses a mixed Korean-English style with some repeated 013 themes, but every section earns its place and the structure makes the complexity navigable.

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 28-section parameter, lack of output schema, and many caveats, the description is remarkably complete. It covers status handling, no-data modes, fiscal-year mapping, string formatting, array error behavior, and even compensates any auto-routing specifics needed for newer section variants.

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 the baseline is 3 even without parameter guidance. The [Usage] examples reinforce parameter selection, but the schema already defines corp, year, report, max_items, and report_type, including group aliases and allowed values; the description does not add substantial new parameter semantics beyond that.

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 first sentence states a specific verb and resource: it retrieves 28 business-report detail sections as structured data, either one section or multiple. The [Purpose] section also distinguishes it from get_financials and get_audit_profile/get_audit_report, so it is easy to tell apart from close siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes explicit usage examples mapping user requests to corp, year, and report_type, and explains what happens when year is omitted. It also names alternatives for financial-statements and auditor-opinion detail, giving practical routing guidance instead of leaving the choice 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?

Annotations already declare readOnly/openWorld/non-destructive, and the description adds substantial behavioral caveats beyond those: only the latest corrected filing is returned once corrected (originals must be fetched via search_disclosures → download_document), withdrawn filings carry no marker, empty data should not be read as 'not issued', and fetch_failed/truncated_note values mean 'unconfirmed' not 'none'. These are exactly the silent behaviors that would lead wrong conclusions.

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 into named sections (Purpose/Usage/Response/Rules) with the main purpose front-loaded in the first sentence. It is long, but each section earns its place — especially the Rules block, which contains four distinct hard-won operational warnings. It loses one point for a mild redundancy between the opening sentence and [Purpose] restating overlapping terms.

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?

Even without an output schema, the [Response] section defines the filings[] structure, the nine inner sections, ordering (newest first), date semantics (corrected filings can carry an amended date outside the requested window), and raw string values with '-' fields omitted. Combined with safety disclosures covered by annotations and a schema that documents every parameter, nothing predictable for the agent 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% and the schema itself is unusually detailed (start date = original filing acceptance date, limit cut at filing level not row level, statement_type supports single/enum/array/alias/Korean names). The description adds marginal meaning beyond that: a concrete natural-language usage example ('대한항공 유상증자 조건' → corp='대한항공', statement_type='equity') and the note that widening the date window costs nothing. Baseline 3 is appropriate because the schema does the heavy lifting.

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 verb-resource pair: the tool retrieves 6 types of key information from securities registration statements (모집·매출 조건, 인수인, 자금 사용목적, 합병·분할 조건) as structured JSON. It also differentiates itself from siblings by naming get_corporate_event, search_disclosures(kind="issuance"), and download_document as the tools for adjacent needs, so an agent can distinguish it 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 [Purpose] section explicitly routes three alternative situations: board decision → get_corporate_event, listing scan → search_disclosures(kind="issuance"), narrative/investment-risk → download_document. The [Rules] section adds the other side, stating when results must not be trusted (withdrawn filings unmarked, 사모·일괄신고서·소액공모 out of scope), leaving no ambiguity about when this tool is the right one.

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/idempotent/destructive annotations, the description discloses critical behavioral nuances: response content depends on requester identity (operator gets extra fields, public callers don't), local stdio may show total_calls>0 with unique_users=0, and error_rate uses a 0-1 decimal while share_pct is a percentage. These are non-obvious but essential for correct interpretation, making the tool much safer to use.

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 clear [Purpose], [Usage], [Response], and [Rules] sections, front-loading the core purpose. Though verbose, every section adds necessary detail for a tool with conditional behavior; a slight over-length is justified by complexity, but it could be tightened.

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 response structure, which it does thoroughly: including common fields, conditional operator-specific fields, and important rules about units and edge cases. An agent has everything needed to call the tool and 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?

The schema already fully explains the 'days' parameter (trailing window, 0=entire period, default 30). The description adds only usage examples, not new semantic meaning. With 100% schema coverage, the description's contribution here is minimal, so the baseline score of 3 is appropriate.

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 returns tool usage aggregates ('도구 사용량 집계를 반환합니다') and specifies exactly what metrics are included: per-tool call counts, popularity, latency, error rate, cache hits, and daily trends. This is distinct from sibling tools focused on financial data, audits, or documents, leaving no ambiguity about its purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The [Usage] section provides three concrete examples mapping natural language requests to parameter values: default 30 days, days=90 for recent trends, and days=0 for all-time cumulative. While it doesn't explicitly contrast with alternatives, no sibling tool serves this purpose, and the examples give clear when-to-use 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?

Annotations already show readOnlyHont true and destructiveHont false, and the description does not contradict them. It adds substantial behavioral and response semantics: *_pct are annual percentages while mrp·srp·tax_rate are decimals, close is unadjusted price, wacc_pct is null when credit rating is undisclosed, returns must be computed from flt_rt not close deltas, aggregates have varying n, and notes[] accumulate downgrades and fallacks. These are exactly the traits an agent needs beyond annotation flags.

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

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

The description is long but tightly organized under [Purpose], [Usage], [Response], and [Rules] headings, with the core selection mechanism front-loaded. Every section carries operational information; examples are concise and rules are dense but each earns its place for a 24-parameter, multi-kind 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?

For a 24-parameter tool with no output schema, the description covers argument routing, output units, null semantics, aggregation caveats, evidential citation, and note-readding. It stops short of enumerating the full response shape per kind, so an agent must infer some return fields, but the provided units and rules substantially compensate for the missing output 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?

The input schema already provides 100% per-parameter coverage with kind-scoped descriptions, so the baseline is 3. The description adds value beyond the schema by turning natural-language intents into kind/corp/ksic mappings, explaining override semantics, and clarifying output-pfield units and null behavior like wacc_pct. It does not repeat the schema, but it does help select parameter values correctly.

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+resource: it calls out that valuation data (market time series, WACC, peers) is selected by kind, and immediately differentiates from siblings by saying financials go to get_financials and KSIC/market classification to get_company_profile. This makes the tool's place among 15 siblings 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?

The [Usage] section gives two explicit intent-to-parameter mappings (e.g., '에스에프에이 최근 1년 주가' → kind='market', corp='에스에프에이'), and the [Purpose] section explicitly routes financial figures to get_financials and industry/market classification to get_company_profile. It also tells agents the tool is evidence, not adoption, so they know not to treat outputs as final conclusions.

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 mark the tool read-only, idempotent, and non-destructive. The description adds important behavioral rules beyond that: coverage.note must be read first, empty results over non-ingested scopes mean 'not seen' not 'does not exist', fs_div=both produces up to 2 rows per company, and ICFR absence semantics differ between 연결 and 별도. No annotation contradiction is present.

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

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

The description is long but information-dense and well-structured with Purpose, Usage, Response, and Rules sections. Every section earns its place: examples are actionable, the response conventions prevent misreading output codes, and the rules prevent costly misinterpretations like treating missing coverage as nonexistence.

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 tool with no output schema, this description is remarkably complete. It covers the tool's role, concrete invocation patterns, response format conventions, coverage caveats, row-count pitfalls, and ICFR-specific edge cases. The schema handles the remaining parameter detail, so nothing important 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 100%, so the schema already documents all 19 parameters; the baseline is 3. The description adds genuine value by giving parameter-usage examples, recommending fields='brief' for list/count asks, explaining multi-year arrays via coverage.years[], and clarifying fs_div row implications. It does not need to restate every parameter.

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: it finds listed companies by audit report conditions without a company name. The [Purpose] section names concrete use cases and explicitly routes detail work to get_audit_profile/get_internal_control and raw text to get_audit_report, making sibling differentiation 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?

It gives explicit when-to-use guidance: list/aggregate queries belong here, while detail and original-text queries belong to named sibling tools. Numbered examples map natural-language requests to concrete parameter values, so an agent knows exactly how to invoke it.

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 mark the tool read-only and non-destructive, so the description goes beyond them by disclosing batch behavior, 90-day chunking, the request budget of 60, counter nesting semantics, early_stopped implications, and correction-disclosure handling. This is rich behavioral context that materially affects how an agent interprets 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?

The description is long but highly structured with Purpose, Usage, Response, and Rules sections, each earning its place. For a tool with 13 optional parameters and subtle batch-mode behaviors, the density is justified and the most critical operational rules are front-loaded.

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 still explains the response codes (corp_cls, report_nm correction prefixes) and the exact meaning of counters like total_available, matched, returned, incomplete, and early_stopped. It covers the non-obvious result-interpretation traps an agent would otherwise miss, making the definition complete for correct invocation and result understanding.

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 the baseline is 3; the schema already documents each parameter in detail. The tool description adds usage examples for corp/days/preset/start/end and stresses the corp parameter's performance implications, but it does not substantially define parameters beyond what the schema already provides.

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 precise job: find rcept_no in the DART disclosure list and serve as the entry point to download_document/get_attachments. It also distinguishes itself from get_periodic_report and find_corp_code, so an agent can tell 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?

The [Purpose] section explicitly routes business-report section data to get_periodic_report and same-name company resolution to find_corp_code, giving clear when-not-to-use guidance. The [Usage] examples translate natural-language requests into concrete parameter choices, and the [Rules] section adds operational conditions such as always passing corp when a company is named.

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