Feature request: Add conversations.mark (mark channel as read) tool

[nveer]

Problem
The Slack MCP server supports reading channels, searching messages, sending messages, and creating drafts — but has no way to mark a channel or DM as read. This makes it impossible to build complete inbox triage workflows where an AI agent processes messages and updates the user's Slack UI to reflect what's been handled.
Without conversations.mark, any automated triage workflow leaves every processed channel still showing as unread, forcing the user to manually clear each one. For teams deploying AI-assisted Slack workflows at scale, this is the single biggest gap in the current tool set.

Proposed Solution
Add a tool wrapping Slack's conversations.mark API:
slack_mark_as_read — Mark a single channel or DM as read up to a specific message timestamp.

Parameters:

• channel_id (string, required): The channel, group, or DM to mark
• ts (string, required): Timestamp of the most recent message to mark as read

A batch variant (slack_mark_channels_read) that accepts an array of {channel_id, ts} pairs would also be valuable for triage workflows that process multiple channels per run.

Required Slack Scopes

• channels:write
• groups:write
• im:write
• mpim:write

Use Case
We're building an AI-powered Slack triage system for a 50+ person sales organization. The workflow:

1. Scans DMs, @mentions, and customer channels for unread messages
2. Classifies by urgency and category (customer-facing, internal, escalation)
3. Drafts responses for human review
4. Marks triaged channels as read ← currently impossible via MCP

We've built a standalone MCP server as a temporary workaround, but this capability belongs in the official server since it completes the natural read → process → clear lifecycle that every inbox workflow needs.

Additional Context

• conversations.mark is a lightweight API call (POST with channel + ts)
• It modifies the calling user's read cursor and syncs across all their Slack clients
• Rate limit is ~1 request per second — the batch variant should include delays
• The third-party korotovsky/slack-mcp-server already supports this, which suggests community demand

[cchensh]

@stevengill , @manucaicedo would you mind taking a look at this request?

[stevengill]

Appreciate the feature request! I've shared it with the product team. No timeline yet but they are aware of this usecase :)