Add safe search

[kinoh]

Fix #119

Changes

• When SLACK_MCP_SAFE_SEARCH is set, exclude DMs from Slack API search results.
• Treat conflicting filter_in_im_or_mpim as an error in safe search mode.
• Return a cursor even when filtering results in an empty response.

Considerations

• Fewer results returned
  • Multiple Slack API calls: rate limit (Tier 2, 20 requests/min) becomes effectively tighter.
  • Server-side custom pagination: adds excessive state-management complexity.
  • It seems reasonable to accept DM count leakage or dummy responses.

Tests

• Unit tests
• Verified with @modelcontextprotocol/inspector that DMs are filtered for both Slack browser tokens and User OAuth tokens
  • Bot tokens cannot use search, so no bot-token test is required.

[korotovsky]

Hi @kinoh, may I ask you to elaborate a bit more on the root cause of the issue? From what I can see at a high level, MCP has been granted a token that provides permissions to fetch DMs and group DMs. With this PR, however, it looks like you are trying to strip out those capabilities. This doesn’t seem to align with the permissions granted by the connected token.

Additionally, I feel the issue may only arise because search is being attempted in a multi-user context. If that’s the case, then in my opinion the problem should be addressed in a fundamentally different way.

[kinoh]

@korotovsky

Thanks for the comment!

Root Cause

The issue is not a mismatch of Slack permissions but a visibility leakage problem. When the server runs as the token owner, search results seems to reflect user's visibility.

Notably, in our testing, DM results appear in search even when the user token doesn't include im:* scope. This suggests Slack's search API doesn't fully respect token scopes, making it impossible to restrict search results through permission configuration alone.

Why Server-Side Filtering

Slack's search.messages API requires a user token; bot tokens cannot use it. This means enabling search in a multi-user MCP setup requires sharing a personal token, which directly leads to the visibility leakage described above.

Since we cannot avoid using a personal token for search, and token scopes don't reliably limit search visibility, server-side filtering is the only way to address this issue, I think.