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

With no annotations provided, the description carries the full disclosure burden and excels at it. It reveals the core insight (correction itself is not a violation, only the original state matters), discloses that it computes golden time and reduction schedules from originalDeadline, and — critically — states that exemptions/reductions are FTC discretion, returning 'judgment materials, not confirmations'. This honesty about output nature is exemplary and prevents agent overconfidence.

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

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

The description is front-loaded with the single most important insight (correction isn't a violation; the problem is the original state) before the bullet list. Each bullet earns its place — errorType behavior, deadline calculations, the transaction_changed exception, and the discretion caveat. It is dense but efficiently organized with zero filler; only the missing output-format note prevents a 5.

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

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

For a complex legal-risk tool with 6 parameters, 2 enums, and no output schema or annotations, the description is commendably complete. It explains what comes back (violation status, exemption paths, recommendations with cited clauses), the schedule calculations, and the discretionary nature of outcomes. It doesn't describe the exact output structure (field names, format), but for a judgment-tool it conveys everything an agent needs to invoke and interpret it 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%, with detailed descriptions for all 6 parameters including full enum semantics for errorType and regime. The description adds modest value beyond the schema — it links originalDeadline to the golden-time and 75→50→30→20% reduction schedule, and explains transaction_changed is a new duty rather than a correction. These are useful additions, but the schema already documents parameter meaning thoroughly, so the description's marginal contribution is limited.

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: diagnosing the folk belief that correcting a disclosure triggers fines, using the penalty notice original text. It specifically states the tool assesses whether the original disclosure state (omission, false, delay) constitutes a violation per errorType, which is a specific verb+resource+scope. It doesn't explicitly name sibling alternatives, but the function is unambiguous and none of the 17 siblings perform correction-risk assessment.

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

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

Usage context is implied rather than stated. The description explains behaviors (errorType-based violation status, originalDeadline golden-time calculation) but never explicitly says 'use this when' or names when NOT to use it relative to siblings like check_disclosure_duty or detect_undisclosed_transactions. The transaction_changed bullet hints that such cases route to a re-disclosure path, but no alternative tool is named.

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, and it does so thoroughly. It reveals that results are candidates, not final; that EGROUP_API_KEY is required for group audits; that uncovered companies are omitted; that range_too_large is a possible response; and that '0 candidates' does not imply compliance. This is exemplary transparency for a high-stakes audit tool.

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

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

The description is long but every sentence earns its place, covering output semantics, exclusions, error behavior, authentication, and legal caveats. The core purpose is front-loaded in the first sentence, and the bulleted caveats are clearly separated. For a tool with no annotations and no output schema, this level of detail is warranted, not padded.

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

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

Given no annotations, no output schema, six parameters, and a complex legal audit context, the description is remarkably complete. It explains inputs, return contents, exclusions, coverage semantics, error handling, authentication requirements, and limitations. An agent has enough information to invoke the tool correctly and interpret its 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 coverage is 100%, so the baseline is 3, but the description adds useful parameter-related context beyond the schema. It clarifies that the period is based on the original filing's receipt date for both from and to, that group audits require EGROUP_API_KEY, and that the group/companies parameter choices interact with coverage behavior. This earns 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?

The description names a specific verb (audit), a specific resource (J001 large internal transaction disclosures), and a specific objective (finding delayed-submission candidates by comparing receipt date with board resolution date). It also draws clear boundaries, stating it only covers track A (resolution-based) filings and cannot detect non-disclosures, which distinguishes it from sibling tools.

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

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

The description gives strong context about when this tool is appropriate and when it is not: it excludes corrections, special exemption forms, and undisclosed transactions, and it explains coverage limitations. It does not explicitly name sibling alternatives like detect_undisclosed_transactions, but the exclusions are clear enough for an agent to route correctly.

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

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

With no annotations provided, the description carries the full burden and does so extensively. It discloses that content accuracy is not checked, due:false items are ignored for non-filing, J009 has non_filing_is_signal:false, ambiguous assignments get ambiguous_assignment/possibly_filed_late flags, representative filings don't replace individual duties, and not_filed candidates are not confirmed and are enumerated in scope_caveats. This gives the agent a realistic model of the tool's behavior and limitations.

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 front-loads the core purpose and main caveat in the first two sentences, then uses bullet points to enumerate behavioral rules without repetition. It is long but each bullet adds a distinct fact relevant to invocation or interpretation, making it appropriately sized for a tool with 6 parameters and nuanced judgment logic.

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

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

There is no output schema, but the description names result categories (on_time, late_candidates, not_filed_candidates), explains due:false and non_filing_is_signal semantics, and points to scope_caveats for excluded cases. It also covers authentication, limits, representative-filing exceptions, and snapshot timing, giving the agent enough information to call and interpret 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 description coverage is 100%, with each parameter (year, group, today, duties, companies, year_month) already documented. The description adds some operational context such as the 80-company limit and the May snapshot default, but it does not meaningfully enhance the semantics of individual parameters beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description opens with '정기공시 이행 점검' and specifies that it checks periodic disclosures of J004 and J009 per company, whether filed and on time. It also explicitly states '내용의 정확성은 보지 않습니다' (does not check content accuracy), which distinguishes it from content-review-focused sibling tools. 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 description provides clear context: deadlines are calendar-fixed and judged by receipt date, J009 non-filing is not a signal (non_filing_is_signal:false), due:false items are not judged as non-filing, and representative company submission does not substitute individual duty. It also gives operational constraints like EGROUP_API_KEY requirement and the 80-company limit. However, it does not explicitly name alternative tools or state when to use a sibling instead, so it lacks explicit when-not-to-use routing.

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

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

No annotations are provided, so the description carries the full burden. It discloses important behavioral traits: it returns skipped non-business days with dates, weekdays, holiday names, and legal basis; it warns about missing/unverified holiday data via warnings; it explains the nuance that Labor Day (5/1) is not a public office holiday, causing divergence between civil law and notice-based business day calculations until 2027. It also warns that holiday laws change and gives a concrete example (2027-05-03 substitute holiday). This is rich behavioral context beyond a simple 'calculates business days' statement.

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

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

The description is moderately sized but information-dense. It front-loads the core purpose in the first sentence, then provides critical usage warnings and behavioral details. The bullet points are well-structured. It loses one point because the warning about 2027 Labor Day is somewhat verbose and could be tightened, but every sentence earns its place by conveying important caveats.

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

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

Given the tool's complexity (4 parameters, no output schema, no annotations), the description is quite complete. It explains what each parameter returns, warns about data limitations, and provides legal context. It doesn't explicitly describe the output format structure, but without an output schema, a brief note on return shape would help. However, the description does list the types of outputs (business day status, holiday name, deadline adjustment, skipped days list, legal basis, warnings), which is sufficient for an agent to understand what to expect.

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 by explaining the semantics of each parameter with examples: add_business_days for '이사회 의결일 + 상장 3영업일 / 비상장·공익법인 7영업일', add_calendar_days for '분기 종료 후 45일', count_business_days_to for '오늘부터 기한까지 남은 영업일'. It also clarifies that date alone returns business-day status and next business day. This goes beyond the schema's basic descriptions, though it doesn't add syntax details for the date format (already in schema pattern).

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 computes Korean business days, holidays, and deadline adjustments, listing specific outputs (business day status, holiday name, deadline adjustment, N-business-day/N-calendar-day deadlines, remaining business day count). It distinguishes itself from sibling tools by being the only date-calculation tool among disclosure/search/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?

The description explicitly instructs when to use the tool: '기한·영업일·공휴일이 걸린 날짜 질문에는 반드시 이 도구를 호출하세요' (must call this tool for date questions involving deadlines, business days, holidays). It also warns that the model's own calendar knowledge is outdated, providing a clear directive to prefer this tool over internal knowledge. It does not name specific sibling alternatives, but the sibling list contains no other date-calculation tool, so the guidance is sufficient.

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 transparency burden and does so well: it discloses that the tool does not call external APIs and requires no auth key, always includes 근거 조문 and 계산식 in results, and returns insufficient_data instead of estimating missing financial figures. It does not state side-effect/read-only behavior, but the disclosed traits substantially inform invocation.

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: core function first, then output guarantees and the missing-data fallback, then a high-impact warning about amountBasis. Every sentence contributes actionable information, and the critical warning is clearly marked and front-loaded.

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

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

Given 24 parameters, no output schema, and no annotations, the description is reasonably complete for tool selection and safe invocation: it states the computation scope, result contents, missing-data behavior, and a key input pitfall. It does not enumerate every duty-specific parameter combination, but the richly documented schema compensates for that gap.

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 parameters. The description adds semantic value by highlighting amountBasis as decision-critical and by explaining the insufficient_data behavior tied to totalEquity/paidInCapital, plus routing to get_financials. This goes beyond the baseline but does not exhaustively synthesize all 24 parameters.

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

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

The description opens with a specific verb and resource: '공정거래법상 공시의무 대상 여부를 판정하고 공시기한·지연 시 예상 과태료를 계산합니다.' This clearly identifies the tool's core function and differentiates it from sibling audit/search tools in substance, though it does not explicitly name or contrast any sibling tool.

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

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

The description provides an explicit conditional alternative: when 자본총계·자본금 are missing, the tool will not estimate and returns insufficient_data, and the agent should 'get_financials 로 재무수치를 먼저 조회하세요.' This gives a concrete when-not-to-use instruction and a named alternative. General when-to-use context is implied by the purpose statement but not elaborated for all duty types.

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 behavioral burden. It discloses key behaviors: the tool cannot read unsent drafts, it returns not_checkable when financial statements are not found, it gives unit-error hints for ~1000x differences, and it may produce structural false positives for generic totals. This gives the agent realistic expectations 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 well structured with a purpose statement followed by concise bullets. Every bullet adds meaningful constraint or behavior, and warnings are front-loaded. It is slightly long, but the length is justified by the domain complexity.

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

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

For a complex tool with no output schemacompress, the description is quite complete: it covers what is checked, what is not checked, key limitations, and the not_checkable outcome. The compare_rcept_nos and include_generic_totals semantics are covered in the schema. It could more explicitly describe the output shape, but this is not a blocking gap.

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 parameters are already well documented. The description adds no per-parameter detail beyond the schema, which is acceptable under the baseline, but it also does not enrich the meaning of rcept_no or max_issues beyond what the schema already provides.

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

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

The description states a specific action and resource: it recalculates all mechanically re-calculable items in the J004 filing to find discrepancies. It also clearly scopes the tool to submitted DART filings via rcept_no, distinguishing it from generic search/read/duty-check sibling tools.

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

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

The description gives strong usage boundaries: only already-submitted filings with a receipt number are checked; draft files are not readable; it checks internal consistency only, not accounting truthfulness; and include_generic_totals is flagged as experimental with false-positive risk. It does not explicitly name alternative sibling tools, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure and delivers exhaustively: the 50-second self-stop due to the MCP client's ~60s timeout, cancellation semantics (no result retention but DART queries may complete), partial-result behavior, document-verification rules (counterparty must match in the original text), cache/persistence behavior, token 6-hour expiration, and legal penalty implications (50M-70M won fines). This is exemplary disclosure of traits well beyond what a schema could express.

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 an enormous wall of text—likely 4,000+ characters of dense Korean prose—with no clear sections or headers despite using ★ and — markers. While most sentences earn their place given the tool's complexity, the sheer volume and lack of hierarchy make it hard for an agent to scan for the core workflow (summary-first, continuation protocol). It is over-specified and would benefit from structured sections with the key operating rules front-loaded.

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

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

For a highly complex cross-filing detection tool with no output schema, the description is remarkably complete: it covers the output structure (action_items_preview, available_sections, not_judged, coverage, continuation, diagnostics, detail_access), the detection logic for each transaction type (funds borrowing 90-day window, goods/services 4x threshold, securities aggregate-only), edge cases (perspective:거래상대방, candidate_if_counterparty_qualified), and scope caveats. Nothing essential is missing for an agent to call it 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?

All 5 parameters have schema descriptions (100% coverage), so the baseline is 3. The description substantially enriches continuation_token semantics—the repeat-call protocol, the 'same arguments' requirement, rejection as continuation_invalid with changed args, and the 6-hour token lifetime—and clarifies the group/rcept_no mutual-exclusion implications when rerunning. This adds genuine meaning beyond the schema for the most complex parameter.

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

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

The description opens with a precise verb-resource-outcome statement: cross-referencing the actual transaction details in the annual J004 filing against J001 large-scale internal transaction disclosures to find 'undisclosed candidates' (거래는 했는데 공시가 없는). This clearly distinguishes it from siblings such as check_j004_consistency and audit_group_disclosures, which target different verification tasks.

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

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

The description gives strong workflow guidance: when to follow up with read_detection_result for full details, the continuation protocol for calling repeatedly until complete:true, when to stop and query the remaining companies individually (continuation.stalled=true), and the per-call 20-company limit. However, it never explicitly names alternatives or states when NOT to use this tool versus siblings like audit_group_disclosures or search_disclosures.

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 disclosure burden and handles it exceptionally. It states no key is required (auth), discloses business-day adjustment including substitute holidays, explains the quarterly reference-period logic (the most common error point), reports same-day collisions, and flags that absence from the calendar does not mean no duty exists. This is a model of behavioral transparency for an unannotated tool.

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

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

The description is well-structured and front-loaded: purpose first, then bulleted contents, then a critical warning. It is somewhat long, but every segment earns its place — the items list, business-day adjustment, reference-period caveat, and the not_in_calendar warning are all operationally important. The bullet-point formatting aids scannability for an agent.

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 7 parameters and intricate business logic (business-day adjustment, reference-period semantics, collision detection), the description is remarkably complete. Since there is no output schema, the description explains what the agent will receive: chronological deadlines with D-days, per-item content (items), reference dates, and collision alerts. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds contextual value (what items appear, reference periods, collision reporting) but does not elaborate on individual parameters beyond the schema. The 'duties' keys are listed only in the schema, not reiterated in the description. The schema already documents each parameter clearly, so the description's minimal parameter-specific contribution is acceptable.

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 concrete verb+resource ('answers what must I disclose this year and when') and precisely scopes what it returns: fixed-calendar periodic disclosure deadlines computed with D-days, sorted chronologically. It clearly differentiates from siblings like search_disclosures (searching) and check_disclosure_duty (checking a specific duty) by focusing exclusively on fixed-deadline periodic items, listing each covered duty explicitly.

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

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

The description gives strong usage context: it covers periodic disclosures with fixed calendar deadlines and explicitly warns that cause-based events (large-scale internal transactions, unlisted company important matters within 7 business days) are NOT on the calendar and require not_in_calendar. It doesn't name an alternative sibling by name, but the caveat effectively routes the agent away from this tool for event-driven disclosures. The quarter-reference caveat also guides correct interpretation of results.

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 of behavioral disclosure — and it delivers richly. It discloses the correction basis (정정 반영 최종본 기준), the semantics of coverage (훑은 구간, 0건 != "그런 공시가 없다"), the selection rule (회사당 1건), and the lookback stop condition (후보가 모이면 멈춤). This is exemplary for an unannotated tool.

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

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

The core purpose is front-loaded in the first sentence, and the caveats are organized as compact bullet points. Each bullet earns its place (correction basis, coverage semantics, time range behavior). It is somewhat long for an 8-parameter tool, but the density of useful caveats justifies the 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 complex 8-parameter tool with no output schema and no annotations, the description covers the essential interpretation traps (coverage, 0건 meaning, final-version basis) and output format (마크다운 표 구조 보존). What's missing is minor — e.g., no explicit statement of timeouts or result count display — but these aren't critical to correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine behavioral meaning beyond the schema: it clarifies that count consumes one download per precedent, explains lookback_days' non-monotonic scan behavior (후보가 모이면 더 내려가지 않으며 항상 전수로 확인), and ties coverage to interpretation of results. This elevation 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?

The description states a specific verb and resource — answering "다른 회사는 이 항목을 어떻게 썼나" by fetching recent disclosures of the same type, selecting one per company, and returning the original text as markdown. It clearly differentiates from siblings: it's for 문안 참고 (wording reference) and explicitly contrasts with 지연 판정 (delay judgment), distinguishing it from check_disclosure_duty and search_disclosures.

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

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

It gives clear context on when to use it (finding third-party wording/문안), grounds the default scope (대규모내부거래 J001), and explicitly states what it is NOT for ("

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

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

With no annotations provided, the description carries the full behavioral burden, and it does so well: it explains that amounts come as raw/value/display, that change is prior-period difference, that cumulative treatment applies only when cumulative fields exist, that OFS falls back to CFS, and that some companies may have no financial statements at all. This is substantial behavioral disclosure 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 compact and front-loaded: the main purpose appears first, followed by four tight bullets, each adding distinct value. There is no fluff or repetition of schema content.

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

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

Given there is no output schema and no annotations, the description covers a lot: defaults, fallback behavior, value formats, change semantics, and availability caveats. It is slightly incomplete regarding error behavior or what the response looks like beyond amounts and key_metrics, but it is still quite complete for a query 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 description coverage is 100%, so the baseline is 3. The description adds some integration context (key_metrics fields usable as downstream inputs) and output semantics, but it does not meaningfully expand on the input parameters themselves, which are already well documented 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 states a specific verb and resource: '단일회사 재무제표를 조회합니다' (retrieve single-company financial statements), and it gives a concrete default (latest annual report's balance sheet). It is clearly distinguishable from siblings like get_group_structure or read_disclosure because it scopes to single-company financial statement data.

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

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

The description gives clear usage context: defaults for year, report type, statement type, and fs_div fallback. It also warns that non-externally-audited companies may have no DART financial statements and suggests portal financials as an alternative for group affiliates. It does not explicitly name a sibling tool to prefer instead, so it stops short of full 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?

With no annotations, the description carries the full burden and performs well: it discloses API key requirements, annual refresh cadence (매년 5/1) with yearly caching, the DART join limitation based on 법인등록번호 rather than names, and the FTC naming convention. These are precisely the behavioral caveats an agent needs.

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

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

The description is tight and well-structured: a one-sentence purpose, one contextual sentence, and three focused bullet points. Every sentence adds value, with the most important caveats front-loaded.

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

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

Given no output schema, the description adequately states what is returned (overview plus full affiliate list) and covers auth, freshness, naming, and join limitations. Minor gaps include no explicit mention of output format for compact mode or financials, but those are covered in the parameter 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 baseline is 3. The description adds useful context for the group parameter (FTC naming convention, e.g., 에스케이 not SK) and reinforces the DART join logic, but these are mainly elaborations of what the schema already documents.

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

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

The first sentence states a specific verb (돌려줍니다), a precise resource (공정위 지정 기업집단), and the return contents (개요와 소속회사 전수). It clearly distinguishes this structural data source from analytical siblings like check_disclosure_duty and audit_group_disclosures.

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 statement '소속회사 목록이 곧 공정위 공시의무의 모집단입니다' establishes clear context for when to use this tool. It also notes the EGROUP_API_KEY prerequisite. However, it does not explicitly name alternatives or state when not 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?

Despite having no annotations, the description discloses the 30-minute memory TTL, result_unavailable rejection after expiry/retrieval/server restart, the non-JSON nature of intermediate chunks, the exact-concatenation guarantee, and the prohibition on claiming unread details as confirmed. This is far more than minimal behavioral disclosure.

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

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

The purpose is front-loaded in the first sentence, and the remaining content is organized into compact, information-dense bullets covering pagination, unit semantics, and warnings. No filler is present; each warning earns its place as safety-critical guidance.

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

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

For a paginated reader with no output schema and no annotations, it covers input selection, chunk size limits, ordering and concatenation behavior, failure mode, TTL, and result semantics. The references to next_offset and total_chars provide enough of the response contract for an agent to use 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 the baseline is 3, but the description adds operational nuance: using next_offset as-is, UTF-16 code units with Hangul = 1 unit, response-size budget shortening, and section values drawn from available_sections. Most of this reinforces the schema rather than adding entirely new parameter information, but the added emphasis is genuinely 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?

First sentence names the action (읽습니다), the object (판정 근거·caveat 전문), and the required identifier (result_id). It also clarifies what the tool is not: it does not rerun the detection engine and needs no key, which distinguishes it from detect_undisclosed_transactions.

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?

States clearly that this is the reader for a detect_undisclosed_transactions summary and explains section selection, omission for full output, and next_offset-based continuation. It does not explicitly name alternative tools for re-running detection, so the when-not guidance is implied rather than fully explicit.

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

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

No annotations, so description carries the burden. It discloses error behavior for HWP-only disclosures and board_date extraction. However, it doesn't mention truncation via max_chars or caching behavior with force_refresh, which are described only in the schema. Given no annotations, this is a gap.

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?

Concise, front-loaded purpose, uses bullet points for additional details. No wasted words.

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

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

Covers main behavior, error case, and board_date extraction. Missing explicit response structure (truncated flag) and caching behavior, but those are in schema. Given no output schema, it could be more explicit about return fields, but it's adequate.

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 description adds no additional parameter semantics. The description mentions rcept_no but doesn't go beyond schema descriptions for format, max_chars, or force_refresh.

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

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

States a specific verb+resource (returns disclosure text) with format (markdown) and key features (table preservation, board_date extraction, error handling). It distinguishes from search_disclosures (search vs read) and read_detection_result (different resource).

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

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

Implies usage when you have a receipt number and need the full text. Provides context about table preservation and board_date extraction, which hints at when it's beneficial. However, it doesn't explicitly name alternatives or 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?

With no annotations, the description carries behavioral disclosure itself. It transparently explains the ambiguous-entity behavior, the EGROUP_API_KEY requirement, the first-call cost of ~103 portal requests, and one-year caching. It does not describe not-found statuses or full response shape, but the disclosed behaviors are material and well covered.

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

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

The description is compact and front-loaded: one clear main sentence followed by two high-signal bullets. Every sentence adds practical value, with no filler or repetition of schema content.

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

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

Given the 100% schema coverage and no output schema, the description covers the main workflow, ambiguity handling, and expensive side-effects well. The only notable gap is the absence of explicit behavior for not-found or invalid inputs, but the overall definition remains sufficient for correct invocation in most 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 the baseline is 3. The description adds meaningful semantics beyond the schema by explaining the cost/caching implications of includeGroup=true and the retry strategy for ambiguous queries, which aids correct use.

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

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

The description states a specific action ('풀어줍니다' = resolves) applied to concrete inputs (company name, stock code, corporate code, registration number, group name) and outputs (corp_code, stock_code, registration number, group). It is clearly distinguished from the sibling disclosure/financial tools by its identifier-resolution 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 gives helpful same-tool guidance, such as re-calling with a candidate's corp_code when status is ambiguous yielding and the strong requirement for includeGroup=true. However, it does not explicitly state when to prefer this tool over sibling alternatives or 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 present, so the description carries the full behavioral disclosure burden. It reveals non-obvious traits: batch mode does full-period collection with dedup/count, large ranges return range_too_large with split intervals, truncated/partial_results diagnostics mean incomplete results, and pre-correction original filings are included. This is substantial and prevents misinterpretation of duplicated or incomplete data.

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

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

The description is front-loaded with the core purpose and uses four compact bullets covering mode behavior, error handling, diagnostics, and correction inclusion. Every sentence carries operational information 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 tool with 15 parameters and no output schema, the description covers the main operational pitfalls: splitting large ranges, interpreting incomplete-result diagnostics, and handling pre-correction filings. It does not describe the result structure beyond diagnostics, but the schema and behavioral notes together give an agent enough to invoke the tool correctly in most 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 description coverage is 100%, so the baseline is 3. The schema already documents all parameters, including defaults, enums, patterns, and warnings such as the last_report_only caution. The description adds some context about mode behavior and delay determination, but mostly reinforces schema-level information rather than adding new parameter-level meaning.

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 '공시를 검색합니다' (searches disclosures), a specific verb and resource, and adds that six FTC corporate-group presets are built in. This clearly separates it from read_disclosure as a search operation, though it does not explicitly name siblings or exclusions.

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 internal usage guidance: page vs batch modes, dedup/count behavior, and explicit instructions to split large ranges when range_too_large is returned. However, it does not state when to prefer this over sibling tools like read_disclosure or the audit/check tools, so cross-tool routing is left implied.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It covers the corpus size, the no-key requirement, the presence of abolished standards in old documents, and the mandatory practice of reading caveats and preferring 2026 manual answers. It does not describe output structure or pagination, but the safety warnings are substantial and valuable.

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

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

The description is compact and front-loaded: purpose and corpus in sentence 1, intended use in sentence 2, then bullet-pointed tips and a critical warning. Every sentence earns its place, and the warning is non-redundant. It is slightly longer than minimal but well organized.

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

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

For a search tool with 3 simple parameters and no output schema, the description covers the essentials: what is searched, how to search, and critical caveats about outdated content. It tells the agent that results include caveats and that lit26-* entries should be prioritized, which is sufficient for correct invocation and interpretation, though the exact result format is not spelled out.

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 parameters are already well documented in the schema. The description adds only a minor tip that search terms work best as core nouns and that category narrows by disclosure type—both largely redundant with the schema. This is a small increment over the 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 it searches 430 official Q&As extracted from FTC guides/FAQs/manuals, including 79 key cases from the 2026 manual, and explicitly frames its purpose as providing official answers for edge cases that rules alone cannot decide. This distinguishes it from sibling tools like search_disclosures and find_precedents by focusing on authoritative Q&A content.

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

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

It gives clear context: use when rules alone cannot determine a boundary case, with search tips on core nouns and category filtering. It also warns to read each result's caveats and prefer 2026 manual entries (lit26-*) over outdated documents. However, it does not explicitly name sibling alternatives or state when not to use the tool, so it falls short of the highest mark.

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 bears full burden, and it does well: it discloses side-effect-free local lookup, explicitly says no API key or API invocation is needed, states that the key value is not exposed, and lists the returned metrics. This fully characterizes behavior for a zero-parameter diagnostic tool.

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

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

Two sentences: the first front-loads the complete list of returned items and key behavioral facts, the second gives concrete trigger questions. Every sentence earns its place 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?

For a no-parameter, no-output-schema tool, the description is complete: it covers all return values, the local/no-auth nature, and examples of when to call it. There are no structured fields left to clarify, so nothing 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?

The tool has 0 parameters, so baseline is 4. The description reinforces that no authentication inputs are needed by stating '키·API 호출 불요' (no key/API call required), which adds relevant context beyond the empty schema.

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

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

The description uses a specific verb ('돌려줍니다' - returns) and identifies the resource as server status/config diagnostics, enumerating the exact data fields. This clearly distinguishes it from all sibling tools, which are domain-specific disclosure/financial 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?

It gives explicit usage context and sample queries ('키를 넣었는데 인식이 안 된다', '한도가 얼마 남았냐', '공휴일 데이터가 몇 년도까지 있냐'), plus a constraint (local lookup, no key/API call required). It doesn't name alternatives or say when not to use it, but no sibling serves a diagnostic role, so the guidance is adequate.

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