Skip to main content
Glama
lh8966

GitLab WeChat MCP

by lh8966
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

GitLab WeChat MCP 工具

一个用于获取 GitLab 代码提交记录并发送到企业微信的 MCP (Model Context Protocol) 工具。

功能特性

  • 🔍 获取 GitLab 提交记录：支持按日期查询指定用户的代码提交

  • 📊 智能日报生成：自动生成格式化的代码提交日报

  • 💬 企业微信集成：支持 Webhook 和 API 两种方式发送消息

  • 🛠 MCP 协议支持：可与支持 MCP 的 AI 助手无缝集成

  • ⚙️ 灵活配置：支持环境变量和配置文件

  • 🔒 错误处理：完善的错误处理和日志记录

Related MCP server: GitLab MCP Server

安装

1. 获取项目代码

由于这是一个本地开发的项目，您已经有了完整的代码。如果需要在其他地方使用，可以：

方式1：直接使用当前目录（推荐）

# 当前项目已在 d:\wwwroot\azWork\workBook 目录
# 打开PowerShell或命令提示符，进入项目目录
cd d:\wwwroot\azWork\workBook

# 验证项目文件是否存在
dir
# 应该能看到：package.json, README.md, src文件夹等

方式2：复制到其他位置使用

如果您想在其他位置使用这个工具，比如复制到桌面：

# 1. 复制整个项目文件夹到桌面
# 在文件管理器中：
# - 右键点击 d:\wwwroot\azWork\workBook 文件夹
# - 选择"复制"
# - 进入桌面，右键选择"粘贴"
# - 重命名为 gitlab-wechat-mcp（可选）

# 2. 进入复制后的项目目录
cd C:\Users\%USERNAME%\Desktop\gitlab-wechat-mcp

# 3. 验证文件完整性
dir

方式3：使用Git管理（如果需要版本控制）

# 在项目目录中初始化Git仓库
cd d:\wwwroot\azWork\workBook
git init
git add .
git commit -m "初始化GitLab WeChat MCP工具"

# 如果要推送到远程仓库
# git remote add origin https://your-git-server.com/your-repo.git
# git push -u origin main

2. 安装依赖

npm install

如果遇到网络问题，可以使用国内镜像：

npm install --registry=https://registry.npmmirror.com

3. 测试连接

npm test

测试输出示例：

✓ GitLab连接测试成功
✓ 企业微信连接测试成功
✓ 获取提交记录测试成功
✓ 发送测试消息成功

4. 配置环境变量

复制环境变量模板：

# Windows PowerShell
copy .env.example .env

# 或者手动复制文件
# 右键点击 .env.example 文件 -> 复制 -> 粘贴 -> 重命名为 .env

编辑 .env 文件，填入你的配置：

# GitLab 配置
GITLAB_URL=https://gitlab.com
GITLAB_TOKEN=glpat-xxxxxxxxxxxxxxxxxxxx
GITLAB_USERNAME=zhangsan

# 企业微信配置（选择一种方式）
# 方式1：使用 Webhook（推荐）
WECHAT_WEBHOOK_URL=https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

# 方式2：使用企业微信 API（如果不用Webhook，可以用这种方式）
# WECHAT_CORP_ID=wwxxxxxxxxxxxxxxxx
# WECHAT_CORP_SECRET=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
# WECHAT_AGENT_ID=1000002

# MCP 配置（一般不需要修改）
MCP_SERVER_NAME=gitlab-wechat-mcp
MCP_SERVER_VERSION=1.0.0

配置示例说明：

  • GITLAB_TOKEN: 类似 glpat-xxxxxxxxxxxxxxxxxxxx 的格式

  • GITLAB_USERNAME: 你的GitLab用户名，如 zhangsan

  • WECHAT_WEBHOOK_URL: 企业微信机器人的完整URL地址

配置说明

GitLab 配置

  1. 获取 Personal Access Token：

    • 登录 GitLab（如 https://gitlab.com）

    • 点击右上角头像 → Settings（设置）

    • 左侧菜单选择 "Access Tokens"（访问令牌）

    • 填写表单：

      • Token name: mcp-daily-report（可自定义）

      • Expiration date: 选择过期时间（建议1年）

      • Scopes: 勾选 read_api 和 read_repository

    • 点击 "Create personal access token"

    • 重要：复制生成的token（格式如：glpat-xxxxxxxxxxxxxxxxxxxx），离开页面后无法再次查看

  2. 配置参数示例：

    GITLAB_URL=https://gitlab.com
GITLAB_TOKEN=glpat-xxxxxxxxxxxxxxxxxxxx
GITLAB_USERNAME=zhangsan

企业微信配置

支持两种方式：

方式1：Webhook（推荐，简单易用）

  1. 创建企业微信群机器人：

    • 在企业微信中创建或进入一个群聊

    • 点击群聊右上角 "..." → 群机器人 → 添加机器人

    • 选择 "自定义机器人"

    • 填写机器人名称：GitLab日报机器人

    • 点击 "添加"

    • 重要：复制生成的Webhook URL（格式如：https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx）

  2. 配置示例：

    WECHAT_WEBHOOK_URL=https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

方式2：企业微信 API（高级用法）

  1. 获取企业信息：

  2. 创建应用：

    • 应用管理 → 自建 → 创建应用

    • 填写应用名称：GitLab日报

    • 选择可见范围

    • 创建后获取 "AgentId" 和 "Secret"

  3. 配置示例：

    WECHAT_CORP_ID=wwxxxxxxxxxxxxxxxx
WECHAT_CORP_SECRET=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
WECHAT_AGENT_ID=1000002

使用方法

作为 MCP 服务器运行

npm start

开发模式（自动重启）

npm run dev

MCP 工具说明

本工具提供以下 3 个 MCP 工具：

1. get_gitlab_commits

获取 GitLab 用户在指定日期的代码提交记录。

参数：

  • date (必需)：查询日期，格式 YYYY-MM-DD

  • username (可选)：GitLab 用户名，默认使用配置的用户名

  • projectId (可选)：项目 ID，不指定则查询所有项目

使用示例：

  1. 获取今天的提交记录：

{
  "date": "2024-01-15"
}

  1. 获取指定用户的提交记录：

{
  "date": "2024-01-15",
  "username": "zhangsan"
}

  1. 获取特定项目的提交记录：

{
  "date": "2024-01-15",
  "projectId": "123"
}

返回结果示例：

{
  "success": true,
  "data": {
    "date": "2024-01-15",
    "username": "zhangsan",
    "total_commits": 3,
    "commits": [
      {
        "project_name": "web-frontend",
        "commit_message": "修复登录页面样式问题",
        "commit_id": "abc123",
        "time": "09:30"
      }
    ]
  }
}

2. send_to_wechat

发送消息到企业微信。

参数：

  • message (必需)：要发送的消息内容

  • messageType (可选)：消息类型，text 或 markdown，默认 text

使用示例：

  1. 发送普通文本消息：

{
  "message": "今日代码提交总结：完成了3个功能模块的开发",
  "messageType": "text"
}

  1. 发送Markdown格式消息：

{
  "message": "## 今日工作总结\n\n- ✅ 完成登录功能\n- ✅ 修复样式问题\n- 🔄 正在开发支付模块",
  "messageType": "markdown"
}

返回结果示例：

{
  "success": true,
  "message": "消息发送成功"
}

3. generate_daily_report

生成并发送 GitLab 提交记录的日报到企业微信。

参数：

  • date (必需)：查询日期，格式 YYYY-MM-DD

  • username (可选)：GitLab 用户名，默认使用配置的用户名

  • projectId (可选)：项目 ID，不指定则查询所有项目

使用示例：

  1. 生成今日日报：

{
  "date": "2024-01-15"
}

  1. 生成指定用户的日报：

{
  "date": "2024-01-15",
  "username": "john.doe"
}

  1. 生成特定项目的日报：

{
  "date": "2024-01-15",
  "username": "john.doe",
  "projectId": "456"
}

返回结果示例：

{
  "success": true,
  "message": "日报已成功发送到企业微信",
  "data": {
    "commits_count": 3,
    "projects_count": 2,
    "report_sent": true
  }
}

日报格式示例

生成的日报包含以下信息：

# john.doe 的代码提交日报

**日期**: 2024-01-15
**提交数量**: 3
**涉及项目**: project-a, project-b

## 提交详情

### 1. 修复用户登录问题
- **项目**: project-a
- **时间**: 2024-01-15 09:30:00
- **分支**: main
- **详情**: 解决了用户登录时的验证码问题
- **链接**: [查看提交](https://gitlab.com/project-a/-/commit/abc123)

### 2. 添加新功能模块
- **项目**: project-b
- **时间**: 2024-01-15 14:20:00
- **分支**: feature/new-module
- **链接**: [查看提交](https://gitlab.com/project-b/-/commit/def456)

完整使用流程示例

场景：每日自动生成并发送工作日报

  1. 配置完成后，测试连接：

npm test

  1. 手动获取今日提交记录： 使用MCP工具 get_gitlab_commits：

{
  "date": "2024-01-15"
}

  1. 生成并发送日报： 使用MCP工具 generate_daily_report：

{
  "date": "2024-01-15",
  "username": "zhangsan"
}

  1. 查看企业微信群消息： 日报会自动发送到配置的企业微信群中。

与 AI 助手集成

本工具支持 MCP 协议，可以与支持 MCP 的 AI 助手（如 Claude Desktop）集成使用。

Claude Desktop 配置

在 Claude Desktop 的配置文件中添加：

{
  "mcpServers": {
    "gitlab-wechat": {
      "command": "node",
      "args": ["D:\\wwwroot\\azWork\\workBook\\src\\index.js"],
      "env": {
        "GITLAB_TOKEN": "your_token",
        "GITLAB_USERNAME": "your_username",
        "WECHAT_WEBHOOK_URL": "your_webhook_url"
      }
    }
  }
}

配置文件位置：

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

配置后的使用方式： 在Claude Desktop中直接对话：

  • "帮我获取今天的GitLab提交记录"

  • "生成今日工作日报并发送到企业微信"

  • "查看昨天的代码提交情况"

故障排除

常见问题

  1. GitLab Token 权限不足

    • 确保 Token 具有 read_api 和 read_repository 权限

    • 检查 Token 是否过期

  2. 企业微信消息发送失败

    • 检查 Webhook URL 是否正确

    • 确认机器人是否被正确添加到群组

    • 验证企业微信 API 配置是否完整

  3. 找不到用户或项目

    • 确认用户名拼写正确

    • 检查项目 ID 是否存在

    • 验证 Token 是否有访问相应项目的权限

调试模式

设置环境变量启用详细日志：

export LOG_LEVEL=debug
npm start

测试连接

可以通过 MCP 工具测试各个服务的连接状态：

  1. 测试 GitLab 连接

  2. 测试企业微信连接

  3. 发送测试消息

开发

项目结构

src/
├── index.js              # MCP 服务器主文件
├── config/
│   └── index.js          # 配置管理
├── services/
│   ├── gitlab.js         # GitLab API 服务
│   └── wechat.js         # 企业微信服务
└── utils/
    ├── logger.js         # 日志工具
    └── errors.js         # 错误处理

添加新功能

  1. 在相应的服务文件中添加新方法

  2. 在 index.js 中注册新的 MCP 工具

  3. 更新文档和示例

许可证

MIT License

贡献

欢迎提交 Issue 和 Pull Request！

更新日志

v1.0.0

  • 初始版本发布

  • 支持 GitLab 提交记录获取

  • 支持企业微信消息发送

  • 支持自动日报生成

  • 完整的 MCP 协议支持

Available Tools

3 tools
generate_daily_reportC

生成并发送GitLab提交记录的日报到企业微信

ParametersJSON Schema
NameRequiredDescriptionDefault
usernameNoGitLab用户名（可选，默认使用配置的用户名）
dateYes查询日期，格式：YYYY-MM-DD
projectIdNo项目ID（可选，不指定则查询所有项目）

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 generates and sends reports, implying a write/send operation, but doesn't cover critical aspects like authentication needs, rate limits, error handling, or what '发送' entails (e.g., direct message, group chat). For a tool with no annotations and a mutation action, 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.

Conciseness5/5

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

The description is a single, efficient sentence in Chinese: '生成并发送GitLab提交记录的日报到企业微信'. It's front-loaded with the core action and destination, with zero wasted words. Every part earns its place by specifying the what, from where, and to where.

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's complexity (generating and sending reports, implying mutation), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the report contains, how it's formatted, success/failure responses, or integration details. For a tool with behavioral implications and no structured support, more context is needed to be fully helpful.

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 parameter details (e.g., 'username' is optional with a default, 'date' is required in YYYY-MM-DD format, 'projectId' is optional for filtering). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating value.

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: '生成并发送GitLab提交记录的日报到企业微信' (generate and send daily GitLab commit reports to WeChat). It specifies the verb ('生成并发送'), resource ('GitLab提交记录的日报'), and destination ('企业微信'), making the action explicit. However, it doesn't differentiate from sibling tools like 'get_gitlab_commits' or 'send_to_wechat', which might handle parts of this process separately.

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 doesn't mention sibling tools (e.g., 'get_gitlab_commits' for just fetching commits or 'send_to_wechat' for sending messages), prerequisites, or exclusions. Usage is implied from the purpose but lacks explicit context for tool selection.

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

get_gitlab_commitsC

获取GitLab用户在指定日期的代码提交记录

ParametersJSON Schema
NameRequiredDescriptionDefault
usernameNoGitLab用户名（可选，默认使用配置的用户名）
dateYes查询日期，格式：YYYY-MM-DD
projectIdNo项目ID（可选，不指定则查询所有项目）

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 retrieves commit records but doesn't describe key behaviors: whether it's read-only (implied by '获取' but not explicit), what permissions are needed, if there are rate limits, how results are formatted (e.g., list of commits with details), or error handling. For a tool with no annotations, this leaves significant gaps in understanding its operational traits.

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

Conciseness5/5

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

The description is a single, clear sentence in Chinese: '获取GitLab用户在指定日期的代码提交记录'. It is front-loaded with the core purpose, has zero redundant words, and efficiently communicates the tool's function without unnecessary elaboration. This makes it easy for an agent to parse and understand quickly.

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 complexity (3 parameters, no output schema, no annotations), the description is incomplete. It lacks details on behavioral aspects (e.g., read-only nature, authentication needs), output format (what commit data is returned), and usage context. While the schema covers parameters well, the absence of annotations and output schema means the description should compensate more to help the agent invoke the tool correctly, which it doesn't do adequately.

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 description adds minimal semantic context beyond the input schema. It mentions 'GitLab用户' (GitLab user) and '指定日期' (specified date), which align with the 'username' and 'date' parameters in the schema. However, with 100% schema description coverage, the schema already documents all parameters thoroughly (e.g., 'username' is optional with a default, 'date' is required in YYYY-MM-DD format, 'projectId' is optional for filtering). The description doesn't provide additional insights like example values or edge cases, so it meets the baseline for high schema coverage.

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: '获取GitLab用户在指定日期的代码提交记录' (Get GitLab user's code commit records for a specified date). It specifies the verb ('获取' - get), resource ('代码提交记录' - code commit records), and scope ('GitLab用户' - GitLab user, '指定日期' - specified date). However, it doesn't explicitly differentiate from sibling tools like 'generate_daily_report' or 'send_to_wechat', which appear to serve different purposes (report generation and messaging).

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 doesn't mention any prerequisites, exclusions, or scenarios where other tools might be more appropriate. For example, it doesn't clarify if this is for daily summaries vs. real-time monitoring or how it relates to 'generate_daily_report'. Without such context, the agent must infer usage from the tool name and parameters alone.

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

send_to_wechatC

发送消息到企业微信

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYes要发送的消息内容
messageTypeNo消息类型text

TDQS

C2.9/5.0
Behavior2/5

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 states the action '发送消息' (send message), implying a write operation, but doesn't cover critical aspects like authentication requirements, rate limits, error handling, or what happens upon success/failure. This leaves significant gaps in understanding the tool's behavior.

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

Conciseness5/5

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

The description is a single, efficient sentence in Chinese that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.

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 complexity of a message-sending tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., side effects, response format), usage context, and doesn't compensate for the absence of structured fields, making it inadequate for full agent understanding.

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 schema description coverage is 100%, with clear descriptions for both parameters ('message' and 'messageType'), including enum values and defaults. The description adds no additional meaning beyond the schema, such as examples or constraints, 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.

Purpose4/5

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

The description '发送消息到企业微信' clearly states the action (send) and target (WeChat Enterprise), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'generate_daily_report' or 'get_gitlab_commits', which are unrelated communication tools, so it doesn't need sibling differentiation but could be more specific about what kind of messages it sends.

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 or any context for its application. It lacks information about prerequisites, target audience (e.g., specific WeChat groups or users), or scenarios where it's appropriate, leaving the agent with minimal usage context.

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. Dates show when Glama detected each change.

  1. 3 tool updates
    • First observedgenerate_daily_report
    • First observedget_gitlab_commits
    • First observedsend_to_wechat
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0
Disambiguation4/5

The three tools have distinct primary purposes: get_gitlab_commits retrieves data, generate_daily_report processes and sends a report, and send_to_wechat handles generic messaging. There is minor potential confusion between generate_daily_report and send_to_wechat since both involve sending to WeChat, but their descriptions clarify the difference (report generation vs. generic message).

Naming Consistency4/5

All tools use snake_case, which is consistent. The naming pattern is mostly verb_noun (get_gitlab_commits, send_to_wechat), but generate_daily_report uses 'generate' instead of a more direct verb like 'create', and includes an adjective 'daily', causing a slight deviation. Overall, the naming is clear and follows a readable convention.

Tool Count3/5

With only 3 tools, the server feels thin for its apparent scope of integrating GitLab and WeChat workflows. While it covers core functions (fetch commits, generate reports, send messages), it lacks tools for other potential operations like managing GitLab issues or WeChat groups, making the count borderline low for the domain.

Completeness3/5

The server covers basic data flow: retrieving GitLab commits, generating a report, and sending to WeChat. However, there are notable gaps such as no tools for updating or deleting reports, handling errors, or supporting other GitLab features (e.g., merge requests, issues). The surface is functional but incomplete for broader integration tasks.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • GitLab MCP Server

    bioanywhere
    F
    license
    Not graded
    quality
    Not graded
    maintenance
    Connects AI assistants to GitLab projects, enabling users to query merge requests, review discussions, view test results and pipelines, search by branch, and respond to comments through natural language commands.
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lh8966/gitlab-wechat-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server