[FEATURE] Slack MCP: implement the claude/channel capability so Slack activity can drive turns

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Watching Slack is pull-only today. The Slack MCP is a tools-only server (read channel, read thread, search, send, drafts), so Claude only learns about a new Slack message if something asks it to go look.

To actually watch a channel, DM, or thread, I have to build it in user-land: a poll loop that re-queries Slack on an interval, wrapped in a background watcher that turns each qualifying result into a notification. That works, but it is a custom path every user has to reinvent, it spends tokens on empty polls, and its latency is the poll interval rather than the event.

This is a follow-up to #60364 (closed), which asked for a first-class OAuth-based Slack MCP. That half exists now. The missing half is push.

Proposed Solution

Have the Slack MCP implement the claude/channel experimental capability alongside its existing tools, so a session can subscribe to Slack activity and each qualifying event arrives as a notifications/claude/channel notification that starts a turn.

Subscription shapes that would cover most real use:

• a public channel, a DM, a group DM, or a single thread
• filters so the agent is not woken for everything: only messages from a given user, only messages matching a keyword, mentions only, or thread replies only
• the event types a polling implementation already has to reconstruct by diffing: new message, edit, thread reply, deletion

Channels looks like the right primitive for this. A Slack conversation is a low-latency conversational surface where every inbound message should start a fresh turn, which is the contract Channels already defines.

Alternative Solutions

Polling from user-land, which is what I do now: an interval poll wrapped in a background watcher that emits one notification per qualifying event. It works and I would keep it as a fallback, but it is per-user glue for something the platform already specifies, and the empty polls are pure overhead.

Using the existing tools reactively, so asking Claude to go read a channel when I think something happened. That defeats the point of an unattended agent.

Writing a custom MCP server that implements claude/channel and proxies Slack. Viable, but it duplicates the official Slack MCP auth and surface, and after #60364 the auth is the part I least want to re-own.

Priority

Critical - Blocking my work

Feature Category

MCP server integration

Use Case Example

1. I am waiting on a reply in a Slack thread before I can continue a piece of work.
2. Today I start an interval poller that re-reads that thread and wakes me when the reply lands.
3. With a Slack channel, I subscribe to that thread and go do something else. When the reply arrives the notification starts a turn, Claude reads it, and the work continues.
4. Same shape for an on-call channel: subscribe with a filter so a matching alert starts a turn, instead of being discovered on the next poll.

Additional Context

Related: #61010 reports that a notifications/claude/channel delivered after a tool-only turn lands in the TUI prompt buffer instead of starting a new turn. Worth fixing alongside this one, because a Slack channel would hit that path constantly: reply-only turns (read the message, answer via the channel send tool, stop) are the normal shape for a chat-driven agent, which is exactly the case that issue describes.