DigitalOcean MCP Server Cursor IDE Setup (2026)

How do you connect DigitalOcean to Cursor? Generate a Personal Access Token from the DigitalOcean control panel, add a digitalocean entry to ~/.cursor/mcp.json running @digitalocean/mcp via npx with DIGITALOCEAN_API_TOKEN in its env block, and pass a --services flag naming which parts of your infrastructure it can touch. Restart Cursor, and it can create and manage App Platform apps, resize Droplets, inspect managed databases, and query DigitalOcean's docs, scoped to whatever services you listed.

That --services flag matters more here than the equivalent option on most platform integrations: DigitalOcean's server covers a genuinely wide surface — Apps, Droplets, Kubernetes (DOKS), Container Registry (DOCR), networking, Spaces, GenAI infrastructure, and more — and it's opt-in per service rather than all-or-nothing. Leaving it off entirely, or listing more than you need, hands the AI tools for infrastructure you may not want it anywhere near.

If you're comparing hosting platforms for MCP-driven deploys, this site also covers Vercel, Netlify, Heroku, and Railway — DigitalOcean's is the only one of the five where a single server also reaches down to raw compute (Droplets) and Kubernetes rather than staying at the app-platform layer.

What the DigitalOcean MCP Server Can Do

Scoped to the apps service, typical prompts include:

With droplets and databases also enabled:

With docs enabled (useful even on its own, with no API token required for this one):

Prerequisites

Step 1: Create a Personal Access Token

1. Log in to the DigitalOcean control panel
2. Go to API → Tokens
3. Click Generate New Token
4. Name it something identifiable, like cursor-mcp
5. Set an expiration — DigitalOcean defaults to 90 days; pick something you're actually willing to rotate on schedule rather than "no expiry" out of convenience
6. Grant read/write scope depending on whether you want the AI creating and modifying resources or just inspecting them
7. Copy the token immediately — it isn't shown again

Step 2: Configure Cursor MCP with Scoped Services

Start narrow. If you only want App Platform management:

{
  "mcpServers": {
    "digitalocean": {
      "command": "npx",
      "args": ["@digitalocean/mcp", "--services", "apps"],
      "env": {
        "DIGITALOCEAN_API_TOKEN": "your_token_here"
      }
    }
  }
}

To cover apps, Droplets, and managed databases together:

{
  "mcpServers": {
    "digitalocean": {
      "command": "npx",
      "args": ["@digitalocean/mcp", "--services", "apps,droplets,databases"],
      "env": {
        "DIGITALOCEAN_API_TOKEN": "your_token_here"
      }
    }
  }
}

Valid service names include apps, databases, droplets, doks (Kubernetes), docr (Container Registry), functions, networking, spaces, accounts, volumes, and several GenAI-platform-specific services — pass a comma-separated list matching only what you actually use. Restart Cursor after saving.

Step 3: Test the Connection

List my DigitalOcean apps

Or, if you enabled droplets:

List my Droplets and their current status

A real response with your actual resources confirms the connection. If you get an empty list on an account you know has resources, check that the token's scope actually covers the service you're querying — a read-only token still returns data for list-style calls, but a token scoped to the wrong product returns nothing rather than an explicit permission error in some cases.

The Gotcha Worth Planning For: Service Scope Is Broader Than Most Teams Need by Default

It's tempting to just pass every service name to avoid revisiting the config later, but the tool list genuinely gets long — app-create, droplet-resize, domain-create, key-create (SSH keys), and more, each one a real write action against billed infrastructure once enabled. Treat --services the same way you'd treat IAM scoping on any cloud provider: start with the one or two services this specific project needs, and add more deliberately rather than defaulting to everything. docs-search and insights are the safest to leave on broadly since they're read-only by nature; droplets, apps, and databases are where an overly broad grant turns into a real blast radius if a prompt goes sideways.

Troubleshooting

"401 Unauthorized" or "invalid token"
The token expired (check the expiration you set in Step 1) or was regenerated elsewhere. DigitalOcean tokens are shown once — if you lost it, generate a new one rather than trying to recover the old value.

Service commands return "not enabled" or don't show up as available tools
The --services flag in args doesn't include that service. Add it to the comma-separated list and restart Cursor — this is a config-side restriction, not a token permission issue, so a token with full account access still won't expose droplets tools if --services apps is all that's listed.

"Insufficient permissions" on a write action even though list/read calls work
Your Personal Access Token may be scoped read-only. Regenerate it with read/write access if you actually want the AI creating or modifying resources, not just inspecting them.

Deploy or resize commands are slow to reflect in the control panel
DigitalOcean's API is eventually consistent for some operations — a droplet resize or app deploy can report success from the API before the control panel UI fully reflects the new state. Give it a minute before assuming a command silently failed.

npx @digitalocean/mcp fails outright
Confirm Node 18+ and that npx resolves in the same shell environment Cursor uses — a stale global npm cache is a common, boring cause; npm cache clean --force and retry before assuming it's an auth problem.

When Not to Use This

If your account has resources across multiple teams or clients on one DigitalOcean account, be deliberate about which token you use — a Personal Access Token's scope is tied to your account's overall permissions, not a specific project or team, so --services limits which tool categories load but doesn't create a hard boundary around which specific droplets or apps a given token can reach within an enabled service. For genuinely separate blast radii per client, use separate DigitalOcean teams with separate tokens rather than one broad token and hoping prompts stay scoped correctly.

Frequently Asked Questions

Q: What's the difference between --services apps and leaving --services off entirely?
A: Behavior without the flag isn't guaranteed to expose every service by default in every version — treat --services as required rather than optional, and list exactly the services you want. This also keeps the AI's available tool list focused, which tends to produce more accurate tool selection than a huge unscoped list.

Q: Do I need a paid DigitalOcean account, or does this work on the free tier / trial credits?
A: The MCP server itself has no separate cost — it just calls the same API your account already has access to. Whatever your account's normal DigitalOcean billing and access looks like applies the same way here.

Q: Can this server manage Kubernetes clusters (DOKS), not just Droplets and Apps?
A: Yes, add doks to the --services list. It exposes cluster-level operations through DigitalOcean's Kubernetes API rather than requiring a separate kubectl-based MCP server for basic cluster management tasks — though for deep in-cluster work (pod logs, exec into containers), a dedicated Kubernetes MCP server still covers more ground.

Q: Is there a way to scope this to a single project or team, not the whole account?
A: Not at the MCP config level — scoping happens through the DigitalOcean account/team structure and which token you generate, not through a project-ID field in mcp.json. If you manage multiple clients or teams, use a token generated under the specific team you want the connection scoped to.

Q: What happens if I enable a service my token doesn't have permission for?
A: The tool loads (since --services is a config-side setting, not a permission check), but calls against that service fail with a permission or authorization error from DigitalOcean's API rather than the tool being hidden entirely. Match your token's actual scope to your --services list to avoid confusing failures.

Q: Does this replace doctl, DigitalOcean's own CLI?
A: Not really — they serve different workflows. doctl is still the better tool for scripting and one-off manual commands. This MCP server is for chaining DigitalOcean context into an AI coding session, like checking a Droplet's status while debugging a deploy, without leaving your editor.

Related Guides

---