Skip to main content
Two tools: query_slack for searching and reading, update_slack for posting messages.
The agent calls query_slack("auth migration"). Behind the scenes, a sub-agent searches messages, fetches relevant threads, and returns a synthesized answer.

When to use this vs SlackTools

Setup

Or pass directly: SlackContextProvider(token="xoxb-..."). See SlackTools for OAuth scope requirements.

Example queries

Queries that work well give the provider a topic to search and context to narrow results: Queries that are too vague:

Configuration

Read/write modes

Control what the agent can do:
Use write=False for research, triage, audit, and eval agents. The read sub-agent physically cannot post because send_message isn’t in its toolkit.

Multi-provider example

The main value of context providers is reducing tool surface when an agent has multiple sources:
The agent sees 2 tools (query_slack, query_gdrive) instead of 20+.

Tips

  • Token naming: SLACK_BOT_TOKEN is preferred; SLACK_TOKEN is a fallback.
  • Search: search_messages needs a user token. Set SLACK_USER_TOKEN or pass user_token=. With only a bot token, the read sub-agent uses channel history and threads.
  • Private channels: The bot must be invited to access private channel history.
  • Thread context: Ask for “the thread” or “the decision” to pull the full thread instead of just the parent message.
  • Channel names: Natural names like #general work. The sub-agent resolves them to IDs.
  • Write clarity: “Post this to #team” is safer than vague “send it.”

Resources

SlackTools Reference

All 12 methods and OAuth scope requirements

Cookbook Example

Working example with search and posting