feat: add --enabled-tools flag to filter available MCP tools

[RedSlowpoke]

Summary

• Add a new CLI flag --enabled-tools (alias -e) to specify which MCP tools to load
• Add SLACK_MCP_ENABLED_TOOLS environment variable as fallback
• If not set, all tools are enabled (backward compatible)
• Provides flexibility to limit tool exposure based on security requirements or use case

Changes

• cmd/slack-mcp-server/main.go: Add flag parsing and env var support
• pkg/server/server.go: Add shouldAddTool() helper and conditional tool registration
• README.md and docs/03-configuration-and-usage.md: Document the new feature

Example Usage

# Enable only read-only tools
slack-mcp-server --enabled-tools=conversations_history,conversations_replies,channels_list

# Via environment variable
SLACK_MCP_ENABLED_TOOLS=conversations_history,channels_list slack-mcp-server

Available Tools

conversations_history, conversations_replies, conversations_add_message, reactions_add, reactions_remove, attachment_get_data, conversations_search_messages, channels_list

Test plan

• Build passes: go build ./cmd/slack-mcp-server
• Existing tests pass: go test ./...
• Verify --help shows new flags

[korotovsky]

Somehow closes #167

[korotovsky]

How does this work when for example you need explicitly enable SLACK_MCP_ADD_MESSAGE_TOOL since default value is all tools?

[RedSlowpoke]

How does this work when for example you need explicitly enable SLACK_MCP_ADD_MESSAGE_TOOL since default value is all tools?

These are separate concerns:

• SLACK_MCP_ENABLED_TOOLS controls which tools are exposed via MCP.
• SLACK_MCP_ADD_MESSAGE_TOOL controls whether conversations_add_message and reactions_add are allowed (checked by the handler).

If ENABLED_TOOLS is empty, all tools are exposed. But even then, ADD_MESSAGE_TOOL must be set for the handler to accept message actions.

When both are used, they act together restrictively:
To use conversations_add_message, the tool must be both exposed and explicitly enabled.

My vision is that it's enough to rely on ENABLED_TOOLS going forward — it’s more generic and precise. The per-tool flags still work but are optional if exposure is already controlled.

[korotovsky]

The problem with "If ENABLED_TOOLS is empty, all tools are exposed" is everyone who is running MCP on @latest and eventually with your new default empty string, then once we will add new tools, then their deployments will get new tools out of blue (tools injection)

[RedSlowpoke]

@korotovsky I've added tests and some more changes. But my understanding that those 2 flags work in a different "layers". The current one in runtime, and the one that I've proposed should work on registration.

Let me know what should i add or change further, to achive the goal. Thanks.

[korotovsky]

It is a secondary layer, right, but then it somehow becomes confusing when we set empty value for "all tools", but then later on somehow the tool would be disfunctional (but enabled) so +1 extra env is needed.

What is the goal of the PR? Do you want to automatically get all new tools once MCP gets updated, or you just one to get control over selectivity what is enabled in the MCP server when it's running?

[RedSlowpoke]

My goals

1. Granular, transparent control
   I want to control which tools are registered, not just checked at runtime. This is useful for our internal plugin, where allowed tools are defined in .mcp.json.
2. Save context
   Don’t register tools that won’t be used. This slightly reduces context and keeps things cleaner.

⸻

Behavior
• No changes for existing users — changing how current flags affect registration would be breaking, so this PR keeps today’s behavior.
• An empty SLACK_MCP_ENABLED_TOOLS works exactly as it does now (all tools exposed by default).
• I can add a concrete usage example showing how to enable conversations_add_message correctly.

[RedSlowpoke]

@korotovsky could you kindly tell me what should I do to progress with MR or could you close it as not desired change?

[korotovsky]

Hi @RedSlowpoke, I see main issue with existing SLACK_MCP_ADD_MESSAGE_TOOL, if it's not defined and you also not set any configuration for this new PR == default value equals all tools, which results in a very contradictory config in my opinion - your "feature" dictate all tools are enabled (incl. message tool? That would have been logical), but fact that SLACK_MCP_ADD_MESSAGE_TOOL is not set would take priority over and user will get an error and it will be very awkward behavior.

[RedSlowpoke]

I may propose the following strategy:

Slack message sending behavior

ENABLED_TOOLS ↓ \ SLACK_MCP_ADD_MESSAGE_TOOL →	absent / empty	true	list (channels/users)
absent / empty	- (currently denied in runtime, will be not registered)	YES (current behaviour)	YES (scoped, current behaviour)
NOT absent and does NOT include slack.add_message	-	-	-
includes slack.add_message	YES	YES	YES (scoped)

Legend:
- = send tool is NOT registered
YES = user can send messages
YES (scoped) = user can send messages only to specified channels/users

Do you think it's transparent and awkward, or how can I do this better?

[korotovsky]

From what I could see here 2ef39fe#diff-fe7a244e18e92d8f347af17363209172e1d79224f086b0585a1bbeef3b626c4eR268-R275 did I understand correctly, that SLACK_MCP_ENABLED_TOOLS has now higher priority over old SLACK_MCP_ADD_MESSAGE_TOOL but there is a special logic if they both NOT set (disarm tool) because default value for SLACK_MCP_ENABLED_TOOLS for SLACK_MCP_ENABLED_TOOLS is actually enable tools?

[RedSlowpoke]

did I understand correctly, that SLACK_MCP_ENABLED_TOOLS has now higher priority

yes, if set

there is a special logic if they both NOT set (disarm tool)

Yes

Basically the idea, that if you use the latest introduced flag - you understand how it works, and if you don't use it. It works (almost) as it was when the oldest flags were introduced.

[korotovsky]

Let's the docs also cover SLACK_MCP_ADD_MESSAGE_MARK.

[korotovsky]

OK I think we are quite close to get that merged, could you improve a general docs about how new functionality works with a couple of examples (not tool prompts), (I will also use it in the release notes later) and then we will merge it.

[korotovsky]

As I understand this is a breaking change for people for a) updates on @latest and b) had some write tools, right? (just wanted to double check for release notes)

[RedSlowpoke]

Write tools are no longer registered by default

Write tools (conversations_add_message, reactions_add, reactions_remove, attachment_get_data)
are no longer registered by default. Previously they appeared in the tool list but failed at
runtime without their respective permission env vars.

If you had these env vars configured:

• SLACK_MCP_ADD_MESSAGE_TOOL for conversations_add_message
• SLACK_MCP_REACTION_TOOL for reactions_add/remove
• SLACK_MCP_ATTACHMENT_TOOL for attachment_get_data

No action needed - tools will be registered and work as before.

If you didn't: You'll see fewer tools in the list. This is intentional - they weren't
functional anyway.

Alternative: Use SLACK_MCP_ENABLED_TOOLS to explicitly list tools without permission restrictions.