Headless CLI agent has no access to Slack MCP Tools

Support Help
, ,
1

I’m trying to run a scheduled Slack check using the Cursor Agent CLI (headless) so that when I’m away, the agent periodically reads my Slack DMs and runs any task requests in my project.

Setup

  • I have the Slack MCP configured and working in Cursor (Settings → MCP). In the IDE, the agent can use slack_read_channel, slack_send_message, etc.

  • I run the standalone Cursor Agent CLI (Windows: agent.cmd from %LOCALAPPDATA%\cursor-agent) in a loop script every 15 minutes with:

  • agent -p --trust --model “Composer 1.5” --workspace “”

  • The prompt tells the agent to read my Slack task inbox (channel ID), run any tasks, and post status back to Slack, following a project rule in .cursor/rules/.

What happens

When the CLI runs, the agent replies that it does not have access to the Slack MCP tools (slack_read_channel, slack_send_message). It says they’re not in its available tools and that list_mcp_resources shows no MCP resources. The same workflow works when I run it inside the IDE (e.g. “Check my Slack” in Composer).

What I’d like clarity on

  1. Is the headless CLI supposed to use the same MCP servers as the IDE?

If yes: is there a specific way to run the CLI (e.g. from the project directory, or with a flag like --approve-mcps) so it picks up the Slack MCP (and other MCPs) I’ve configured in Cursor?

  1. If the CLI uses a separate MCP config:

Where is that config (e.g. user-level vs workspace) and how do I add/authenticate the Slack MCP for the CLI so that agent -p … can call Slack tools?

  1. If MCP is IDE-only for now:

Is headless + MCP (e.g. Slack) on the roadmap, and is there a recommended workaround for “run agent on a schedule with Slack access” (e.g. only via the IDE, or another approach)?

The headless CLI docs don’t mention MCP or loading IDE/workspace config, so I’m not sure what the intended behavior is for CLI + MCP.

Environment

  • Windows, Cursor Agent CLI (installed via irm ’ Cursor · CLI ’ | iex)

  • Slack MCP working in Cursor IDE; same project/workspace used for the CLI with --workspace

Thanks for any guidance. (Mostly written by Cursor :slight_smile: )

3

Hey, good question. The CLI does support MCP servers and it should use the same config as the IDE.

A few things to check:

  1. Add --approve-mcps to the command. Without this flag, the CLI might not load MCP servers. Try:

    agent -p --trust --approve-mcps --model "Composer 1.5" --workspace <project> "<prompt>"

  2. Check whether the CLI can see your MCP servers at all. Run this from your project directory:

    agent mcp list

    If the Slack MCP doesn’t show up, the issue is that the CLI can’t find the config.

  3. Env variables: the CLI doesn’t automatically inherit your shell environment. It only uses what you put in the env block in mcp.json. If the Slack MCP uses tokens via env vars (like SLACK_BOT_TOKEN, etc.), make sure they’re set explicitly in the config:

    {
  "mcpServers": {
    "slack": {
      "command": "...",
      "args": ["..."],
      "env": {
        "SLACK_BOT_TOKEN": "xoxb-your-token"
      }
    }
  }
}

Can you share the output of agent mcp list and the structure of your mcp.json (without tokens)? That’ll make it easier to see where it’s breaking.

4

Thanks for the follow up, @deanrie,

Here’s what I see:

1. agent mcp list (from project dir, same agent binary as my loop):

  • slack: Error: Connection failed

So the CLI does see the Slack MCP in config, but the connection to Slack fails.

2. Assertion on Windows

When running the agent I also get:

Assertion failed: !(handle->flags & UV_HANDLE_CLOSING), file src\win\async.c, line 76

3. My mcp.json (structure only, no tokens):

{

  "mcpServers": {

    "slack": {

      "url": "https://mcp.slack.com/mcp",

      "auth": {

        "CLIENT_ID": "3660753192626.8903469228982"

      }

    }

  }

}

So I’m on Slack’s hosted MCP (https://mcp.slack.com/mcp) with only CLIENT_ID in auth — no env block or SLACK_BOT_TOKEN. My guess is the IDE has OAuth tokens stored elsewhere and the CLI doesn’t, so the CLI can’t connect. Can you confirm whether the CLI is supposed to use the same stored Slack tokens as the IDE, and if so, what I need to do so the CLI can connect (or if there’s a different supported way to run the agent headless with Slack MCP)?

Thanks for your help with this!

5

Hey, the fact that agent mcp list shows the server but with a connection error is the key point. It’s almost certainly an OAuth issue. When the IDE connects, it opens a browser for auth and saves tokens, but the CLI doesn’t automatically complete that flow.

Try logging in explicitly via the CLI:

agent mcp login slack

This should start the OAuth flow and save tokens for the CLI. After that, check agent mcp list again. The status should change.

If agent mcp login doesn’t work (possible, OAuth for remote MCP in the CLI is still a bit unstable), there’s a workaround. Instead of the hosted Slack MCP mcp.slack.com/mcp, use a stdio-based Slack MCP server with a Bot Token directly, for example @modelcontextprotocol/server-slack or similar:

{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": {
        "SLACK_TOKEN": "xoxb-your-token",
        "SLACK_TEAM_ID": "your-team-id"
      }
    }
  }
}

Stdio MCP servers work reliably in the CLI, unlike OAuth-based remote servers.

About the Windows assertion error UV_HANDLE_CLOSING, that’s a separate bug. Is it affecting CLI stability for you?

The team is aware of the OAuth flow issue in the CLI. Let me know what you get from agent mcp login slack.

6

Hey @deanrie,

The response I get fromagent mcp login slackis as follows:

 ✗ MCP login failed
 Unexpected error during MCP login: Incompatible auth server: does not support dynamic client registration

Looks like it may be the same issue you are referring to. What do you suggest as next steps?

Thanks for the help!

7

Yes, that’s exactly the issue. Slack’s hosted MCP (mcp.slack.com) doesn’t support dynamic client registration, which the CLI uses for OAuth. Right now, the OAuth flow for remote MCP servers in the CLI is unreliable, so agent mcp login won’t help here.

I’d recommend trying the workaround from my previous reply. Switch to the stdio-based Slack MCP using a Bot Token:

{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": {
        "SLACK_TOKEN": "xoxb-your-token",
        "SLACK_TEAM_ID": "your-team-id"
      }
    }
  }
}

To do this, you’ll need to create a Slack App with a Bot Token (xoxb-…) at Slack API: Applications | Slack and grant the needed scopes (like channels:read, chat:write, etc, depending on what you need). Stdio servers work fine in the CLI, so no OAuth is required.

The team is aware of the OAuth flow issue in the CLI.

Let me know if you’ve got any questions about setting up the stdio option.