[cursor-agent] MCP server tools/resources/prompts not loaded after OAuth (DCR) login until manual disable/enable cycle

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

When using cursor-agent with an MCP server that requires OAuth, completing the OAuth login flow via /mcp login does not result in the MCP server’s tools, resources, or prompts being loaded. Running /mcp list-tools after a successful login returns:

No tools available for

Inspecting the MCP server logs confirms that after the token exchange completes, cursor-agent does not proceed to query the server for its capabilities (tools, resources, prompts). The last recorded server-side activity is the POST /token request — no subsequent capability discovery requests are made.

Workaround:
After completing the OAuth login, manually cycling the server connection resolves the issue:
/mcp disable
/mcp enable
After these two commands, tools, resources, and prompts are correctly loaded.

Video recording is attached from reproduction done over a minimal FastMCP server setup (the same issue has been reproduced with two additional production servers).

Steps to Reproduce

  1. Configure cursor-agent with a single MCP server that requires OAuth with DCR.
  2. Run /mcp login .
  3. Complete the OAuth authorization flow in the browser window.
  4. Run /mcp list-tools .
  5. Observe: “No tools available for ” is displayed.

Expected Behavior

After successfully completing the OAuth (DCR) login flow via /mcp login, cursor-agent should automatically perform MCP capability discovery (tools, resources, prompts) without requiring a manual disable/enable cycle. The behavior should be consistent with Cursor IDE (GUI), where tools, resources, and prompts are immediately available after login.

Screenshots / Screen Recordings

Operating System

Linux

Version Information

CLI Version 2026.03.25-933d5a6

Does this stop you from using Cursor

No - Cursor works, but with this issue

1 Like

Hi Robert!

This looks like a bug. After completing the OAuth flow via /mcp login, the CLI session doesn’t pick up the newly saved tokens for the MCP connection. The /mcp disable + /mcp enable workaround works because it forces a fresh connection.

Your workaround is the correct approach until this is fixed. I’ve flagged this with our team.

1 Like