OpenDART MCP Server

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

No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states what information is provided, without mentioning whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or response format. For a tool with no annotation coverage, this represents a significant gap in behavioral transparency.

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 appropriately concise with a clear two-part structure: purpose statement followed by parameter list. The purpose is front-loaded, and the parameter section is formatted for readability. No unnecessary verbiage is present, though the parameter explanations could be more informative.

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 that an output schema exists (which reduces the need to describe return values), the description covers the basic purpose and parameters. However, with no annotations and 0% schema description coverage, the description should do more to explain behavioral aspects and parameter semantics. It's minimally adequate but leaves significant gaps in understanding how to use the tool effectively.

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 compensate. It does list the three parameters with brief Korean explanations, but these don't add meaningful semantic context beyond what's already evident from parameter names. The explanations ('고유번호(8자리)', '시작일(YYYYMMDD)', '종료일(YYYYMMDD)') essentially restate the parameter titles in Korean with format hints, but don't explain their significance, constraints, or relationships. With 0% schema coverage and minimal parameter explanation, this is inadequate.

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: '지분증권 - 증권신고서 내 지분증권 요약정보를 제공합니다' translates to 'Equity securities - provides summary information of equity securities within securities registration statements.' This specifies the verb (provides), resource (equity securities summary information), and scope (within securities registration statements). It doesn't explicitly distinguish from sibling tools, but the specificity is sufficient for clear understanding.

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 no guidance on when to use this tool versus alternatives. While the purpose is clear, there's no mention of prerequisites, appropriate contexts, or comparison to similar tools like 'get_debt_securities_reg' or 'get_depositary_receipts_reg' from the sibling list. The user must infer usage from the purpose alone.

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