MCP Project Query Server
# MCP Project Query Server
一个基于 Model Context Protocol (MCP) 的项目查询服务器,采用 TypeScript 开发,具有 Spring Boot 风格的目录结构。
## 项目结构
```
mcp-demo/
├── src/
│ ├── main/
│ │ ├── controllers/ # 控制器层 - 处理MCP工具调用
│ │ │ ├── ProjectController.ts
│ │ │ └── WallpaperController.ts
│ │ ├── services/ # 服务层 - 业务逻辑处理
│ │ │ ├── ProjectService.ts
│ │ │ └── WallpaperService.ts
│ │ ├── repositories/ # 数据访问层 - 数据持久化
│ │ │ └── ProjectRepository.ts
│ │ ├── models/ # 数据模型 - 接口定义
│ │ │ └── Project.ts
│ │ ├── config/ # 配置类
│ │ │ └── AppConfig.ts
│ │ └── index.ts # 主入口文件
│ └── resources/ # 资源文件
│ └── projects.json # 项目数据
├── dist/ # 构建输出目录
├── package.json
├── rollup.config.mjs
└── tsconfig.json
```
## 功能特性
### 项目管理功能
- `get_project_info`: 根据项目名称查询项目信息
- `get_project_count`: 获取项目总数
- `get_project_all`: 获取所有项目列表
- `add_project`: 新增项目
### 壁纸功能
- `get_random_wallpaper`: 从 Bing 壁纸获取随机壁纸
## 开发指南
### 安装依赖
```bash
npm install
```
### 开发模式
```bash
npm run dev
```
### 构建项目
```bash
npm run build
```
### 启动服务
```bash
npm start
```
### 构建输出
构建完成后,`dist` 目录将包含:
```
dist/
├── index.js # 统一的 CommonJS 入口文件
└── resources/ # 复制的资源文件
└── projects.json # 项目数据文件
```
## 架构设计
本项目采用分层架构设计,参考 Spring Boot 的目录结构:
1. **Controller 层**: 负责处理 MCP 工具调用,参数验证和响应格式化
2. **Service 层**: 包含业务逻辑,处理具体的业务需求
3. **Repository 层**: 负责数据访问和持久化
4. **Model 层**: 定义数据结构和接口
5. **Config 层**: 管理应用配置
这种设计提供了良好的代码组织、可维护性和可扩展性。
## 技术栈
- **TypeScript**: 提供类型安全和更好的开发体验
- **Rollup**: 模块打包工具
- **MCP SDK**: Model Context Protocol 开发工具包
- **Zod**: 运行时类型验证
TDQS
Scored across 5 tools
Four tools clearly target project-related operations (add, list all, count, get info), but 'get_random_wallpaper' is an unrelated outlier that creates domain confusion. The project tools themselves are distinct in purpose, though 'get_project_all' and 'get_project_info' could potentially overlap if an agent needs specific project details versus a full list.
Four of the five tools follow a consistent 'verb_project_noun' pattern (e.g., add_project, get_project_all), with clear action-object naming. The outlier 'get_random_wallpaper' breaks this pattern by using a different object (wallpaper) and lacks the 'project' prefix, but the core set is mostly consistent.
With 5 tools, the count is reasonable for a project management server, but the inclusion of an unrelated wallpaper tool makes the scope feel thin for the stated purpose. The project domain has only 4 dedicated tools, which is borderline minimal for basic CRUD operations (e.g., missing update/delete).
For a project query server, there are significant gaps in coverage: it provides create (add_project) and read operations (get all, count, info), but lacks update and delete tools, leaving the lifecycle incomplete. The unrelated wallpaper tool does not contribute to the domain, and the absence of project modification capabilities will likely cause agent failures in workflows requiring edits or removals.