DART-MCP

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

With no annotations, the description carries full burden. It discloses the fallback/auxiliary nature ('실패시 보완하는 보조 도구') and return value constraints ('당기 데이터만 표시' - current period only). However, it lacks mention of error handling, rate limits, or authentication requirements.

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?

Well-structured with clear sections (summary → usage context → Args → Returns). Information is front-loaded with purpose and sibling differentiation first. Every sentence serves a function; no redundancy despite Korean/English mixed context.

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 zero annotations, zero schema coverage, and no output schema, the description successfully explains the tool's role, parameter semantics, and return format ('텍스트' containing detailed items). Minor gap: lacks error handling or rate limit disclosure expected for financial APIs.

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?

Given 0% schema description coverage, the Args section fully compensates by providing semantic meaning for all 5 parameters, including Korean business term mappings for enums (e.g., '11011': 사업보고서) and examples (e.g., '삼성전자, 네이버'). The None behavior for statement_type is also explained.

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 clearly states it provides company financial information via JSON API and explicitly identifies itself as a '보조 도구' (auxiliary tool) that compensates for failures. It distinguishes from siblings by naming search_disclosure and search_detailed_financial_data as the primary 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?

Explicitly states when to use: 'search_disclosure, search_detailed_financial_data이 2023년 9월 이전 자료 분석에 실패했을 때 대안으로 활용' (use as alternative when primary tools fail for pre-September 2023 data). This provides clear when-to-use guidance and names specific alternatives.

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