连板潜力股扫描

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

With no annotations provided, the description carries the burden of disclosing side effects. It does explicitly state that results are written to reports.db, which is an important behavioral trait. However, it does not mention whether repeated runs overwrite or append, whether the date parameter selects past trading days, or any failure/re-run semantics.

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 a single, information-dense sentence that front-loads the core operation and packs in scoring criteria, output destination, and optimal run timing. Every clause adds value, though the long comma-separated chain could be slightly better structured.

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 the main purpose, the scoring methodology, the output side effect, and the best execution time, which is reasonably complete for a one-parameter scan/write tool. It is weakened by the lack of date parameter semantics and absence of guidance on how to interpret or retrieve the written reports.db data.

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 0% and there is one optional 'date' parameter that is not described. The description mentions '当日' (current day) and suggests after-close execution, but it does not explain how the date parameter is formatted, whether it defaults to today, or how historical dates are handled. The description fails to compensate for the schema's lack of parameter documentation.

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—scanning the day's limit-up stocks, backtracking consecutive limit-up height and turnover, and scoring with an 8-item checklist. It also identifies the output destination (reports.db), making the tool's function unambiguous. However, it does not explicitly differentiate itself from sibling tools like limit_up_latest or stock_zt_pool_em.

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 '收盘后运行最佳' gives a clear timing context: this tool is best executed after market close. This is useful practical guidance. It does not provide exclusions or explicitly name alternative tools, but the timing constraint is a clear usage signal.

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