Send customizable Slack notifications with rich formatting, color-coded status, priority levels, and support for task completion notifications.
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., "@Slack Notifications MCP Server Send a success notification for the build task."
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.
A powerful Model Context Protocol (MCP) server that brings Slack notifications to Claude AI workflows. Perfect for getting notified when long-running tasks complete, errors occur, or when user input is needed.
📱 Rich Slack Messages: Formatted messages with attachments, colors, and fields
🎯 Task Completion Notifications: Specialized notifications for development workflows
🔧 Webhook Configuration: Easy setup with Slack webhook URLs
🌈 Color-Coded Status: Visual indicators for success, error, warning, and info
🎨 Customizable: Channel selection, bot username, emojis, and priority levels
🚀 Zero Config: Works with environment variables or runtime configuration
Related MCP server: Discord Notification MCP Server
send_slack_notificationSend a customizable Slack notification with full formatting options.
Parameters:
title (required): The notification title
message (required): The notification message
webhook_url (optional): Slack webhook URL (if not configured globally)
channel (optional): Target channel (e.g., #general, @username)
username (optional): Bot username (default: "Claude Code")
icon_emoji (optional): Bot emoji (default: ":robot_face:")
color (optional): Message color (good, warning, danger, info, or hex)
priority (optional): Priority level (low, normal, high, urgent)
slack_task_completion_notificationSend a specialized notification for task completion with intelligent formatting.
Parameters:
status (required): success, error, warning, or info
taskType (optional): Type of task (e.g., "Build", "Deploy", "Test")
duration (optional): How long the task took
summary (optional): Brief summary of accomplishment
url (optional): Related URL (e.g., localhost development server)
webhook_url (optional): Slack webhook URL (if not configured globally)
channel (optional): Target channel
configure_slack_webhookConfigure global Slack webhook settings for the session.
Parameters:
webhook_url (required): Your Slack webhook URL
default_channel (optional): Default channel for notifications
Go to Slack API: Visit api.slack.com
Create New App: Click "Create New App" > "From scratch"
Configure Incoming Webhooks:
Go to "Incoming Webhooks" in the sidebar
Activate incoming webhooks
Click "Add New Webhook to Workspace"
Choose your channel and authorize
Copy the webhook URL (starts with https://hooks.slack.com/services/...)
Clone this repository: ```bash git clone https://github.com/chiuchau-cyril/mcp-slack-notifications.git cd mcp-slack-notifications ```
Install dependencies: ```bash npm install ```
Build the project: ```bash npm run build ```
Add to your Claude Code MCP configuration:
```json { "mcpServers": { "slack-notifications": { "command": "node", "args": ["/Users/cyril/Documents/git/mcp-servers/slack-notifications/dist/index.js"], "env": { "SLACK_WEBHOOK_URL": "https://hooks.slack.com/services/YOUR/WEBHOOK/URL" } } } } ```
Add to your Claude App MCP settings:
```json { "slack-notifications": { "command": "node", "args": ["/Users/cyril/Documents/git/mcp-servers/slack-notifications/dist/index.js"], "env": { "SLACK_WEBHOOK_URL": "https://hooks.slack.com/services/YOUR/WEBHOOK/URL" } } } ```
Run the test suite to verify everything works:
```bash node test-slack-notifications.js ```
```javascript // Simple notification { "title": "🎉 Task Complete", "message": "Your build finished successfully!", "channel": "#development", "color": "good" } ```
```javascript // Task completion with details { "status": "success", "taskType": "React Build", "duration": "2 minutes", "summary": "Compiled 45 components successfully", "url": "http://localhost:3000", "channel": "#dev-notifications" } ```
```javascript // Error with high priority { "title": "❌ Build Failed", "message": "TypeScript compilation errors detected", "color": "danger", "priority": "urgent", "channel": "#alerts" } ```
```javascript // Set up webhook for the session { "webhook_url": "https://hooks.slack.com/services/YOUR/WEBHOOK/URL", "default_channel": "#claude-notifications" } ```
This MCP server implements the same intelligent notification timing as the macOS version:
Commands waiting for confirmation (Do you want to proceed?)
Password prompts
Any user input required
Priority: urgent with red color
Build processes completed
Tests finished running
Deployments completed
Color: Green (success) / Red (error) / Orange (warning)
Simple queries (ls, pwd)
Commands still running normally
Quick operations (< 30 seconds)
Green (good): Success, completed tasks
Orange (warning): Warnings, partial failures
Red (danger): Errors, critical issues
Blue (info): Information, status updates
Custom: Any hex color code (e.g., #FF5733)
Low: #cccccc (gray)
Normal: #0099cc (blue)
High: #ff9500 (orange)
Urgent: #ff0000 (red)
Attachments: Structured message layout
Fields: Key-value pairs with short/long display
Timestamps: Automatic message timing
Footer: "Claude Code" branding
Node.js 18+
Slack workspace with webhook permissions
Internet connection for webhook delivery
Set these for easier configuration:
```bash export SLACK_WEBHOOK_URL="https://hooks.slack.com/services/YOUR/WEBHOOK/URL" export SLACK_DEFAULT_CHANNEL="#claude-notifications" ```
For automatic notification behavior, add these rules to your Claude configuration:
```markdown
When a task takes longer than 2 minutes or requires user input, send a Slack notification using the appropriate tool.
User input needed → Immediate notification with urgent priority
Task completed → Result notification with appropriate status
Errors occurred → Error notification with danger color ```
Webhook URLs contain secrets - keep them private
Don't commit webhook URLs to version control
Use environment variables for production deployments
Limit webhook permissions to necessary channels only
Contributions are welcome! Please feel free to submit a Pull Request. For major changes, please open an issue first to discuss what you would like to change.
MIT License - see LICENSE file for details.
🐛 Issues: GitHub Issues
💬 Discussions: GitHub Discussions
📧 Email: Contact for enterprise support
macOS Notifications MCP Server - Native macOS notifications
Model Context Protocol - Official MCP documentation
Made with ❤️ for the Claude AI ecosystem
Configure global Slack webhook URL for notifications
| Name | Required | Description | Default |
|---|---|---|---|
| webhook_url | Yes | Slack webhook URL to configure globally | |
| default_channel | No | Default channel for notifications |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose side effects like overwriting existing webhook or persistence requirements, leaving behavioral understanding incomplete.
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?
Single sentence, front-loaded, no redundant information. Could benefit from slightly more detail without becoming verbose.
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?
Adequate for a simple configuration tool, but missing mention of output or confirmation of configuration. With no output schema, description could explain return behavior.
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 coverage is 100%, so baseline is 3. Description adds no extra meaning beyond what is in the schema.
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?
Clear verb 'configure' and resource 'global Slack webhook URL'. Distinguishes from siblings by being the setup step versus sending notifications.
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?
Implied that this is for configuration before sending notifications, but no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a Slack notification via webhook
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | Color for the message attachment | info |
| title | Yes | The notification title | |
| channel | No | Slack channel to send to (e.g., #general, @username) | |
| message | Yes | The notification message | |
| priority | No | Notification priority level | normal |
| username | No | Bot username for the message | Claude Code |
| icon_emoji | No | Emoji icon for the bot (e.g., :robot_face:) | :robot_face: |
| webhook_url | No | Slack webhook URL (optional if configured globally) |
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 tool sends via webhook, omitting details about error handling, default webhook URL, idempotency, or required authentication. The description adds little beyond the schema's parameter descriptions.
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 very concise (one sentence, 5 words) and immediately states the tool's function. While minimal, it is not verbose; fits the tool's straightforward nature.
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 8 parameters, no annotations, and no output schema, the description is insufficiently complete. It does not explain the return value, behavior when webhook URL is omitted, or how to interpret the 'color' and 'priority' parameters in context.
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 coverage is 100% with descriptions for all 8 parameters. The description does not add additional meaning beyond what the schema already provides, so it meets the baseline.
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 'Send a Slack notification via webhook' clearly states the action and resource, distinguishing it from sibling tools such as 'configure_slack_webhook' (configure vs. send) and 'slack_task_completion_notification' (task-specific vs. generic).
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 explicit guidance on when to use this tool versus alternatives like 'slack_task_completion_notification' or prerequisites such as having a configured webhook. The purpose is implied but not contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a specialized Slack notification for task completion
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Optional URL related to the task (e.g., localhost link) | |
| status | Yes | Status of the completed task | |
| channel | No | Slack channel to send to (optional) | |
| summary | No | Brief summary of what was accomplished | |
| duration | No | How long the task took (e.g., "5 minutes", "30 seconds") | |
| taskType | No | Type of task that was completed (e.g., "Build", "Deploy", "Test") | |
| webhook_url | No | Slack webhook URL (optional if configured globally) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden, but it only repeats the basic purpose. It fails to disclose side effects, authentication needs, rate limits, or any behavioral traits beyond sending a notification.
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 short sentence, which is concise but lacks structure. It could be improved without being verbose.
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?
With 7 parameters and no output schema, the description should provide more context on what 'specialized' means and what the notification includes. It is too vague for an AI agent to fully understand the tool's behavior.
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 coverage is 100% with parameter descriptions. The tool description adds no additional meaning; baseline of 3 is appropriate as the schema handles parameter semantics.
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 sends a Slack notification for task completion, distinguishing it from the generic send_slack_notification sibling. However, 'specialized' lacks specificity about what makes it different.
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 on when to use this vs. siblings. The description does not mention prerequisites, alternatives, or when not to use it.
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.
v1.0.0configure_slack_webhooksend_slack_notificationslack_task_completion_notificationTools have distinct purposes: configuration, generic notification, and specialized task completion. Minor overlap between send_slack_notification and slack_task_completion_notification, but descriptions clarify the specialization.
All use snake_case with 'slack_' prefix, but 'slack_task_completion_notification' is noun-heavy while others are verb_noun (configure_, send_). Pattern is somewhat inconsistent.
3 tools is on the lower side but appropriate for a focused Slack notification server. Each tool covers a core function without unnecessary bloat.
Basic configuration and sending are covered, including a specialized notification type. However, missing webhook validation, deletion, or listing, which may be needed for full lifecycle management.
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.
Create Tasks and run Workflows in Bleep from Claude, ChatGPT, and other AI assistants.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
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/Chiuchau-Inc/mcp-slack-notifications'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
