Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/slack-aaronsb/issues.md or /mcp/slack-aaronsb/issues.json, or Pod over MCP.

Reported issues for Slack

Pod holds 16 of 23 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to Slack.

Most discussed

Design: consolidate 16 tools into ~8 self-evident ones — reads never mutate, one interaction grammar

Problem

The server exposes 16 tools, several of which overlap (catch-up / check-unreads / check-mentions; read / get-context / download-file; list-users / list-channels), and the split forces an agent to re-reason about which tool is right — and which ones mutate state — on every call. The design target for agent-facing tools: a tool you never have to figure out how to use — the correct call is obvious from the name plus one glance at the schema, the naive zero-argument c

Read the thread · 2026-08-18 · closed · 2 comments

catch-up auto-marks channels read — the naturally-named tool must be the safe one

Problem

catch-up marks channels as read as a side effect, and announces it after the fact:

💬 Full content displayed - marking as read
🔍 Thorough review complete - marking as read

The trap is in the naming: when a user says "catch me up on today," an agent pattern-matches to the tool literally named catch-up — and silently clears the user's unread badges across every channel it summarizes. In one briefing session it marked five channels read before the behavior was noticed. The

Read the thread · 2026-08-18 · closed · 2 comments

list-users omits IDs, mentions never resolve, and there's no 'whoami' — agents can't answer 'is this me?'

Problem

Three related identity gaps forced an agent to give up on the one question that mattered in a daily catch-up: "is <@U0AAAAAAAAA> — the person being asked to take over a workstream, and named on an urgent deal team — the user I'm working for?" (IDs anonymized throughout.)

1. list-users returns no user IDs

The tool description promises "matching display names, usernames, and IDs", but the result contains only the display name:

## Users (1)

**Aaron Bockelie** (@bockeli

[Read the thread](https://github.com/aaronsb/slack-mcp/issues/44) · 2026-08-18 · closed · 2 comments

### Implement ADR-004's renderMessage seam (single normalizer, unresolved field)

The mention-resolution branch (#59) ships tag resolution as a render function threaded through the existing formatters. The review correctly notes ADR-004 decided a stronger shape: a single `renderMessage` normalizing every Slack message into `{author, body, tags, unresolved}`, with formatters doing no message assembly of their own, and misses carried in an `unresolved` field (which doubles as ADR-005's repair queue) rather than only left raw in the body.

#59's function-threading is the right f

[Read the thread](https://github.com/aaronsb/slack-mcp/issues/63) · 2026-08-20 · closed · 1 comment

### Retire the five tools ADR-003 replaced — cut the surface to 11 at v2.0.0

ADR-003 is Accepted. Its additive half shipped; its subtractive half never did.

`poll`, `read`, and `ack` are registered and working. The five tools ADR-003 retired into them are also still registered, undeprecated, and — in `catch-up`'s case — still the most naturally-named entry point in the server. Sixteen tools where the architecture decided eleven.

This issue tracks the deletion, plus three decisions ADR-003 left to implementation.

## Decisions

**Hard cut at v2.0.0, no deprecation windo

[Read the thread](https://github.com/aaronsb/slack-mcp/issues/49) · 2026-08-19 · closed · 1 comment

### Blocks-only messages render as empty bodies — the highest-signal posts disappear from briefings

## Problem

Messages whose content lives in Block Kit blocks (or attachments) with no top-level `text` fallback render as **empty bodies**. Two company-announcement posts in `#all-hands` — 51 and 33 reactions, clearly the most important messages of the day — came back like this from `catch-up`:

unknown (1787001371.622709) [popular] [33 reactions]

unknown (1786995972.214599) [popular] [51 reactions]


`get-context` on the same messages showed the thread replies but the root mess

[Read the thread](https://github.com/aaronsb/slack-mcp/issues/45) · 2026-08-18 · closed · 1 comment

### Publish to npm by trusted publishing (OIDC) instead of a long-lived NPM_TOKEN

slack-mcp publishes from a long-lived `NPM_TOKEN`. google-workspace-mcp used to as well, and that token expired silently. This describes the OIDC path that replaced it, so this repo can follow the same convention.

**This repo's current state:** `ci.yml`, `npm-publish.yml`, `release.yml`, with two `NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}` steps — one for the platform packages, one for the wrapper. `id-token: write` is already set.

**Two differences from the other repos, both real work:**

1. 

[Read the thread](https://github.com/aaronsb/slack-mcp/issues/25) · 2026-08-17 · closed · 1 comment

### check-mentions silently scans only 15 of 177 channels — unreliable for completeness

## Problem

`check-mentions` silently scans only a small subset of channels. Across two runs this session it reported:

> Note: Scanned 15 of 177 channels. Some mentions might be in unscanned channels.

and returned **0 mentions** — despite the user being @-mentioned repeatedly in an active channel (`#jira-hybrid-plugin-build-team`) within the window. Mentions in the other ~162 channels are missed entirely.

## Impact

`check-mentions` can't be trusted for completeness. An end-of-week / at-menti

[Read the thread](https://github.com/aaronsb/slack-mcp/issues/24) · 2026-06-02 · closed · 1 comment

## Most recent

### Idle-exit: server should terminate itself when its client disappears

## The finding (2026-08-20, live)

A remote Claude Code workspace (`ssh://user@host/...`) spawns its MCP servers on the remote host over SSH channels. When the session dies or the connection wedges, the spawned servers are never reaped: the host accumulated two full generations of slack-mcp (21h and 2h old) plus sibling MCP servers, each orphan pinning an SSH channel. sshd's default `MaxSessions 10` per connection then made every new channel open — including reconnect attempts — hang at "connect

[Read the thread](https://github.com/aaronsb/slack-mcp/issues/82) · 2026-08-20 · open · 0 comments

### Localhost graph reports: reuse the setup launcher to render relationship views

Once ADR-008's views prove they query useful things, reuse the embedded-web-launcher pattern from `pkg/setup` (go:embed UI, localhost-only serving, cross-platform browser launch — the same posture that keeps tokens on the machine) to serve dynamic reports: a view executed on request, rendered as an interactive graph page (embedded vis bundle, no CDN, no data leaves localhost).

Why it's nearly free: views are deterministic functions of the folds (ADR-008's read models), so a report page is a ren

[Read the thread](https://github.com/aaronsb/slack-mcp/issues/61) · 2026-08-20 · open · 0 comments

### Probe Slack's composer user-autocomplete endpoint before building ring-3 matching

ADR-005 records this as an open probe. Filing it so it runs rather than sits in the ADR.

## Why

Slack's own composer does live partial matching on `@` input, which implies a server-side autocomplete endpoint with Slack's own ranking. If it answers, ring-3 directory matching stops being ours to build and the local cache becomes a fast path rather than the whole answer.

ADR-003's endpoint-findings table was that ADR's highest-value section, and it changed conclusions rather than confirming them

[Read the thread](https://github.com/aaronsb/slack-mcp/issues/50) · 2026-08-19 · open · 0 comments

### Live-message cursor unreliable: get-context capped to ~10 recent, can't page earlier, and read-state fights the official client

## Problem

Two related problems make reading channel/DM history unreliable, especially for live conversations.

### 1. `get-context` is capped to the ~10 most-recent messages, with no working way to page earlier

`get-context` (without `messageTs`) returns only the last ~10 messages, and there is no reliable way to retrieve earlier history. The trailing hint suggests `catch-up ... cursor=<...>` for pagination, but the cursor doesn't walk backward through history — repeated calls return the same

[Read the thread](https://github.com/aaronsb/slack-mcp/issues/23) · 2026-06-02 · closed · 1 comment

### Feature: download file attachments from messages/threads

## Problem

When reading a Slack thread via `get-context` / `search`, messages that include file attachments (PDFs, images, etc.) surface the accompanying text but there's no way to retrieve the actual file. Users end up having to leave the MCP workflow, open Slack in a browser, and download the file manually before they can act on it.

## Example

A thread in a customer channel contained a message "Here is the PDF version." with an attached PDF. `get-context` returned the message text but not a

[Read the thread](https://github.com/aaronsb/slack-mcp/issues/21) · 2026-04-14 · closed · 0 comments

### Align CI/release process with groupware MCP server standards

## Context

All four groupware MCP servers (slack-mcp, jira-cloud, confluence-cloud, google-workspace-mcp) reached consensus on a common CI/release pattern to ensure consistency across projects and establish a reusable template for future MCP servers.

## Agreed Standard

1. **ci.yml** — lint + test + build on PRs and feature branches, Node 22
2. **release.yml** — `v*` tag triggers GitHub Release creation + .mcpb bundle upload
3. **npm-publish.yml** — `v*` tag triggers npm publish with provenanc

[Read the thread](https://github.com/aaronsb/slack-mcp/issues/20) · 2026-04-11 · closed · 1 comment

### search and get-context truncate/miss standalone message bodies

## Problem

When a long standalone message (not a threaded conversation) is posted to a channel, there's no reliable way to retrieve its full text content.

### Observed behavior

**search**: Returns results but truncates the message body. For example, a message with 30 numbered items gets cut off after the title line:

#lazos | Aaron Bockelie | 1775656975.382349 PIG Health Scan ToS (v20260406) — Review Findings Here are 30 specific improvements for the legal team to address: *...


[Read the thread](https://github.com/aaronsb/slack-mcp/issues/18) · 2026-04-08 · closed · 0 comments

### Feature request: Support file attachment listing and download

## Summary

The MCP tools (`search`, `get-context`, `catch-up`) don't surface file attachment metadata from Slack messages. There's currently no way to discover or download files attached to messages through the MCP interface.

## Current behavior

When a message has a file attachment (e.g., a zip file), the tool output only shows the message text — the file name, type, size, and download URL are not included.

## Expected behavior

- File attachment metadata (name, type, size, permalink) should

[Read the thread](https://github.com/aaronsb/slack-mcp/issues/17) · 2026-04-07 · closed · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/aaronsb/slack-mcp/issues).