claude-code - 💡(How to fix) Fix [FEATURE] Slack MCP: Support file uploads, Block Kit blocks on send_message, and unfurl control [1 participants]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• 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:

1. No file upload tool — There is no tool wrapping Slack's files.uploadV2 API, so Claude cannot upload images, GIFs, or documents to channels or DMs.
2. No Block Kit support on send_message — The tool only accepts a message (text) parameter with no blocks parameter, so Claude cannot send inline images via image blocks.
3. No unfurl control — unfurl_media and unfurl_links parameters are not exposed. Bot-sent messages default to unfurl_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:

1. Add a files_upload tool — wrapping Slack's files.uploadV2 API, accepting a local file path and a channel/DM target. This is the most complete solution as it handles all file types.
2. Add a blocks parameter to send_message — allowing Block Kit JSON, particularly image blocks with slack_file references (upload first, then embed).
3. Expose unfurl_media and unfurl_links on send_message — even just setting unfurl_media: true by 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 osascript on 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 the unfurl_media: false default on bot messages.

Priority

High - Significant impact on productivity

Feature Category

MCP server integration

Use Case Example

1. A colleague messages me on Slack: "claude told me to tell you to drink some water"
2. I ask Claude to reply with a funny cat-drinking-water GIF
3. Claude finds a GIF on Giphy/Tenor, but cannot send it — every URL format renders as plain text
4. Claude downloads the GIF locally and tries to upload it, but there's no file upload tool
5. The only option is Claude copying the GIF to my clipboard so I can manually paste it
6. With files.uploadV2 support (or even just unfurl_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_thread drop 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.