slack-mcp-server: MCP Access to Slack Without Installing a Bot

The gap slack-mcp-server targets: Slack data for LLM clients without an app review

Getting Slack content into a language model usually means creating a Slack app, requesting scopes, waiting for an admin to approve the install, and then maintaining a token rotation process. That path is reasonable for a company-wide deployment and unreasonable for one engineer who wants their own DMs and a handful of channels available to a local assistant. slack-mcp-server exists for that second case. The README describes two access models: OAuth mode, where you supply tokens, and what the project calls stealth mode, which it says runs "without requiring additional permissions or bot installations." The repository also lists GovSlack and Enterprise Slack setups among its supported environments, which matters because those workspaces often have stricter app governance than a standard tenant. The intended user is someone wiring Slack into an MCP-capable client such as a desktop assistant or an agent framework, not someone building a Slack app for other people to install. The project is written in Go and distributed under the MIT licence, so there is no separate commercial tier described in the material.

Four tools, one disabled by default, and what each parameter actually controls

The README documents four tools. conversations_history pulls messages from a channel or DM, taking a channel_id that can be a raw ID like Cxxxxxxxxxx or a name such as #general or @username_dm. conversations_replies does the same for a thread, requiring both channel_id and thread_ts in the 1234567890.123456 format. conversations_search_messages wraps Slack search with optional filters for channel, DM or group DM, user, date and content. conversations_add_message posts a message, and the README is explicit that it is disabled by default: you enable it with the SLACK_MCP_ADD_MESSAGE_TOOL environment variable, and if you set that variable to a comma-separated list of channel IDs, posting is enabled only for those channels. That is a sensible default for a tool that hands write access to a model. The limit parameter is the more interesting design choice. It accepts either a time range (1d, 1w, 30d, 90d) or a plain message count like 50, and the README notes 90d is the default history limit for the free tier. It also states that limit must be empty when a cursor is supplied, so pagination and range selection are mutually exclusive on a single call. Both history and replies accept include_activity_messages, which defaults to false and, when true, adds events like channel_join and channel_leave to the output.

Stealth mode versus OAuth: two different trust models in one binary

The README frames stealth mode as the headline feature and OAuth mode as the alternative. In OAuth mode you provide tokens and the server uses them; the README's stated advantage is that you do not need to "refresh or extract tokens from the browser." In stealth mode the server operates with no scopes and no bot installation. The material does not describe the mechanism behind stealth mode, so the honest position is that the README asserts the capability without documenting how it authenticates or which Slack endpoints it uses. That gap matters for anyone evaluating it for a managed workspace: an approach that relies on undocumented behaviour can break when Slack changes something, and you have no vendor relationship to escalate through. The repository does carry an Archestra MCP catalog quality badge in its README, which is a catalog listing rather than a security audit. Treat stealth mode as a convenience for personal or low-stakes access, and treat OAuth mode as the path to choose when someone else's compliance review is involved. The project also supports Stdio, SSE and HTTP transports and can route outgoing requests through a proxy, which is the configuration you would need in a network that does not allow direct egress.

Unread triage and the priority ordering built into it

One feature stands apart from the raw history tools. The README describes an unread messages capability that collects unread messages across channels with priority sorting, ordering DMs above partner channels above internal ones, plus @mention filtering and mark-as-read support. That ordering is a product decision rather than a technical default, and it tells you who the maintainer had in mind: someone catching up on a backlog who wants direct messages surfaced before a busy internal channel. It is also the feature most likely to interact badly with a workspace where you keep a large number of channels muted or where an automated integration posts into a DM. The README does not state how the unread state is derived or whether mark-as-read is reversible, so if you care about preserving unread counts across devices, test that behaviour against a throwaway account before pointing it at your primary one. The same caution applies to the embedded user information and the user and channel cache: the README lists caching as a feature for faster access, without describing invalidation. In a workspace with frequent membership changes, a stale cache is the kind of failure that produces quietly wrong output rather than an error.

Running it: transports, environment variables and the one flag that matters most

The README gives the shape of a deployment without a full command transcript. You choose a transport (Stdio, SSE or HTTP), configure proxy settings if your network requires them, and supply credentials according to the mode you picked. The environment variables named in the material are SLACK_MCP_ADD_MESSAGE_TOOL for enabling posting, optionally as a comma-separated channel allowlist, and the token material for OAuth mode. The README references an Environment Variables section for the details, and that section is truncated in the material available here, so treat any variable name beyond SLACK_MCP_ADD_MESSAGE_TOOL as unverified until you read the repository directly. The practical setup order is: pick Stdio if your MCP client launches the server as a subprocess, pick HTTP or SSE if the server runs somewhere else on your network, then decide between OAuth and stealth, then leave posting disabled until you have a specific channel you want the model to write to. If you do enable posting, pass channel IDs rather than leaving the variable open-ended, because the README's own example shows that a list restricts the tool to those channels. That single configuration choice is the difference between a read assistant and something that can post into every channel your token can see.

Where it breaks: bot tokens, search, and the free-tier history window

The README states plainly that conversations_search_messages is not available when using bot tokens, because bot tokens cannot call the search.messages API. If your workspace provisioning hands you an xoxb token, search is off the table and you are limited to the history and replies tools. That is a real constraint, not a footnote, because search is often the fastest way to answer a question about a large workspace. The second constraint is the history window. The limit parameter's default of 90d is described as the free tier's history limit, which implies that on a paid tier you can request more, but the material does not say how far back a paid workspace can go or whether the server enforces a ceiling of its own. The third is the interaction between limit and cursor: because limit must be empty when a cursor is provided, a client that wants both a bounded window and pagination has to issue two different kinds of call. Finally, stealth mode's undocumented mechanism is itself a failure mode. If Slack changes the surface it depends on, the server stops working and there is no permission grant to revoke or renew. None of these are reasons to avoid the project, but they are the reasons to keep a fallback.

How it differs from Slack's own app model and from generic MCP bridges

The obvious alternative is a conventional Slack app built with the official SDK and exposed to your assistant through a thin wrapper. The difference is in the permission model rather than the feature list. A Slack app declares scopes, an admin approves them, and the resulting token has a documented, auditable set of capabilities. slack-mcp-server inverts that: stealth mode asks for nothing and therefore has no scope contract to inspect, while OAuth mode asks for tokens you supply yourself. If your organisation needs to answer the question "what exactly can this thing read," the app route gives you an answer and stealth mode does not. The other comparison is against writing your own MCP server in Python or TypeScript. The README's feature list is the argument against that: name-based channel lookup with #Name and @Lookup, date-or-count pagination, unread priority sorting, DM and group DM retrieval, embedded user info, caching, and three transports. Reproducing that is a few weeks of work, and the pagination semantics alone (limit versus cursor, the 90d default) are fiddly enough that copying an existing implementation is cheaper than deriving it. The counter-argument is that a small server you wrote is a small server you can debug, and this one's stealth path is not documented well enough to debug from the README alone.

Maintenance cost, licence, and what to check before you commit

The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and licence text are preserved. That is a permissive arrangement, and it means you can vendor the server into an internal tool without a legal conversation. It also means there is no warranty, so the operational risk sits with you. The release cadence visible in the material is modest: v1.2.2 in late February 2026, v1.2.3 in early March, and v1.3.0 in mid May, with the last push to the default branch in July 2026. That pattern suggests a maintained project rather than an abandoned one, though the gap between the last release and the last commit means features may land on master before they are tagged. Upgrading is a Go binary swap or a rebuild, so the mechanical cost is low; the real cost is re-verifying credentials after a Slack-side change, because stealth mode has no versioned contract. The README's own support request asks readers to star the repository, and it cites monthly visitor and user figures. Those numbers are the maintainer's claim and are not evidence of code quality, so weigh them accordingly. Read the Environment Variables section in full, confirm the token or cookie path works against your workspace, and test the unread mark-as-read behaviour on an account you do not mind disturbing before you point the server at your primary Slack identity.

Editorial conclusion

Adopt slack-mcp-server if you need read-oriented Slack context inside an MCP client and cannot get a workspace admin to approve a bot install, or if you want a bot-free path for a single developer's own DMs and channels. Do not adopt it if your use case centers on posting into shared channels, since conversations_add_message is off until SLACK_MCP_ADD_MESSAGE_TOOL names the channels, and do not adopt it if you rely on Slack's own search API with a bot token, because the README states search is unavailable for xoxb tokens. Before rolling it out, verify that an OAuth token or the stealth cookie path actually works against your workspace, including GovSlack or Enterprise Grid if that is your environment, and confirm which limit values your tier's history window accepts.

Official sources

1. Issues
2. korotovsky/slack-mcp-server on GitHub
3. License: MIT
4. README
5. Releases