[FEATURE] Slack MCP: Support file uploads, Block Kit blocks on send_message, and unfurl control
Resolved 💬 2 comments Opened Apr 22, 2026 by DJK101 Closed May 28, 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
The Slack MCP send_message tool can only send plain text. This makes it impossible for Claude to send any visual content via Slack — no images, no GIFs, no file attachments, no rich formatted messages.
Three gaps combine to cause this:
- No file upload tool — There is no tool wrapping Slack's
files.uploadV2API, so Claude cannot upload images, GIFs, or documents to channels or DMs. - No Block Kit support on
send_message— The tool only accepts amessage(text) parameter with noblocksparameter, so Claude cannot send inline images viaimageblocks. - No unfurl control —
unfurl_mediaandunfurl_linksparameters are not exposed. Bot-sent messages default tounfurl_media: false, so even direct image/GIF URLs (Giphy, Tenor, etc.) render as plain text links instead of inline previews.
Proposed Solution
Any combination of the following would resolve this:
- Add a
files_uploadtool — wrapping Slack'sfiles.uploadV2API, accepting a local file path and a channel/DM target. This is the most complete solution as it handles all file types. - Add a
blocksparameter tosend_message— allowing Block Kit JSON, particularlyimageblocks withslack_filereferences (upload first, then embed). - Expose
unfurl_mediaandunfurl_linksonsend_message— even just settingunfurl_media: trueby default would fix the simplest case of sharing image/GIF URLs.
The Slack docs describe the recommended workflow: upload a file via files.uploadV2, get the file ID, then reference it in an image block on chat.postMessage.
Alternative Solutions
- Clipboard workaround: Claude can download a file locally and copy it to the user's system clipboard (e.g. via
osascripton macOS), then the user manually pastes it into Slack. This works but defeats the purpose of an automated Slack integration. - Playwright browser automation: Navigate to Slack's web UI and upload through the browser. This requires the user to be authenticated in the Playwright browser session, which is fragile and complex.
- Various URL formats tested: Giphy page URLs, direct media URLs (
media.giphy.com,i.giphy.com), Tenor page URLs, Tenor direct media URLs, bare URLs, angle-bracket-wrapped URLs, Slack markdown link syntax — none render inline due to theunfurl_media: falsedefault on bot messages.
Priority
High - Significant impact on productivity
Feature Category
MCP server integration
Use Case Example
- A colleague messages me on Slack: "claude told me to tell you to drink some water"
- I ask Claude to reply with a funny cat-drinking-water GIF
- Claude finds a GIF on Giphy/Tenor, but cannot send it — every URL format renders as plain text
- Claude downloads the GIF locally and tries to upload it, but there's no file upload tool
- The only option is Claude copying the GIF to my clipboard so I can manually paste it
- With
files.uploadV2support (or even justunfurl_media: true), Claude could have sent the GIF directly in one step
Additional Context
- Related bug: #51720 — the reading-side equivalent of this gap.
slack_read_channel/slack_read_threaddrop Block Kit blocks and attachments from incoming messages. Together, these two issues mean the Slack MCP cannot read or write any rich content. - This also affects practical workflows like sharing screenshots, diagrams, build logs, CSV exports, or CI artifacts via Slack.
- Slack's built-in GIF picker (powered by Tenor) sends GIFs as Block Kit image blocks — so even "native" Slack GIF behavior cannot be replicated through the MCP.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗