Click on "Install 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., "@Claude Code DingTalk MCP Server notify the team that the deployment succeeded and took 3 minutes"
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.
Claude Code 集成钉钉机器人通知的 MCP Server 实现
✅ 环境变量配置 - 支持通过环境变量自动初始化，无需手动配置
✅ 钉钉群机器人集成 - 完整的 Webhook API 支持
✅ 多种消息格式 - 支持文本、Markdown、链接三种消息类型
✅ 安全签名验证 - 支持 HMAC-SHA256 签名验证
✅ 专用任务通知 - 格式化的任务完成通知模板
✅ TypeScript 开发 - 完整的类型安全和智能提示
✅ 即插即用 - 与 Claude Code 无缝集成
Related MCP server: Discord Notification MCP Server
npm install -g claude-code-dingtalk-mcpclaude mcp add dingtalk-mcp dingtalk-mcp-server
钉钉群 → 群设置 → 智能群助手 → 添加机器人 → 自定义
安全设置选择"加签"，获取 Webhook URL 和密钥
export DINGTALK_WEBHOOK="https://oapi.dingtalk.com/robot/send?access_token=YOUR_TOKEN"
export DINGTALK_SECRET="YOUR_SECRET"创建 .mcp.json 文件：
{"mcpServers": {"dingtalk-notifications": {"command": "dingtalk-mcp-server"}}}重启 Claude Code，然后运行：
dingtalk_send_text {"content": "测试成功！"}✅ 完成！现在可以在每次对话结束时调用 dingtalk_notify_session_end 发送通知
npm install -g claude-code-dingtalk-mcp# 如果您的 Claude Code 支持 MCP 管理器
npx @modelcontextprotocol/cli add claude-code-dingtalk-mcp# 无需安装，直接使用
npx claude-code-dingtalk-mcp选择以下任一方式安装：
# 方式1：全局安装（推荐）
npm install -g claude-code-dingtalk-mcp
# 方式2：项目本地安装
npm install claude-code-dingtalk-mcp
# 方式3：直接使用（无需安装）
npx claude-code-dingtalk-mcp在您的项目根目录或 Claude Code 全局配置目录创建/编辑 .mcp.json 文件：
全局安装方式：
{
"mcpServers": {
"dingtalk-notifications": {
"command": "dingtalk-mcp-server",
"description": "钉钉通知服务器"
}
}
}本地安装方式：
{
"mcpServers": {
"dingtalk-notifications": {
"command": "node",
"args": ["./node_modules/claude-code-dingtalk-mcp/dist/index.js"],
"description": "钉钉通知服务器"
}
}
}NPX 方式：
{
"mcpServers": {
"dingtalk-notifications": {
"command": "npx",
"args": ["claude-code-dingtalk-mcp"],
"description": "钉钉通知服务器"
}
}
}在钉钉群中：群设置 → 智能群助手 → 添加机器人
选择 "自定义" 机器人
设置机器人名称（如：Claude Code 通知）
重要：选择安全设置 → 加签（推荐）
复制生成的 Webhook URL 和 签名密钥
方式1：系统环境变量
# 添加到 ~/.bashrc 或 ~/.zshrc
export DINGTALK_WEBHOOK="https://oapi.dingtalk.com/robot/send?access_token=YOUR_ACCESS_TOKEN"
export DINGTALK_SECRET="YOUR_SECRET_KEY"
export DINGTALK_KEYWORDS="Claude,任务完成,通知" # 可选方式2：项目 .env 文件
# 在项目根目录创建 .env 文件
DINGTALK_WEBHOOK=https://oapi.dingtalk.com/robot/send?access_token=YOUR_ACCESS_TOKEN
DINGTALK_SECRET=YOUR_SECRET_KEY
DINGTALK_KEYWORDS=Claude,任务完成,通知# 重启 Claude Code 以加载新的 MCP 配置
claude code restart
# 或者关闭 Claude Code 后重新打开在 Claude Code 中运行以下命令测试：
# 测试基本连接
dingtalk_send_text {"content": "🎉 Claude Code 钉钉通知测试成功！"}
# 测试会话结束通知
dingtalk_notify_session_end {
"sessionType": "配置测试",
"summary": "成功配置了 Claude Code 钉钉通知功能"
}Claude Code 会在以下位置查找 .mcp.json 配置：
当前项目目录：./mcp.json 或 ./.mcp.json
用户主目录：~/.claude/mcp.json
全局配置：~/.config/claude-code/mcp.json
Q: 提示找不到 dingtalk_xxx 命令？
A: 检查 .mcp.json 配置是否正确，重启 Claude Code
Q: 钉钉通知发送失败？
A: 检查环境变量配置，确保 Webhook URL 和密钥正确
Q: 如何确认 MCP Server 是否运行？
A: 在 Claude Code 中输入 dingtalk_ 按 Tab 键，应该会显示可用命令
Q: 支持团队共享配置吗？
A: 是的，将 .mcp.json 提交到代码仓库即可团队共享
如果您已设置环境变量，MCP Server 将自动初始化，无需手动配置：
# 直接发送通知，无需配置步骤
dingtalk_notify_task_complete {
"taskName": "项目构建",
"status": "success",
"details": "构建成功，所有测试通过",
"duration": "2分30秒"
}如果未设置环境变量，可以在 Claude Code 中手动配置：
dingtalk_configure {
"webhook": "https://oapi.dingtalk.com/robot/send?access_token=YOUR_ACCESS_TOKEN",
"secret": "YOUR_SECRET_KEY"
}dingtalk_configure手动配置钉钉机器人设置
参数：
webhook (必需): 钉钉机器人 Webhook URL
secret (可选): 签名验证密钥
keywords (可选): 安全关键字数组
dingtalk_send_text发送文本消息
参数：
content (必需): 文本内容
atAll (可选): 是否 @所有人，默认 false
dingtalk_send_markdown发送 Markdown 格式消息
参数：
title (必需): 消息标题
text (必需): Markdown 格式文本内容
atAll (可选): 是否 @所有人，默认 false
dingtalk_send_link发送链接消息
参数：
title (必需): 链接标题
text (必需): 链接描述文本
messageUrl (必需): 目标 URL
picUrl (可选): 图片 URL
dingtalk_notify_session_end发送会话结束通知（新功能）
参数：
sessionType (可选): 会话类型，如 "开发协助"、"代码审查"、"问题解决"，默认 "开发协助"
duration (可选): 会话时长，如 "30分钟"、"1小时20分"
mainTasks (可选): 主要任务列表
summary (可选): 会话摘要，默认 "会话已完成"
filesCount (可选): 修改/创建的文件数量，默认 0
toolsUsed (可选): 使用的工具/命令数量，默认 0
atAll (可选): 是否 @所有人，默认 false
重要功能：每次 Claude Code 对话完成后，自动推送通知到钉钉群！
在 Claude Code 对话即将结束时，直接调用：
dingtalk_notify_session_end {
"sessionType": "开发协助",
"duration": "45分钟",
"mainTasks": ["实现钉钉MCP Server", "添加环境变量支持", "编写使用文档"],
"summary": "成功开发并部署了钉钉通知MCP Server，支持多种消息格式和自动会话通知",
"filesCount": 8,
"toolsUsed": 15
}设置环境变量后，使用脚本自动触发：
# 设置会话信息
export CLAUDE_SESSION_TYPE="代码审查"
export CLAUDE_SESSION_DURATION="30分钟"
export CLAUDE_MAIN_TASKS="代码质量检查,安全漏洞扫描,性能优化建议"
export CLAUDE_SESSION_SUMMARY="完成了全面的代码审查，发现并修复了3个安全问题"
export CLAUDE_FILES_COUNT="5"
export CLAUDE_TOOLS_USED="12"
# 触发通知
npm run notify-session-end安装钩子后，每次会话结束自动触发：
# 安装钩子
./claude-hook.sh install
# 钩子会在 Claude Code 会话结束时自动运行
# 无需手动操作！dingtalk_notify_task_complete {
"taskName": "代码部署",
"status": "success",
"details": "✅ 部署到生产环境成功\\n- 版本: v2.1.0\\n- 测试: 100% 通过\\n- 性能: 优化 15%",
"duration": "3分45秒"
}dingtalk_send_markdown {
"title": "📊 每日构建报告",
"text": "## 📊 每日构建报告\\n\\n**日期**: 2025-01-15\\n**状态**: ✅ 成功\\n\\n### 📈 统计数据\\n- 构建次数: 12\\n- 成功率: 100%\\n- 平均耗时: 2分15秒\\n\\n### 🔧 修复问题\\n- 修复了登录超时问题\\n- 优化了数据库查询性能\\n\\n---\\n*来自 Claude Code 自动化构建*"
}dingtalk_send_text {
"content": "🎉 代码审查完成！所有检查项目都已通过，可以开始合并到主分支。",
"atAll": false
}在钉钉群中，点击群设置 → 智能群助手 → 添加机器人
选择"自定义"机器人
设置机器人名称和头像
重要：配置安全设置（推荐使用"加签"方式）
获取 Webhook URL 和签名密钥
关键词验证：消息中必须包含设定的关键词
加签验证：使用 HMAC-SHA256 签名验证（推荐）
IP 白名单：限制请求来源 IP
# Webhook URL 示例
https://oapi.dingtalk.com/robot/send?access_token=f248fa5a2e04cf0c13abb23831c4a6190f3837fa7ddf3338f759db5a67079469
# 签名密钥示例（加签验证）
SECad12bf23f1e2e3c3d7dae0cd58e41c2b4daa9d1066cdf7ce452c4732ecf0c30e消息频率限制：每个机器人每分钟最多发送 20 条消息
消息格式：确保 Markdown 格式正确，特殊字符需要转义
安全配置：生产环境建议启用签名验证
环境变量优先级：环境变量配置优先于手动配置
错误处理：工具会返回成功/失败状态，请检查返回值
Q: 提示"DingTalk client not configured"
A: 请检查环境变量设置或使用 dingtalk_configure 手动配置
Q: 消息发送失败 A: 请检查：
Webhook URL 是否正确
签名密钥是否匹配
是否触发了安全关键字验证
是否超过频率限制（20条/分钟）
Q: npm 安装失败 A: 请确保 Node.js 版本 ≥ 18.0.0
# 启用调试日志
DEBUG=dingtalk-mcp-server npx claude-code-dingtalk-mcp# 克隆仓库
git clone https://github.com/claude-code-community/dingtalk-mcp-server.git
cd dingtalk-mcp-server
# 安装依赖
npm install
# 开发模式运行
npm run dev
# 构建项目
npm run build
# 测试
npm testclaude-code-dingtalk-mcp/
├── src/
│ ├── dingtalk.ts # 钉钉客户端封装
│ ├── index.ts # MCP Server 主程序
│ └── test.ts # 测试用例
├── dist/ # 编译输出
├── .env.example # 环境变量示例
├── LICENSE # MIT 许可证
├── README.md # 说明文档
└── package.json # 项目配置MIT License - 详见 LICENSE 文件
让 Claude Code 的任务完成通知更加便捷！ 🚀
Configure DingTalk webhook settings
| Name | Required | Description | Default |
|---|---|---|---|
| webhook | Yes | DingTalk webhook URL with access token | |
| secret | No | Optional secret for signature verification | |
| keywords | No | Optional keywords for security validation |
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 'configure' which implies a write/mutation operation, but doesn't specify whether this is a one-time setup, overwrites existing settings, requires authentication, or has side effects like rate limits. This is a significant gap for a tool that likely modifies system state.
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, efficient sentence 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a configuration tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., idempotency, permissions), expected outcomes, or error handling, which are crucial for an agent to use it correctly in context with sibling notification tools.
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 schema already documents all parameters (webhook, secret, keywords) with their types and optionality. The description adds no additional meaning beyond what the schema provides, such as example values or usage context, meeting the baseline for high coverage.
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 action ('configure') and resource ('DingTalk webhook settings'), making the purpose understandable. However, it doesn't differentiate this configuration tool from the sibling notification tools (dingtalk_notify_session_end, dingtalk_send_link, etc.), which would require a 5.
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 prerequisites (e.g., needing a DingTalk account), exclusions, or how it relates to the sibling tools for sending notifications, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a session completion notification with automatic stats
| Name | Required | Description | Default |
|---|---|---|---|
| sessionType | No | Type of session (e.g., "开发协助", "代码审查", "问题解决") | 开发协助 |
| duration | No | Session duration (e.g., "30分钟", "1小时20分") | |
| mainTasks | No | List of main tasks completed in this session | |
| summary | No | Brief summary of the session | 会话已完成 |
| filesCount | No | Number of files modified/created | |
| toolsUsed | No | Number of tools/commands used | |
| atAll | No | Whether to @all members |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'automatic stats' which hints at some automated behavior, but doesn't clarify what these stats include, how the notification is formatted, whether it requires specific permissions, or any rate limits. This leaves significant gaps for a tool that presumably sends external notifications.
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, efficient sentence that front-loads the core purpose ('Send a session completion notification') and adds a key feature ('with automatic stats'). There's zero waste or redundancy, making it appropriately sized for the tool's complexity.
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 7 parameters with full schema coverage but no annotations or output schema, the description is minimally adequate. It identifies the tool's purpose but lacks details on behavioral traits, error handling, or output expectations. For a notification-sending tool, more context on delivery mechanism or response format would be helpful.
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 schema already documents all 7 parameters thoroughly. The description adds no additional parameter semantics beyond implying that parameters like 'duration' and 'mainTasks' feed into 'automatic stats'. This meets the baseline of 3 when schema coverage is high.
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 action ('Send a session completion notification') and the resource ('with automatic stats'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like dingtalk_send_text or dingtalk_send_markdown, which might also send notifications but with different content formats or purposes.
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 implies usage at the end of a session ('session completion notification'), but provides no explicit guidance on when to use this tool versus alternatives like dingtalk_send_text for general messages. There's no mention of prerequisites, exclusions, or comparative context with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a link message to DingTalk group
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Link title | |
| text | Yes | Link description text | |
| messageUrl | Yes | Target URL | |
| picUrl | No | Optional image URL |
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') but doesn't mention whether this requires authentication, has rate limits, affects group state, or what happens on success/failure. For a messaging tool with zero annotation coverage, this leaves critical behavioral traits unspecified.
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, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 complexity of a messaging tool with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral aspects like authentication needs, error handling, or response format, and it fails to differentiate from sibling tools, leaving gaps in contextual understanding.
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 schema already documents all four parameters (title, text, messageUrl, picUrl) with clear descriptions. The description adds no additional meaning beyond implying these parameters are used to construct a 'link message,' which is minimal value over what the schema provides.
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 action ('Send') and target ('link message to DingTalk group'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like dingtalk_send_markdown or dingtalk_send_text, which presumably also send messages to DingTalk groups but in different formats.
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 like dingtalk_send_markdown or dingtalk_send_text. It mentions 'link message' but doesn't explain what contexts or message types warrant a link format over text or markdown, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a markdown message to DingTalk group
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Message title | |
| text | Yes | Markdown formatted text content | |
| atAll | No | Whether to @all members |
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') but doesn't cover critical aspects like whether this requires specific permissions, rate limits, error handling, or what happens on success/failure. For a messaging tool with zero annotation coverage, 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly while conveying the essential action and target.
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 complexity of a messaging tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, dependencies on other tools like 'dingtalk_configure', or how it fits into the broader DingTalk ecosystem. This leaves the agent with incomplete context for reliable use.
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 description adds no parameter-specific information beyond what's already in the schema, which has 100% coverage with clear descriptions for 'title', 'text', and 'atAll'. Since the schema fully documents the parameters, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract from the schema's completeness.
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 action ('send') and resource ('markdown message to DingTalk group'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'dingtalk_send_text' or 'dingtalk_send_link' which also send messages, leaving room for ambiguity about when to choose markdown format over text or link formats.
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 like 'dingtalk_send_text' or 'dingtalk_send_link'. It lacks context about prerequisites (e.g., authentication setup via 'dingtalk_configure'), target audience, or scenarios where markdown is preferred over plain text or links.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a text message to DingTalk group
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Text content to send | |
| atAll | No | Whether to @all members |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions sending a message but doesn't cover critical aspects like authentication requirements, rate limits, error conditions, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap.
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, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and front-loads the core functionality without unnecessary elaboration.
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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error handling, or behavioral traits like side effects. Given the complexity of sending messages (which involves authentication and potential failures), 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?
Schema description coverage is 100%, so the schema already documents both parameters ('content' and 'atAll') adequately. The description doesn't add any parameter-specific information beyond what's in the schema, such as content length limits or '@all' behavior details, meeting the baseline for high schema coverage.
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 action ('send a text message') and target ('to DingTalk group'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'dingtalk_send_markdown' or 'dingtalk_send_link' that also send messages, which prevents a perfect score.
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 like 'dingtalk_send_markdown' or 'dingtalk_send_link', nor does it mention prerequisites or context for sending messages. It simply states what the tool does without usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
dingtalk_configuredingtalk_notify_session_enddingtalk_send_linkdingtalk_send_markdowndingtalk_send_textEach tool has a clearly distinct purpose: configure webhook settings, notify session end with stats, and send three different message types (link, markdown, text). There is no overlap in functionality, making tool selection straightforward for an agent.
All tools follow a consistent 'dingtalk_verb_noun' pattern with snake_case throughout. The naming is predictable and readable, with no deviations in style or convention.
With 5 tools, the server is well-scoped for its purpose of DingTalk integration. Each tool serves a specific function (configuration, notifications, messaging), and none feel redundant or missing for the apparent scope.
The toolset covers core messaging and notification workflows for DingTalk, including configuration and different message formats. A minor gap might be the lack of tools for reading or managing incoming messages, but the surface is largely complete for sending notifications and messages.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Let your AI agent notify you by email, Slack, Discord, or webhook. One tool: send_notification.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Create Tasks and run Workflows in Bleep from Claude, ChatGPT, and other AI assistants.
Drive your real WhatsApp inbox from Claude — send, reply, label, assign, and triage via TimelinesAI.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sfyyy/claude-code-dingtalk-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
