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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral detail beyond annotations by enumerating the content areas: business info, balance sheet, income statement, investment data, and venture confirmation info. It also discloses the per-call point cost, which helps the agent understand operational impact.

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 short, front-loaded with an English summary, and the Korean sentence adds specific data categories beyond the English text. The cost note is brief and useful. Minor redundancy exists because the Korean wording repeats the English lookup intent, but it remains compact and scannable.

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?

With only one simple parameter, no output schema, and read-only annotations, the description provides enough context for an agent to understand what the tool returns by enumerating the information categories. It does not specify the exact response shape or field names, but for a simple business lookup this is a reasonable level of completeness.

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%, and the biz_no parameter is already documented with format requirements: business registration number, 10 digits, no hyphen. The tool description adds little to parameter understanding beyond confirming the tool is about Korean businesses. Since the schema carries the full load, a baseline score of 3 is appropriate.

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 a specific action ('Look up') and a specific resource ('venture company information of a Korean business'), and lists the data categories returned. It does not explicitly name a sibling tool to differentiate from, but the venture-company scope is distinctive enough to separate it from broader business-info tools like biz_detail.

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 phrase '벤처기업을 대상으로' implies this tool is intended for venture company information, giving some usage context. However, it does not explicitly say when to prefer this over sibling alternatives such as biz_detail, nor does it state exclusions or conditions. Usage guidance is present only by implication.

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