Slack MCP server for a small team: which scopes to approve, narrow or decline
A teammate posts in your admin channel: "Can we connect Claude to Slack?" If you hold the Slack admin role at a firm of 5 to 100 people, refusing sends the team to an unofficial Slack MCP server on GitHub, run from a laptop. Approving everything lets an AI client read private channels and direct messages as each person and post in their name. This guide gives you a middle path: a table that says approve, narrow or decline for each group of permissions the Slack MCP server uses, built from Slack's own documentation, plus a short test for when an agent that already lives in the thread is the simpler answer.
The short answer
Treat the request as an app approval, not as a new kind of integration. Slack's MCP server documentation says workspace admins can approve and manage MCP client integrations, and that each client must be backed by a registered Slack app. So the work is the one you already do for any Slack app, with three differences: the client acts with a person's own token, the permissions are listed per tool, and the thing most likely to go wrong is a client that asks for far more than the job needs.
A workable first policy for a small team:
- Approve one named client for read-only search, for two or three named people, as a pilot.
- Decline anything that sends messages, creates channels or writes to canvases and lists until the pilot shows a real need.
- Decline private-channel and direct-message history for everyone by default.
- Decline unofficial servers that skip approval, and say why in the same message.
- Put a recurring review of approved clients in the admin channel.
What the Slack MCP server is, and what the client sees
MCP, the Model Context Protocol, is an open standard for letting an AI application discover and call tools on another system. Slack's MCP overview describes two directions: the Slack MCP server, which lets an AI client such as Claude or Cursor work with Slack, and Slackbot as an MCP client, which lets Slackbot call tools in other apps. This article is about the first direction, because that is what a teammate means by "connect Claude to Slack".
What the client can do is a tool list. According to the Slack MCP server guide, the server searches messages, files, users and channels, reads channels and threads, sends, schedules and drafts messages, creates conversations, adds reactions, creates and updates canvases, uploads files and works with lists. The Slack help center lists ChatGPT, Claude, Cursor and Perplexity among the partner clients you can start from.
"As each user" is the part admins ask about most. The server uses OAuth: each person goes through a consent screen and authorizes the client, and the permissions sit on that person's user token, per the same guide. Slack's general-availability announcement says the server respects user permissions. In practice that means three things:
- A search returns what that person could already see, not everything in the workspace.
- A message the client sends is sent as that person, not as a bot with a clearly marked name.
- If a person later leaves a private channel, the client loses it with them. If they hold broad access, the client holds it too.
"It respects permissions" only limits the client to what the person can already reach, so a person with broad access gives the client broad access.
Why the decision is per client, not per server
The admin decision is about each client app, not about the Slack MCP server as a whole, so approving Claude does not approve Cursor and every client gets its own row in your decision table.
The reason is in how Slack identifies clients. The docs say an MCP client must be backed by a registered Slack app with a fixed app ID, which lets admins manage and approve it through the standard app approval process and lets Slack tie requests to that app for logging, rate limits and access control. They also say only directory-published apps or internal apps may use MCP, and unlisted apps are not allowed.
When a teammate asks for "Slack MCP", ask which client they want to use. Write the answer down as the app name, not as the protocol. Approve Claude and a later request for Cursor is a new request with a new set of scopes, a new owner and a new review date.
A practitioner case shows how this plays out in a stricter organization. A university team's internal Slack app that used the hosted server was rejected by the Slack admins, who treated AI connectors as a policy question and refused the history scopes for any app, and did not approve AI assistants in that workspace at all, as recorded in a public GitHub issue. That is one author's report from a large organization, not a small firm, but it shows the two questions admins actually ask: is this kind of client allowed at all, and are these particular scopes allowed.
The decision table
The scopes below come from the per-tool list in the Slack developer documentation. The approve, narrow or decline column is a recommendation for a small team, not something Slack prescribes.
| What the client asks to do | Scopes on the user token | Recommendation | Reason |
|---|---|---|---|
| Search public channels | search:read.public | Approve for the pilot group | Reads only what the person can already search, and is the most common reason people ask |
| Search private channels, group DMs, DMs | search:read.private, search:read.mpim, search:read.im | Narrow: pilot only, named people | Reaches the most sensitive conversations |
| Search files, read files | search:read.files, files:read | Narrow | Files hold contracts, invoices and exports |
| Read a channel or thread | channels:history, groups:history, mpim:history, im:history | Narrow: public history first, decline private and DM history | Whole history, not a search hit |
| Send or schedule a message | chat:write | Decline at first | Posts in the person's name |
| Create channels or DMs, add reactions | channels:write, groups:write, im:write, mpim:write, reactions:write | Decline | Not needed to answer a question |
| Read or write canvases and lists | canvases:read, canvases:write, lists:read, lists:write | Narrow to read, decline write | Writes change shared documents |
| Upload files | files:write | Decline | Moves data out of Slack |
| User profile and email | users:read, users:read.email | Narrow | Email addresses are personal data |
Two cautions on using the table. First, the docs list scopes per tool, but they do not say that you can pick scopes one by one: what you can approve depends on what the client requests. If a client asks for the whole bundle, your real choice is the bundle, and "narrow" means asking the vendor for a smaller scope set or declining. Second, the history row deserves its own conversation. Approving a client that requests the history scopes means approving read access to whole channel and thread history, not just search, because reading a channel or thread is a separate tool with its own scopes. Admins who think "search only" and approve a client that also requests history have approved more than they meant to. The university case above shows the other side: without the history scopes, the read-channel and read-thread tools stop working.
A worked admin thread
This is a made-up example to show the order of questions. Names are invented.
Priya (account manager), in #slack-admins: Can we connect Claude to Slack? I want it to find what we agreed with Acme.
Sam (admin): Which client, and which workspace are you using it from?
Priya: Claude.ai, our main workspace.
Sam: Here is the table. For a first pass I can approve public search for you and Dev. Reading full channel history and posting stay off until we see a need. Private channels and DMs stay off.
Priya: I do need the Acme private channel.
Sam: Then we make it narrow: you tell me the channel, I check who is in it, and we decide after the pilot week. Please also tell me the first question you will ask, so I can check the audit log against it.
Sam named the client, offered the smallest useful approval, wrote the exception down instead of granting it by default, and tied the pilot to a real question. None of that needed a policy document.
Failure handling and trade-offs
A client asks for more than the pilot needs. Decline it and ask for the smaller set. If the vendor cannot offer one, the answer is no for now. A slightly annoyed teammate is cheaper than a post-incident review.
Someone installs a server that skips approval. An open-source server that needs no workspace permissions is not a cheaper version of the approved path, it is the path that skips the approval step and audit log you were trying to keep. One popular open-source server describes a mode that works in "stealth" with no permissions or scopes in the workspace, says it is not an official Slack product, and documents browser session tokens as an option. An engineering team that audited its own integration catalog wrote that third-party servers generally bypass vendor governance such as admin approval and audit logs; that is an author report, but it matches the way the Slack docs tie approval and logging to the registered app. Your rule can be one sentence: only clients that appear in the Slack app approval list, never a local server using someone's session.
An old reference server is still running. Anthropic's original Slack MCP server did not turn off link unfurling when posting, which a security advisory showed could leak data to third-party servers after a prompt injection. The server was archived and, according to that advisory, will not be patched. If anyone on your team installed it before the hosted server existed, ask them to remove it. The author's broader advice, to keep an inventory of who installed which MCP server, is worth copying.
Prompt injection through a message. Any client that reads messages and can also post is exposed to instructions hidden in the text it reads. That is the case for keeping search and posting apart in the table, and the design is covered in how to stop prompt injection in Slack AI agent tool calls.
Audit and network controls may not match your plan. The docs say MCP activity can be audited with the associated audit logs, and that an app's IP allowlist applies to MCP requests. The page does not say which Slack plans include audit logs, so check your own admin console before you promise anyone an audit trail. If a pilot depends on an allowlist, make sure the client's addresses are on it, or requests will fail.
Trade-off: speed against exposure. The more history a client can read, the better its answers about past decisions. The same history includes the things nobody should have pasted into a channel. Start narrow and widen with a reason, rather than the other way round.
Verify it works
Run the pilot for a week and check four things:
- The client sees what the person sees. Ask the pilot user to search for something only in a private channel they are not in. It should return nothing.
- The audit trail exists. Find the pilot user's activity in the audit logs. If you cannot, treat the pilot as unaudited.
- Nothing posted that nobody meant to post. If you declined
chat:write, no new messages should appear under the user's name from the client. - The scopes are what you approved. Open the app's settings after the first consent and compare the granted scopes to your table.
Then put a repeating reminder in the admin channel to review every approved client, including who owns it and whether anyone still uses it. The wider routine for any Slack app is in Slack app management for a small team, and the agent-specific checks are in the security checklist for a small team.
When an agent in the thread is the simpler answer
An MCP client suits a person who works inside Claude, ChatGPT or Cursor all day and wants Slack as one more source. It does not suit a team whose actual need is "somebody tell me the status of the Acme renewal", asked in Slack where the answer will be read by others. For that, a second app, a second consent screen per person and a second review cycle may be more machinery than the job needs.
The Kipwise agent is built for that second case. A teammate mentions it once in a channel thread and plain replies in that thread continue the work. It uses each person's own connected-account permissions for the tools they connect, so a page, file or record that person cannot open is not read to them through the agent. Before it posts, or changes something in a connected service, it shows an Approve or Deny card that only the person who asked can use, and the card expires after 30 minutes. Your workspace can turn any lookup or change off. Some organizations only let an administrator approve a new app, so you may need to approve the Kipwise agent first, which is the same admin step this article describes. See the Kipwise agent page for what it covers and pricing: $10 per user per month with a minimum of 3 users, and a short trial. The approval pattern behind that card is explained in how to add human approval to AI agent workflows in Slack.
Choose by the shape of the work:
| If the need is | Use |
|---|---|
| One person researching across Slack from an AI chat window | An approved MCP client, narrow scopes |
| A team asking recurring questions in a thread, with writes that need a person's yes | An agent in the thread with an approval card |
| Anyone proposing a local server with no workspace permissions | Neither, until it goes through approval |
For the Claude-specific product that lives inside Slack, which is a different thing from the MCP server, see Claude in Slack for a small team.
What to do next
Open your Slack admin page for installed apps today and list every app whose name contains an AI client or any MCP tool, with the person who installed it. Then paste the decision table above into your admin channel, replace the pilot names with your own, and answer the oldest open "can we connect Claude" request with one of three words: approve, narrow or decline.
