Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@finsage 对比贵州茅台和五粮液的财务指标"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
给 AI Agent 装上「A 股眼睛」——一个专注 A 股的金融分析 MCP Server。 用自然语言分析个股、按条件选股、生成公司简报；数据默认离线 mock，填入 key 即接真实 A 股与 LLM。
🔗 Live Demo：https://a7c068bdc039499baa6defa9a85d7cce.gz3.agentos-app.net （交互式体验四个核心能力，默认展示离线演示数据）
FinSage 把「大语言模型的理解能力」与「金融数据」桥接起来：你（或你的 AI Agent）用中文提问，它先让 LLM 解析意图与参数，再调用数据层拉取行情/财务，最后由 LLM 合成可读的分析结论。既可作为 MCP Server 被任意支持 MCP 的客户端（Claude Desktop、Cursor、各类 Agent 框架）调用，也可作为 REST API 独立部署。
差异化定位：专注 A 股 + 免费数据源（akshare）+ 可插拔 LLM。大多数开源金融 AI 工具盯着美股，A 股场景明显供给不足——这是天然的护城河；而 MCP 形态让它刚好卡在 2026 年「Agent / 工具调用」的流量入口上。
🤝 MCP 原生：四个核心 tools + 一个组合工具直接接入任意 MCP 客户端，让你的 Agent 能「查 A 股、做分析、做对比、出研报」
🔗 组合工具 research_company：一句话完成「分析 + 简报 + 同业对比」，专为 Agent 编排设计，无需多次往返
🌐 Remote MCP：默认 stdio（本地），设 FINSAGE_MCP_TRANSPORT=sse 即可云端暴露，被远程 Agent 通过 MCP 协议调用
🗣️ 自然语言接口：分析贵州茅台的毛利率和ROE、筛选低估值高ROE的股票
🧩 双层可插拔架构：数据层（mock / akshare）、LLM 层（mock / OpenAI 兼容）
📴 零依赖即可跑通：默认 mock 模式离线可用，无需 API key、无需联网
🐳 一键部署：Docker / docker-compose 就绪，附带 GitHub Actions CI
📚 自带 OpenAPI 文档：REST 模式启动后访问 /docs
Related MCP server: AI-Kline MCP Server
flowchart LR
C[MCP 客户端\nClaude/Cursor/Agent] -->|自然语言| MCP[FinSage MCP Server]
API[FastAPI /api/v1] -->|自然语言| SVC[编排层 services]
MCP --> SVC
SVC --> LLM[LLM 层\n解析意图+合成]
SVC --> DATA[数据层\n行情/财务]
LLM -. mock / OpenAI兼容 .-> LLMIMPL[(LLMProvider)]
DATA -. mock / akshare .-> DATAIMPL[(DataProvider)]
SVC --> RESP[结构化 JSON 响应]两种入口共享同一套编排与数据/LLM 层：
入口 | 能力 |
MCP tools |
|
REST API |
|
pip install -r requirements.txt
python -m finsage # 或: finsage-mcp默认以 stdio 方式启动 MCP Server。把它接入支持 MCP 的客户端即可。
远程传输（Remote MCP）：若要让云端部署的 FinSage 被远程 Agent 通过 MCP 协议调用，设置环境变量以 SSE 模式启动：
FINSAGE_MCP_TRANSPORT=sse python -m finsageSSE 端点默认监听
127.0.0.1:8000（可用FASTMCP_SERVER_HOST/FASTMCP_SERVER_PORT调整）。远程客户端（或网关）即可用 MCP-over-SSE 连上来——这正是「给任意 Agent 装 A 股眼睛」的云端形态。
Claude Desktop 配置（claude_desktop_config.json）：
{
"mcpServers": {
"finsage": {
"command": "python",
"args": ["-m", "finsage"],
"env": {
"FINSAGE_DATA_PROVIDER": "mock",
"FINSAGE_LLM_PROVIDER": "mock"
}
}
}
}本地调试（MCP Inspector）：
npx @modelcontextprotocol/inspector python -m finsagepip install -r requirements.txt
uvicorn finsage.main:app --reload --port 8000
# 打开 http://localhost:8000/docsdocker compose up --buildpip install ".[real]" # 安装 akshare + openai
cp .env.example .env
# 编辑 .env:
# FINSAGE_DATA_PROVIDER=akshare
# FINSAGE_LLM_PROVIDER=openai
# FINSAGE_LLM_API_KEY=sk-xxx
python -m finsage # 或 uvicorn finsage.main:app --port 8000支持任意 OpenAI 兼容端点（如 DeepSeek）：把
FINSAGE_LLM_BASE_URL改成对应地址即可。
MCP（任意客户端中自然语言即可）：
用户: 分析贵州茅台的毛利率和ROE
→ analyze_stock(query="分析贵州茅台的毛利率和ROE", symbol="600519")
用户: 筛选低估值高ROE的白酒股
→ screen_stocks(query="低估值高ROE的白酒股", top_n=10)
用户: 给我 600519 的公司简报
→ stock_report(symbol="600519", include_risk=true)
用户: 对比贵州茅台和五粮液
→ compare_stocks(symbols=["600519","000858"])
用户: 给我一份贵州茅台的综合研究，顺便和五粮液比一下
→ research_company(symbol="600519", compare_with=["000858"])REST：
# 综合研究（分析 + 简报 + 同业对比，一步到位）
curl -X POST http://localhost:8000/api/v1/research \
-H 'Content-Type: application/json' \
-d '{"symbol":"600519","compare_with":["000858"]}'REST：
curl -X POST http://localhost:8000/api/v1/analyze \
-H 'Content-Type: application/json' \
-d '{"query":"分析贵州茅台的毛利率和ROE","symbol":"600519"}'
# 对比多标的
curl -X POST http://localhost:8000/api/v1/compare \
-H 'Content-Type: application/json' \
-d '{"symbols":["600519","000858"]}'仓库内含一个零依赖的静态演示页 demo/index.html，可直接体验四个核心能力（个股分析 / 条件选股 / 公司简报 / 多标的对比），对比页带 Chart.js 图表。
在线体验：https://a7c068bdc039499baa6defa9a85d7cce.gz3.agentos-app.net
本地运行：用任意静态服务器打开目录即可，例如 python -m http.server 后访问 demo/index.html
演示页默认展示离线 mock 演示数据；在页面顶部填入你运行中的后端地址（默认 http://localhost:8000）并点「测试连接」，即可切换为实时数据
pip install pytest pytest-asyncio
pytest -q测试全部基于 mock provider，无需网络与 API key 即可通过。
MCP Server 形态（analyze / screen / report / compare 四工具）
多标的对比（/compare + compare_stocks）
组合工具 research_company（分析+简报+同业对比，Agent 编排落地）
Remote MCP（SSE 传输，云端可被远程 Agent 调用）
交互式演示页 demo/（带图表，最利于传播）
新闻/公告情绪分析接入
技术指标（MACD/KDJ）计算层
Streaming 流式选股过程
MIT
用自然语言分析 A 股标的，返回价格、关键财务与 LLM 生成的简明投资要点。
Args: query: 自然语言请求，例如「分析贵州茅台的 ROE 和毛利率」。 symbol: 可选，直接指定标的代码或名称，如 600519 / 贵州茅台。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| symbol | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It clearly states what the tool returns (price, key financials, LLM points) and that it uses an LLM, but it omits potential side effects like data freshness, error behavior, or whether real-time data is used.
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 concise and well-structured: a short purpose statement followed by a compact Args section. Every sentence adds value, with no redundancy or unnecessary detail.
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 absence of annotations and output schema, the description provides adequate coverage of purpose and parameters but lacks depth on output format specifics, financial metrics included, or selection criteria against sibling tools. It is sufficient for a simple tool but leaves some gaps.
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 compensates by explaining each parameter with concrete examples. It clarifies that 'query' is a natural language request and 'symbol' is optional with a specific code/name format, adding value beyond the bare schema.
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?
Description clearly states the tool analyzes A-share stocks using natural language and returns price, key financials, and LLM-generated investment points. This specific verb+resource+output distinguishes it from siblings like screen_stocks (screening) and compare_stocks (comparing).
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 provides usage context through query and symbol examples, implying when to use the tool (for natural language stock analysis). However, it does not explicitly mention when not to use it or alternatives such as stock_report or screen_stocks, leaving tool-selection guidance vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
横向对比多只 A 股标的的关键指标，并返回 LLM 生成的对比结论。
Args: symbols: 标的代码或名称列表，如 ["600519","000858"]。 metrics: 可选对比维度(英文key)，默认核心财务指标。
| Name | Required | Description | Default |
|---|---|---|---|
| metrics | No | ||
| symbols | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses that the output is an LLM-generated conclusion, which is a notable behavioral trait, and mentions default core financial indicators. However, it does not cover limitations, permission requirements, or output structure.
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 two short paragraphs, front-loading the purpose and then listing parameters. Every sentence earns its place with no 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?
The tool is simple (2 params), and the description covers purpose, parameters, and output nature. However, without an output schema, it could further specify the structure of the comparison conclusion or constraints on the number of symbols, leaving a small gap.
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 descriptions are absent (0% coverage), but the description explains both parameters: symbols as a list of codes/names with an example, and metrics as optional English keys with default behavior. This adds essential meaning beyond the bare schema, though valid metric keys are not enumerated.
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 compares key indicators of multiple A-share stocks and returns LLM-generated conclusions. This distinguishes it from sibling tools like analyze_stock (single stock analysis) and stock_report (single stock report).
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 implies usage for multi-stock comparison but does not explicitly state when to use this tool over alternatives. No when-not conditions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按自然语言条件筛选 A 股标的，返回按得分排序的候选清单。
Args: query: 自然语言筛选条件，例如「低估值且高 ROE 的白酒股」。 top_n: 返回前 N 只，默认 10，范围 1-50。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_n | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a key behavioral trait—returns a score-sorted candidate list—and describes the top_n range. However, it does not explicitly state that the operation is read-only, what happens on invalid queries, or any rate/result limits beyond top_n.
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 concise and well-structured: a single front-loaded purpose sentence followed by a clean Args list. No wasted words, and every sentence adds value.
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 simple 2-parameter tool with no output schema, the description is complete: it covers the query semantics, top_n behavior, and the return format (scored candidate list). No critical gaps for the intended use case.
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%, but the description's Args section fully compensates. It explains query with a concrete example ('低估值且高 ROE 的白酒股') and defines top_n's default and range (1-50). This goes beyond the bare schema types.
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 states a specific verb ('筛选' / screen), a specific resource ('A 股标的' / A-share stocks), and a concrete output ('返回按得分排序的候选清单' / returns a candidate list sorted by score). This clearly distinguishes it from siblings like analyze_stock and compare_stocks, which perform different operations.
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 implies usage: use when you want to filter stocks by natural language criteria. However, it provides no explicit when-to-use, when-not-to-use, or exclusions relative to the sibling tools. There is no mention of alternatives or complementary tools, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
生成单只 A 股标的的公司概览与风险点简报。
Args: symbol: 标的代码或名称，例如 600519 / 贵州茅台。 include_risk: 是否包含风险点，默认 True。
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| include_risk | No |
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, yet it reveals little beyond the output shape. It does not state whether the tool performs live data lookups, whether it is read-only, what happens for invalid or non-A-share symbols, or any potential failure modes. The 'A 股' scope is a useful constraint but insufficient for a financial data tool.
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 compact and well-structured: a single purpose sentence followed by a lean Args block. Every line earns its place, the most important information is front-loaded, and the parameter documentation follows a standard readable format with no filler.
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 simple two-parameter tool, the description covers the essentials — purpose and parameter semantics — adequately. However, with zero annotations and no output schema, it should offset those gaps by disclosing more behavioral context, such as data sources, read-only guarantees, or failure behavior, and by hinting at when it should be selected over analyze_stock. Those clear gaps keep it at minimum viable rather than better.
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: the Args section explains symbol's accepted formats (code or name, with concrete examples '600519 / 贵州茅台') and include_risk's meaning and default value (True). This adds real value beyond the bare schema; the only minor gap is the lack of stricter format constraints for symbol beyond the example.
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 uses a specific verb ('生成' / 'generate') and a specific resource ('单只 A 股标的的公司概览与风险点简报' — company overview and risk briefing for a single A-share stock). The '单只' (single) scope differentiates it from screen_stocks and compare_stocks, but it never distinguishes itself from the near-sibling analyze_stock, leaving ambiguity about when each single-stock tool is appropriate.
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 guidance on when to use this tool versus its alternatives. It neither names sibling tools nor states exclusion conditions (e.g., 'for broader screening, use screen_stocks'), and the closest sibling analyze_stock is not mentioned at all. The single-stock scope is an implication of the purpose, not explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyze_stock and stock_report both target single stocks and return financial information, but analyze_stock is query-driven with LLM investment points while stock_report is a structured risk-focused briefing. screen_stocks and compare_stocks are clearly distinct for multi-stock scenarios.
Three tools follow verb_noun pattern (analyze_stock, screen_stocks, compare_stocks), but stock_report breaks the pattern as noun_noun. Singular/plural inconsistency also appears (stock vs stocks).
Four tools provide a focused set for A-share analysis: single-stock analysis, screening, detailed report, and comparison. This is well-scoped and each tool has a clear purpose.
Core analysis workflows are covered (analyze, screen, report, compare), but there is no direct tool for historical price data or sector-level scans. Minor gap that agents can work around via analyze_stock.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
China A-share market data for research, backtesting and AI agents via MCP.
MCP server giving AI agents one-connection access to China A-share market intelligence: financials,
Real SEC, 13F, insider, congress & macro data your AI agent can cite. Hosted MCP, 24 tools.
Read-only China A-share data for AI agents: market, limit-up, capital flow and disclosures.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MikeWang1994/finsage'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
