How to Set Up the Slack MCP Server: Let AI Read Channels, Post Only With Approval
Short answer: create a free MCP Trail account, connect Slack from the marketplace so the bot token stays server-side, then allowlist the read tools, put post message behind human approval, and turn on DLP scanning. Your assistant can summarize #engineering and draft announcements, but it cannot send a message to a channel without a person clicking approve.
The Slack MCP server is one of the highest-leverage integrations you can give an AI assistant — and one of the easiest to get wrong. A Slack bot token (xoxb-...) pasted into a local MCP config can read every channel the bot was invited to, and nothing records what the model did with it. An assistant that can post to #general unsupervised is its own category of incident. The fix isn’t to avoid Slack; it’s to put a gateway between the AI and your workspace.
What the Slack MCP server actually exposes
Once connected, the Slack MCP server hands your assistant a set of tools that map onto Slack’s Web API — roughly:
- Read channels and messages — list the channels the bot can see, pull recent history, resolve users and threads
- Search — query across messages the workspace has indexed
- Post and reply — send a message to a channel, reply in a thread, add a reaction
That last group is the dangerous one. Reading is recoverable; a wrong message in a customer-facing channel is not. So the setup below treats the two groups differently: reads are cheap and allowlisted, writes are gated.
Slack auth: a bot token and its scopes
Slack access is scoped by a bot token, and the token only carries the OAuth scopes you grant when the app is installed. Typical scopes for an MCP setup:
| Scope | Grants | Needed for |
|---|---|---|
channels:read | List and read public channels | Listing channels, resolving IDs |
channels:history | Read messages in public channels | Summarizing and reading history |
search:read | Search messages | The search tool |
chat:write | Post messages as the app | Posting and replying |
groups:read | See private channels the bot is in | Working in private channels |
Two things are worth internalizing. First, the bot only ever reaches channels it has been invited to — Slack-side membership is your first permission boundary. Second, scopes are granted at install time and are hard to trim later, so it’s tempting to over-grant chat:write “just in case.” That’s exactly the scope the gateway is going to keep on a leash.
Why host the Slack MCP server behind a gateway?
- The bot token never lives in a client config — stored encrypted, injected at runtime
- Every channel read, search, and post is in the audit log — with arguments and result status
- Posting can require approval — the message parks in a queue until a human signs off
- Read tools are allowlisted, write tools are gated — least privilege enforced at the tool level, not just the scope level
- One shared endpoint — the whole team uses the same governed server instead of copying tokens around
If any of that hosting story is new to you, the no-Docker hosting guide covers the runtime side in full.
Step 1: Create your free MCP Trail account
Sign up at app.mcptrail.com — the free tier covers everything in this tutorial, including the audit log.
Step 2: Connect Slack from the MCP Marketplace
Open MCP Marketplace in the sidebar, search for Slack, and click Connect. This provisions a hosted runtime for the Slack MCP server — no npm, no Node, nothing installed on your laptop.
Step 3: Authorize your Slack workspace
The wizard shows a Connect account step. Click it and Slack’s own authorization screen opens, listing exactly which scopes the app is requesting (the ones in the table above). Pick the workspace and approve.
MCP Trail’s OAuth broker stores the resulting bot token in an encrypted per-user vault, injects it into the hosted server at runtime, and refreshes it automatically — it never touches the client side. Disconnect the workspace at any time from Vault in the sidebar.
Scope tip: the token only reaches channels the app is a member of. Invite the bot to the specific channels you want the AI to work in rather than adding it everywhere. Least privilege starts on the Slack side, before the gateway even sees a call.
Step 4: Watch the server come online
The setup log shows the hosted runtime booting, the MCP handshake completing, and the Slack tools being discovered — the channel-list, history, search, and post tools among them. Green checks mean you’re live.
Step 5: Connect your AI client
Click Connect an agent and pick your client for a ready-made snippet. Under the hood it’s always the same endpoint plus a bearer token:
{
"mcpServers": {
"slack": {
"url": "https://<your-endpoint>",
"headers": { "Authorization": "Bearer <your-token>" }
}
}
}Or with Claude Code:
claude mcp add --transport http slack "https://<your-endpoint>" \
--header "Authorization: Bearer <your-token>"The full per-client walkthrough — Claude Desktop, Cursor, VS Code — is in the client connection guide.
Step 6: Verify it works
Ask your assistant:
Summarize the last 20 messages in #engineeringThen check Audit log in the sidebar — the channel-history call is there with its arguments and result status. That audit trail is the whole point: you can always answer “what did the AI read, and when.”
Set the right policy per tool
This is where the Slack setup stops being a token dump and becomes governance. Open your server under Guardian servers and set a policy per tool. A sensible starting point:
| Slack tool | Read / write | Recommended policy |
|---|---|---|
| List channels | Read | Auto-allow |
| Read channel history | Read | Auto-allow |
| Search messages | Read | Auto-allow |
| Post message to channel | Write | Human-in-the-loop approval |
| Reply in thread | Write | Human-in-the-loop approval |
| Add reaction | Write | Auto-allow (low blast radius) |
Reads are allowlisted so the assistant stays fast and useful. Everything that writes to a channel a human can see routes through approval. You can read more on the allowlist pattern in the tool allowlist guide.
Put “post message” behind human approval
Find the post-message tool in the tools list and set its policy to human approval. From then on, when the assistant wants to send a message, the request parks in the Approval queue until someone approves or rejects it — and you can wire that queue to fire Slack alerts so the right person sees it immediately.
Concretely: an agent drafting a weekly update for #announcements composes the full message, then stops. A human sees the exact text, the target channel, and who the agent is acting for, and clicks approve. Drafting stays fast; publishing stays human. This is the same human-in-the-loop model you’d want on any irreversible action.
Scan message content for secrets
Before anything lands in a channel — or leaves one — turn on DLP scanning (sidebar → Custom DLP rules). It inspects tool arguments and results for patterns like API keys, tokens, or customer emails and can redact or block them. It catches two Slack-specific failure modes: an agent about to post a leaked secret into a public channel, and an agent reading a channel where someone pasted credentials and pulling them into the model’s context. See protecting sensitive data for rule examples.
Slack-specific gotchas
- Rate limits are real. Slack’s Web API is tiered and throttles aggressively — an agent that fans out one history call per channel across a large workspace will hit
429s. Keep prompts scoped to specific channels rather than “summarize everything.” - Workspace and channel scoping. The bot sees only its workspace and only the channels it’s a member of. Cross-workspace or Enterprise Grid setups need the app installed per workspace.
- Private channels are opt-in. A private channel is invisible to the bot until it’s explicitly invited, even with
groups:readgranted. If the AI “can’t find” a channel, it usually just hasn’t been added.
Prefer to run it locally?
The npx route with SLACK_BOT_TOKEN in your client config works for personal experiments. But for anything team-facing, a plaintext token plus unaudited, unapproved posting is a hard sell to whoever owns security — the hosted setup above answers those questions by default.
FAQ
Can the AI post to Slack without approval?
Only if you let it. Out of the box you decide per tool: leave the post tool auto-allowed for a personal sandbox, or set it to human approval so nothing reaches a channel without a click. With approval on, the message waits in the queue — the AI drafts, a person publishes.
What scopes does the Slack MCP server need?
At minimum channels:read and channels:history to read, search:read to search, and chat:write to post. Add groups:read for private channels. You grant these on Slack’s consent screen at connect time; the gateway can then disable or gate any tool regardless of what the token technically allows.
Can the AI read every channel in my workspace?
No — only channels the bot has been invited to, and only through tools you’ve enabled. That’s two boundaries: Slack-side membership, then gateway-side tool policy. Everything it does read is recorded in the audit log.
Does this work with Claude Desktop and Cursor?
Yes — any HTTP-capable MCP client. The Connect an agent panel generates configs for Claude Code, Claude Desktop, Cursor, VS Code, and more.
Explore features · Use cases · Open MCP Trail