Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
SLACK_MODENoEvent receiving mode: socket or webhook. Default is socket.socket
SLACK_APP_TOKENNoApp-level token with connections:write, xapp-… Required in socket mode (SLACK_MODE=socket, the default).
SLACK_BOT_TOKENYesBot token, xoxb-… Required.
SLACK_MCP_HTTP_PATHNoPath for incoming Slack events in webhook mode./slack/events
SLACK_MCP_HTTP_PORTNoPort for incoming Slack events in webhook mode.3000
SLACK_MCP_LOG_LEVELNodebug, info, warn, error or silent. Logs go to stderr.info
SLACK_MCP_STATE_DIRNoWhere pending questions are stored, one JSON file per workspace.~/.slack-bot-mcp
SLACK_SIGNING_SECRETNoSigning secret from Basic Information. Required in webhook mode (SLACK_MODE=webhook).
SLACK_MCP_ALLOWED_CHANNELSNoComma-separated targets send_message may post to: channel IDs, #names, user IDs or emails. Default is any.
SLACK_MCP_PENDING_TTL_DAYSNoPending 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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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. is_member: false means the bot must be invited before it can post there (unless it has chat:write.public).

send_messageA

Post a message as the bot to a channel, a thread, or a user's DM. target accepts a channel ID (C…), #channel-name, user ID (U…), @handle, email, or a person's name; users get a direct message. Use context to add small reference details under a divider at the bottom (Jira ticket, comment link, source, IDs). Use blocks only when you need a custom Block Kit layout (header, fields, images, etc.). Returns the message ts, which you can pass to wait_for_reply or use as thread_ts to reply in a thread.

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 text, context and blocks fully replace the old content, so resend any context you want to keep.

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. channel accepts a channel ID, #channel-name, or a user (ID, @handle, email) for the bot's DM with them. Use cursor from the previous response to page further back. Thread replies are not included; use conversations_replies for those.

conversations_repliesA

Read the replies in a thread, oldest first, including the parent message. thread_ts is the ts of the parent message (or of any message in the thread).

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 since_ts = the ts of your question (from send_message). Replies both as new messages and inside the question's thread are found. On replied: false, follow the returned next_step: after a couple of timeouts, stop waiting, tell the user, and collect the answer later with check_replies. Keep timeout_seconds below your MCP client's tool-call timeout (often 60 seconds; Claude Code users can raise it with MCP_TOOL_TIMEOUT).

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 channel and since_ts, checks one conversation instead. Cheap to call, so use it for long waits: end your turn, then call it later from a scheduled or looped run.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.8/5.0

Scored across 14 tools

Disambiguation4/5

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.

Naming Consistency3/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues