Connect DigitalOcean to Claude, ChatGPT and Cursor with governed access

A platform engineering lead gets asked on a Tuesday for something small: a list of every DigitalOcean account key and who created it, because an audit wants it by Friday. The answer exists and it is one API call. But the people who can make that call hold tokens that also destroy droplets, delete Kubernetes clusters, rotate registry credentials and detach volumes. So the routine request turns into a ticket, the ticket queues behind one engineer, and the person who asked has worked around it before the list arrives.

That gap is the reason pointing an AI assistant at cloud infrastructure usually stalls. DigitalOcean's API is wide. The connector exposes 684 tools spanning droplets, apps, databases, Kubernetes, networking, registries and monitoring. Give an agent the token an engineer already uses and you have given it every one of them.

Elaichi sits between the credential and the person. You connect DigitalOcean once, decide which tools are ever visible, group those into toolboxes per team, and let people point Claude, ChatGPT or Cursor at a single organisation endpoint. What each person's agent can actually reach is worked out from their own standing in your organisation, not from the reach of the token underneath.

Six teams, one DigitalOcean account

Nobody has a single relationship with DigitalOcean. Platform engineering owns the Kubernetes clusters and decides which 1-click apps are allowed to land on them. SRE lives in actions and account status, because when a deploy stalls the first question is what the platform itself believes happened. Security cares about account keys: how many exist, who minted them, when they were last rotated. Data works through metadata and add-ons, since that is where the managed pieces of a pipeline are described. Product engineering ships apps and follows deployments through to health. Finance operations reads the account and its SaaS add-ons, because that is what the invoice is made of.

Four record types carry most of the traffic between them: account keys, actions, apps and Kubernetes clusters. Every team has a real claim on some and none at all on others. Finance operations needs the add-ons attached to the account and has no business creating a database user. Security needs to enumerate account keys without gaining the ability to mint more. SRE needs to read actions across projects it never deploys to.

A cloud API cannot express any of that. A DigitalOcean token carries the resources it was granted when it was created, and from then on it treats every caller the same. The account has no idea whether the request came from Finance or from Platform. Something above the token has to know.

Connecting DigitalOcean when the credential is a pasted token

Open Connections, choose Add connection, pick DigitalOcean. What follows is shorter than people expect, and the shortness is the part that matters. This connector authenticates with an API key. No vendor window opens, there is nothing to approve, and no per-person grant is recorded anywhere. Somebody generates a token inside DigitalOcean, pastes it in, optionally sets Share with, and presses Connect. You land on Connection added, and from then on the connection can do precisely what that token could do.

This puts the security decision before Elaichi rather than inside it. Two things fix what the connection will ever be capable of: which human generated the token and what they scoped it to. A token minted with full write access yields a connection that can delete a Kubernetes cluster no matter how carefully you configure everything afterwards. A read-scoped token yields one that simply cannot, which is a harder guarantee than any rule layered on top.

So treat token generation as the design step. Most teams end up with several DigitalOcean connections, each backed by its own scoped token and named for the job: Production, Staging, Platform, Security, Data, Billing. A Billing connection whose token only reads account and invoice data is safe to share widely. A Production connection whose token can write is not.

Sharing then does the work a consent screen would have done elsewhere. Since nobody gets their own grant, the way a person uses DigitalOcean without holding the token is to be given Use on a connection somebody else owns. They run the tools bound to it. They cannot open it, edit it, transfer it, see it listed, or read the token. Set Share with at connect time if you know the audience, or share deliberately once the connection proves out.

Which DigitalOcean tools anyone should see

684 tools is well past the point where review is a strategy. Nobody is going to read that list, judge it tool by tool, and still remember the reasoning in six months. Work the other way: start with nothing visible and admit one object family at a time, a family being a resource plus the handful of operations that act on it.

Account and keys. Reading here settles most audit questions on its own: list_all_digitalocean_accounts, list_all_digitalocean_account_keys, get_single_digitalocean_account_key_by_id. Writing here is a different matter. create_a_digitalocean_account_key, update_a_digitalocean_account_key_by_id and delete_a_digitalocean_account_key_by_id manufacture and revoke credentials, so an agent holding them can extend its own reach. Keep that side out of general circulation.

Actions. list_all_digitalocean_actions and get_single_digitalocean_action_by_id are the platform's own account of what happened. They are read-only by nature and belong in nearly every toolbox, because they turn "the deploy is stuck" into a timestamp.

Apps and deployments. list_all_digitalocean_apps, get_single_digitalocean_app_by_id and digitalocean_apps_list_logs answer the daily questions. create_a_digitalocean_app and update_a_digitalocean_app_by_id change what is running. delete_a_digitalocean_app_by_id removes it. The first group can be broad, the second belongs to the team that owns the service, the third should live in one place or nowhere.

Clusters and 1-clicks. list_all_digitalocean_kubernetes_clusters and list_all_digitalocean_1_clicks describe the estate. create_a_digitalocean_1_clicks_kubernete adds to it, which is a platform engineering call rather than a chat-window one.

Add-ons and edge. list_all_digitalocean_add_ons_apps and list_all_digitalocean_metadata are descriptive. create_a_digitalocean_add_ons_saa, update_a_digitalocean_add_ons_saa_by_id and update_a_digitalocean_saa_plan_by_id move spend. delete_a_digitalocean_add_ons_saa_by_id, delete_a_digitalocean_cdn_endpoint_by_id, delete_a_digitalocean_endpoint_cach_by_id and delete_a_digitalocean_certificate_by_id are the ones that turn a typo into an outage.

Anything not named in a toolbox is not reachable. Lean on that: you are not auditing a catalogue this size, you are choosing the few dozen entries that earn their place.

A toolbox per team

A template is where the thinking lives: tool entries with their overrides and nothing connected to them yet. Write one per team rather than one per person.

"DigitalOcean read" is the one most people get: list_all_digitalocean_accounts, list_all_digitalocean_account_keys, list_all_digitalocean_actions, get_single_digitalocean_action_by_id, list_all_digitalocean_apps and list_all_digitalocean_metadata. Rename entries to the words your engineers type and rewrite the descriptions in your own vocabulary, which matters more than it sounds.

"Product engineering apps" adds create_a_digitalocean_app, update_a_digitalocean_app_by_id and digitalocean_apps_list_logs, and deliberately omits delete_a_digitalocean_app_by_id. "Platform" adds list_all_digitalocean_1_clicks and create_a_digitalocean_1_clicks_kubernete. "Finance" is list_all_digitalocean_add_ons_apps plus list_all_digitalocean_accounts and stops there.

Share each template at Edit with the team that maintains it, and at View with everyone who should be able to see the standard without altering it.

Then stamp it. Stamping produces a toolbox and binds a connection to each entry, and the toolbox is what MCP clients actually talk to. Stamp "DigitalOcean read" twice against different connections and you get a Production toolbox and a Staging toolbox with identical entries and very different blast radius. An entry left unbound shows as needs connection and stays inert until you bind it.

Plan around two properties. Stamping copies at creation, so editing a template next month leaves every toolbox already stamped from it untouched and a fix has to be applied to each one. And entry lists stop at 200, which is irrelevant for per-team toolboxes and immediate if you try to mirror the catalogue.

Governing it, starting from who it is shared with

The share is the first control, because it decides whether anything else is ever consulted. A DigitalOcean connection or toolbox goes to a member, to a team, or to everyone, at View, Use or Edit. View shows it without running it, Use runs it, Edit changes its settings and its sharing. Most mistakes are Edit handed to someone who needed Use.

Use is the interesting level. Someone with Use on the Production connection runs tools against a token they never see and cannot list. That delegation is resolved again on every call against the person who owns the connection, so it dies the moment their own access does.

Restrictions cut the other way. They are allow-lists or block-lists over connectors and individual tools, aimed at a role or at one member, with no organisation-wide form. A member rule replaces the role's rule rather than merging with it, which is why authoring one is its own permission. They bite at four points: connect time, when tools are listed, when one is called, and on the outbound request. They match the original catalogue name, so renaming an entry in a template changes nothing. An allow rule naming nothing denies everything, which is the blunt instrument for a team that should not touch DigitalOcean at all.

Roles decide who configures any of this. Eight ship with the product: Org Owner, Org Admin, People Admin, Team Admin and Member consume a billable seat, while Guest, Billing Admin and Auditor do not. Custom roles always do. Each member holds one role drawn from 38 permissions in 13 groups. Only connector:create is flagged high-trust, for a reason that lands hard on infrastructure teams: a custom connector can be aimed at any destination, and no restriction constrains it afterwards.

One timing detail, stated exactly. Every call is re-checked, but role and restriction changes read a snapshot up to about a minute old, two at worst. Revoking a share, disconnecting the account or removing a member takes effect on the very next request.

One endpoint, resolved per person

Everyone points their client at the same organisation address, copied from the Connect your AI client dialog. There is no per-person URL and no scripted rollout; each person adds it by hand, once, in the client they use. What differs is the result. The endpoint resolves against whoever signed in, so two engineers pasting the same URL see different DigitalOcean tools, and a Finance analyst may see nothing that writes.

At first use the client asks which scopes to consent to: Read, Create and change, Delete, and Run tools. Only Read starts on, which is the right default for infrastructure. Enabling Delete against a DigitalOcean toolbox should be a decision taken in daylight, not a box cleared during setup.

Past 30 advertised tools, counting the platform's own operations together with your connected ones, individual names stop being listed and are replaced by search_tools and execute_tool. With 684 tools in this catalogue that threshold is not hypothetical. The search ranks lexically rather than by meaning, so your entry names carry weight: an entry named for the words people actually type is findable, one named after an internal project is not.

Connect DigitalOcean to Claude

Copy the organisation endpoint from the Connect your AI client dialog. In Claude, open Settings, then Connectors, then Add custom connector, and paste it. On Team and Enterprise plans only an Owner may add a custom connector, so this is usually done once by whoever administers the workspace rather than by every engineer.

Claude then asks for consent. Read is on and the rest are off; leave Create and change off for DigitalOcean unless the person genuinely deploys. Sign in, and the tools that appear are whatever your toolboxes and restrictions leave for that account. Someone seeing fewer DigitalOcean tools than a colleague is per-person resolution working, not a broken setup.

Connect DigitalOcean to ChatGPT

In ChatGPT, open Settings, then Apps, switch developer mode on, choose Create, paste the organisation endpoint and run Scan tools. The scan is what pulls your DigitalOcean entries in. If a tool you expected is missing, check the toolbox binding before changing anything in ChatGPT.

This path needs a Business, Enterprise or Edu workspace and is web-only, so it will not appear anywhere but the browser. Consent behaves as it does elsewhere: Read on, Create and change, Delete and Run tools off until somebody decides otherwise. For a catalogue this large, expect search_tools and execute_tool rather than a list of names.

Connect DigitalOcean to Cursor

Cursor reads MCP servers from a JSON file, so this one is per-machine rather than per-account. Add an entry under mcpServers in ~/.cursor/mcp.json to make DigitalOcean available everywhere, or in a repository's .cursor/mcp.json to scope it to one codebase. The repo-local form is often the better default for infrastructure work, because the person working on a service gets DigitalOcean tools while they are in that project and not while they are elsewhere.

Being per-machine, a reimage or a second workstation means doing it again, so keep the snippet where your engineers already look. Consent still applies, and the account signing in still decides which tools resolve.

Day two

Tokens get rotated and connections break. When a DigitalOcean token is revoked or expires the connection stops working, and Reconnect is what repairs it: the owner supplies a current token, every toolbox stamped against that connection resumes, and nobody has to touch their client.

Offboarding is where the pasted-token shape costs you something. Removing a member ends their access on the next request. But if that person owned the DigitalOcean connection, everyone using it through a share loses it too, because the delegation resolves against the owner. Transfer connections away from anyone who might leave, and do it ahead of the departure rather than during it.

Access requests are the pressure valve. Rather than widening a share because one person needed one thing once, let them ask for the connection or toolbox and approve it explicitly. The request and its resolution both land in the audit log.

That log is append-only by construction. It covers tool calls, shares, restrictions, memberships, roles, teams, connections and transfers, toolboxes, SSO and SCIM changes and sign-ins, and records the id of the DigitalOcean record a call created or changed. Arguments and results are left out on purpose, since a call's payload is your data. It is eventually consistent, so give a row a moment to appear. Forward it to Datadog if that is where infrastructure alerting already lives, and route notifications to Slack or email.