get_disclosure_list

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 the default values for parameters (e.g., last_reprt_at default N, sort default date, sort_mth default desc, page_count default 10, max 100). However, it does not explicitly state that this is a read-only, non-destructive operation (likely safe) or mention any rate limits or pagination beyond the parameters. Missing a note on return format (e.g., list of disclosure items) but acceptable for a search 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 moderately concise with a clear structure: a one-line summary, two usage tips, a blank line, then a parameter definitions section. Every sentence provides value. Could be slightly tightened (e.g., reduce redundancy in parameter defaults) but overall 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?

Given no output schema, the description does not explain the return format (e.g., list of disclosure objects, fields included). While the agent may infer from the tool name, a brief note on the response structure would improve completeness. The description covers input well but leaves output unspecified, which could cause misuse if the agent expects a different structure.

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 0%, so the description must fully explain parameters. It does so thoroughly: each parameter is described with its meaning, allowed values (e.g., pblntf_ty letters, corp_cls options, sort criteria), and defaults. This provides sufficient semantic context for the agent to construct correct queries.

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: '공시검색: 회사·기간·공시유형 등 여러 조건으로 공시 목록을 조회합니다.' (Disclosure search: retrieve a list of disclosures by various conditions including company, period, and disclosure type). It distinguishes itself from sibling tools like get_disclosure (single disclosure) and get_corp_code (company code lookup) by focusing on list retrieval with filtering.

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

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

Provides explicit guidance on when to use this tool: specify bgn_de for recent searches, and use get_corp_code first to obtain corp_code for a specific company. States default behaviors (e.g., end_de default today) and limitations (corp_cls cannot be specified multiple times). This helps the agent decide when to use this tool versus alternatives.

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