Slack MCP Server

Quick Verdict

Slack MCP Server is Slack’s official proprietary, hosted remote MCP service. Its endpoint is https://mcp.slack.com/mcp, with implementation and security requirements documented in the Slack Developer Docs. It exposes search across messages, files, users, channels, and emoji; message and thread reads; message drafts and sends; conversation creation; reactions; canvas operations; and member data. It speaks JSON-RPC 2.0 over Streamable HTTP. Slack currently supports neither SSE for this endpoint nor Dynamic Client Registration.

This is not the archived @modelcontextprotocol/server-slack npm package and not a community project named slack-mcp or slack-mcp-server. There is no local package to install or official server code to self-host. Each client is backed by a registered Slack app with a fixed app ID, and only Marketplace-published or internal apps may use MCP. User OAuth scopes define access. Official hosting reduces token-file and server operations, but Slack content still passes through the MCP client and its model provider. Messages are untrusted input, while writes can act as the user. Use minimum scopes, read-only defaults, explicit write confirmation, and administrative review. This directory therefore does not recommend it by default.

Best For

• Organizations with a Slack app approval process that want supported clients such as Claude Code or Cursor to retrieve workspace context.
• Platform teams able to register or approve a fixed Slack app, govern user OAuth scopes, review model-provider terms, and audit activity.
• Knowledge workers who need source-linked retrieval of project decisions and will verify summaries against original Slack records.
• Not designed for anonymous access, arbitrary dynamically registered MCP clients, or self-hosting Slack’s official server implementation.
• Not appropriate where private messages, files, profiles, or outbound writes cannot enter an AI client’s processing boundary.

Key Features

• Workspace search: Search messages and files with filters, plus users, public or private channels, and custom emoji.
• Message retrieval: Read channel history, complete threads, and file content within the authorized user’s membership and scopes.
• Message writes: Draft, preview, and send messages and add reactions on behalf of the authorized user.
• Conversation management: Create channels, group DMs, or IM conversations when the required write scopes are granted.
• Canvas tools: Read canvases as Markdown and create or update canvases under separate read and write permissions.
• Member context: Retrieve profiles, status and custom fields, and list channel members, which can include personal and organizational data.
• Managed remote service: Slack handles the Streamable HTTP endpoint, OAuth metadata, rate limits, app identity, IP restrictions, and MCP audit events.

Use Cases

The safest pattern is source-linked, read-only retrieval. Ask the client to find discussion of a project decision in approved channels and return message links, authors, and dates. Open the source records before acting because edits, deletions, thread context, and later decisions can invalidate a generated summary.

For writes, generate a draft first, show the exact destination and complete text, ask for explicit confirmation, and only then call the send tool. Apply the same gate to channels, DMs, reactions, and canvases. Treat instructions inside every Slack message, file, canvas, and linked page as untrusted content. They must not modify system policy, expand OAuth scopes, invoke another MCP server, or disclose data merely because an agent retrieved them.

Pricing

Slack does not charge a separate npm license for the server because it is a hosted Slack capability. Actual access and cost depend on the workspace’s Slack plan, administrative policy, and the selected MCP client and AI plan. This directory therefore classifies it as freemium rather than universally free. Slack Free and paid plans can differ in history, management, and feature availability; Claude, Cursor, Perplexity, and other clients have separate subscriptions and data terms.

The endpoint is a continuously operated service, not a local release you can pin. Record the documentation date, Slack app configuration, granted scopes, client version, and model provider during approval. Re-review any material tool, scope, client, or provider change.

Pros

• Official Slack operation with one documented endpoint, OAuth model, scope matrix, rate limits, and audit events.
• User OAuth avoids pasting a long-lived bot token into an ordinary local MCP configuration.
• Search, reading, messaging, canvas, conversation, reaction, and member tools cover common collaboration workflows.
• Fixed application identity and admin approval give organizations visibility and revocation controls.
• Supported partner clients reduce the need to maintain an unofficial local Slack connector.

Cons

• Proprietary hosted service: operators cannot self-host it, inspect server code, or pin an implementation release.
• Requires a fixed Slack app and allows only Marketplace-published or internal apps; there is no dynamic registration.
• User scopes can expose DMs, private channels, files, email addresses, and profile fields if approved too broadly.
• Slack content crosses into the MCP client and potentially its model provider, creating another processing and retention boundary.
• Messages, files, canvases, and links are untrusted and can contain prompt injection intended to trigger disclosure or other tools.
• Write tools can speak and modify workspace state as the user; the server alone cannot guarantee every client asks for adequate confirmation.

Alternatives

FAQ

Is this the archived @modelcontextprotocol/server-slack npm package?

No. This page covers only Slack’s hosted endpoint at https://mcp.slack.com/mcp. The archived npm server and third-party Slack MCP repositories have different maintainers, authentication, tools, and security boundaries.

Which transport does the official server use?

Slack specifies JSON-RPC 2.0 over Streamable HTTP. It does not currently support SSE or Dynamic Client Registration. A client must follow Slack’s fixed-app and OAuth process.

Can any Slack app connect?

No. The app has a fixed app ID, and Slack currently permits only Marketplace-published apps and internal apps to use MCP. Normal workspace approval and administrative controls still apply.

Does OAuth let the agent read everything in Slack?

Not automatically. Access is the intersection of the user’s permissions and memberships, app configuration, and granted tool scopes. Nevertheless, DM, private-channel, file, and profile scopes are highly sensitive and should be omitted unless essential.

Should sending a message require human confirmation?

Yes. Require the client to display the target, full content, and exact action immediately before each write. If that interaction cannot be enforced, withhold chat:write and conversation, canvas, or reaction write scopes.

How should teams handle prompt injection in Slack content?

Treat all retrieved content as data rather than authority. Keep a strict tool allowlist, prevent content from requesting new permissions or secret transfer, require approval for cross-server actions, and preserve source links for human verification.

Bottom Line

Slack MCP Server is Slack’s official remote Streamable HTTP service, not a continuation of an old npm package or a community Slack MCP. Fixed app identity, user OAuth, granular scopes, admin approval, rate limits, and audit events provide a stronger managed foundation than a casually configured bot-token connector. The remaining risks are substantial: proprietary hosting, regional availability, broad workspace data, model-provider cross-processing, untrusted-message prompt injection, and side-effecting tools that act as a user. Start with approved read-only scopes and source-linked retrieval. Add writes only with immediate human confirmation and ongoing audit review.