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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses automatic DART_API_KEY injection and that the response is the original, unprocessed JSON. However, it omits operational traits such as rate limits, possible DART error payloads, or explicit read-only semantics.

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 one concise, front-loaded sentence plus a short parenthetical about API key injection. Every word earns its place, and there is no redundancy with the schema.

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 description plus the detailed endpoint catalog in the schema gives an agent enough to select an endpoint, pass params, and understand the raw JSON return shape and automatic auth. It stops short of a 5 because it omits operational caveats such as rate limits and error behavior, and gives no alternative-tool routing.

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 100%, with rich parameter documentation in the input schema itself, including the endpoint catalog and reprt_code mappings. The tool description adds no parameter-level detail beyond that, so the baseline score of 3 applies.

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 uses a specific verb and resource: it calls Open DART official endpoints and returns raw JSON without processing. It clearly distinguishes itself from the KRX/document/corp-code siblings by naming the DART API scope and the unprocessed-output contract.

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?

Usage is implied rather than explicit: the description indicates this tool is for hitting Open DART endpoints and getting raw JSON, but it does not state when to prefer it over siblings like download_dart_document or search_corp_code. There is no when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool returns raw JSON without processing and that the API key is auto-injected. However, it doesn't disclose potential failure modes (e.g., what happens if the API returns an error, rate limits, or whether the tool validates parameters). The description adds some behavioral context but not comprehensive 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 concise and front-loaded: the main purpose is stated in the first sentence, and the API key injection note is a useful addition. The api_id catalog is long but necessary for a tool with 31 possible values. The structure is clear, though the catalog could arguably be moved to the schema (it already is partially there). Overall, every sentence earns its place.

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 the tool's complexity (31 API IDs, nested params object, no output schema), the description is fairly complete. It explains the raw return behavior and key injection. However, it doesn't mention error handling, response format details, or how to discover valid param values for each API ID. Since there's no output schema, a bit more about the return shape could help, but the 'raw JSON' statement covers the basics.

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 100%, so the schema already documents both parameters. The description adds value by explaining the api_id catalog in detail (31 service IDs with Korean labels) and giving examples for params. This goes beyond the schema's basic descriptions, helping an agent understand what values to pass. The description doesn't repeat the schema verbatim but enriches it.

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 a specific verb ('호출하여'), a specific resource (KRX 공식 오픈API), and a clear behavior (원본 JSON을 가공 없이 그대로 반환). It also mentions automatic API key injection, which distinguishes it from sibling tools like call_dart_api. The description is unambiguous and tells an agent exactly what this tool does.

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 when to use this tool: when you need raw KRX open API data without transformation. It doesn't explicitly state when not to use it or name alternatives, but the sibling list (call_dart_api, download_dart_document, search_corp_code) makes the context clear. The description could be stronger by explicitly saying 'use this for KRX data, not DART data', but the resource is clearly identified.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It explains the download-and-return behavior and notes the direct_url is the official original-document link, which is useful. However, it does not disclose potential failure modes, size limits, or whether the ZIP is processed server-side, leaving some behavioral ambiguity.

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 a single, compact sentence that front-loads the core action and key output details. It is efficient, though it could be slightly more structured by separating the return-value explanation from the main action.

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 no output schema and no annotations, so the description must cover return values and behavior. It mentions returning text and a web link, which is helpful, but it does not describe the format of the text, error handling, or what happens when max_chars is set. For a download tool with two parameters, this is adequate but not 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?

Schema description coverage is 50%: rcept_no is described only by its pattern, while max_chars has a full description. The tool description adds meaning by explaining rcept_no is a 14-digit DART receipt number and that the output includes text and a web link, which helps the agent understand the parameters' role. It does not fully compensate for the undocumented rcept_no semantics, but the pattern and context provide adequate guidance.

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 downloads a DART disclosure document (ZIP) using a 14-digit receipt number and returns text content and a web link. It also clarifies that the returned direct_url is the official link for viewing the original document, which distinguishes its purpose from sibling API 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?

The description implies usage for downloading DART disclosure documents, but it does not explicitly state when to use this tool versus siblings like call_dart_api or search_corp_code. It provides no exclusions or alternative routing guidance, so the agent must infer the appropriate context.

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

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

No annotations are provided, so the description carries the burden. It discloses the search-key types and the rationale for preferring the 6-digit code, which is useful behavioral context. However, it does not disclose return format, pagination behavior, or whether the search is exact-match or fuzzy, which would matter for an agent deciding how to use the result.

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?

One sentence with a parenthetical tip. It is front-loaded with the core purpose and the example is embedded efficiently. No wasted words.

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?

For a simple search tool with 2 parameters and full schema coverage, the description is mostly adequate. However, with no output schema and no annotations, the agent is left without information about the result shape or how to handle multiple matches, which is a meaningful gap for a search tool.

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 100%, so the schema already documents both parameters. The description adds a concrete example and the recommendation to use the 6-digit code, which is helpful but does not add substantial meaning beyond the schema's parameter descriptions.

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 a specific verb ('검색합니다') and resource (기업), and enumerates the three accepted search keys: 회사명, 6자리 종목코드, 8자리 고유번호. It also includes a concrete example (005930) and a recommendation to prefer the 6-digit code to avoid name-change issues, which clearly distinguishes this tool from the sibling API 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?

The description gives clear context on what to search by and even recommends the 6-digit code to avoid name-change effects. It does not explicitly state when to use this tool instead of call_krx_api, call_dart_api, or download_dart_document, but the search-oriented purpose is clear enough that an agent can infer it is the lookup step before those API/document tools.

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