[FEATURE] Slack connector: add mark-as-read (`conversations.mark`) — re-filing #59710 / #73792

Status Open
Maintainer reply None cached
Activity 0 comments · opened Oct 7, 2026

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

I run a cross-channel triage workflow through the Slack connector. It reads my unread mentions, DMs, and channel activity, classifies each item (needs action, FYI, noise), and surfaces only what actually needs me, with drafts for the simple replies.

The connector lets the agent read, search, and summarize. It cannot change my read state. Once triage is done, every channel and DM it processed still shows as unread in Slack, so I click back through them by hand to clear the badges. That's the context-switching the triage was meant to remove.

The workflow ends up informational instead of complete. The agent tells me what I can ignore, but Slack keeps asking for my attention on exactly those items.

Proposed Solution

Add a tool to the Slack connector that moves the authenticated user's read cursor, wrapping Slack's conversations.mark Web API method:

slack_mark_read
  channel_id: string (required) — channel, private channel, DM, or group DM
  ts:         string (required) — timestamp of the message to mark as most recently read

Ideal experience:

At the end of a triage run, the agent lists what it plans to mark as read (for example, "12 FYI and noise items across 7 channels").
I confirm, or exclude specific channels.
The agent marks them, and my Slack sidebar reflects that straight away.

It should affect only my own read state, the same as conversations.mark called with my user token.

Nice to have: a batch variant (slack_mark_read_batch, taking a list of {channel_id, ts}) so a run can mark everything in one call. Slack's docs ask clients not to call this method frequently and to coalesce updates, so batching fits that guidance.

Alternative Solutions

Mark as read manually in Slack. This is my current workaround, and it's the step I'm trying to eliminate.
Run a separate script or self-hosted MCP with its own Slack user token. This works technically, but it needs a second Slack app, separate admin approval, and a split audit trail alongside the official connector.
Use community Slack MCP servers that support mark-as-read. Several exist, but most rely on browser session tokens (xoxc/xoxd), which many orgs can't approve.

Priority

Medium - Would be very helpful

Feature Category

MCP server integration

Use Case Example

  1. Monday morning: I have 60+ unread items across DMs, mentions, and about 20 channels.
  2. I ask Claude to run my Slack triage.
  3. Claude reads the unreads and returns 5 items that need my reply, 8 FYIs worth a skim, and the rest as noise (bot alerts, resolved threads, channels where I'm only cc'd).
  4. I handle the 5 action items and skim the FYIs in the summary.
  5. Today: I open each remaining channel in Slack to clear it. That's around 20 clicks, and I end up re-reading things I've already decided to ignore.
  6. With this feature: I say "mark the rest as read." Claude calls slack_mark_read for each FYI and noise conversation at its latest triaged ts, and my sidebar is clean.

Additional Context

Prior requests: #59710 (May 2026) and #73792 (July 2026) asked for the same tool. Both were closed by the inactivity bot, not declined, and the closure note invited a new issue if the request is still relevant. This is the third independent request.

Technical considerations:

  • conversations.mark needs channels:write, groups:write, im:write, and mpim:write on the user token. The connector already requests these scopes for its create-conversation tool, so this shouldn't expand the permission surface users have approved.
  • Slack recommends coalescing calls to this method, which supports a batch variant or marking at the end of a run.
  • Rate limit is Tier 3 (50+ per minute).

Ownership question: The connector is Slack's hosted MCP server (mcp.slack.com). If adding tools is Slack's decision rather than Anthropic's, could a maintainer confirm that and say where to raise it? That would stop this being re-filed here a fourth time.

Similar features elsewhere: A related request exists for Gmail (#53534, mark_as_read for the Gmail connector). Community Slack MCP servers such as korotovsky/slack-mcp-server and aaronsb/slack-mcp already expose mark-as-read.

View original on GitHub ↗