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

Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context beyond the annotations: filtering is applied client-side over the most recent 100 events, the default window is 180 days, the return shape is identical to get_dart_filings, and error conditions are documented (no events in range -> widen dates; invalid regex; unknown company -> search_dart_company). These details let the agent anticipate behavior and handle failures, going well beyond what annotations convey.

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

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

The description is long but meticulously structured: it front-loads purpose and differentiators, then flows through 'Not this tool', 'What this adds', Args, Returns, Examples, Use when, and Errors. Every sentence earns its place; there is no filler or repetition of schema content. The use of sections and bullet-like formatting makes it scannable despite its length, and the most critical routing information appears first.

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

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

The tool has a rich output schema (indicated as present) and a complex sibling landscape. The description covers all necessary aspects: purpose, differentiation, parameter semantics, return shape (explicitly matching get_dart_filings), default behavior, examples, and error handling. An agent can confidently select and invoke this tool correctly without needing additional documentation. No gaps are apparent.

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 extra semantics: it explains that 'kinds' is a JavaScript regex matched against Korean report names and provides concrete examples ('증자|합병|전환사채'), clarifies the default date window (180 days), and gives full usage examples for corp, kinds, from/to. It also documents the limit range (1-100). These additions go beyond the schema descriptions, though not exhaustively (e.g., no explicit mention that 'corp' can be omitted for market-wide scans appears in the description and schema both). The extra examples and filtering behavior justify 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 the specific verb ('List') and resource ('major-event disclosures, DART type B') and enumerates concrete event types (capital increases, mergers, convertible bonds, treasury stock, bankruptcy, lawsuits). It also explicitly names sibling tools it is not, distinguishing it from get_dart_filings, get_edgar_filings, and get_disclosure_feed. An agent can instantly tell what this tool does and how it differs from its peers.

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 explicit when-to-use and when-not-to-use guidance. It opens with 'Not this tool for:' and lists alternatives for full filings, US 8-K, and cross-market feeds. It further explains what it adds over get_dart_filings (regex filter, 180-day default window, matched-count totals) and ends with 'Use when: event-driven screening...' plus an explicit 'For every filing category... use get_dart_filings.' This is textbook routing guidance.

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