MCP field guide / Slack
// mcp field guide · communication
Reading Slack is harmless. Posting to it isn't — and it's the sneaky-irreversible kind: the instant a message sends, people are notified and integrations ingest it, and deleting it later un-notifies no one. That's why the meaningful control is a gate before the post, not a cleanup after.
GUARD FIT · READ SURFACE
PASS-THROUGHSearch, channel/thread history, user lookups — no state change. Most real Slack-MCP usage is read-heavy retrieval.
GUARD FIT · THE POST PATH
STRONGSending a message is effectively irreversible. A gate before a post to a public channel or customer DM is the whole point.
Overall fit: MODERATE — weak on reads, strong on the one write that matters.
Slack's own official server is now canonical — a hosted remote server at mcp.slack.com/mcp, announced Feb 17, 2026, that lets an approved AI client act in a workspace on behalf of an authenticated user. Access is gated: the client must be a registered Slack app that a workspace admin explicitly approves, and each tool maps to specific OAuth scopes (chat:write, channels:history, search:read.public, users:read…).12 The earlier @modelcontextprotocol/server-slack reference server was archived on 2025-05-29 and is unmaintained ("no security guarantees").4
The archived reference server exposes 8 tools (names verified from source). For the official server, Slack's docs describe tools as capabilities rather than published identifier strings — so exact machine names there are unverified and shown as the documented capability.
| Risk | Reference server (verified names) | Official server (documented capabilities) |
|---|---|---|
| read-only | slack_list_channels, slack_get_channel_history, slack_get_thread_replies, slack_get_users, slack_get_user_profile | Search messages/files, search users/channels, read channels/threads, read a canvas, fetch user info, list channel members |
| mutating | slack_add_reaction | Add reactions, create a conversation/channel, create/update a canvas, draft a message (not sent) |
| post = irreversible | slack_post_message, slack_reply_to_thread | Send messages, reply in threads |
Don't assume a retract exists: the archived server has no delete- or edit-message tool (only the 8 above). For the official server, a delete/update-message tool is unverified — we couldn't confirm one is documented. Either way, treat a post as final: even where a delete exists, it doesn't undo the notification.
Incident summarizer. Search and read #incidents history and threads, then post a synthesized status — read-heavy, but the final post is public and consequential.
Knowledge retrieval. Search past discussions and canvases to answer "how did we solve X before" — pure read, nothing written.
Workflow notifier. On task completion, send a message or thread reply ("deploy done," "PR needs review").
Reads: don't gate them. Search, history, and user lookups change nothing; gating is noise, and retrieval is most of what Slack MCP is used for.
The post is the control point — and it's effectively irreversible. When a send fires, the message is delivered instantly: notifications push to phones and desktops, and outbound webhooks and integrations ingest it. A later delete does not un-notify anyone or recall what integrations already received. So the honest control is a gate before the post commits, not a compensating "delete after." This matters most in public channels and customer-facing DMs, where a wrong or hallucinated message is a visible, sometimes reputational, event.
A natural boundary: the official server's draft capability is exactly the "human reviews before sending" seam. A guard formalizes it — hold the send, show the exact text and destination, let a person approve — and records who approved the post. Creating a channel or canvas in a shared workspace is also worth a gate; reactions are low-stakes. This is compensation-is-not-undo in its most everyday form: you can't un-say it, so decide before you say it.
Let an agent read Slack freely; hold the message send for a human, with the exact text and channel shown before it goes out.
Read the quickstart → More MCP profilesProfiles describe third-party software from its public sources; ChronoMCP is not affiliated with these projects. Official-server tool identifiers are documented as capabilities rather than published names; risk groupings are our classification. Capabilities reflect sources current as of Aug 2026 and can change — check the source links for the latest.