Slack MCP has no dynamic registration: how Sume connects anyway

Slack's MCP server needs a registered Slack app with a client secret and does not support Dynamic Client Registration, so Sume uses its own Slack app.

5 min readSume
All posts

Slack's hosted MCP server cannot be added the way most remote MCP servers are. Slack documents that it does not support Dynamic Client Registration and that clients must be backed by a registered Slack app using a client id and secret. So Sume connects with its own registered Slack app, a confidential OAuth flow on the server, and user tokens. You click Connect; you never paste a secret.

What Slack's page says

Slack's MCP server overview, read 2026-10-05, gives https://mcp.slack.com/mcp as the endpoint, states that Dynamic Client Registration and SSE-based connections are not supported, says MCP clients must be backed by a registered Slack app, and points user-token OAuth at the oauth/v2_user/authorize endpoint. Those are Slack's statements; the rest of this post is about what Sume does with them.

Contrast with Sume's own MCP

Sume's hosted MCP at https://mcp.sume.com/mcp does support dynamic client registration for MCP clients, with public clients and PKCE. That is the opposite shape: your client registers itself with Sume. Here Sume is the client of Slack, so Sume needs an app that Slack already knows. See registration at Sume for the client-side rules.

What Sume configures

Per the integrations catalog doc, the Slack row needs a client id and a client secret in the server environment, and a registered redirect URI that ends in /api/integrations/slack/callback on the matching web host. Sume uses the documented user-token OAuth endpoints. Tokens and pending PKCE material are stored in an AES-256-GCM envelope; if the encryption configuration is missing, a live connect fails closed.

Who registers with whom (Slack: read 2026-10-05; Sume: repo docs)
DirectionRegistrationClient type
Your MCP client to SumeDynamic client registrationPublic client with PKCE
Sume to Slack MCPPre-registered Slack appConfidential, client id and secret

A setup step people miss

Consent can succeed and MCP can still reject the app. In the Slack app, Sume's setup notes say to open Agents, then the Slack Model Context Protocol server section, and enable the Slack MCP server. That step is separate from the Agent experience switch. Without it, initialization fails after a perfectly good OAuth consent.

What this means for you

As a workspace admin you only click Connect on the Slack row and approve scopes in Slack. Because the app is confidential, there is no client to register in Claude, Cursor or any other tool for this connection; the connector lives inside your Sume workspace and the Sume agents use it.

  • No secret to paste into a client
  • Reconnect after about an hour, see the post on the Slack connector expiry
  • Read and search scopes only

If you build your own Slack agent

You face the same constraint Sume does. Create and register a Slack app, keep its client secret on a server, use Slack's user-token authorization endpoint, and do not expect your MCP client to register itself. A client that can only do dynamic registration cannot talk to Slack's server directly.

That is also why a pure client-side setup, such as pasting a URL into a desktop MCP client, is not how the Sume Slack connector works. The OAuth happens on the Sume server for your workspace, and the agents inside Sume call the tools.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume