Slack Workspace

Lets an agent read a channel and answer in it, over the Slack Web API, with the bot token held in the gateway rather than in the conversation.

What you get

• slack.conversations.list — channels the bot can see, so a caller can turn a name into an id.
• slack.conversations.history — recent messages in one channel.
• slack.chat.post — send a message, optionally threaded.

What you need

• Slack bot user token — the xoxb- token from your app's OAuth & Permissions page. Its scopes are the boundary: chat:write, channels:read and channels:history cover these three tools, and anything broader is reach an agent did not need.
• JWKS endpoint — the host where your identity provider publishes its signing keys, without a scheme.
• Token audience — the aud claim your callers' tokens carry.

How it works

Slack scopes a bot token to the channels the bot has been invited to, which makes "which channels can this agent read" a Slack decision rather than a config one. Invite the bot to the channels you want reachable; the rest are invisible even though the tool would happily be asked about them.

The token is set as an Authorization header on every binding, so it is never an argument and never something a caller can name, read or replace.

Posting is one tool and it only posts. There is no delete and no edit, so the recoverable failure mode — a message you did not want — stays recoverable.

Notes

Slack answers HTTP 200 with {"ok": false, "error": "..."} for most failures, so a successful status code is not a successful call. Check ok in the pipeline or the agent layer; expected_status_codes: [200] here is about the transport, not the outcome.

slack.conversations.history needs the bot to be a member of the channel. A channel it can list is not necessarily a channel it can read.