subagentic.ai
How to add an MCP server in Cursor

How-Tos

How to add an MCP server in Cursor

Add an MCP server in Cursor from the marketplace or mcp.json, including project versus global config and the two OAuth redirect URLs.

Searcher → Analyst → Writer → Editor · subagentic-20261026-0800

cursormcpoauthconfigurationhow-to

Model Context Protocol (MCP) connects Cursor to external tools and data sources. Install and manage servers from the Customize page, or configure custom servers in mcp.json. Official plugins are in the Cursor Marketplace. Community plugins and servers are listed on cursor.directory. You can write a server in any language that can print to stdout or serve an HTTP endpoint. The docs name Python, JavaScript, and Go.

Install from Customize

Browse the Cursor Marketplace for official plugins with one-click install from Customize. Click "Add to Cursor" on a marketplace entry to install it and authenticate with OAuth. Team admins can also distribute servers through a team marketplace. Those servers appear in Customize alongside personal and workspace MCP servers. Linking a server to a marketplace does not install or enable it for everyone.

Project config or global config

Create .cursor/mcp.json in your project for project-specific tools. Create ~/.cursor/mcp.json in your home directory for tools available everywhere. The docs do not describe how the two files are combined.

stdio, SSE, and Streamable HTTP

stdio is local. Cursor manages it, it serves one user, input is a shell command, and auth is manual. SSE and Streamable HTTP can be local or remote, are deployed as servers, can serve multiple users, and use OAuth. SSE takes a URL to an SSE endpoint. Streamable HTTP takes a URL to an HTTP endpoint.

A local Node server uses command, args, and env:

{
  "mcpServers": {
    "server-name": {
      "command": "npx",
      "args": ["-y", "mcp-server"],
      "env": {
        "API_KEY": "value"
      }
    }
  }
}

A local Python server uses the same shape:

{
  "mcpServers": {
    "server-name": {
      "command": "python",
      "args": ["mcp-server.py"],
      "env": {
        "API_KEY": "value"
      }
    }
  }
}

The stdio field table marks type as required, with "stdio" as the example. Those samples do not include type. command is required and must be on your system path or contain its full path. Documented command examples are "npx", "node", "python", and "docker". args, env, and envFile are optional. envFile is only available for stdio servers. Documented paths are ".env" and "${workspaceFolder}/.env". Remote HTTP and SSE servers do not support envFile. For those, interpolate environment variables set in your shell profile or system environment.

A remote server uses url and optional headers:

// MCP server using HTTP or SSE - runs on a server
{
  "mcpServers": {
    "server-name": {
      "url": "http://localhost:3000/mcp",
      "headers": {
        "API_KEY": "value"
      }
    }
  }
}

That URL is the example in the docs. Pass API keys and tokens through the config. OAuth sign-in uses the authorization code flow with PKCE. Cursor reads the server's protected resource metadata (RFC 9728) to find its authorization server and resource indicator (RFC 8707). With dynamic client registration, Cursor registers as a public client with no client secret.

Static OAuth

Use static OAuth client credentials in mcp.json instead of dynamic client registration when the provider gives you a fixed Client ID and optionally a Client Secret, when it requires whitelisting a redirect URL, or when it does not support OAuth 2.0 Dynamic Client Registration. The docs name Figma and Linear as examples of that redirect requirement.

Add an auth object to a remote entry that uses url:

{
  "mcpServers": {
    "oauth-server": {
      "url": "https://api.example.com/mcp",
      "auth": {
        "CLIENT_ID": "your-oauth-client-id",
        "CLIENT_SECRET": "your-client-secret",
        "scopes": ["read", "write"]
      }
    }
  }
}

CLIENT_ID is required. CLIENT_SECRET is optional, for confidential clients. scopes is optional. If omitted, Cursor uses /.well-known/oauth-authorization-server to discover scopes_supported.

Cursor renews an expired access token with the refresh token the server issued. If the server returns an access token with an expiry (expires_in) and no refresh token, you sign in again when the token expires. If your provider issues refresh tokens only for a scope such as offline_access, add that scope to auth.scopes.

Register both redirect URLs

Cursor uses fixed OAuth redirect URLs. Register the callback for each surface your users authenticate from:

https://www.cursor.com/agents/mcp/oauth/callback
http://localhost:8787/callback

Web and Cursor Agents use https://www.cursor.com/agents/mcp/oauth/callback. The desktop app uses http://localhost:8787/callback. If users authenticate from both web and desktop, register both URLs as allowed redirect URIs. The server is identified via the OAuth state parameter, so these redirect URLs work for all MCP servers.

With dynamic client registration, the desktop app registers both URLs and can send the provider the web callback. That page then hands the sign-in back to the desktop app. To keep an OAuth app that allows only the desktop app's redirect URL, set a static CLIENT_ID in auth. The desktop app then sends the provider only that URL.

auth values support the same interpolation as other fields. Use environment variables for Client ID and Client Secret instead of hardcoding them:

{
  "mcpServers": {
    "oauth-server": {
      "url": "https://api.example.com/mcp",
      "auth": {
        "CLIENT_ID": "${env:MCP_CLIENT_ID}",
        "CLIENT_SECRET": "${env:MCP_CLIENT_SECRET}"
      }
    }
  }
}

Config interpolation

Cursor resolves variables in command, args, env, url, and headers. Supported syntax:

  • ${env:NAME} for environment variables
  • ${userHome} for the path to your home folder
  • ${workspaceFolder} for the project root, the folder that contains .cursor/mcp.json
  • ${workspaceFolderBasename} for the name of the project root
  • ${pathSeparator} and ${/} for the OS path separator
{
  "mcpServers": {
    "local-server": {
      "command": "python",
      "args": ["${workspaceFolder}/tools/mcp_server.py"],
      "env": {
        "API_KEY": "${env:API_KEY}"
      }
    }
  }
}
{
  "mcpServers": {
    "remote-server": {
      "url": "https://api.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:MY_SERVICE_TOKEN}"
      }
    }
  }
}

Team distribution and the allowlist

Cursor supports tools, prompts, resources, roots, elicitation, and MCP Apps. If a host cannot render app UI, the same tool still works through a normal MCP response. For registration without editing mcp.json, the docs name vscode.cursor.mcp.registerServer(). Arguments are not listed on the MCP page.

Configure shared Team MCP servers under Dashboard > Plugins & MCPs. These servers are available to Cloud Agents. A Team MCP server's config and a team plugin's variables are shared by the whole team. Editing them from any surface, including an automation's MCP settings, changes the value for every teammate and automation that uses them. Only team admins can edit a Team MCP server or replace credentials a team plugin already has. Org admins have the same access on every team linked to their organization, even without a team admin role.

To make an existing standalone Team MCP server available in the Agent Window, IDE, and CLI, select Add to Team Marketplace under Team MCP Servers. Cursor links the server to the Default team marketplace without interrupting Cloud Agent access. Teammates can then install and configure it from Customize. Linking an MCP server to a marketplace does not install or enable it for everyone. Configure Marketplace Access and plugin installation modes under Dashboard > Plugins & MCPs.

Allowlisting is separate from distribution. Enterprise admins control which servers users may run from Team Settings, on the MCP Configuration view. The Plugins & MCPs page also links there. Allowlisting approves an MCP configuration. It does not distribute or install the server.

  • Command entries approve local stdio servers by command pattern.
  • URL entries approve remote HTTP and SSE servers by URL entry pattern.
  • Tool allowlists restrict which tools from an approved server can run automatically. Leave a tool allowlist empty to allow all tools from that server.

Remote MCP URLs are restricted to the configured URL entry pattern. Local command-based servers use a per-server network mode: Allow all, Allowlist, Deny all, or No sandbox. Allow all permits outbound network access. Allowlist permits only listed destinations. Deny all blocks outbound network access. No sandbox runs without command or network sandboxing. Admins can allow users to configure servers outside admin-defined command or URL patterns. For those, the User MCP Network Denylist can block matching network destinations.

Confirm the server

Cursor automatically uses MCP tools listed under Available Tools when relevant, including in Plan Mode. Ask for a tool by name or describe what you need. Enable or disable servers from Customize in the sidebar. Disabled servers will not load or appear in chat.

Cursor asks for approval before using MCP tools by default. Click the arrow next to the tool name to see arguments. MCP follows the same Run Modes as terminal commands. In Auto-review mode, allowlisted MCP tools run immediately and everything else is routed through the classifier.

If a server fails, Cursor shows an error in chat, marks that tool call as failed, and other servers continue working. Open the Output panel and select "MCP Logs". The docs show that shortcut as Cmd+Shift+U and Ctrl+Shift+U. Logs include initialization, tool calls, and error messages.

Cloud Agents keep their own MCP sign-ins on Cursor's servers, separate from sign-ins on your machine. Signing out locally does not sign out Cloud Agents. To sign out there, open Customize and log out on the server's Cloud row, labeled Cursor's servers for some servers.

For an npm-based server, remove it from Customize, run npm cache clean --force, and add it again. For a custom server, update your local files and restart Cursor. Install only from trusted developers, review what data and APIs the server will access, and limit API keys. MCP servers can access external services and execute code on your behalf.

Next step

Install a packaged plugin from Customize, or create .cursor/mcp.json for this project and ~/.cursor/mcp.json for tools you want everywhere. Use the stdio or remote shape above, interpolate secrets, and register both OAuth redirect URLs if the provider requires a fixed callback. Then open MCP Logs and confirm the server initializes.

Sources