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

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

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

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

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

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

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

Even without an output schema, the [Response] section defines the filings[] structure, the nine inner sections, ordering (newest first), date semantics (corrected filings can carry an amended date outside the requested window), and raw string values with '-' fields omitted. Combined with safety disclosures covered by annotations and a schema that documents every parameter, nothing predictable for the agent is missing.

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

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

Schema description coverage is 100% and the schema itself is unusually detailed (start date = original filing acceptance date, limit cut at filing level not row level, statement_type supports single/enum/array/alias/Korean names). The description adds marginal meaning beyond that: a concrete natural-language usage example ('대한항공 유상증자 조건' → corp='대한항공', statement_type='equity') and the note that widening the date window costs nothing. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description states a specific verb-resource pair: the tool retrieves 6 types of key information from securities registration statements (모집·매출 조건, 인수인, 자금 사용목적, 합병·분할 조건) as structured JSON. It also differentiates itself from siblings by naming get_corporate_event, search_disclosures(kind="issuance"), and download_document as the tools for adjacent needs, so an agent can distinguish it without opening schemas.

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

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

The [Purpose] section explicitly routes three alternative situations: board decision → get_corporate_event, listing scan → search_disclosures(kind="issuance"), narrative/investment-risk → download_document. The [Rules] section adds the other side, stating when results must not be trusted (withdrawn filings unmarked, 사모·일괄신고서·소액공모 out of scope), leaving no ambiguity about when this tool is the right one.

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