Skip to main content
Glama
zhenzp

Fund MCP Server

by zhenzp

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:sse

SSE 端点: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

环境变量说明

变量名

默认值

说明

FUND_KB_API_URL

https://report.haiyu.datavita.com.cn/api/admin/knowledge/query

基金知识库 API 地址

PORT

3000

服务监听端口

NODE_ENV

development

运行环境

MCP_TRANSPORT

stdio

MCP 传输模式

快速开始

🚀 一键部署

Windows 用户

# 双击运行或在命令行执行
deploy.bat

Linux/macOS 用户

# 给脚本执行权限并运行
chmod +x deploy.sh
./deploy.sh

📦 手动部署

  1. 安装依赖

    npm install
  2. 构建项目

    npm run build
  3. 启动服务

    # HTTP 模式
    npm run start:http
    
    # SSE 模式
    npm run start:sse
    
    # 标准 MCP 模式
    npm start

部署选项

1. 快速部署 (开发环境)

  • Windows: deploy.batscripts\deploy.bat

  • Linux/macOS: ./deploy.sh./scripts/deploy.sh

2. 生产环境部署

  • Linux: ./scripts/deploy-production.sh deploy

  • systemd 服务: 参考 scripts/DEPLOYMENT.md

3. Docker 部署

cd scripts
docker-compose up -d

4. 查看详细部署说明

  • 查看 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 restart

Docker

# 查看状态
docker-compose ps

# 查看日志
docker-compose logs -f

# 重启服务
docker-compose restart

故障排除

常见问题

  1. 端口被占用

    lsof -i :3000
    kill -9 <PID>
  2. 权限问题

    chmod +x scripts/*.sh
  3. 依赖问题

    npm cache clean --force
    rm -rf node_modules package-lock.json
    npm install

日志位置

  • 应用日志:logs/fund-mcp-server.log

  • 错误日志:logs/fund-mcp-server-error.log

贡献

  1. Fork 项目

  2. 创建功能分支

  3. 提交更改

  4. 推送到分支

  5. 创建 Pull Request

许可证

Apache-2.0

支持

  • 📖 部署文档:scripts/DEPLOYMENT.md

  • 🐛 问题反馈:GitHub Issues

  • 💬 讨论:GitHub Discussions

自动发布到 npm

当你推送版本标签(如 v0.1.1)时,仓库会使用 GitHub Actions 自动发布到 npm。

前置准备:

  • 在 npm 创建 Automation Token,并在 GitHub 仓库 SettingsSecrets and variablesActions 中添加:

    • 名称: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 tools
fund.echoC

Echo back a message. Example interface for scaffold.

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYesText to echo back

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

获取的知识库列表信息

ParametersJSON Schema
NameRequiredDescriptionDefault
kwNo关键词,支持模糊查询
pageSizeNo每页数量,默认10
pageNumNo页码,默认1

TDQS

C2.6/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose3/5

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.

Usage Guidelines2/5

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.

Tool Schema Changelog

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

  1. 3 tool updates
    • First observedfund.echo
    • First observedfund.knoewledge
    • First observedfund.stock_search

TDQS

B3/5.0

Scored across 3 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness2/5

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

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    B
    quality
    D
    maintenance
    A 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.
    2
    MIT
  • A
    license
    B
    quality
    B
    maintenance
    A Model Context Protocol server that enables interaction with Yahoo Finance to retrieve stock pricing, company information, and historical financial data through natural language queries.
    10
    1,798 PyPI
    29
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    A 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.
    49
    MIT
  • A
    license
    B
    quality
    D
    maintenance
    A 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.
    15
    41 npm
    3
    MIT