get_document

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

With no annotations, the description carries full burden. It discloses text extraction behavior and truncation when max_chars exceeded (with truncated=true flag). It also mentions the purpose (1차 원본 인용용). However, it does not cover error handling, missing documents, or authorization requirements, leaving some behavioral gaps.

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 two concise sentences with front-loaded main action. Every part is meaningful: the tool's purpose, parameter hint, return behavior, and use case. There is no redundant information.

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 low complexity (2 parameters, no output schema), the description covers the essential aspects: what it does, how to get the required parameter, and truncation behavior. It does not detail error cases or response structure, but for a simple retrieval tool, this is reasonably 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 input schema has 0% description coverage, so the description adds significant meaning. For rcept_no, it explains it is the receipt number from search_disclosures results. For max_chars, it implicitly explains its role via the truncation behavior. This adds value beyond the raw schema fields.

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 retrieves the original text of a disclosure document using a receipt number. It specifies the resource (공시서류 원문) and the action (조회). It also distinguishes itself from siblings by linking rcept_no to search_disclosures, clarifying it is a follow-up tool for document text retrieval.

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 explicitly states that rcept_no comes from search_disclosures results, providing clear context for when to use this tool (after search_disclosures). However, it does not mention when not to use it or provide alternative scenarios, but the context is clear enough for appropriate selection.

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