A 股选股 MCP Server — 把一套 5 层漏斗选股引擎封装为 MCP 工具，供 Claude / Cursor / 任意 LLM Agent 直接调用。
A-share stock screener exposed as MCP tools — a 5-layer funnel screening engine your LLM agent can call directly.
数据源(腾讯行情/Tushare) → 5层漏斗选股引擎 → SQLite → MCP Server ──→ 你的 Agent
↑ stdio
Claude / Cursor / DSH / 自研Agent工具 | 说明 | 耗时 |
| 5 层漏斗选股：主板过滤 → 换手率<10% → 全天最低价>MA5 → 创5年新高 → 筹码峰非顶部。 | full 2–5 min，test ~30s |
| 查询最近一次选股结果（读 SQLite，秒回，演示首选） | <1s |
| 单只实时报价，如 | ~1s |
选股结果入库去重（is_new 标记新增/续选），天然支持 Agent 做"今天有哪些新入选"这类增量分析。
Related MCP server: stock-mcp-server
# 安装
pip install git+https://github.com/Sqyl/ashare-mcp-server.git
# 环境变量（全市场扫描需要 Tushare 免费token；test/pool 模式和实时报价不需要）
export TUSHARE_TOKEN=xxx # https://tushare.pro 免费注册
# export ASHARE_DB=/path/to/ashare.db # 可选，默认 ./data/ashare.dbClaude Code / Cursor / 任意 MCP client 配置：
{
"mcpServers": {
"ashare-screener": {
"command": "ashare-mcp",
"env": { "TUSHARE_TOKEN": "xxx" }
}
}
}配好后对你的 Agent 说：
"先 run_screen test 跑个小样本，然后告诉我今天有哪些入选" "查一下 600519.SH 现在什么价"
层 | 条件 | 数据源 |
1 | 主板（60x/000/001/002），换手率 < 10%，剔除 ST/停牌 | 腾讯实时快照（批量） |
2 | 全天最低价 > MA5 | Tushare 按交易日批量 |
3 | 前复权最高价创近 5 年新高 | 腾讯日 K（带重试） |
4 | 筹码峰（120 日量价分布）不在当前价位顶部 | 腾讯日 K 计算 |
5 | 与前一日结果去重，标记 🆕 新入选 | SQLite |
策略本身来自个人回测迭代（如换手率阈值 8%→10% 的调整依据），仅供学习研究，不构成投资建议。
限频对策：腾讯实时接口按 50 支/批分组；日 K 拉取带 3 次重试 + 0.3s 间隔；Tushare 按交易日批量查询取代逐只查询
字段陷阱：腾讯实时接口指数与个股字段数不同（~45 vs ~60 字段），解析按 len(f) 分流处理
前复权口径：新高判断统一用腾讯前复权日 K，避免除权假突破
并发安全：SQLite WAL 模式，选股写入与实时采集互不阻塞
MIT
查最近一次选股结果(读DB秒回，演示首选)。空库时友好提示。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does reasonably well: it discloses that the read hits the DB and returns instantly, and that an empty database produces a friendly prompt instead of an error. Permissions, rate limits, and result shape are not covered, keeping it below a 5.
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?
Two short clauses with the core purpose front-loaded and zero padding. The parenthetical demo hint is slightly promotional rather than informational, but the entry still earns its length.
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?
A zero-parameter tool with an output schema, so return values need not be described. The description covers purpose, latency expectations, and the empty-DB edge case, which is sufficient for correct invocation.
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 the baseline of 4 applies; there is nothing for the description to clarify beyond the implicit 'most recent' default behavior.
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?
States a specific verb+resource: retrieves the most recent stock-screening results, with 'latest' clarifying scope against siblings like run_screen and quote. It does not explicitly name a sibling, so it falls short of a 5, but an agent can distinguish it from run_screen (which produces a screen) without opening a schema.
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?
'演示首选' (preferred for demos) and '读DB秒回' (instant DB read) imply when to reach for this tool rather than run_screen, but there is no explicit when-not or named alternative. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
实时报价。ts_code 格式: 600519.SH / 000858.SZ
| Name | Required | Description | Default |
|---|---|---|---|
| ts_code | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 hints that data is real-time (a useful freshness trait) but says nothing about authentication, rate limits, market-hours behavior, or whether results are cached/delayed.
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?
Two short sentences, front-loaded with purpose and then the format hint, with no filler. It is arguably under-specified rather than over-long, but nothing is wasted.
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 return fields need not be explained, and the single parameter's format is covered. However, for a tool with two nearby siblings, the complete absence of usage guidance leaves a real gap in selecting it correctly.
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%, so the description must compensate, and it does: it supplies the exact ts_code format with concrete examples ('600519.SH / 000858.SZ'), which the schema omits entirely. It could still clarify what the suffix means (exchange) or whether bare codes are accepted.
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?
States a clear verb+resource pair ('实时报价' / real-time quote), so an agent knows it fetches current price data for a security. It does not differentiate itself from siblings run_screen or latest_results, leaving the boundary between 'quote' and 'latest_results' ambiguous.
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?
There is no statement of when to use this tool versus run_screen or latest_results, and no prerequisites or exclusions. The agent must infer usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
跑完整5层漏斗选股(主板/换手/MA5/5年新高/筹码峰)。
mode: full=全市场(2-5分钟, 需 TUSHARE_TOKEN) | pool=自选池 | test=小样本(10支)
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | full |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose meaningful behavior: execution time (2-5 minutes), an authentication prerequisite (TUSHARE_TOKEN) for full mode, and the sample size for test mode. It never states that the operation is read-only or whether it has side effects, which is the remaining gap.
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?
Two dense lines: the purpose first, then a pipe-delimited mode table. No filler, no repetition, and the highest-value constraint (runtime, token) is attached directly to the mode it applies to.
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?
For a multi-minute screening job with a default-able single parameter, the description covers purpose, mode semantics, cost, and auth. An output schema exists so return values need no explanation, but the description omits whether pool mode depends on prior configuration or whether results are persisted for latest_results.
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 0% and the schema exposes 'mode' as a bare string with no enum, so the description must compensate — and it does, defining all three values (full/pool/test) with their scope and cost. It does not state that full is the default, which the schema alone conveys.
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 names a specific verb+resource ('跑完整5层漏斗选股') and enumerates the five funnel layers, so an agent knows exactly what the tool computes. It does not explicitly contrast itself with the siblings latest_results or quote, which is the only gap.
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 mode line gives concrete when-to-use conditions for each mode: full for the whole market with a 2-5 minute cost and TUSHARE_TOKEN requirement, pool for a watchlist, test for a 10-stock sample. There is no tool-level routing guidance (e.g. when to prefer latest_results instead), so it stops short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0latest_resultsquoterun_screenScored across 3 tools
run_screen executes the funnel, latest_results reads stored output, and quote fetches live prices — three clearly distinct actions on distinct targets. No overlap or plausible misselection between them.
All names use lowercase snake_case, which is consistent. However, only run_screen follows a strict verb_noun pattern; latest_results and quote are noun-only, a minor deviation rather than a break in convention.
Three tools is slightly thin for a screener but each earns its place: execute, retrieve results, and live quotes. No redundancy, though one more tool (e.g. parameterized/custom screen) would round it out.
The core loop of run-screen → view-results → quote is covered, but there is no way to customize screen criteria, browse historical runs, or look up stock metadata beyond the quote call. These are notable gaps an agent may need to work around.
China A-share data for AI agents: 57 read-only tools plus 6 tools for your own watchlist.
China A-share market data over MCP: 22 tools for quotes, K-line, financials, money flow, top-trader boards, sectors, macro, convertible bonds and factor screening. Five tools need no API key, so you can connect and try it immediately.
China A-share market data for research, backtesting and AI agents via MCP.
Screen China A-shares for dividend yield and value quality on live Eastmoney data.
