Built-in Slack MCP integration requests full scope superset even when only read tools are exposed

[rradillen]

Describe the bug

When authenticating the built-in Slack MCP server ( mcp.slack.com ) via Copilot CLI, the generated OAuth consent URL requests the full superset of Slack scopes — including write scopes ( chat:write ,  files:write ,  channels:write ,  canvases:write ,  lists:write ,  reactions:write ,  im:write ,  mpim:write ,  groups:write ) — even though the session only exposes a small set of read-only tools:

•  slack_read_channel 
•  slack_read_thread 
•  slack_list_channel_members 
•  slack_search_public 

Example generated authorize URL (redacted):

https://slack.com/oauth/v2_user/authorize?response_type=code&client_id=REDACTED&state=REDACTED&code_challenge=REDACTED&code_challenge_method=S256&redirect_uri=http%3A%2F%2F127.0.0.1%3A58672%2F&scope=canvases%3Aread+canvases%3Awrite+channels%3Ahistory+channels%3Aread+channels%3Awrite+chat%3Awrite+emoji%3Aread+files%3Aread+files%3Awrite+groups%3Ahistory+groups%3Aread+groups%3Awrite+im%3Ahistory+im%3Aread+im%3Awrite+lists%3Aread+lists%3Awrite+mpim%3Ahistory+mpim%3Aread+mpim%3Awrite+reactions%3Aread+reactions%3Awrite+search%3Aread.files+search%3Aread.im+search%3Aread.mpim+search%3Aread.private+search%3Aread.public+search%3Aread.users+users%3Aread+users%3Aread.email&resource=https%3A%2F%2Fmcp.slack.com%2F&prompt=select_account

Expected behavior

Actual behavior
Users are asked to grant far broader permissions (including message sending, file uploads, channel creation, list/canvas writes) than the tool set they can actually use, violating least-privilege expectations.

Suggested fix

• Scope the OAuth request dynamically to the active/allowed tool set, or
• Provide a config option (e.g. in  mcp-config.json ) to restrict which scopes are requested for the built-in Slack MCP connection.

Affected version

1.0.87-0

Steps to reproduce the behavior

1. Ensure the built-in Slack MCP server ( mcp.slack.com ) is available in Copilot CLI (no custom config needed — it's a first-party integration).
2. In an interactive Copilot CLI session, run  /mcp  (or trigger any Slack-related request) so Copilot needs to authenticate with Slack.
3. Confirm only a subset of read tools are currently exposed for the session, e.g.  slack_read_channel ,  slack_read_thread ,  slack_list_channel_members ,  slack_search_public  (visible via the tool list /  <tools_changed_notice>  or  /mcp  output).
4. Trigger the OAuth flow (Copilot opens/prints an authorization URL and starts a local loopback listener, e.g.  http://127.0.0.1:PORT/ ).
5. Inspect the generated  https://slack.com/oauth/v2_user/authorize?...  URL's  scope=  query parameter.
6. Observe: the  scope  parameter includes the full superset of Slack scopes — including write scopes ( chat:write ,  files:write ,  channels:write ,  canvases:write ,  lists:write ,  reactions:write ,  im:write ,  mpim:write ,  groups:write ) and additional read scopes ( users:read ,  users:read.email ,  emoji:read ,  search:read.private/mpim/im/files/users ) — none of which are required by the 4 tools actually exposed.

Expected behavior

The requested  scope  list should match only the tools actually enabled/exposed for the current session (or at minimum, be configurable), rather than always requesting the full write+read superset.