Slack MCP Server: Options, Auth Models & Safety

What it is, honestly: there is no single, current, vendor-maintained Slack MCP server to point you at. An early Slack server shipped in the original modelcontextprotocol/servers reference collection, but reference servers requiring third-party API credentials were later trimmed back or archived as the ecosystem matured, and Slack was among them. What exists now is a handful of independently-maintained community servers with genuinely different auth models — this page explains the landscape rather than one install command, because picking the wrong auth model here has real account-security implications.

Why it matters for data work

Slack is where a lot of institutional knowledge lives and dies unsearched — the thread where someone explained why a metric jumped, the channel where an incident got debugged. An agent that can search and read Slack history can pull that context into an analysis instead of you scrolling back through channels by hand. It's genuinely useful; it's also one of the higher-stakes integrations on this list because of what a compromised token can reach.

Install & configure — two different auth models

Community Slack MCP servers split roughly into two camps, and you should know which one you're installing before you do it:

// Pattern A: real Slack app, bot token (safer)
{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": ["-y", "<slack-mcp-package>"],
      "env": { "SLACK_BOT_TOKEN": "xoxb-...", "SLACK_TEAM_ID": "T0..." }
    }
  }
}

Pattern A registers a proper Slack app in your workspace and connects with a bot token (xoxb-...). This is the model Slack's own platform is built around: scoped permissions (channels:history, chat:write, etc.), an admin-visible app install, and a token you can revoke without touching your personal login. Pattern B, common in some community servers, instead extracts your own browser session's tokens (xoxc/xoxd) so the agent acts as you — no app install needed, but the token carries your full personal permissions and bypasses admin visibility into what the "app" can do, because there isn't one. Prefer Pattern A for anything beyond a personal, throwaway experiment.

Which one should you actually pick?

For team or production use: a bot-token server, installed as a real Slack app scoped to the channels it needs, approved by whoever administers your workspace. For solo, read-only exploration on your own account where creating a Slack app isn't worth the friction: a session-token server is faster to set up, but understand you're granting an agent process the same reach your own logged-in session has, including DMs. Either way, verify the specific repo is actively maintained — this corner of the ecosystem moves fast and abandoned forks are common.

How do I keep it safe?

Scope a bot token's OAuth scopes to the minimum the task needs (read scopes only if you don't need the agent posting messages), invite the bot only to specific channels rather than granting workspace-wide history access, and treat a session-token setup as equivalent in sensitivity to sharing your Slack password — because functionally, it's close to that. Never let a Slack-reading agent also hold write access to a system an attacker could reach by posting a crafted message into a channel it monitors; that's a textbook prompt-injection path.

Troubleshooting

Because implementations vary, troubleshooting is more about verifying assumptions than fixing one known bug:

• "missing_scope" errors: the bot token's OAuth scopes don't cover the action — add the scope in the Slack app config and reinstall the app to the workspace.
• Bot can't see a channel: bot tokens only see channels the bot has been explicitly invited to (/invite @yourbot), by design.
• Session-token server suddenly fails: browser session tokens expire when you log out or Slack rotates them — these aren't long-lived credentials like a bot token.
• Package seems abandoned: check the last commit date before debugging further; a stale Slack API integration is a common failure mode in this space.

Author & links

Author: No single maintainer — community-implemented, quality and auth model vary by project

Start here: github.com/modelcontextprotocol/servers (registry and historical reference implementation)

License: Varies by implementation — check each repo

Related skills

For code and issue context alongside chat, see the GitHub MCP server. For docs and knowledge-base content, see the Notion MCP server.

← Back to MCP Servers