Where does the bug appear (feature/product)?
Somewhere else…
Describe the Bug
Cursor Cloud Agents sends scope: null during OAuth 2.1 authorization requests, resulting in access tokens without API scopes. This prevents Cloud Agents from accessing team-configured MCP servers that use OAuth with scope-based authorization, despite the MCP server correctly advertising available scopes via OAuth metadata.
Impact
- Severity: High - Blocks all team-configured MCP servers using OAuth with scope-based auth
- Affected: Cursor Cloud Agents only (Desktop IDE works correctly)
- Workaround: Server-side scope auto-injection for trusted clients (requires code changes to each MCP server)
Steps to Reproduce
Reproduction Steps
- Create an OAuth-protected MCP server that advertises scopes via
/.well-known/oauth-authorization-server - Configure in Cursor Team Dashboard at cursor.com/dashboard → Integrations & MCP
- Launch a Cursor Cloud Agent that uses the MCP server
- Observe: OAuth succeeds but access token has no scopes
- Result: All MCP tool calls fail with “insufficient permissions”
- Cursor Version: Latest as of May 2026
Expected Behavior
The Problem
When a Cursor Cloud Agent authenticates with an OAuth-protected MCP server:
MCP server advertises available scopes via /.well-known/oauth-authorization-server- Cursor initiates OAuth flow with correct audience
Cursor sends scope: nullin the authorization request- Auth provider (Auth0) issues token with no API scopes
- MCP tool calls fail with “insufficient permissions”
Evidence from Auth0 Logs
Cursor Cloud Agents (broken):
{
"client_id": "3yuw7FezTnY2s4uwHTpuVheN0MsTd2yP",
"audience": "https://api.df.overmind-demo.com", // ✅ Correct
"scope": null // ❌ MISSING - should request advertised scopes
}
Cursor Desktop IDE (working):
{
"client_id": "3yuw7FezTnY2s4uwHTpuVheN0MsTd2yP",
"audience": "https://api.df.overmind-demo.com", // ✅ Correct
"scope": "openid profile email brent:read brent:write account:read" // ✅ Correct
}
Expected Behavior Per MCP Specification
According to the MCP OAuth specification:
- MCP client discovers OAuth metadata at
/.well-known/oauth-authorization-server/{server_name}/oauth - Server advertises
scopes_supportedin metadata response - Client MUST request those scopes in the authorization request
- Auth provider issues token with the requested scopes
Our MCP server correctly advertises scopes:
{
"authorization_servers": ["https://overmind-demo.us.auth0.com"],
"scopes_supported": ["openid", "profile", "email", "account:read", "brent:read", "brent:write"]
}
What Makes This Worse Than the Related Forum Issue
The existing forum thread “MCP step-up consent not exposed for insufficient scope” describes problems with step-up consent for insufficient scopes.
Our case is more fundamental: Cursor Cloud Agents doesn’t request ANY scopes even on the initial authorization, despite them being advertised in the OAuth metadata. This violates the MCP specification’s OAuth flow requirements.
Operating System
Windows 10/11
MacOS
Linux
Version Information
this happens in cloud agents only Latest as of May 2026
cursor ide works as expected.
Additional Information
Someone even wrote a blog post about it https://medium.com/@george.vetticaden/the-missing-mcp-playbook-deploying-custom-agents-on-claude-ai-and-claude-mobile-05274f60a970
Related Resources
- Related Forum Thread: MCP step‑up consent not exposed for insufficient scope
- MCP OAuth Specification: https://spec.modelcontextprotocol.io/specification/architecture/authentication/
Does this stop you from using Cursor
No - Cursor works, but with this issue