ETF 전체시세 스크리너 (시장 전체)

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

No annotations provided, so the description carries the burden. It discloses the data source (키움 ka40004), the ~1,150 universe size, performance implication ('좁힐수록 조회도 빨라집니다' via tax_type filter), and a caveat that index_name matches only ~1/4 of tickers. Lacks explicit statement about safety/read-only nature or pagination, but adds meaningful behavioral context given zero annotations.

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?

Description is two dense sentences that pack purpose, scope, examples, and alternatives. Slightly verbose with the Korean phrasing but every clause earns its place. Could be tightened but is efficiently front-loaded with the core purpose.

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?

Well-completed for a screening tool with 6 params at 100% schema coverage and no output schema. Variables like sort enums and filters are well-explained in schema; description resolves the key decision of when to use it vs siblings. Missing return-format clarification but acceptable given the task type.

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 coverage is 100% with detailed param descriptions. The description adds practical context beyond schema: tax_type performance hint, min_volume filtering rationale (거래정지 종목 극단적 괴리율 제거), manager prefix-partial-match semantics, and index_name 1/4 coverage caveat. This enriches the enum and integer params with domain knowledge.

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?

Specific verb '스크리너' + resource '상장 ETF 전 종목(약 1,150개)' + sort dimensions (괴리율·등락률·거래량·추적오차). Clearly distinguishes from ETFs-only tools (get_etf_info, get_etf_returns) and general stock screeners (get_valuation_rank, get_ranking) by stating it's for when '종목을 아직 고르지 않은 상태에서'.

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?

Explicitly states when to use ('종목을 아직 고르지 않은 상태에서 찾을 때'), and names concrete alternatives with when NOT to use (get_etf_info, get_etf_returns, get_valuation_rank, get_ranking). Even gives use case examples like 'NAV보다 비싸게 거래되는 ETF', '거래량 많은 ETF'.

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