Fund MCP Server
Click on "Deploy 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., "@Fund MCP Serversearch for information about index funds"
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.
Fund MCP Server
一个基于 Model Context Protocol (MCP) 的基金知识库服务器,提供基金相关知识的查询和检索功能1。
服务介绍
Fund MCP Server 是一个专门为基金投资领域设计的 MCP 服务器,通过集成外部知识库 API,为用户提供基金知识查询服务。该服务器支持多种部署模式,包括标准 MCP 协议、HTTP REST API 和 Server-Sent Events (SSE) 模式。
主要功能
基金知识查询: 通过关键词搜索基金相关知识库
多协议支持: 支持 MCP 标准协议、HTTP REST API 和 SSE
灵活部署: 支持本地部署、Docker 部署和生产环境部署
跨平台: 支持 Windows、Linux 和 macOS
技术特性
基于 TypeScript 开发,类型安全
使用 Zod 进行参数验证
支持环境变量配置
提供健康检查和监控接口
Related MCP server: MCP Yahoo Finance
服务配置
MCP sever configuration
{
"mcpServers": {
"fund-mcp-server": {
"command": "npx",
"args": [
"-y",
"fund-mcp-server"
]
}
}
}
HTTP REST API 配置
启动 HTTP 模式服务:
npm run start:http服务将在 http://localhost:3000 启动,提供以下 API 端点:
GET /api/health- 健康检查GET /api/tools- 获取可用工具列表POST /api/tools/call- 调用工具
SSE 模式配置
启动 SSE 模式服务:
npm run start:sseSSE 端点:http://localhost:3000/sse
环境变量配置
必需环境变量
创建 llm-config.env 文件或设置以下环境变量:
# 知识库 API 配置
FUND_KB_API_URL=https://report.haiyu.datavita.com.cn/api/admin/knowledge/query
# 服务端口配置
PORT=3000
# 运行环境
NODE_ENV=production
# MCP 传输模式 (可选: sse, http)
MCP_TRANSPORT=http环境变量说明
变量名 | 默认值 | 说明 |
|
| 基金知识库 API 地址 |
|
| 服务监听端口 |
|
| 运行环境 |
|
| MCP 传输模式 |
快速开始
🚀 一键部署
Windows 用户
# 双击运行或在命令行执行
deploy.batLinux/macOS 用户
# 给脚本执行权限并运行
chmod +x deploy.sh
./deploy.sh📦 手动部署
安装依赖
npm install构建项目
npm run build启动服务
# HTTP 模式 npm run start:http # SSE 模式 npm run start:sse # 标准 MCP 模式 npm start
部署选项
1. 快速部署 (开发环境)
Windows:
deploy.bat或scripts\deploy.batLinux/macOS:
./deploy.sh或./scripts/deploy.sh
2. 生产环境部署
Linux:
./scripts/deploy-production.sh deploysystemd 服务: 参考
scripts/DEPLOYMENT.md
3. Docker 部署
cd scripts
docker-compose up -d4. 查看详细部署说明
查看
scripts/README.md获取脚本说明查看
scripts/DEPLOYMENT.md获取详细部署指南
项目结构
fund-mcp-server/
├── deploy.bat # Windows 部署入口
├── deploy.sh # Linux/macOS 部署入口
├── scripts/ # 部署脚本文件夹
│ ├── README.md # 脚本说明
│ ├── DEPLOYMENT.md # 详细部署指南
│ ├── deploy.sh # Linux 快速部署
│ ├── deploy.bat # Windows 快速部署
│ ├── deploy-production.sh # 生产环境部署
│ ├── fund-mcp-server.service # systemd 服务配置
│ ├── Dockerfile # Docker 镜像
│ └── docker-compose.yml # Docker Compose
├── tool-registry/ # 工具注册表
├── tool-handlers/ # 工具处理器
├── common/ # 公共模块
├── dist/ # 构建输出
└── package.json # 项目配置端口配置
默认端口:3000
环境变量:
PORT=8080命令行:
--port 8080
开发
安装依赖
npm install开发模式
npm run watch构建
npm run build测试
npm test服务管理
生产环境
# 查看状态
./scripts/deploy-production.sh status
# 查看日志
./scripts/deploy-production.sh logs
# 重启服务
./scripts/deploy-production.sh restartDocker
# 查看状态
docker-compose ps
# 查看日志
docker-compose logs -f
# 重启服务
docker-compose restart故障排除
常见问题
端口被占用
lsof -i :3000 kill -9 <PID>权限问题
chmod +x scripts/*.sh依赖问题
npm cache clean --force rm -rf node_modules package-lock.json npm install
日志位置
应用日志:
logs/fund-mcp-server.log错误日志:
logs/fund-mcp-server-error.log
贡献
Fork 项目
创建功能分支
提交更改
推送到分支
创建 Pull Request
许可证
Apache-2.0
支持
📖 部署文档:
scripts/DEPLOYMENT.md🐛 问题反馈:GitHub Issues
💬 讨论:GitHub Discussions
自动发布到 npm
当你推送版本标签(如 v0.1.1)时,仓库会使用 GitHub Actions 自动发布到 npm。
前置准备:
在 npm 创建 Automation Token,并在 GitHub 仓库
Settings→Secrets and variables→Actions中添加:名称:
NPM_TOKEN值:你的 npm Automation Token
使用方式:
npm version patch # 或 minor/major
git push --follow-tags
# 或者显式推送标签
# git push origin v0.1.1工作流位于 .github/workflows/publish-on-tag.yml,规则:
触发条件:推送
v*.*.*标签步骤:安装依赖 → 构建 → 将
package.json版本对齐标签 →npm publish --access public
Available Tools
3 toolsfund.echoC
Echo back a message. Example interface for scaffold.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Text to echo back |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool echoes a message, implying a simple read-like operation, but doesn't cover traits like side effects, error handling, or performance. For a tool with zero annotation coverage, this is a significant gap in transparency.
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 front-loaded with the core purpose in the first sentence. The second sentence adds context about it being an example interface, which is relevant. It avoids unnecessary details, though it could be slightly more structured for clarity.
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 lack of annotations and output schema, the description is incomplete. It explains the basic function but doesn't address behavioral aspects like what 'echo back' entails (e.g., format, latency) or provide usage context. For a tool with minimal structured data, more descriptive detail is needed.
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 100%, so the input schema already documents the single parameter 'message' with its type and description. The description adds no additional meaning beyond this, such as format examples or constraints. Baseline 3 is appropriate when the schema handles parameter documentation adequately.
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's purpose: 'Echo back a message.' It specifies the verb ('echo back') and resource ('a message'), making it easy to understand. However, it doesn't differentiate from sibling tools like 'fund.knowledge' or 'fund.stock_search', which likely serve different purposes, so it misses full sibling distinction.
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 no guidance on when to use this tool versus alternatives. It mentions 'Example interface for scaffold,' which implies it's a demo or test tool, but doesn't specify contexts, exclusions, or comparisons to siblings. Without explicit usage rules, the agent lacks direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fund.knoewledgeC
获取的知识库列表信息
| Name | Required | Description | Default |
|---|---|---|---|
| kw | No | 关键词,支持模糊查询 | |
| pageSize | No | 每页数量,默认10 | |
| pageNum | No | 页码,默认1 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('get knowledge base list information') without mentioning any behavioral traits such as whether it's read-only, requires authentication, has rate limits, or what the return format looks like. This leaves significant gaps for a tool with parameters and no output schema.
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 a single phrase '获取的知识库列表信息', which is concise and front-loaded with the core action. However, it's overly brief and under-specified for a tool with parameters and no output schema, slightly reducing its effectiveness despite the efficient structure.
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 tool has 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the return values, behavioral context, or usage scenarios, leaving the agent with insufficient information to fully understand how to invoke and interpret results from this tool.
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 input schema has 100% description coverage, with clear documentation for 'kw' (keyword for fuzzy search), 'pageSize' (items per page, default 10), and 'pageNum' (page number, default 1). The description adds no additional meaning beyond what the schema provides, so it meets the baseline of 3 where the schema does the heavy lifting.
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 '获取的知识库列表信息' translates to 'Get knowledge base list information', which states the purpose (retrieving a list) but is vague about what 'knowledge base' refers to and doesn't distinguish from siblings like 'fund.echo' or 'fund.stock_search'. It provides a basic verb+resource but lacks specificity and sibling differentiation.
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?
No guidance is provided on when to use this tool versus alternatives like 'fund.stock_search'. The description implies it's for listing knowledge bases, but there's no explicit context, exclusions, or prerequisites mentioned, leaving the agent with no usage direction beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fund.stock_searchC
搜索股票信息,基于东方财富API
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | 搜索关键字,如股票代码、股票名称或拼音简称 | |
| count | No | 返回结果数量,默认10,最大50 |
TDQS
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. It mentions the API source but doesn't describe rate limits, authentication needs, error handling, or what happens when no results are found. For a search tool with external API dependencies, this leaves significant gaps in understanding its operational 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 description is extremely concise with a single sentence that directly states the tool's purpose and source. Every word earns its place, and there's no redundant or unnecessary information.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the search returns (e.g., stock codes, names, prices), how results are formatted, or any limitations of the API. For a tool with external dependencies and no structured output documentation, more context is needed.
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 schema description coverage is 100%, with both parameters ('input' and 'count') fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 where the schema does the heavy lifting.
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's purpose as '搜索股票信息' (search for stock information) with the specific source '基于东方财富API' (based on East Money API). It distinguishes from siblings like 'fund.echo' and 'fund.knoewledge' by focusing on stock search functionality. However, it doesn't explicitly differentiate from potential similar tools beyond the sibling list provided.
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 no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, limitations, or scenarios where other tools might be more appropriate. The agent must infer usage from the purpose alone.
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.
3 tool updates
- First observed
fund.echo - First observed
fund.knoewledge - First observed
fund.stock_search
TDQS
Scored across 3 tools
The three tools have clearly distinct purposes: echo is for testing/echoing messages, knowledge is for retrieving knowledge base information, and stock_search is for searching stock data. There is no overlap in functionality, making it easy for an agent to select the correct tool.
All tools follow a consistent naming pattern: 'fund.' prefix followed by a descriptive term (echo, knowledge, stock_search). The terms are in snake_case and clearly indicate the tool's function, with no deviations or mixed conventions.
With only 3 tools, the server feels thin for a 'Fund MCP Server' that implies financial or investment functionality. While the tools cover basic operations (testing, knowledge retrieval, stock search), the scope suggests more comprehensive tools (e.g., for portfolio management, analysis) might be missing, making it borderline appropriate.
The tool surface is significantly incomplete for a fund-related domain. It lacks core operations such as creating/updating/deleting fund data, analyzing investments, or managing portfolios. The tools provided (echo, knowledge list, stock search) are limited and do not support typical fund management workflows, leading to potential agent failures.
Maintenance
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server for querying Forkast documentation
A Model Context Protocol server for Wix AI tools
MCP server giving AI agents one-connection access to China A-share market intelligence: financials,
Related MCP Servers
- AlicenseBqualityDmaintenanceA Model Context Protocol server that provides LLMs with access to Valyu's knowledge retrieval and feedback APIs for searching proprietary/web sources and submitting transaction feedback.2MIT
- AlicenseBqualityBmaintenanceA Model Context Protocol server that enables interaction with Yahoo Finance to retrieve stock pricing, company information, and historical financial data through natural language queries.101,798 PyPI29MIT
- AlicenseNot gradedqualityBmaintenanceA Model Context Protocol server that provides intelligent stock data assistance through Tushare's financial data API, enabling users to query comprehensive stock information, financial data, and market indices through natural language.49MIT
- AlicenseBqualityDmaintenanceA Model Context Protocol server that enables Claude Desktop to access investment fund data in Turkey through the FonParam API, allowing users to list, compare, and analyze funds, view company statistics, and get inflation data.1541 npm3MIT