OpenDART MCP Server

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an information-providing tool, which implies read-only behavior, but doesn't specify whether it requires authentication, has rate limits, returns paginated results, or what the output format looks like. The description lacks details about error conditions, data freshness, or any side effects, leaving significant gaps for a tool with no annotation coverage.

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 two sentences: one stating the purpose and another listing parameters. The parameter documentation is structured clearly with bullet-like formatting. There's no unnecessary repetition or verbose explanations, though the dual-language presentation (Korean purpose statement, English parameter names) could be slightly confusing.

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 there's an output schema (which handles return values), no annotations, and 3 parameters with 0% schema coverage, the description does the minimum required: it states the purpose and documents parameters. However, for a financial data tool with no behavioral annotations, it should ideally include more context about data sources, update frequency, or authentication requirements to be fully complete.

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?

The description includes an Args section that documents all three parameters (corp_code, bgn_de, end_de) with brief explanations in Korean. Since schema description coverage is 0%, this adds meaningful value beyond the bare schema. However, the explanations are minimal ('고유번호(8자리)' for corp_code, date format constraints for bgn_de/end_de) and don't elaborate on where to obtain corp_code values or how date ranges are interpreted.

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: '전환사채권 발행결정 - 주요사항보고서 내 전환사채권 발행결정 정보를 제공합니다' (Provides convertible bond issuance decision information from major matter reports). It specifies the verb ('제공합니다' - provides) and resource ('전환사채권 발행결정 정보' - convertible bond issuance decision information), though it doesn't explicitly differentiate from sibling tools like 'get_bond_with_warrant_decision' or 'get_exchangeable_bond_decision'.

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 implies usage context by mentioning '주요사항보고서 내' (within major matter reports), suggesting this tool retrieves information from regulatory filings. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like other bond-related tools in the sibling list, nor does it mention any prerequisites or exclusions beyond the date range constraint noted in the parameters.

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