slack-bot-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SLACK_MODE | No | Event receiving mode: socket or webhook. Default is socket. | socket |
| SLACK_APP_TOKEN | No | App-level token with connections:write, xapp-… Required in socket mode (SLACK_MODE=socket, the default). | |
| SLACK_BOT_TOKEN | Yes | Bot token, xoxb-… Required. | |
| SLACK_MCP_HTTP_PATH | No | Path for incoming Slack events in webhook mode. | /slack/events |
| SLACK_MCP_HTTP_PORT | No | Port for incoming Slack events in webhook mode. | 3000 |
| SLACK_MCP_LOG_LEVEL | No | debug, info, warn, error or silent. Logs go to stderr. | info |
| SLACK_MCP_STATE_DIR | No | Where pending questions are stored, one JSON file per workspace. | ~/.slack-bot-mcp |
| SLACK_SIGNING_SECRET | No | Signing secret from Basic Information. Required in webhook mode (SLACK_MODE=webhook). | |
| SLACK_MCP_ALLOWED_CHANNELS | No | Comma-separated targets send_message may post to: channel IDs, #names, user IDs or emails. Default is any. | |
| SLACK_MCP_PENDING_TTL_DAYS | No | Pending questions older than this are dropped. | 7 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| whoamiA | Show the server version, which Slack bot and workspace this server is connected to, the connection mode, the OAuth scopes the bot has, and which tools are missing scopes. Call this first when a Slack action fails with a permission error. |
| users_searchA | Find workspace members by email, real name, display name, @handle or job title. Returns user IDs to use with send_message and other tools. Exact matches come first. |
| user_infoB | Get profile details for one Slack user, identified by user ID (U…), email, or @handle. |
| channels_listA | List channels the bot can see, optionally filtered by name. Private channels and DMs appear only if the bot is a member. |
| send_messageA | Post a message as the bot to a channel, a thread, or a user's DM. |
| edit_messageA | Replace the content of a message the bot posted, identified by channel and ts (as returned by send_message). Slack only lets a bot edit its own messages. The new |
| delete_messageA | Delete a message the bot posted, identified by channel and ts (as returned by send_message). Slack only lets a bot delete its own messages. Deleting the parent of a thread leaves its replies in place. This cannot be undone, so confirm with the user unless they asked for it. |
| conversations_historyA | Read recent messages from a channel or DM, newest first. |
| conversations_repliesA | Read the replies in a thread, oldest first, including the parent message. |
| reactions_addB | Add an emoji reaction to a message as the bot. |
| reactions_removeA | Remove an emoji reaction the bot previously added to a message. |
| get_inboxA | Return direct messages and @mentions the bot received while this MCP server was running. Only covers events delivered to this process: messages sent before it started, or delivered to another running instance of the same Slack app, are not here. To reliably fetch replies in a known channel or thread, use wait_for_reply or conversations_history. |
| wait_for_replyA | Block for a short time until someone other than the bot replies in a channel, DM or thread, then return the new messages. Use it only when an answer is likely within a minute or two; every call costs a model turn. Pass |
| check_repliesA | Check once, without waiting, whether people answered the bot. With no arguments, checks every pending question (saved by send_message with expect_reply, or by wait_for_reply on timeout), including ones from earlier sessions; answered questions are removed from the pending list. With |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
Most tools map to distinct resource+action pairs (send/edit/delete_message, reactions_add/remove, conversations_history/replies), and the descriptions explicitly explain boundaries. The one fuzzy cluster is read/wait behavior: check_replies, wait_for_reply, get_inbox and conversations_history all retrieve incoming messages and differ only in polling semantics and scope, which an agent must read carefully to pick correctly. user_info vs users_search is also mildly overlap-prone but clarified by the descriptions.
Conventions are mixed: verb_noun (send_message, edit_message, check_replies, get_inbox, wait_for_reply), noun_verb mirroring Slack's API (channels_list, reactions_add, reactions_remove, conversations_history, conversations_replies), a bare noun (user_info) and a bare verb-ish name (whoami). All names remain readable and most are guessable to anyone familiar with Slack's API, but there is no single predictable pattern to extrapolate from.
14 tools sit comfortably in the well-scoped 3-15 range, and each tool earns its place: identity/context, user & channel discovery, message lifecycle, reading, reactions, and reply-waiting. No obvious filler or redundant duplicate tools.
The core bot messaging lifecycle is fully covered: send, edit, delete, read history and thread replies, react/unreact, receive mentions/DMs, and wait/check for replies, plus discovery tools for users and channels. Gaps are minor-to-moderate: no file upload/download, no message search, no channel creation/invite or member listing, and edit/delete are limited to the bot's own messages, but agents can work around these for typical bot workflows.