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

With no annotations, the description carries the full burden and does well: it explains what the tool returns (violation status, exemption paths, recommendations with cited provisions), how it uses originalDeadline to calculate golden time and mitigation schedules, and that exemptions are discretionary judgment material. It also notes local rule behavior without needing an API key.

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 an intro paragraph and four bullet points, each covering a distinct behavioral aspect. Every sentence adds substance, with no 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?

Given no output schema and no annotations, the description adequately explains return values and behavior: it lists the output types (violation status, exemption paths, recommendations, schedules) and the special path for transaction_changed. It also notes the discretionary nature of exemptions, making it complete for a diagnostic 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?

The schema already covers 100% of parameters with descriptions. The description adds value by explaining how errorType maps to violation/exemption logic and how originalDeadline triggers additional calculations, plus the special transaction_changed case. It also references crossConfirmable and newlyDesignatedWithin30d via exemption path names.

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

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

The description clearly states the tool diagnoses correction disclosure risk based on the penalty notice, explaining it evaluates whether the original disclosure constitutes a violation and returns exemption paths and recommendations. This distinguishes it from siblings like find_precedents or check_disclosure_duty by focusing specifically on correction risk.

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

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

The description implies when to use the tool (to assess whether a correction incurs a penalty) and provides specific guidance for transaction_changed, stating it is not a correction but a new disclosure obligation. However, it does not explicitly compare to sibling tools or state when not to use 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?

No annotations are provided, so the description carries the full burden. It is exceptionally transparent: it discloses the output payload (delay days, penalty, golden-time status, basis), the 'candidate not confirmed' caveat, exclusion of correction filings, separate classification of special financial-transaction forms, range_too_large handling, permanent cache behavior, and auth requirements. This goes far beyond what an agent could infer from the schema.

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

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

The description is compact and well-structured: a single lead sentence defines the core function, followed by five focused bullet points that each add a distinct, non-redundant caveat. Every sentence earns its place with no filler 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 complexity of a date-range audit tool with six optional/required parameters and no output schema, the description is remarkably complete. It covers input selection logic, the audit method, expected output fields, special-form handling, corrections exclusion, range-limit feedback, caching, and auth requirements, giving the agent a full mental model.

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 describes all parameters at 100% coverage, so the baseline is 3. The description adds meaningful semantics by explaining that group and companies are mutually exclusive selectors with one required—a constraint not reflected in the schema's required array. It also links today to the golden-time calculation and clarifies that from/to are receipt-date based, adding value over the schema alone.

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

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

The description opens with a specific verb (감사해) and resource (대규모내부거래(J001) 공시), clearly stating it audits disclosures to find deadline-delay candidates. It distinguishes the tool from siblings by describing the exact comparison method (receipt date vs. board resolution date) and the listed/unlisted business-day thresholds.

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 makes the intended context clear: audit J001 disclosures for a business group or company list over a date range. It also flags prerequisites such as EGROUP_API_KEY and warns that unjoined coverage companies are omitted. However, it does not explicitly name alternative tools or state when not to use it, stopping short of full 'when vs. alternatives' guidance.

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

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

With no annotations, the description carries full burden and does so thoroughly: it discloses local data/no auth key, warns that legal amendments change holidays, explains Workers' Day divergence, and states that missing/unverified data produces warnings that should prevent the agent from asserting results. It also mentions the result includes skipped non-business days and legal basis clauses.

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 ideal but front-loads the core function in the first sentence and organizes warnings and behavior into clear bullets. Each sentence adds meaningful operational context, so it remains efficient despite its length.

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

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

For a 4-parameter tool with no output schema and no annotations, this description covers return contents (skipped days, legal basis, warnings, notes), data-source caveats, and sibling division of labor. It is complete enough for an agent to invoke and interpret results safely.

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 already documents all four parameters with examples. The description only reiterates general support for N-business-day/N-calendar-day calculations and adds no parameter-specific semantics 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?

Description declares '한국 영업일·공휴일 기준의 날짜 계산을 담당합니다' and enumerates concrete functions: checking a date, adding N business/calendar days, and counting remaining business days. It also distinguishes itself from sibling check_disclosure_duty by delegating disclosure-type deadline determinations.

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

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

Explicitly instructs to call this tool for any date question involving deadlines/business days/holidays because model calendar knowledge may be outdated. It also provides exclusion guidance: check_disclosure_duty handles deadline determinations for specific disclosure types, including legal basis.

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

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

With no annotations, the description carries the full burden and does so well: it states no external API/auth is needed, results always include 근거 조문/계산식, missing data yields insufficient_data instead of estimation, and incorrect amountBasis can flip the determination. These are important non-obvious behaviors beyond the schema.

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

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

The description is three compact paragraphs, front-loaded with purpose, followed by authentication behavior, output characteristics, and a critical warning. Every sentence adds value with no padding, and the warning emoji improves scannability.

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 23-parameter tool with no output schema, the description covers essential operational context: auth-free execution, output composition, missing-data behavior, and a critical parameter that can invert results. It doesn't exhaustively address every edge case, but the highly detailed parameter descriptions in the schema compensate.

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 baseline is 3. The description adds cross-parameter value by explaining the insufficient_data consequence for missing totalEquity/paidInCapital and directs users to get_financials. It also highlights amountBasis pitfalls with concrete examples, enriching the schema's per-parameter notes.

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

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

The description clearly states the tool's function: '공시의무 대상 여부를 판정하고 공시기한·지연 시 예상 과태료를 계산합니다' (determines disclosure obligation and calculates deadline/penalty). This uses a specific verb and resource, and the focus on diagnosis distinguishes it from sibling search/read/audit 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?

Explicit guidance is given for a key scenario: '자본총계·자본금이 없으면 ... get_financials 로 재무수치를 먼저 조회하세요' (if capital figures are missing, first look up financials via get_financials). It also warns about amountBasis. However, it doesn't provide when-not-to-use guidance for other sibling diagnostic tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains that only document-internal consistency is checked, not underlying accounting truthfulness, and warns that include_generic_totals may produce false positives due to merged-cell tables. It also describes the unit-error hint behavior, demonstrating transparency about how the tool operates.

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 efficiently structured: an opening sentence states the main purpose and importance (84% of violations are J004), followed by a clear bullet list of capabilities, a limitation caveat, and cross-references to other tools. Every sentence adds value with no filler.

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

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

For a complex tool with four parameters and no output schema, the description comprehensively covers purpose, usage scenarios, limitations (internal consistency, false positives), parameter behavior, and integration with assess_correction_risk. It provides sufficient context for an agent to decide when and how to invoke the tool, including how to interpret results indirectly through the max_issues parameter.

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% with detailed descriptions for all parameters (e.g., compare_rcept_nos explains unit matching, include_generic_totals explains experimental nature and risks). The description reinforces these points but does not add substantial new meaning beyond the schema, so the baseline 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's purpose: it recalculates all mechanically re-calculable items in J004 corporate group status disclosures to find inconsistencies. It specifies the scope (financial status checks, unit error hints) and distinguishes itself from other tools by noting it only checks internal consistency and recommending assess_correction_risk for correction decisions.

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

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

The description explicitly states when to use it: for pre-submission self-check or post-submission inspection. It also provides guidance on alternatives, noting that it does not judge truthfulness and should be used with assess_correction_risk for correction. The bullet points explain trade-offs for parameters like include_generic_totals and compare_rcept_nos, giving clear usage context.

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

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

With no annotations, the description carries the full burden. It discloses download consumption per precedent, caching of already-read disclosures, corrected-final basis, and the lookback_days early-stop behavior with coverage confirmation. These are meaningful behavioral traits 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 a compact intro followed by five tight bullet points, each addressing a distinct aspect (search scope, filters, versions, cost, lookback). No filler or repetition—every sentence 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?

Despite no output schema and no annotations, the description covers return format (markdown with table structure), resource consumption, data scope (J001 default, presets), and explicitly distinguishes from sibling search_disclosures. For an 8-parameter tool, this is complete and self-sufficient.

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 contextual value: it explains preset defaults, corp_cls meaning ('same listing class'), exclude_corp usage, and count's download cost, which enriches the schema descriptions without being redundant.

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 precise purpose: answers 'how did other companies write this item' and details the mechanism (keyword search, company-dedup, returns original markdown text). It also distinguishes itself from search_disclosures by stating it uses corrected final versions for reference, not delay judgment.

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 explicitly says to use search_disclosures for delay judgment, naming the alternative. It also provides concrete usage context: default preset internal_transaction, filtering with corp_cls and exclude_corp, and lookback_days behavior, all of which guide when and how to use this 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It fully discloses the auto-fallback from consolidated to separate statements, the exact value formats (raw/value/display), the meaning of 'change' (period-over-period, cumulative for income/cash flow), and the limitation regarding non-audited companies. This goes well beyond mere operational description and provides deep insight into expected behavior.

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

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

The description is longer than typical but every bullet point adds meaningful information: defaults, cross-tool compatibility, value formats, change semantics, and limitations. It is well-structured with a clear opening sentence followed by value-adding bullets. Slightly verbose, particularly the key_metrics cross-reference which could be seen as specialized, but overall concise for 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 tool with 7 optional parameters, no output schema, and no annotations, the description is remarkably complete. It covers default behaviors, fallback logic, output structure, change basis, and validation caveats. The only omission is a detailed return schema, but the description provides enough about value formats to compensate. The cross-tool references also situate it well within the broader toolset.

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?

Input schema coverage is 100% and parameter descriptions are already detailed (e.g., unit, fs_div, statement all have defaults and explanations). The description mostly repeats schema information (e.g., fallback for fs_div, default year) rather than adding new parameter-level meaning. It does add context about how output values relate to parameters (unit conversion) but this is not substantial enough to raise the score above the baseline for full schema coverage.

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

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

The description opens with a clear and specific verb+resource statement: '단일회사 재무제표를 조회합니다' (retrieves single-company financial statements). It distinguishes itself from siblings by emphasizing '단일회사' (single-company), contrasting with get_group_structure which handles group financials. The default (most recent annual report's balance sheet) and fallback behavior further clarify the tool's exact scope.

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

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

The description provides explicit guidance on when to use this tool and when not to. It states that companies not subject to external audit may not have DART financials, and directly recommends using get_group_structure(include_financials=true) for conglomerate subsidiaries. It also connects key_metrics output to check_disclosure_duty inputs, giving concrete cross-tool usage context.

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

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

With no annotations, the description carries the full burden and discloses key behaviors: EGROUP_API_KEY requirement, annual May 1 data refresh with yearly caching, DART join constraint (법인등록번호, not name), naming convention (에스케이 not SK), and financial units in KRW. These are non-obvious traits that materially affect tool invocation and output 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 each sentence adds value: core purpose first, then critical caveats and cross-references. Bullet points break down complex details efficiently. Not as lean as the TDQS 4.3 example, but no filler 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 5-parameter tool with no output schema and no annotations, the description covers essential context: data source freshness, join limitations, API key requirement, and usage in compliance workflows. It could be more explicit about exact return structure (e.g., field names for overview), but it gives sufficient operational guidance for an agent to select and call the tool 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 coverage is 100%, so baseline is 3, but description adds significant semantics beyond schema: notes group name/code format, explains compact for token reduction, details join_dart fallback behavior, and maps include_financials fields to check_disclosure_duty inputs. The main gap is lack of exact output field names for the base response, but the description enriches each parameter meaningfully.

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

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

The description clearly states it returns the overview (동일인·대표회사·소속회사 수) and all subsidiaries for FTC-designated corporate groups, with a specific verb "돌려줍니다". It distinguishes itself by emphasizing the subsidiary list as the population for FTC disclosure obligations, separate from sibling tools like get_financials or resolve_entity.

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: include_financials output can be directly used as inputs for check_disclosure_duty, and unresolved DART joins should be supplemented via resolve_entity(fetchJurirNo=true). It also notes annual data refresh timing, which helps determine when to use this tool for periodic compliance checks.

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

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

With no annotations, the description fully carries the burden. It discloses caching behavior (permanent, immutable), board_date extraction for reuse in check_disclosure_duty, and the HWP-only error case (body_unparsable + viewer URL). These go beyond schema basics and are highly actionable.

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?

One lead sentence plus four bullets, each covering a distinct behavioral aspect with no redundancy. It is slightly longer than absolute minimum but every sentence earns its place, and the bullet structure improves scannability.

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, so the description covers return behavior: markdown tables, truncation via max_chars, and the HWP error path. It doesn't enumerate every possible return field, but for a raw-text-read tool this is sufficient. The board_date integration note adds extra practical value.

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 rationale for force_refresh (disclosures are immutable) and reinforces the format distinction (markdown preserves tables), but most parameter meaning is already 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 it returns the full disclosure text as markdown-preserving tables. The verb '읽기' (read) with resource '공시 원문' (disclosure full text) is specific and distinguishes it from siblings like search_disclosures (search) and find_precedents (precedents).

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 explicitly states when to use: '다른 회사의 기재 사례·문안을 참고하거나 공시 내용을 분석할 때 사용하세요' (use when referencing other companies' filing examples or analyzing disclosure content). It does not name explicit alternatives or exclusions, but the use context is clear.

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

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

With no annotations, the description carries the full burden and excels: it discloses ambiguous results (status="ambiguous" with candidates), the need to re-call with corp_code, API call costs for fetchJurirNo (1 DART call) and includeGroup (~103 portal calls first time), the EGROUP_API_KEY requirement, and 1-year caching. This is rich, honest behavioral context.

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

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

The description is longer than two sentences but every sentence earns its place—purpose, usage positioning, caveat, and parameter-specific side effects. It is well-structured and front-loaded with the core functionality, though the parenthetical examples make it slightly dense.

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 5 parameters, no output schema, and non-trivial external API behavior, the description covers everything needed: input types, output fields, ambiguity resolution, auth requirements, call costs, and caching. It even mentions status="ambiguous", which hints at the return structure. The only minor gap is the explicit success response shape, but the described fields are sufficient.

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% with each parameter described, so baseline is 3. The description adds meaningful context beyond schema: it explains why fetchJurirNo is needed for portal integration, quantifies the call cost of includeGroup, and describes the ambiguity behavior tied to the query parameter. This added semantic depth justifies a 4.

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

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

States a specific verb ('풀어줍니다' / resolves) and the exact input types (회사명, 종목코드, 법인코드, 법인등록번호, 기업집단명) and outputs (corp_code, stock_code, 법인등록번호, 소속 기업집단). It positions itself as the prerequisite step before other tools, clearly distinguishing its role 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?

Explicitly instructs to call this tool before using other tools to specify a company, and gives a follow-up instruction for ambiguous cases (call again with corp_code). However, it does not name specific sibling tools or state when NOT to use this tool, so it stops short of full alternative guidance.

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

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

No annotations exist, and the description carries the full burden. It discloses the batch de-duplication/counting behavior, range_too_large error with split guidance, diagnostics/truncation warning, post-collection filtering, and the inclusion of pre-correction filings — information not available in 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?

Though dense, every sentence contributes: purpose, preset list, mode semantics, error recovery, filtering, diagnostics, and correction handling. It is front-loaded with the core action and structured with bullets for readability.

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

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

With 15 optional parameters and no output schema, the description covers essential operational caveats: batch splitting, diagnostic checks, and correction inclusion. It also provides fallback guidance for ambiguous entities via schema references, making it complete for a tool of this 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 coverage is 100%, so baseline is 3. The description adds behavioral semantics for mode (page vs batch full collection), report_name_contains (post-collection filter), and last_report_only (impact on delay judgment) beyond the schema's descriptions, pushing it to 4.

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 — and adds built-in FTC disclosure presets, clearly distinguishing it as a search tool. It goes beyond a restatement of the title by enumerating preset types and key search modes, establishing a distinct scope among 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?

It provides clear context for page vs batch modes, including when batch is appropriate for full collection and how to handle range_too_large errors. It also notes report_name_contains for precedent search, but does not explicitly contrast with sibling tools like find_precedents or read_disclosure.

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

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

No annotations are provided, so the description carries the burden. It discloses that it works locally without an API key, that results include caveats, that older documents may contain abolished criteria, and that lit26-* items should be prioritized. It does not detail the return format, but for a search tool this is acceptable.

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

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

The description is longer than average but well-structured with bolded text and bullets. The first paragraph establishes purpose and data source, while bullets add usage tips, warnings, and relationship to other tools. The specific count breakdown is slightly excessive but informative.

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 search tool with no output schema and no annotations, it provides a rich context: use case, query examples, category filter, warning about outdated content, preference for 2026 manual, and alternative tool for current standards. It lacks explicit result format details but covers the main operational context.

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

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

Schema coverage is 100%, so baseline is 3. The description adds practical guidance: search queries work best with core nouns and provides three examples. It also explains category values in Korean and mentions that the query can be a natural sentence. This extra context elevates it above baseline.

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

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

The description clearly states the tool searches official FTC Q&A from guides/FAQs/manuals, specifying the count and use case for edge cases. It distinguishes itself from check_disclosure_duty by noting that current numerical judgment is handled by that tool, and from other siblings by focusing on official Q&A.

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 explicitly says use when rules alone cannot determine boundary cases, gives query tips, mentions category filtering, and warns about outdated documents while directing to check_disclosure_duty for current numeric standards. It also notes that check_disclosure_duty's situation input searches the same knowledge base.

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