公共行情SQL查询

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

无注解，描述承担了行为披露的全部责任。明确声明了只读、不发起网络请求、从本地公共 SQL 读取，并解释了 limit 控制返回最近条数。这些信息对代理安全调用至关重要，且没有与任何结构化字段冲突。

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?

三句话，每句都有实质内容：第一句定义核心功能，第二句说明关键参数约定，第三句给出使用场景和限制。没有任何冗余或重复，信息密度高且结构合理。

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?

结合输出模式的存在和100%参数覆盖率，描述已覆盖了核心行为、参数约定、使用场景和限制。唯一可以增强的是给出具体调用示例或明确提及 kind 参数的行为，但这并非必需，整体对于该工具的复杂度来说已经足够完整。

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?

模式描述覆盖率为100%，基线为3。描述额外解释了 symbol 的用法（6位代码查个股，加前缀如 sh000001 查指数），并说明了 limit 的行为（控制返回最近条数），这超出了模式中简短的描述，为参数语义增加了实际价值。

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?

描述明确了具体动作（查询）、资源（公共 SQL market_data.db 中的个股/指数日 K 前复权数据）和范围（个股/指数），并说明了区分特征——只读、不发网络请求。与 stock_quote、market_prices 等兄弟工具形成清晰区分。

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?

明确说明这是"上层任务获取行情的标准只读入口"，提供了使用场景和约束（不发网络请求）。虽然没有明确点名替代工具或说"何时不用"，但已让代理理解这是获取日K行情的首选标准方式，上下文足够清晰。

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