시장 순위 조회

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

With no annotations, the description carries the full burden and explains the behavioral differences between rise/fall and open_rise/open_fall (previous close vs today's open), the market scanning requirement, and the inclusion of an execution strength column for open-based types. It does not disclose auth requirements or rate limits, but for a query tool this is minor.

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 dense but every sentence contributes: it front-loads the purpose, then details types, constraints, and use cases. It could be slightly more concise (e.g., removing internal API codes ka10027...), but the structure is logical and not wasteful.

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 covers parameter semantics, constraints, and use cases thoroughly for a 4-parameter tool. However, without an output schema, it only hints at return values (e.g., execution strength column for open types) and does not describe the complete result structure or pagination, leaving some completeness gap.

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 covers all parameters, but the description adds meaning beyond it: it explains the semantic distinction between rise/fall and open_rise/open_fall, why market is restricted for open-based types, and the purpose of min_volume and credit_ratio. This goes well beyond the schema's descriptive text.

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 daily market rankings ('당일 시장 순위를 조회합니다') and enumerates the ranking types (rise, fall, volume, value, open_rise, open_fall, credit_ratio), making the purpose specific. It distinguishes from siblings by mentioning get_credit_trend for a different use case, though it does not explicitly contrast with other ranking tools like get_valuation_rank.

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 explicit conditions for when certain types are valid: open_rise/open_fall require market to be kospi or kosdaq and min_volume to narrow the population, and credit_ratio is for finding forced-sell pressure, with get_credit_trend explicitly named as the alternative for a specific stock's credit balance time series. This gives clear usage guidance, though it does not cover all possible alternatives.

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