screen_kr_momentum

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It specifies filtering logic and optional filters, but does not explicitly state side effects (e.g., read-only, no modifications), rate limits, or error conditions. The phrase '추격 매수 방지' hints at safety but is not fully transparent. The output schema exists, so return value details are covered, but behavior beyond filtering is unclear.

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 detailed but well-structured with section headers ([시드], [사전필터], etc.) and a bulleted list for parameters. It is slightly lengthy but every section contributes to understanding. The front-loading could be improved by placing the main purpose more prominently, but overall it is organized and efficient.

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 complexity (13 parameters, multi-step filtering) and presence of an output schema, the description provides strong context. It explains the algorithm flow and option details. However, it mentions '10가지 기술적 전략' without elaboration, leaving a gap. No mention of error handling or performance considerations. Still, it is largely complete for an experienced agent.

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 13 parameters with 0% description coverage, so the description fully compensates. It provides Korean explanations for each parameter, including allowed values for 'market', defaults, and purpose (e.g., 'top_n: 시드 후보 상한'). This adds significant meaning beyond the bare schema properties, making parameter semantics very clear.

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 filters Korean stocks for volume surge and trend alignment over recent N days. It uses specific verbs and resource description ('필터링합니다') and is distinct from siblings like 'screen_kr_breakout' which focuses on breakouts. The purpose is unambiguous and specific.

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 details a step-by-step filtering pipeline with seed, pre-filters, and optional filters, providing clear context on how the tool operates. However, it does not explicitly compare with sibling tools (e.g., when to use this over screen_kr_breakout or screen_us_momentum) or state when not to use it. The sequential logic is well explained, but exclusions are missing.

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