Slack MCP, or an assistant reading company conversations

Slack MCP, or an assistant reading company conversations

Slack offers an official server in the protocol describing how tools attach to language models. Announced in autumn 2025 and generally available since February 2026, it runs as a remote service at the vendor's address, so nothing needs hosting on your side.

Once connected, an assistant can search messages and files, read channels and threads, send messages, react to them, and look up people. Some capabilities, such as working with shared documents, require a paid Slack plan, while the server itself costs nothing beyond what you already pay.

Before the configuration, one thing to understand first, since it determines whether the deployment will be safe: the permission model. It governs what the assistant actually sees.

User tokens versus app tokens

This distinction is the most important in the whole text and the most often confused during first setup.

A user token acts on behalf of a specific person and is bounded by their permissions. If you cannot see a channel in Slack, an assistant running on your token cannot see it either. Access to private conversations covers only those you take part in.

An app token acts on behalf of an installed program and carries permissions granted to the whole organisation. An app with broad scope sees private channels regardless of who invoked it.

The consequence is serious. An assistant connected through a broadly scoped app token answers everyone identically, so somebody outside a team can learn the contents of a conversation they have no access to. Slack's permission model then stops working, even though nothing changed inside Slack.

The practical conclusion is unambiguous. For uses where an assistant answers a specific person, use that person's authentication. Leave app tokens for tasks performed on the system's behalf, on an explicitly narrow scope: posting notifications to one channel, reading one public channel.

On the official server that choice is settled in practice. The documentation lists the permission scopes for every tool of that server on a user token alone, and the authorisation endpoints named for clients issue exactly that kind of token; app tokens appear separately, for the experience inside Slack itself. The starkest example is searching messages, since Slack's search interface does not work with an app token. The broadly scoped app token risk described above therefore concerns community and self written servers above all, where nothing narrows the choice.

Approval and organisational control

Connecting does not happen quietly, and that is good news for whoever owns security.

A client connects through the standard authorisation mechanism, and a workspace administrator approves which tools may connect. Without that approval a user cannot add an assistant for themselves, even holding an account.

That solves a problem that with external tools is real: half the company attaching tools nobody knows about to work conversations. Here the list of admitted clients is single and visible.

Approach the rollout in stages. Start with one team and one client, on read only permissions. After two weeks you will know what people actually use it for, and only then decide about extending the scope to state changing operations.

Consider separately what happens to conversation content on the client's side. The server exposes data, and where it travels next and how long it is kept depends on the tool fetching it. Ask that question before approval rather than after.

What an assistant can do with it

Describing the uses concretely pays off, since they determine whether a permission scope is justified.

The most useful is finding context. A question about when a deadline change was decided and by whom leads the assistant to a thread from three months ago that nobody would find by hand. That use requires reading alone and gives the greatest value at the smallest risk.

The second is summarising. A channel holding four hundred messages from a week, reduced to a list of decisions, saves time for somebody returning from leave and incidentally reveals what was never decided.

The third is combining with other sources. An assistant with simultaneous access to conversations and to a code repository, covered in the piece on the GitHub server, can link an issue to the discussion that led to it.

The fourth is acting: posting a summary to a channel, reminding about an unresolved thread, marking a message. That is where caution begins, since a message sent in error on a user's behalf is visible to everyone and hard to retract.

A practical rule: state changing operations should require confirmation rather than happening on their own. A model invokes tools based on what it read, and in company communication it also read other people's messages.

Limits worth knowing about

Three constraints decide how much an assistant actually manages, and descriptions of integrations usually omit them.

The first is rate limits. Every tool carries its own threshold and, more to the point, draws on the same budget as your other integrations, since the limits apply identically whether a call goes through this server or through ordinary Slack interface methods.

The second is the Slack plan. On the free plan history reaches ninety days, so an assistant hunting for a decision made six months ago fails to find it not because the question was poor but because the message is no longer visible. On that same plan the integration count stops at ten apps, and shared documents are a paid plan feature.

The third is the catalogue of admitted applications. Only apps published in Slack's marketplace and an organisation's internal apps may use the server, and an unlisted app simply will not connect. A client also has to be backed by a registered Slack app with a fixed identifier, which is what lets administration approve the traffic and find it later in the audit logs.

Risks that deserve naming

This section matters most during a rollout and rarely appears in material about integrations.

The first risk is content coming back from the tool. Messages fetched from Slack enter the model's context directly, and the model treats them as information. A message holding a sentence phrased like an instruction can therefore influence what the assistant does next, including invoking another tool. In company communication the content comes from many people, including channels where somebody outside the organisation writes.

The second is the scope following from an app token. Described above, and it is the most common serious configuration mistake.

The third is context accumulation. An assistant reading conversations for a month builds a picture of the organisation broader than any single person's, and that picture goes wherever the client runs.

The fourth is personal data. Conversations hold content concerning specific people, so processing it falls under the same rules as other employee data, regardless of it living in a messenger.

Limiting those risks comes down to three things: authentication at the person level rather than the app level, confirming state changing operations, and awareness of where content goes on the client's side.

A fourth is worth adding, simple and effective: narrowing the channel scope. An assistant needing access to three project channels does not have to see the whole workspace, and narrowing the scope at approval reduces all four risks at once. It is the only limit that works regardless of what the model reads and how it reacts.

Setup step by step

Connecting takes a quarter of an hour, provided an administrator has already approved your chosen client.

The first step belongs to administration: admitting the tool to the approved list. Without it the later steps simply fail, and the message is often misleading, suggesting an authentication problem.

The second is adding the server to your client's configuration. Since the server runs remotely, the entry names a service address rather than a command launching a local program. The address is https://mcp.slack.com/mcp, and the exchange runs JSON-RPC 2.0 over streamable HTTP. The older server sent events mode and dynamic client registration are not supported, so a tool that knows only those simply will not connect.

The third is authorising in a browser. A Slack page opens listing the permissions the client requests, and that is the moment to read them. The list states plainly whether the tool wants only to read, or also to write and search private conversations.

The fourth is checking what actually works. Asking about something from a channel you have access to and something from one you do not shows, within minutes, whether permissions behave as you assumed.

The fifth, in team work, is recording it in the project documentation: which client was approved, on what scope, and what it is for. Without that note, a quarter later nobody knows why the assistant sees what it sees.

Signs something went wrong

A few symptoms worth recognising, since each points at a specific cause.

The assistant finds no messages although they exist. Most often person level authentication is missing, since search does not work with permissions granted to an app.

The assistant knows the contents of conversations you have no access to. That signals it runs on a broadly scoped app token, and it calls for changing the configuration immediately rather than adding a warning to the instructions.

The assistant sends messages nobody asked for. That usually means state changing operations require no confirmation, and the model judged sending to be a sensible next step after reading a thread.

The assistant answers from stale information. Search returns what matches in meaning rather than what is newest, so for questions about the current state it pays to state a time range explicitly.

Answers contain content that was in neither the question nor the channel. That is the most serious signal, since it can mean the model executed an instruction found in somebody else's message. Check the run record then, if your client keeps one.

The official server against the alternatives

The first row is the right default, since it removes upkeep and gives an administrator control. Reach for the others when the official scope falls short or when policy requires traffic not to leave your network.

The last row deserves honest consideration. If the task amounts to sending a notification after an event, an ordinary incoming mechanism does it more cheaply, faster, and without the risk of a model inventing something you did not plan.

Common mistakes

The first is connecting an assistant through a broadly scoped app token, which on a community or self written server nothing prevents. Slack's permission model then stops working, and somebody outside a team can learn the contents of a conversation they have no access to.

The second is granting private conversation search permissions at the app level. That permission makes sense only on a user token, since only then does it preserve who sees what.

The third is letting the model send messages without confirmation. A message sent in error on a user's behalf is visible to everyone and hard to retract.

The fourth is treating channel content as safe data. A message holding an instruction enters the model's context exactly like any other.

The fifth is approving a client without checking where fetched content goes and how long it is kept. The server exposes data; the tool on the other side does the rest.

The sixth is rolling out across the whole organisation at once. One team, one client, and read only permissions for two weeks say more than any plan.

The seventh is handing the assistant the whole workspace when it needs three channels. Narrowing the scope at approval is the simplest safeguard and works regardless of how the model behaves.

FAQ

Does Slack's official server cost anything?

The server itself costs nothing beyond what you pay for Slack, and access follows your plan. Some capabilities, such as working with shared documents, require a paid plan, so the scope is narrower on a free one.

How does a user token differ from an app token?

A user token acts within a specific person's permissions, so the assistant sees exactly what that person sees. An app token carries organisation level permissions and sees more, regardless of who asked. For assistants answering people, the first is correct.

Can an assistant search my private conversations?

Under person level authentication, only those you take part in, since your permissions apply. Under a broadly scoped app token that limit disappears, and that is exactly why such an arrangement should be avoided for assistants answering users.

Who decides which tools may connect?

The workspace administrator. A client connects through the standard authorisation mechanism and requires approval, so a user cannot add an assistant for themselves. The list of admitted clients is single and visible to administration.

Is writing your own server better than using the official one?

Usually not, since the official one removes upkeep and gives an administrator control. Your own server, built with the tools covered in the piece on the protocol's toolkit, makes sense for a narrow use with custom logic or under a requirement that traffic not leave your network.

Documentation sits on Slack's developer site, an administrator oriented description in the help centre, and other servers can be found through the protocol's registry.