Which integrations are available for this server?

Supports Docker deployment with container orchestration for the stock data service, including Redis caching layer Provides RESTful API endpoints for stock data queries, financial analysis, and AI-powered research through FastAPI framework Enables high-performance caching of stock market data with automatic fallback mechanisms for improved reliability and speed Offers interactive API documentation and testing interface for all stock market data endpoints

How do I use Stock MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Stock MCP Server show me the current price and RSI for Apple stock" 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.

Stock MCP Server

by huweihua123

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

Stock MCP

English | 中文

开源金融数据 MCP / HTTP 服务，面向 AI Agent、量化脚本和普通后端集成。

中文

这是什么

stock-mcp 是一个开源金融数据服务，提供两套对外接口：

MCP：给 Claude Desktop、Cursor、DeerFlow、各类 Agent 使用
HTTP API：给普通后端、脚本和服务直接调用

它的定位不是“给投资建议”，而是提供：

稳定的数据源接入
标准化的金融工具能力
适合 Agent 使用的 MCP tool / artifact 输出
适合代码执行工作流的 CSV / JSON 数据导出

一键启动

如果你只是想先把服务跑起来，最短路径就是：

git clone https://github.com/yourusername/stock-mcp.git
cd stock-mcp
cp .env.example .env
docker compose up -d --build

启动后默认可访问：

http://127.0.0.1:9898/health
http://127.0.0.1:9898/docs
http://127.0.0.1:9898/mcp

默认 Docker 栈会一起启动：

stock-mcp
redis
postgres

默认端口：

stock-mcp: 127.0.0.1:9898
postgres: 127.0.0.1:15432

说明：

15432 是为了避免占用你本机已有的 5432
容器内部仍然使用 postgres:5432
如果你想修改宿主机映射端口，改 DOCKER_POSTGRES_PORT 即可

核心功能

1. 市场数据

A 股、美股、ETF、指数、加密资产行情
日线 / 分时 / K 线数据
多市场 ticker 解析与标准化
多数据源回退

2. 技术分析

RSI、MACD、均线、布林带等常见指标
K 线形态识别
支撑 / 压力位分析
趋势与动量辅助分析

3. 基本面与研究

估值与基础财务指标
美股宏观和行业研究工具
基于 Tavily 的统一新闻检索
资金流与筹码分布

4. 公告与文档

SEC / EDGAR filings
A 股公告处理
文档 chunk / markdown / 结构化提取

5. Agent / Code Workflow 友好能力

MCP tools 统一注册
MCP artifact 减载，避免把大 blob 直接塞进模型上下文
code-export HTTP 接口，可直接导出 CSV / JSON 给代码执行型 agent

支持的主要数据源

国内源：

Tushare
Akshare
Baostock

国外源：

Yahoo / yfinance
Finnhub
Alpha Vantage
Twelve Data
FRED
CCXT
Crypto
EDGAR

HTTP API 能做什么

当前 HTTP 路由主要分为这些组：

/api/v1/market/*
- 行情、K 线、技术指标、市场数据查询
/api/v1/fundamental/*
- 基本面与估值
/api/v1/money-flow/*
- 资金流分析
/api/v1/news/*
- 统一新闻检索与个股新闻搜索
/api/v1/filings/*
- SEC / A 股公告与文档处理
/api/v1/code-export/*
- 面向代码执行工作流的数据导出
/health
- 健康检查
/docs / /redoc
- OpenAPI 文档

也就是说，这个项目不是只有 MCP。

如果你不打算接 MCP 客户端，完全可以只把它当普通 HTTP 服务来用。

MCP 能做什么

MCP 侧会把这些能力暴露成 tools，主要对应：

行情和资产查询
技术分析
基本面与行业研究
新闻与事件
- 当前统一走 Tavily 检索，不再保留 adapter 原生新闻分支
资金流与筹码
公告与文档处理

MCP 入口：

POST /mcp

适用场景：

Claude Desktop
Cursor
DeerFlow
其他支持 MCP 的 Agent 平台

大体架构

                +-----------------------------+
                |    MCP Clients / HTTP Apps  |
                | Claude / Cursor / Backends  |
                +--------------+--------------+
                               |
                               v
                    +-----------------------+
                    |   Thin Transports     |
                    |  HTTP / MCP / Docs    |
                    +-----------+-----------+
                                |
                                v
                    +-----------------------+
                    |        Runtime        |
                    | auth / proxy / health |
                    | lifecycle / registry  |
                    +-----------+-----------+
                                |
                +---------------+----------------+
                |                                |
                v                                v
        Capability Plugins                Provider Plugins
      market / filings / news         tushare / yahoo / edgar
      money_flow / code_export        finnhub / fred / akshare
                |                                |
                +---------------+----------------+
                                |
                                v
                           Redis / Postgres

职责分层大致是：

src/server/runtime/
- 稳定骨架：配置、鉴权、代理策略、provider/capability registry、生命周期、健康状态
src/server/capabilities/
- 业务能力插件：每个能力自带 plugin / service / http / mcp / schema
src/server/providers/
- 数据源插件：每个 provider 声明自己支持的 contract
src/server/transports/
- 薄入口：HTTP / MCP 只负责协议适配，不承载业务判断
src/server/domain/
- 保留 provider 路由、符号解析、部分领域服务等底层实现；不再作为新增能力入口

当前重构方向是：

不再围绕一个大而全的 BaseDataAdapter 扩展
不再让 route / tool / service 三处并行增长
新能力优先通过 capability plugin 接入
新数据源优先通过 provider plugin + contract 接入

认证模式

stock-mcp 支持三档认证：

1. `none`

本地开发 / 开源试用默认模式
不做鉴权
推荐只监听 127.0.0.1

2. `token`

适合个人部署或内网服务
所有受保护路径统一使用静态 Bearer token

3. `jwt`

适合生产和平台集成
基于 JWTVerifier + OIDC / JWKS
不绑定 Keycloak，兼容任意 OIDC/JWT IdP

在 token 和 jwt 模式下：

/health 匿名开放
/mcp、/api/v1/*、/docs、/redoc、/openapi.json、/ 需要 Bearer token

代理规则

当前项目采用“国外源显式代理，国内源直连”的边界：

显式走代理：

Yahoo / yfinance
Finnhub
Futures
Alpha Vantage
Twelve Data
FRED
CCXT
Crypto
EDGAR

保持直连：

Tushare
Akshare
Baostock

Docker 下默认会把：

PROXY_HOST

覆盖成：

host.docker.internal

这样容器里的国外源可以访问宿主机代理。
如果你的代理不在宿主机上，可以改：

DOCKER_PROXY_HOST

本地运行方式

1. uv 本地运行

uv sync --dev
cp .env.example .env

export STOCK_MCP_AUTH_MODE=none
uv run python -m uvicorn src.server.app:app --host 127.0.0.1 --port 9898

2. Docker Compose 运行

cp .env.example .env
docker compose up -d --build

如果你切换过数据库配置或旧卷和当前配置不一致，建议首次执行：

docker compose down -v
docker compose up -d --build

3. stdio MCP

uv run python -c "import src.server.mcp.server as m; m.create_mcp_server().run(transport='stdio')"

调用示例

HTTP API 示例

curl -X POST http://127.0.0.1:9898/api/v1/technical/indicators/calculate \
  -H "Content-Type: application/json" \
  -d '{
    "symbol": "SSE:600519",
    "period": "6mo",
    "interval": "1d"
  }'

MCP 示例

curl -X POST http://127.0.0.1:9898/mcp \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
      "name": "get_kline_data",
      "arguments": {
        "symbol": "SSE:600519"
      }
    },
    "id": "1"
  }'

常用环境变量

推荐优先关注这些变量：

STOCK_MCP_AUTH_MODE=none|token|jwt
STOCK_MCP_STATIC_BEARER_TOKEN
MCP_HOST, MCP_PORT
DOCKER_POSTGRES_PORT, DOCKER_POSTGRES_USER, DOCKER_POSTGRES_PASSWORD, DOCKER_POSTGRES_DB
PROXY_ENABLED, PROXY_HOST, PROXY_PORT
DOCKER_PROXY_HOST
TUSHARE_ENABLED, TUSHARE_TOKEN, TUSHARE_HTTP_URL
FINNHUB_ENABLED, FINNHUB_API_KEY
TAVILY_API_KEY
SECURITY_MASTER_BACKEND, SECURITY_MASTER_SQLITE_PATH
DATABASE_URL
MCP_TOOL_TIMEOUT_SECONDS, PROVIDER_CALL_TIMEOUT_SECONDS

完整示例见：

/Users/huweihua/java/qiuzhao/stock-mcp/.env.example

测试

uv run pytest

项目目录

stock-mcp/
├── src/server/api/             # FastAPI HTTP 路由
├── src/server/mcp/             # MCP server 与 tools
├── src/server/domain/          # adapter / service / router
├── src/server/infrastructure/  # Redis / Postgres / 外部连接
├── src/server/core/            # 配置、依赖注入、启动流程
├── docs/                       # 补充文档
└── tests/                      # pytest 测试

License

MIT

Related MCP server: Stock MCP Server

English

What it is

stock-mcp is an open-source financial data service with two public interfaces:

MCP for AI agents such as Claude Desktop, Cursor, and DeerFlow
HTTP API for regular backends, scripts, and service integrations

It is designed to provide reliable market data and analysis tools, not investment advice.

One-command start

git clone https://github.com/yourusername/stock-mcp.git
cd stock-mcp
cp .env.example .env
docker compose up -d --build

Default endpoints:

http://127.0.0.1:9898/health
http://127.0.0.1:9898/docs
http://127.0.0.1:9898/mcp

Default services:

stock-mcp
redis
postgres

Default host ports:

stock-mcp: 127.0.0.1:9898
postgres: 127.0.0.1:15432

Main capabilities

Market data across A-shares, US equities, ETFs, indices, and crypto
Technical indicators such as RSI, MACD, moving averages, support/resistance, candlestick patterns
Fundamentals, money flow, chip analysis, filings, and Tavily-backed news search
Agent-friendly MCP tools and code-export endpoints

Public interfaces

HTTP route groups:

/api/v1/market/*
/api/v1/technical/*
/api/v1/fundamental/*
/api/v1/money-flow/*
/api/v1/news/*
/api/v1/filings/*
/api/v1/code-export/*
/health
/docs / /redoc

MCP endpoint:

/mcp

Architecture

MCP clients / HTTP apps
          |
          v
  Thin transports (HTTP / MCP)
          |
          v
Runtime substrate
auth / proxy / lifecycle / registries
          |
          v
Capability plugins <-> Provider plugins
          |
          v
Redis / Postgres

The runtime/plugin refactor is complete. Internal layering:

src/server/runtime/
- stable substrate for auth, proxy policy, provider/capability registry, lifecycle, and health
src/server/capabilities/
- business capability plugins such as market, filings, news, money_flow, code_export
src/server/providers/
- provider plugins declaring which contracts they implement
src/server/transports/
- thin HTTP/MCP protocol adapters
src/server/domain/
- symbol resolution and lower-level domain services behind the runtime/provider facade surface; not an extension entrypoint

Only heavy internal logic remains in src/server/domain/services/; lightweight capabilities stay capability-local by default.

Extension rules:

new capabilities should be added as capability plugins
new data sources should be added as provider plugins
HTTP and MCP surfaces are composed from the same capability registry

Authentication modes

none: local development and quick trial
token: static Bearer token for personal or intranet deployment
jwt: production mode using OIDC / JWKS compatible JWT verification

Proxy boundary

Explicit proxy for foreign providers:

Yahoo / yfinance
Finnhub
Futures
Alpha Vantage
Twelve Data
FRED
CCXT
Crypto
EDGAR

Direct connection for domestic providers:

Tushare
Akshare
Baostock

In Docker mode, PROXY_HOST is overridden to host.docker.internal by default. Override it with DOCKER_PROXY_HOST when needed.

Run modes

Local uv

uv sync --dev
cp .env.example .env
export STOCK_MCP_AUTH_MODE=none
uv run python -m uvicorn src.server.app:app --host 127.0.0.1 --port 9898

Docker Compose

cp .env.example .env
docker compose up -d --build

If you previously used different database settings or stale volumes exist:

docker compose down -v
docker compose up -d --build

stdio MCP

uv run python -c "import src.server.mcp.server as m; m.create_mcp_server().run(transport='stdio')"

Example calls

HTTP:

curl -X POST http://127.0.0.1:9898/api/v1/technical/indicators/calculate \
  -H "Content-Type: application/json" \
  -d '{
    "symbol": "SSE:600519",
    "period": "6mo",
    "interval": "1d"
  }'

MCP:

curl -X POST http://127.0.0.1:9898/mcp \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
      "name": "get_kline_data",
      "arguments": {
        "symbol": "SSE:600519"
      }
    },
    "id": "1"
  }'

Repository layout

stock-mcp/
├── src/server/api/
├── src/server/mcp/
├── src/server/domain/
├── src/server/infrastructure/
├── src/server/core/
├── docs/
└── tests/

License

MIT

Available Tools

22 tools

alphavantage_fetch_to_jsonD

ParametersJSON Schema

Name	Required	Description	Default
`function`	Yes
`symbol`	Yes
`extra_params`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

calculate_support_resistanceD

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes
`period`	No		90d

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

fetch_ashare_filingsD

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes
`filing_types`	No
`start_date`	No
`end_date`	No
`limit`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

fetch_event_sec_filingsD

ParametersJSON Schema

Name	Required	Description	Default
`ticker`	Yes
`start_date`	No
`end_date`	No
`forms`	No
`limit`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

fetch_periodic_sec_filingsD

ParametersJSON Schema

Name	Required	Description	Default
`ticker`	Yes
`year`	No
`quarter`	No
`forms`	No
`limit`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

generate_trading_signalD

ParametersJSON Schema

Name	Required	Default
`symbol`	Yes
`period`	No	30d
`interval`	No	1d

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_asset_infoD

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_chip_distributionD

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes
`days`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_document_chunksD

ParametersJSON Schema

Name	Required	Description	Default
`ticker`	Yes
`doc_id`	Yes
`items`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_filing_markdownD

ParametersJSON Schema

Name	Required	Description	Default
`ticker`	Yes
`doc_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_financial_reportsD

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_kline_dataD

ParametersJSON Schema

Name	Required	Default
`symbol`	Yes
`period`	No	30d
`interval`	No	1d

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_latest_newsD

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_money_flowD

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes
`days`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_north_bound_flowD

ParametersJSON Schema

Name	Required	Description	Default
`days`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_real_time_priceD

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_stock_newsD

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes
`days_back`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_technical_indicatorsD

ParametersJSON Schema

Name	Required	Default
`symbol`	Yes
`period`	No	30d
`interval`	No	1d

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_us_news_sentimentD

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes
`days_back`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_us_valuation_metricsD

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_valuation_metricsD

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes
`days`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

tushare_fetch_to_csvD

ParametersJSON Schema

Name	Required	Description	Default
`api_name`	Yes
`kwargs`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

22 tool updatesv1.0.0Mar 27, 2026
- First observedalphavantage_fetch_to_json
- First observedcalculate_support_resistance
- First observedfetch_ashare_filings
- First observedfetch_event_sec_filings
- First observedfetch_periodic_sec_filings
- First observedgenerate_trading_signal
- First observedget_asset_info
- First observedget_chip_distribution
- First observedget_document_chunks
- First observedget_filing_markdown
- First observedget_financial_reports
- First observedget_kline_data
- First observedget_latest_news
- First observedget_money_flow
- First observedget_north_bound_flow
- First observedget_real_time_price
- First observedget_stock_news
- First observedget_technical_indicators
- First observedget_us_news_sentiment
- First observedget_us_valuation_metrics
- First observedget_valuation_metrics
- First observedtushare_fetch_to_csv

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

D1.8/5.0

Scored 2026-04-18 08:30 across 22 tools

Disambiguation4/5

Most tools have distinct purposes targeting different financial data aspects (e.g., price data, filings, news, technical indicators), though some potential overlap exists between get_stock_news and get_latest_news, and between get_valuation_metrics and get_us_valuation_metrics. The lack of descriptions makes precise disambiguation challenging, but the naming suggests reasonable differentiation.

Naming Consistency4/5

The naming follows a consistent verb_noun pattern with 'get_' or 'fetch_' prefixes for most tools, and descriptive compound nouns. Minor deviations include alphavantage_fetch_to_json and tushare_fetch_to_csv which use different structures, and calculate_support_resistance which uses a verb_verb_noun pattern, but overall the conventions are readable and predictable.

Tool Count3/5

With 22 tools, the count is borderline high for a stock/financial data server, potentially feeling heavy but not extreme. It covers many aspects like price data, filings, news, and technical analysis, which might justify the number, but it could benefit from consolidation or better scoping to avoid redundancy.

Completeness4/5

The tool set appears to cover a broad range of stock market functions including data fetching (price, filings, news), analysis (technical indicators, signals, support/resistance), and metrics (valuation, money flow). Minor gaps might exist in areas like portfolio management or historical backtesting, but core workflows for financial data retrieval and analysis are well-represented.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

xinkuang-china-stock-mcpOAuth
ai.smithery
Access real-time and historical market data for China A-shares and Hong Kong stocks, along with ne…
Finance Search Open Data
246
Helium MCP Server - News, Markets & AI A
io.github.connerlambden
Real-time news with bias scoring, live market data, and AI-powered options pricing
Search Finance AI & Machine Learning
10311
Manawa Terminal A
app.manawa
Live market data, financial analysis, and portfolio research tools across 10,000+ tickers.
Finance Research & Data
311
zwldarren-akshare-one-mcp BOAuth
ai.smithery
Provide access to Chinese stock market data including historical prices, real-time data, news, and…
Finance Search Open Data
93227

Related MCP Servers

Stock Data MCP Server
Finance Search Cryptocurrency
stockmcp
A
license
B
quality
C
maintenance
Provides comprehensive data for A-shares, Hong Kong, and US stocks alongside cryptocurrency markets, supporting technical indicators, news, and financial statements. It features automatic failover across multiple data sources to ensure reliable access to real-time and historical market information.
Updated 6 months ago (2026-03-06 02:36 UTC)
47
34
MIT
Stock MCP Server
Finance Search Data Platforms
kinmeic
A
license
B
quality
D
maintenance
Provides real-time market data for A-shares, Hong Kong, and US stocks using the Tencent Finance API. It enables users to manage stock positions and watchlists through an AI assistant.
Updated 6 months ago (2026-03-03 15:18 UTC)
12
11
ISC
Gangtise Ultra MCP Server
hanlinlibham
F
license
Not graded
quality
D
maintenance
Provides standardized access to Hong Kong stock market data and professional research reports, including broker insights and company notices. It enables intelligent searching, batch queries, and preset analysis templates for market sentiment and investment logic.
Updated 6 months ago (2026-03-06 02:31 UTC)
1
-
Chinese Stock MCP
Finance Search Research & Data
hwibalyu
F
license
Not graded
quality
D
maintenance
Provides real-time quotes, fund flows, and corporate announcements for Chinese A-share stocks. It enables users to search for stocks, analyze financial indicators, and summarize quarterly reports through natural language.
Updated 6 months ago (2026-03-18 05:16 UTC)
-

Stock MCP

中文

这是什么

一键启动

核心功能

1. 市场数据

2. 技术分析

3. 基本面与研究

4. 公告与文档

5. Agent / Code Workflow 友好能力

支持的主要数据源

HTTP API 能做什么

MCP 能做什么

大体架构

认证模式

1. none

2. token

3. jwt

代理规则

本地运行方式

1. uv 本地运行

2. Docker Compose 运行

3. stdio MCP

调用示例

HTTP API 示例

MCP 示例

常用环境变量

测试

项目目录

License

English

What it is

One-command start

Main capabilities

Public interfaces

Architecture

Authentication modes

Proxy boundary

Run modes

Local uv

Docker Compose

stdio MCP

Example calls

Repository layout

License

Available Tools

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

1. `none`

2. `token`

3. `jwt`