MCP Server for Slack: The Real Options

The right MCP server for Slack depends almost entirely on how you can authenticate, not on features. If you can install a Slack app, use a bot-token server. If you can't get admin to approve one, use a session-token server that reuses your own browser login. If you don't want to run anything at all, use a remote bridge. Pick the auth model first; the tools are broadly similar across all of them.

This is the grounded shortlist. Every server below is real, linked, and matched to a specific situation, with the minimal config that actually works. Most of these run locally over stdio — as does roughly 90% of the MCP ecosystem — so your Slack token stays on your machine and never passes through a third party.

Pick by how you can authenticate

Start from what your Slack workspace lets you do. Can you register an app and get a bot token? Use a bot-token server. Locked out by admins? A session-token server logs in as you, no app approval needed. Want zero local setup? Go remote. The table maps each option to that decision.

Server	Auth model	Transport	Official?	Best for
Slack MCP Server (korotovsky)	Session token (no admin) or bot	stdio / SSE / HTTP	Community	The default; DMs + group DMs, flexible auth
Slack MCP Server (Ubie)	Bot token	stdio	Community	Clean bot-app setup you control
Slack MCP Server (session)	Session token, no OAuth	stdio	Community	21 tools, one command, no app registration
Zapier MCP Server	Zapier account (OAuth)	Remote	Community	Zero local setup; Slack + thousands of apps
Graphlit MCP Server	Graphlit + Slack ingest	stdio	Community	RAG/search over Slack, not live posting

If you only read one row: no admin rights → korotovsky; you own a Slack app → Ubie; you want a search index over Slack history → Graphlit.

korotovsky: the default pick

For most people, Slack MCP Server (korotovsky) is the one to reach for first, and the reason is auth flexibility. It works with a no-admin token — the xoxc/xoxd session pair pulled from your own logged-in browser — so you can connect to a workspace where you'll never get an app approved. If you can register a bot, it takes a bot token too.

It's also the only server here that covers DMs and group DMs, not just public channels, and it speaks all three transports: stdio, SSE, and HTTP. Run it locally over stdio and it behaves like any other stdio MCP process.

{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": ["-y", "slack-mcp-server@latest", "--transport", "stdio"],
      "env": {
        "SLACK_MCP_XOXC_TOKEN": "xoxc-...",
        "SLACK_MCP_XOXD_TOKEN": "xoxd-..."
      }
    }
  }
}

The trade-off to understand: a session token acts as you. It carries your full read access to every channel you're in, and it can post as you. Treat those two values like a password — store them in your client's secret handling, not a committed config — and know they expire when your browser session does, so you'll re-pull them periodically. If your workspace forbids this kind of access, don't route around policy; use a sanctioned bot server instead.

Ubie: the clean bot-token option

Use Slack MCP Server (Ubie) when you can register a Slack app and want the auth boundary to be an explicit, revocable bot token rather than your personal session. It handles the core loop — post messages, read channels, and search — over stdio, which is the least surprising setup for a credential you control.

The upside of a bot token over a session token is governance. Scopes are visible in the app config, the token is revocable in one click, and the bot only sees channels it's been invited to. That's the posture you want in a shared or work-managed workspace.

The cost is the setup: you register an app, choose scopes, install it to the workspace, and invite the bot to the channels it should see. If your admin blocks app installs, this option is simply off the table — which is exactly when korotovsky's session auth earns its place.

The other session-token server

Slack MCP Server (session) is the minimalist take on the no-admin approach: session-token access for AI agents with no OAuth and no app registration, exposing 21 tools from a single command. Like korotovsky's session mode, it reuses your existing Slack login instead of a bot.

So when would you pick it over korotovsky? Rarely — korotovsky is the more full-featured of the two and adds bot-token support and multiple transports on top of session auth. Choose this one if you specifically want the smallest, single-command install and you'll only ever use session auth. Otherwise default to korotovsky and skip the decision.

Zapier and Graphlit: when you don't want a live Slack client

These two aren't really "post to Slack" servers, and picking them for that job is a mistake. Zapier MCP Server is a remote bridge: it connects your assistant to Slack alongside Gmail, Teams, and thousands of other apps through your Zapier account, with nothing to install locally. Reach for it when the win is breadth — one connection touching many tools — and you accept that your Slack calls now flow through Zapier's cloud rather than your machine.

Graphlit MCP Server solves a different problem: it ingests Slack — plus Discord, Google Drive, GitHub, Jira, Linear, and more — into a searchable store you can run RAG over. That's for "what did the team decide about X last quarter," not "send this message now." If your goal is querying Slack history rather than acting in it live, this is the right shape; if you want to reply in a thread, it isn't.

What to skip and how to wire it up

Skip installing more than one Slack server. They overlap heavily, and every extra server eats into the roughly 40-tool budget most clients handle before tool selection gets unreliable — that's real math, walked through in Cursor's tool limit. One Slack server is enough; add a second only when it does a genuinely different job, like Graphlit's search index alongside a live-posting server.

Adding any of these is the same three steps in any client — server command or URL, credentials, restart — covered in how to add an MCP server. To compare the wider field or find related tools, start from the best MCP servers, filter by capabilities, or check alternatives when none of these fit your workspace's constraints.