Slack MCP

The 78/100 score is weighted around Slack MCP’s real job: retrieving useful organizational context while preserving permission boundaries and performing controlled actions. Search relevance, permission fidelity, authentication reliability, context efficiency and message-action safety therefore matter more than raw feature count.

The server is first-party, actively maintained and unusually granular about access. The score is held back by recurring OAuth/client interoperability problems, the sensitivity of Slack history, substantial context growth on long threads/files, and the consequences of write actions performed under a user’s identity.

Slack MCP is Slack’s first-party hosted Model Context Protocol server for giving MCP-compatible AI clients permission-controlled access to Slack workspace data and actions.

The canonical endpoint is https://mcp.slack.com/mcp. Slack hosts and manages the server, so the official path does not require installing a local Slack MCP package. The connection uses JSON-RPC 2.0 over Streamable HTTP and OAuth.

The central distinction is authorization. Slack MCP does not simply give an AI “your Slack.” The usable surface is determined by the client application, authenticated Slack user, granted OAuth scopes and the user’s existing workspace permissions.

Slack MCP is not a read-only connector. Its documented surface spans search, conversation retrieval, files, identity, collaboration objects and write actions. Some documented action families contain multiple operations, so a single exact “tool count” can be misleading.

The blast radius is primarily social and organizational rather than machine-level. A mistaken Slack action can publish information or send a message as the authenticated user to coworkers or other workspace participants.

An MCP client sends a structured tool request to Slack’s hosted MCP endpoint. Slack authenticates the user and application, applies OAuth scopes and workspace permissions, runs the permitted Slack operation, and returns the result to the client for use as model context.

Slack can associate MCP requests with the registered client application for logging, rate limiting and access control. Existing app-governance controls remain relevant because the MCP server operates inside Slack’s normal authorization system.

Slack’s current no-code partner list names Claude.ai, Claude Code, Perplexity and Cursor. Slack also documents direct harness connection patterns for Codex, Claude Code, Pi and other MCP-compatible hosts. Client support should be separated from plugin support: a client can support the remote server even when Slack’s Skills Plugin does not configure MCP for it automatically.

The canonical hosted endpoint is:

https://mcp.slack.com/mcp

An older tutorial that installs @modelcontextprotocol/server-slack is describing the archived reference implementation, not Slack’s current first-party hosted service.

The current setup path is client → hosted Slack endpoint → OAuth → granted scopes → tools.

1. Use a supported MCP client or harness.
2. Make sure the workspace allows the Slack MCP integration.
3. Add https://mcp.slack.com/mcp using the client’s remote HTTP MCP configuration.
4. Complete Slack OAuth.
5. Grant only the scopes the workflow requires.
6. Verify that the expected Slack tools appear and perform one narrow read test before enabling broader access.

If an administrator must approve the integration, setup becomes an organizational dependency rather than a purely technical one.

Slack recommends its official Slack MCP and Skills Plugin for Claude Code. Install it inside Claude Code with:

/plugin install slack@claude-plugins-official

or from the shell:

claude plugin install slack

The plugin configures the Slack MCP server and prompts for OAuth. Slack also documents direct CLI configuration:

claude mcp add --transport http --scope local slack https://mcp.slack.com/mcp

After configuration, complete authentication and verify that Slack tools remain available beyond the initial login rather than relying only on a “connected” indicator.

Slack supports Cursor through its plugin, an Add to Cursor flow, or manual MCP configuration. The current manual configuration uses Slack’s hosted endpoint and Slack’s registered Cursor client identity:

{
  "mcpServers": {
    "slack": {
      "url": "https://mcp.slack.com/mcp",
      "auth": {
        "CLIENT_ID": "3660753192626.8903469228982"
      }
    }
  }
}

After saving, use Cursor’s connect action and complete Slack OAuth. Workspace app policy can still block the connection even when the JSON itself is correct.

Slack separates sensitive read categories and write actions into different OAuth scopes. This makes a least-privilege rollout practical rather than forcing one all-or-nothing Slack permission.

Slack MCP has a strong first-party authorization model, but the content behind that model can be exceptionally sensitive. The server can inherit Slack’s identity, user permissions, granular OAuth scopes, app approval, IP controls and audit logging.

The meaningful security question is therefore not whether Slack MCP is simply “safe” or “unsafe.” It is which Slack data and actions this AI client actually needs.

Private workspace data is the main exposure

With the relevant scopes, an AI client can receive private-channel messages, DMs, group DMs and files. Those sources can contain management discussions, HR information, customer details, security discussions, financial information, internal URLs, credentials pasted into chat and unreleased projects.

Write access changes the failure mode

A retrieval error produces a bad answer. A write error can send a message, create a conversation, upload a file or change a collaborative artifact under the authenticated user’s identity.

The evidence set shows a strong maintained server with a weaker authentication/interoperability layer. Several failures were reported in Claude Code or Cursor rather than proven defects in Slack’s server; users still experience the full chain, so those failures matter operationally.

Slack MCP has two separate context costs: the fixed MCP tool-schema surface and the variable Slack content returned by searches, threads, channels and files.

1. Tool-schema cost

Slack does not publish a raw tools/list token measurement. For the broad action surface, MCPVerdict estimates an initial schema footprint of roughly 6,000–10,000 tokens. This is an estimate, not a Slack-published measurement.

2. Returned Slack content

The output is usually the larger variable. A narrow search can add hundreds to a few thousand tokens. A long channel, active thread or multiple retrieved files can add tens of thousands.

Targeted search → relevant thread → narrow read is more context-efficient than dumping a whole channel into the model.

Model-window reference set checked Sep 27, 2026: OpenAI model docs, Anthropic model pages, Google Gemini docs, xAI model/pricing docs and Mistral model docs. The 10K value is the upper end of the Slack schema estimate, not an exact token count for every client or tokenizer.

The context window is not the real cost

A 10K fixed load may look small on a 1M-token model, but Slack search results, long conversation history, other connected tools, project context and model output all compete for the same working context. Context efficiency matters more when the agent repeatedly reads large histories.

The verdict’s realistic test budget uses approximately 40K input + 8K output tokens: find historical decisions, locate one person’s messages, retrieve and summarize a thread, retrieve a file, draft/send a test message, create a disposable channel and verify a permission boundary.

Slack does not separately document a per-call MCP server charge. The table below estimates only the model-token cost of that workload using current public model pricing.

Pricing reference checked Sep 27, 2026: OpenAI, Anthropic, Google, xAI and Mistral first-party pricing/model pages. Introductory or long-context pricing can change; the table uses the short/default public rates relevant to this 40K-input example.

Hidden costs

• workspace/app administrator approval;
• AI-provider data handling for Slack content passed into model context;
• review time for sensitive retrieval or write actions;
• large-thread and file token usage;
• permission-design work;
• retries when OAuth expires or a client mishandles refresh;
• organizational consequences of an incorrectly sent message.

Slack MCP inherits underlying Slack Web API rate limits. Slack evaluates Web API limits by method and workspace, with standard tiers plus special limits for some operations.

The hosted implementation is proprietary, so Slack MCP’s complete server-side telemetry behavior cannot be independently inspected from source.

Slack does document associating requests with the client application for logging, rate limiting and access control, and MCP activity can be surfaced through Slack audit tooling.

Dedicated MCP-specific product telemetry: not separately documented. Server-side operational and audit logging: yes.

“No telemetry” would therefore be an overstatement.

Full MCP 2026-07-28 compliance is classified as Unknown. Slack supports Streamable HTTP, JSON-RPC 2.0 and OAuth authorization metadata, but does not support Dynamic Client Registration on the Slack MCP Server and does not currently publish enough protocol-version detail to verify every July 2026 requirement.

Streamable HTTP alone is not evidence of complete protocol-version adoption.

Slack now participates in MCP in both directions. The two products solve opposite problems and should not be merged into one concept.

The Slack MCP and Skills Plugin bundles two different layers: skills that teach coding agents how to work with Slack development tasks and, in supported clients, the Slack MCP Server connection for interacting with an actual workspace.

Several different implementations have been called “Slack MCP,” which is why older setup guides can conflict with the current Slack-hosted server.

Start with public-channel search and read scopes only. Test retrieval accuracy and authentication stability before adding private content or writes.

1. Find one known historical decision.
2. Locate messages from one person about a topic.
3. Retrieve and summarize one thread.
4. Verify the agent cannot access a channel the user is not allowed to read.
5. Leave DMs, private-channel search, files and write scopes disabled during the first pass.

If retrieval is accurate and the connection remains stable, add one new permission category at a time based on a real workflow.

Slack MCP is one of the stronger cases for a first-party MCP because Slack already owns the identity layer, permission system, workspace search, app approval and administrative controls. The official server can enforce access where the data already lives instead of asking users to hand copied credentials to a third-party wrapper.

The granular separation between public channels, private channels, direct messages, files and write actions is particularly valuable. Permission fidelity scores 92 and scope minimization scores 94 because the server can support a narrow public-search assistant without automatically granting private conversations or message sending.

The weak point is practical interoperability. OAuth behavior across fast-changing MCP clients has produced repeated failures in 2026. Some were client-side rather than Slack-server defects, but a perfectly healthy server is not useful if the client loses or mishandles its credentials.

Why it scores well

• first-party Slack identity and permissions;
• granular separation of public, private, DM, file and write scopes;
• strong workspace-search and current-context value;
• admin approval, IP controls and auditability;
• active maintenance and expanding official integrations;
• real read and write workflows rather than a shallow feature demo.

Why it does not score higher

• OAuth/client interoperability has been inconsistent;
• private Slack history can be exceptionally sensitive;
• write actions create real social/organizational consequences;
• long threads and files can consume substantial model context;
• hosted implementation cannot be independently source-audited;
• full MCP 2026-07-28 compliance remains unverified.

Bottom line

Slack MCP’s permission model is a major advantage only when you use it. Start with public search/read access and expand privileges only when a concrete workflow requires them.

The evaluated evidence set includes recent operational reports across Claude Code and Cursor plus Slack’s own tool and plugin releases. Negative reports are separated from Slack-server defects where the evidence points to client OAuth behavior or workspace policy.

Confidence: Moderate. There is strong evidence for permission behavior, active maintenance and integration friction, but no rigorous public benchmark of retrieval accuracy across large real Slack workspaces.