MyDART

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds substantial behavioral context: preserves heading/table structure, documents[] metadata-only semantics, truncated=true handling, doc_index fallback with warning, and truncate_at clamping/division with all_docs. 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, and Rules sections. Every section adds value for a complex tool. The opening sentence immediately states the core function. Slightly verbose but justified given 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?

No output schema exists, so the description compensates by explaining response roles (main_body, separate_audit, etc.), documents[] metadata behavior, and truncation rules. It also covers edge cases like out-of-range doc_index and clamp behavior, making it complete for the tool's complexity.

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 already covers all parameters with descriptions (100%), providing baseline 3. The description adds extra meaning: explains how to use doc_index after checking documents[].role, clarifies all_docs returns all documents, and details truncate_at budget sharing. This significantly enhances parameter understanding.

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: '공시 원문 본문을 마크다운으로 읽습니다' (reads disclosure original text in markdown). It clearly differentiates from siblings by naming get_audit_report, get_attachments, and get_xbrl for other use cases.

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 guidance: '공시 텍스트 전문이 필요할 때' (when full disclosure text is needed), and alternatives are stated for audit analysis (get_audit_report), attachments (get_attachments), and XBRL (get_xbrl). Also provides concrete usage examples with rcept_no and doc_index.

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, idempotentHint=true, and destructiveHint=false. The description goes well beyond this by explaining that results are similarity-ranked (first item is not authoritative), count is capped by limit, 0 hits add a hint, stock_code presence indicates listing status, and that corp_code is a legal entity code not a ticker. 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 well-organized with clear sections ([Purpose], [Usage], [Response], [Rules]) and is front-loaded with the core purpose. Every sentence adds useful information; there is no filler or redundancy.

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

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

For a simple lookup tool with no output schema, the description fully covers input forms, response semantics (count, hint, stock_code field), candidate ranking behavior, and edge cases like unlisted companies and common-name overflow. It also positions the tool among its siblings. 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% and both parameters are clearly described in the schema. The description adds value by giving example query forms ('005930' as query), explaining how limit interacts with common-name overflow, and noting the meaning of stock_code in responses. A small improvement over schema 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?

The first sentence clearly states the tool's purpose: finding DART corp_code candidates by company name or stock code. It distinguishes itself from siblings by explicitly directing users to get_company_profile for industry/data location and search_disclosures for disclosure lists.

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 provides explicit when-to-use instructions ('corp_code를 모르는 기업 조회 시 이 도구를 먼저 사용합니다'), covers ambiguity cases, and names the alternative tools for different needs. The [Usage] examples further clarify concrete invocation scenarios.

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 rate-limit risks (DART IP block), a hierarchical markdown reliability assessment (is_image_based, char_count, high_pua, needs_ocr, ocr_candidate_pages, image_only_pages), the supported:false replacement path, and differences between viewer JPEG and PDF-scan image routes. These are substantial operational traits that annotations do not convey.

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

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

The description is lengthy but well-sectionalized into Purpose, Usage, Response, and Rules, with dense, relevant content. It front-loads the core purpose and then provides detailed guidance without filler, though some redundancy with schema descriptions exists. The structure makes it easy to navigate despite being long.

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?

Since there is no output schema, the description compensates by summarizing response fields (format, text_quality) and the supported:false fallback path. It also covers edge cases like scanned-only content, ZIP inner files, outline limits, and gives a trust hierarchy for markdown, making it a thorough self-contained reference.

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

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

With 100% schema coverage, the input schema already documents all parameters thoroughly. The description adds workflow-level context, such as obtaining dcm_no via list, choosing mode based on content type, and file precedence in extract mode, which enriches parameter understanding beyond the schema's individual 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 opening sentence clearly states that get_attachments handles attachments (HWP/PDF/DOCX/XLSX) and sibling documents via list, extract, and image modes. It explicitly contrasts with download_document for body text, and singles out specific document types (자금부정통제, 운영실태보고서) that belong to this tool, making the purpose unambiguous and well-differentiated from 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 explicitly says download_document is better for body text, while get_attachments is for attachment originals. It also gives concrete usage examples (mode=text for 본문·표, attachment_links[].retrieve for 붙임) and warns against consecutive traversal of multiple disclosures due to IP blocking, providing clear when and when-not 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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context beyond these: how to interpret data_available=false (not confirmed absent), audit_only=true (structural absence of fees), the need to read applicability.guidance[], and the explicit note that auditor change is not returned. It also explains response conventions like '_m' suffix and opinion domain.

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], and [Rules] sections. The opening sentence summarizes the tool in one line, and each subsequent section provides necessary detail without redundancy. It is not minimal, but the length is justified by the complexity of the domain and the absence of an 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 the tool has 4 parameters, no output schema, and a domain with many edge cases, the description covers response interpretation (fees unit, opinion domain), exceptional states (data_available=false, audit_only=true), and routing guidance (applicability.guidance, next-tool recommendations). It misses no critical aspect for a read-only summary tool and compensates well for the lack of an 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?

Schema description coverage is 100%, so the burden on the description is lower. Nevertheless, the description adds concrete examples for corp/year, explains the effect of light=true (skips parsing, omits certain fields) in a usage example, and provides rules that clarify how parameters map to user intents. It does not add much beyond the schema's already detailed year description, but the examples and light=true clarification are useful.

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 the tool returns a summarized table of audit details (auditor, opinion, fees, hours, site visit, external inquiry) with a specific verb '반환합니다' and explicitly distinguishes it from sibling tools (get_audit_report for full text, get_internal_control for ICFR, get_going_concern, search_audit_findings). This makes the purpose clear and differentiated.

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 provides explicit when-to-use guidance: it is optimal for factual/numeric questions like '누가 얼마에 감사했고, 실사는 어땠나', and explicitly routes to alternatives when full text, ICFR, or going concern checks are needed. The [Usage] section gives concrete examples mapping natural language queries to parameter values, and [Rules] clarifies edge cases (not-yet-filed, unlisted companies) and when not to use the tool.

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 this as read-only/idempotent/non-destructive, the description adds substantial behavioral details: response section keys, fs_label and source_note/correction_note semantics, the kam.count=0 + none_declared interpretation rule, and the unlisted-F-filing exception. It also clarifies that financial figures are intentionally excluded, which is useful non-obvious behavior. 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 longer than the minimal two-sentence ideal but is well structured with [Purpose], [Usage], [Response], and [Rules] sections. The main purpose is front-loaded, and each section contains non-redundant, actionable information. It is appropriately sized for a tool with six parameters and complex Korean audit-report semantics.

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

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

The description is complete for a read-only retrieval tool with no output schema: it explains response structure, important special cases (unlisted filings, none_declared), truncation handling, and when to use alternative tools. The schema covers parameter details, so the description fills the remaining conceptual and interpretive gaps effectively.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value through concrete usage examples mapping requests to corp, year, fs_div, and truncate_at, and it clarifies that 'both' yields two report entries while also showing how fs_div='OFS' is used. This goes slightly beyond the schema by illustrating realistic invocation patterns.

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 returns audit report body text structured paragraph-by-paragraph, covering opinion, basis, KAM, emphasis, other matter, and going concern. It distinguishes itself from sibling tools by explicitly naming get_audit_profile for formal fact summaries and get_internal_control for ICFR, so the purpose is unambiguous.

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 explicit when-to-use guidance: narrative paragraph original text vs. formal fact summaries (get_audit_profile) vs. ICFR consistency checks (get_internal_control). It also tells the user that financial figures belong to download_document, and the [Usage] examples map natural-language requests to concrete parameter values.

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 and idempotentHint=true, but the description goes far beyond by explaining data_location categories (listed, listed_konex, unlisted_reporting, audit_only, etc.) and their behavioral implications. It discloses that listed_konex returns empty get_financials/get_xbrl as NORMAL, and warns that provisional=true results are tentative and one should never conclude 비외감 from no_discovery_found. 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 well-structured with clear sections: Purpose, Usage, Response, Rules. Each sentence earns its place: examples are terse, response fields are explained concisely, and rules are actionable. Despite its length, every part adds essential routing or behavioral context. There is no redundancy or 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?

The tool has 2 parameters, no output schema, but meaningful routing behavior and edge cases. The description covers the response structure (data_location, corp_cls, acc_mt), the full set of data_location possible values, follow-up routing rules, and caveats about provisional queries and listed_konex behavior. It is complete for an agent to invoke this tool correctly and interpret its results in the broader MCP tool ecosystem.

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 provides 100% coverage for both parameters (corp and year) with detailed descriptions. The description adds value by providing concrete example values and explaining the year parameter's routing significance: 'year... Matters only for 비상장사... For non-December closers this year follows the 시작연도 convention shared with the audit tools...' It also introduces the 'provisional=true' concept not fully spelled out in the schema. However, since the schema does most of the heavy lifting, a 4 rather than 5 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 opens with a clear statement: '기업개황(업종·대표자·결산월·상장구분)과 데이터 위치(data_location)를 조회합니다' — a specific verb (조회) and resource (company profile fields). It also explicitly distinguishes from siblings: '감사인·감사의견·감사보수는 get_audit_profile, 회사 지정이 모호해 후보부터 골라야 하면 find_corp_code.' This is more than sufficient for an agent to identify the tool's purpose.

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

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

The 'Purpose' section explicitly states when to use this tool: first call before financial/audit tools for unfamiliar companies, especially unlisted ones. It also provides concrete usage examples ('"카카오는 뭐 하는 회사야?" → corp="카카오"') and rule-based routing to alternatives (get_audit_profile, find_corp_code). The 'Rules' section further clarifies when NOT to retry or draw conclusions, offering explicit usage boundaries.

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

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

Annotations already mark readOnlyHint=true and destructiveHint=false, so the description adds substantial behavioral nuance beyond that: date fields represent filing date not event date, total_count is cumulative while filtered_count is period-scoped, empty timeline does not mean no events, sections_meta can carry endpoint errors, and event_type_counts are pre-truncation. 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?

Despite being long, the description is tightly organized with [Purpose], [Usage], [Response], and [Rules] sections. Every sentence adds operational value—examples, caveats, or count semantics—with no redundant restatement of schema fields.

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 high complexity (7 params, 38 enum values, no output schema), the description is fully complete: it covers purpose, usage conditions, concrete examples, response field interpretation, error caveats, and limit behavior. The openWorldHint is also well-supported by explaining that empty timeline doesn't necessarily mean absence of events.

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 goes far beyond schema labels by explaining mode=single vs timeline semantics, event_types aliases ('capital', 'holdings'), limit truncation behavior with truncated=true, start defaulting to 3 years ago, and period.defaulted flag. The examples map natural-language requests to actual 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 a precise resource scope: 주요사항보고서 자본·지배구조 이벤트 36종 plus 5%룰 and 임원 지분공시. It explicitly contrasts with sibling tools search_disclosures and get_periodic_report, making the tool's unique function 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 [Purpose] section states exactly when to use the tool: for a single event detail or an integrated timeline of capital changes, and also tells when not to use it (search_disclosures for browsing disclosures, get_periodic_report for snapshots). Concrete examples in [Usage] further illustrate correct invocations.

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/destructiveHint, and the description adds substantial behavioral context beyond that: amounts are strings, cumulative vs quarter-alone amounts, period off-by-one traps, no_data routing semantics, scope=full single-company restriction with warning field, and fs_div auto-fallback. 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?

Structured with Purpose/Usage/Response/Rules sections, example queries, and compact bullet points. Dense but every line earns its place; 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?

For a complex financial-data tool with no output schema, the description covers response shape (row keys, string amounts, count semantics), common data traps (cumulative vs quarterly, period off-by-one), and routing fallback. It is sufficient for an agent to select, invoke, 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?

Schema coverage is 100%, but the description adds extensive meaning beyond the schema: half-value trap for thstrm_add_amount vs thstrm_amount, scope=full exact-1 constraint and dropped-rest warning, fs_div echoes actual basis and may auto-fallback, sj_div default includes CIS due to single-statement presentation. These nuances are not present in the input schema.

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

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

Description clearly states it retrieves financial figures (매출·영업이익·순이익·자산/부채/자본 등 재무수치를 조회합니다) and explicitly positions itself as the first choice for financial questions. It distinguishes from siblings by naming get_xbrl, get_periodic_report, and get_going_concern for specific alternative use cases.

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 explicit when-to-use guidance: '재무 질문 대부분은 이걸로 충분합니다' and states to use get_xbrl only for calculations/XRBL/original files, get_periodic_report for narrative, and get_going_concern for distress. Includes concrete natural-language examples mapping to parameter values.

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?

Goes well beyond annotations by explaining that flags.consecutive_op_loss is a count (not bool), grade mapping, cross_check.code meanings, and the interpretation of null vs false for going_concern_mentioned. Also discloses fs_div fallback behavior (CFS request may return OFS). This is rich behavioral context not available in 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 sections (Purpose, Usage, Response, Rules) and front-loaded purpose. It is thorough without being disorganized, though some repetition exists (e.g., mentioning '계속기업 위험 있나' twice). Overall it earns its length given tool 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?

Despite no output schema, the description fully explains the response structure (flags, grade, cross_check.code) and critical interpretation rules (null≠false, quant_only two cases, 판정불가≠양호). This makes the tool fully understandable and actionable without additional documentation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a bit of extra context (e.g., fs_div fallback, example usages) but mostly relies on the already-detailed schema. It does not substantially enhance parameter meaning beyond what schema 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?

Description clearly states the tool judges going-concern risk via the intersection of quantitative financial metrics and auditor report mentions. It names specific sibling alternatives (search_audit_findings, get_financials, get_audit_report) that serve related but distinct purposes, distinguishing it from 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?

Provides explicit when-to-use guidance ('계속기업 위험 있나', especially discrepancies), plus explicit alternatives for other tasks (search_audit_findings for company lists, get_financials for numbers, get_audit_report for original paragraphs). Includes concrete usage examples with parameter values.

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 annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses critical behavioral subtleties: reports is an array with up to two entries, present=false usually means out-of-scope rather than missing data, and a review's 의견거절 must not be conflated with an audit's. It also notes ICFR fallback behavior for 별도 and that 자금부정통제 is not part of the auditor's report, adding substantial context beyond what annotations convey.

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 typical but well-structured with [Purpose], [Usage], [Response], and [Rules] headers. Every sentence adds value—covering use cases, response semantics, and caveats—and the opening sentence is a clear, front-loaded summary. Minor verbosity exists (e.g., detailed year guidance is in the schema), but the overall organization keeps it 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?

For a tool with no output schema, the description compensates thoroughly: it explains the opinion domain, the array structure, the present=false convention, and the review/audit distinction. It also addresses limitations (자금부정통제, CFS applicability) and cross-references related tools, giving the agent everything needed to use the tool correctly 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 description coverage is 100%, so the baseline is 3. The description adds usage examples mapping params to queries and clarifies fs_div semantics (e.g., '연결 기준만' → fs_div="CFS"), but the schema already thoroughly explains year and fs_div meanings. No genuinely new parameter semantics are introduced.

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 clear statement: "get_internal_control 도구는 '감사인'의 내부회계관리제도(ICFR) 감사/검토 보고서를 조회합니다 — 구분·의견·중요한 취약점 여부." This specifies the exact resource (auditor's ICFR reports) and the data returned (opinion, vulnerabilities). It also explicitly contrasts with sibling tools such as search_audit_findings, get_audit_profile, and get_audit_report, making the tool's unique purpose unmistakable.

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

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

The [Purpose] section explicitly states when to use this tool ('ICFR 의견·취약점을 재무제표 감사의견과 대조할 때') and when not to, directing users to get_attachments and search_disclosures for 자금부정통제 and management reports, and to get_audit_profile/get_audit_report for other audit facts. The [Usage] section provides concrete query-to-parameter mappings (e.g., '카카오페이 2024 내부회계 의견' → corp="카카오페이", year=2024).

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 declare readOnly/idempotent/destructive hints. The description adds substantial behavioral context: amounts are strings, status codes 000/013, periods legend mapping, per-element status in arrays, no_data routing, and the fact that 013 for listed companies usually means legitimate absence rather than failure. This goes well beyond the structured fields.

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], and [Rules] sections, front-loaded with a concise summary. Every bullet contributes non-obvious guidance (e.g., 013 semantics, fiscal year alignment rules, array mixing) and the length is justified by the tool's 28-section 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?

Even without an output schema, the description explains critical return semantics: string amounts, section status codes, periods legend, array element status, no_data routing, and citation rules. Combined with comprehensive sibling references and a rich input schema, the description fully prepares an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds concrete usage examples (corp='삼성전자', report_type='dividends') and reinforces the meaning of omitted year and group aliases, but most semantic detail is already present in the schema's parameter descriptions. The examples add clarity without introducing new parameter-level facts.

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 statement: it queries 28 types of business report detail sections as structured data, one or multiple sections at once. It also explicitly routes financial statement figures to get_financials and auditor details to get_audit_profile/get_audit_report, clearly distinguishing it from 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 [Purpose] section states exactly when to use this tool (for section tables like dividends, treasury stock, shareholders) and when to use alternatives (get_financials for financial statements, get_audit_profile/get_audit_report for auditor details). Concrete example queries in [Usage] show how to map user intents to parameters, leaving no ambiguity.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses critical behaviors: identity-dependent response differences (public vs operator), the local stdio quirk where total_calls can be >0 while unique_users=0, and the unit distinction between error_rate (0-1 decimal) and share_pct (percentage). This level of detail is highly valuable for an agent.

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-organized with clear [Purpose], [Usage], [Response], and [Rules] sections. Each section adds distinct value—purpose, examples, response shape, and caveats—without redundancy. The length is justified by the complexity of the identity-dependent behavior and unit conventions.

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

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

Given the tool has no output schema and involves identity-dependent response variations, the description thoroughly covers the response structure (period, overview, by_tool, by_day) and explicitly warns about public vs operator data restrictions. It also clarifies edge cases (local stdio unique_users=0) and unit formats, making it complete for an agent to invoke 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% for the single 'days' parameter, so the baseline is 3. The description adds meaning by explaining the semantics of days=0 as 'entire retained period' and providing concrete examples (default 30, 90-day rank), which enhances understanding beyond the schema's simple 'Trailing window in days'.

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 aggregation ('도구 사용량 집계를 반환합니다') and specifies the metrics: call counts, popularity rankings, response times, error rates, cache hits, and daily trends. This distinguishes it from sibling tools which focus on documents and financial data, making the purpose unambiguous.

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 concrete usage examples with parameter values ('최근 90일 도구별 순위' → days=90, '전체 기간 누적' → days=0) and notes the default window. It also explains when the tool is appropriate (viewing usage stats) but does not explicitly mention alternatives or exclusions, which is acceptable given the unique functionality.

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

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

Discloses behavioral traits far beyond the readOnly/idempotent annotations: all components can be overridden, wacc_pct is null when no credit rating is disclosed rather than assumed, n varies per metric (EBITDA often missing), peers is a curated candidate list with prefix depth dilution, and notes[] must always be read. These are material operational details that affect how the 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 longer than average, but every section (Purpose, Usage, Response, Rules) carries essential information for a tool with 24 parameters and 3 modes. It is front-loaded with the core statement, uses headers, and the Rules section is a dense checklist of non-obvious operational requirements.

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 description completes the picture by specifying response semantics (units, null behavior, source/as_of verbatim citation, notes accumulation) and edge-case handling (peer count relaxation, argument errors). It is sufficient for an agent to select, invoke, and interpret this complex tool.

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

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

Schema covers 100% of 24 parameters with rich descriptions, so the baseline is 3. The description adds value by clarifying unit conventions (*_pct vs decimals for mrp·srp·tax_rate), the close vs flt_rt distinction, and the warning never to compute returns by differencing close. That is meaningful semantic guidance 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 clear verb+resource statement: 'get_valuation_data 도구는 가치평가 데이터(시장 시계열·WACC·유사회사)를 kind 로 골라 조회합니다.' It then enumerates three concrete use cases (시세·β 검산, WACC 산출, 피어 비교) and explicitly distinguishes itself from get_financials and get_company_profile.

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 explicit guidance on when to use: '재무수치는 get_financials, 업종(KSIC)·시장구분은 get_company_profile' and includes two worked usage examples mapping natural-language requests to kind and corp arguments. This gives the agent clear decision rules versus 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?

The description discloses key behavioral quirks beyond annotations: validations_checked=0 means nothing was checked, fs_div_auto semantics, 주석 XBRL not parsed, and no_data is not an error. These are not inferable from annotations and save the agent from misinterpreting responses.

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 sections (Purpose, Usage, Response, Rules) and front-loaded with the core function. No filler; every sentence carries meaningful guidance for a complex tool.

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

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

With no output schema, the description covers response semantics, error conditions, and fallback paths. It explains limitations (CIS/SCE unsupported), raw file access only in local mode, and directs to sibling tools for unsupported cases.

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. The description adds usage examples that illustrate param combinations (fs_div='OFS', sections=['BS'], format='raw') but doesn't add new per-parameter semantics 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 starts with a clear verb-object statement: parses XBRL attached to disclosures, builds financial statements, and performs aggregation validation. It explicitly contrasts with get_financials (wider and faster for simple figures) and states the BS/IS/CF-only limitation, distinguishing it from 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?

Explicit when-to-use and when-not-to-use guidance: says use when you need 합산 검증 or raw XBRL, but for simple figures use get_financials(scope=full). Usage examples provide concrete parameter configurations and mention download_document for non-XBRL parts.

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 indicate readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context: empty results over non-ingested scopes mean 'not seen' rather than 'does not exist', fs_div=both yields up to 2 rows per company requiring corp_code deduplication, breakdown is a population baseline that ignores only finding filters, and ICFR note placement rules. These go far beyond the annotation hints and significantly improve safe usage.

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

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

The description is lengthy but well-structured with [Purpose], [Usage], [Response], and [Rules] sections. Every sentence carries significant information for an 18-parameter tool, though a slightly more compact presentation might be possible. It earns its length through high information density.

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

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

Despite lacking an output schema, the description covers response enums (market Y/K/N, fs_div KOREAN values), empty-result semantics, deduplication requirements, breakdown interpretation, and ICFR edge cases. It provides a self-sufficient reference for an 18-parameter tool with no structured output documentation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description compensates with group-level semantics not present in individual parameter docs: row count vs company count under fs_div=both, breakdown filter semantics, and alias acceptance (한글 values). This adds meaningful meaning beyond the schema.

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

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

The description opens by stating the tool 'finds listed companies by audit report conditions without specifying a company' (회사를 지정하지 않고 감사보고서 조건으로 상장사 목록을 찾습니다). It also explicitly distinguishes itself from sibling tools by noting that individual company details belong to get_audit_profile / get_internal_control and full text to get_audit_report. This is a specific verb+resource with clear sibling differentiation.

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 query-to-parameter mappings (e.g., 'FY2024 코스피 의견거절 회사' → year=2024, market='kospi', opinion='disclaimer') and explicitly states the tool is for list/aggregation questions, while individual company details are the domain of other tools. This provides clear when-to-use and when-not-to-use guidance.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses critical batch behavior: counters nesting (total_available ≥ total_fetched ≥ matched ≥ returned), early_stopped lower-bound semantics, and preset mode dropping 정정공시 by default. It also reveals performance characteristics ('1 request (152× measured)') and the meaning of corp_cls codes, giving the agent a clear model of execution side effects.

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 clear sections ([Purpose], [Usage], [Response], [Rules]). It front-loads the primary purpose and examples. While some performance details repeat the schema's corp parameter description, the overall format makes dense information easily scannable and every section earns its place.

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

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

For a tool with 13 parameters and no output schema, the description provides a thorough behavioral contract: response field meanings (corp_cls, report_nm prefixes), mode-dependent shapes, counter relationships, and early_stopped implications. It also covers parameter selection guidance (when to use days vs start/end, preset vs all_pages) making it sufficiently complete 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?

Even though schema coverage is 100%, the description adds essential meaning beyond parameter comments. The [Rules] section clarifies how limit interacts with matched/returned cutoffs and that early_stopped means matched is a lower bound. It explains the difference between page mode and batch mode row shapes, and that final_only drops 구본 when a 정정 exists, which is not fully captured in the schema.

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

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

The description clearly states the tool's purpose: 'search_disclosures 도구는 DART 공시 목록에서 접수번호(rcept_no)를 찾습니다' and identifies it as the entry point for download_document/get_attachments. It differentiates from siblings by explicitly pointing to get_periodic_report for structured business report data and find_corp_code for entity disambiguation.

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 explicit when-to-use guidance: '회사·기간·공시유형으로 공시를 찾을 때' and when-not-to-use: '사업보고서 섹션의 정형 데이터는 get_periodic_report'. It also provides concrete usage examples for '삼성전자 최근 한 달 공시' and '작년 유상증자 결정 회사 전부', plus a rule to use find_corp_code when company names overlap.

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