量化策略清单：返回可回测的全部策略（20 条单标的择时 + 9 条组合），含各自参数范围与说明，⭐ 并附「实测表现」（performance 字段）—— 在 800 只（沪深300+中证500）· 2019 年至今、含真实交易成本上跑出的真实成绩。verdict 分级：effective 实测有效 / neutral 一般 / weak 偏弱 / avoid 实测亏损；note 字段给避坑提示。⚠️ 无效的策略同样列出（便于避开常见陷阱，如高换手被成本吃光）。用户问'有哪些策略/哪些策略能赚/哪个策略坑/策略参数是什么'用这个。⚠️ 这是清单 + 实测摘要（不跑新计算）；要真跑回测用 ashare_backtest。⚠️ 付费工具（需 Key）：Standard（¥29.9）及以上。
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the output fields (performance, verdict, note), the grading scale (effective/neutral/weak/avoid), that invalid strategies are intentionally listed, the data basis (800 stocks, 2019–present, with trading costs), and that it does not run new computations. The main missing detail is an explicit statement that the call is read-only/side-effect-free and any rate-limit or freshness behavior.
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 purpose is front-loaded, and the dense single paragraph uses bold and symbols to segment information. Every sentence adds useful content (performance fields, grading, pitfalls, usage triggers, alternative tool, pricing). It is slightly long and could be trimmed, but nothing is redundant enough to warrant a lower score.
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?
An output schema exists, so the description is not obligated to explain return values, yet it helpfully names the key fields (performance, verdict, note). Given the zero-parameter complexity and the presence of a sibling backtest tool, the description covers everything an agent needs: what it returns, when to call it, what not to call it for, and the paid-tier requirement.
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 tool takes zero parameters, so per the rubric the baseline is 4. The description does not need to explain parameter syntax and correctly focuses on output semantics instead.
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: returns the complete list of backtestable quantitative strategies (20 single-instrument timing + 9 portfolio) with parameter ranges, descriptions, and measured performance. It explicitly distinguishes itself from ashare_backtest by stating it does not run new calculations. An agent can immediately tell what this tool is for.
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?
Explicit when-to-use triggers are given ('有哪些策略/哪些策略能赚/哪个策略坑/策略参数是什么'), plus a clear when-not (running a new backtest) with the alternative named: '要真跑回测用 ashare_backtest'. It also warns that this is a paid tool requiring a Key at Standard tier or above, which is essential routing information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
