Services → DigitalOcean

Connect DigitalOcean

Droplets, App Platform, managed databases, Kubernetes, networking, DNS, volumes, monitoring and the account's action log — forty tools, one token, nothing to install.

Tier 2 A DigitalOcean personal access token, Read scope ~2 min profile digitalocean/read-only

Setting this up with your own agent? Give it these instructions.

The whole setup

DigitalOcean control panel → API → Tokens → Generate New Token.
Name it prodpeek. Set an expiry. Scopes: Read. Not Read/Write.
Copy it.
In Prodpeek: Services → Add a service, pick digitalocean/read-only, leave the upstream alone, paste the token, Test connection.

That is it. Two minutes, nothing to install.

Why you are not connecting DigitalOcean's MCP

If you connected DigitalOcean through its MCP server, you got about eight tools, all about App Platform, and concluded — correctly — that it was not enough to be useful.

That was not the policy being strict. DigitalOcean ships its MCP as one endpoint per service: apps.mcp.digitalocean.com, droplets.mcp.digitalocean.com, and so on. The local npx @digitalocean/mcp build has the same shape behind a --services flag that loads only the modules you name. So "connect DigitalOcean" really meant connecting it a dozen times — a dozen connections, each with its own credential and its own audit trail, each showing a twelfth of your account.

DigitalOcean's API v2 is one host, one bearer token, and the whole account. So Prodpeek speaks it directly, the same way it does Grafana, SSH, Postgres, Git and Prometheus. One connection. Forty tools.

What your agent can then do


do__list_droplets              what exists, and whether it is up
do__list_droplet_neighbors     why three of them degraded at once
do__list_apps                  App Platform, with each app's live phase
do__get_deployment             which step of the failed deploy failed
do__list_databases             engine, version, status — never the password
do__list_database_firewall_rules  the real reason the app cannot connect
do__list_domain_records        why it still resolves to the old address
do__list_certificates          what expires, and when
do__list_alert_policies        what DigitalOcean is already watching
do__list_actions               every resize, reboot and migration, with when

list_actions is the one people do not expect to want. It is DigitalOcean's own action log — the closest thing the platform has to an audit trail, and usually the fastest answer to *what changed just before this broke?*

list_droplet_neighbors is the second. Shared hardware is invisible until three unrelated droplets degrade together, and then it is the only explanation that fits.

The three endpoints that hand out credentials

DigitalOcean has three reads whose response body *is* a live credential:

Endpoint	What it returns
`/v2/kubernetes/clusters/{id}/kubeconfig`	working cluster-admin credentials
`/v2/registry/docker-credentials`	a docker login for your private registry
`/v2/databases/{id}`	a `connection` object containing the database password

The first two have no tool. Not denied by a rule — there is no code in the adapter that builds those paths, so no argument and no bug reaches them.

The third is different, and the difference is the interesting one. A database cluster's status, version, region and maintenance window are exactly what you want during an incident. Denying the whole endpoint to avoid one field would have cost real visibility, so get_database exists and the adapter removes connection, private_connection and users before answering. You get the diagnostics; the password is replaced with a note saying it was removed.

App Platform env vars get the same treatment: the keys survive, the values do not. "Is DATABASE_URL set at all?" is the question worth answering.

Why Tier 2

A DigitalOcean token is Read or Read/Write for the entire account. There is no per-resource scoping and no "may not read billing" flag. Read genuinely cannot write — real, and worth having — but it *can* read everything this profile chooses not to expose, so for several tools the gateway is the only thing saying no. Tier 2, said plainly.

Checking the token is really Read


# Should succeed
curl -sS -H "Authorization: Bearer $DO_TOKEN" \
"https://api.digitalocean.com/v2/account" | head -c 200

# Should FAIL with 403: creating a tag is the cheapest harmless write
curl -sS -o /dev/null -w '%{http_code}\n' -X POST \
-H "Authorization: Bearer $DO_TOKEN" -H 'Content-Type: application/json' \
-d '{"name":"prodpeek-permission-test"}' \
"https://api.digitalocean.com/v2/tags"

A 403 on the second is the vendor fence doing its half. A 201 means the token is Read/Write — delete it and make a Read one.

Screenshots

API → Tokens → Generate New Token, with Read scope and an expiry.

Grant exactly this

A personal access token with Read scopeDigitalOcean tokens are Read or Read/Write for the whole account; there is no per-resource scoping. Read genuinely cannot write — that part is real and vendor-enforced — which is why every write in this profile is refused twice over.
An expiry on the tokenDigitalOcean offers 30/60/90 days, a year, or no expiry. Take a bounded one. A token with no expiry is a credential you will forget you issued.

And none of this

The permissions that look harmless and quietly demote the profile from “the credential cannot” to “we asked it not to”.

Write (Read/Write) scopeIt would let the token create, resize, reboot and destroy every resource on the account. The gateway issues only GET and has no tool that builds a write path, but a Read/Write token means the vendor fence is gone and only the gateway is left.
A token belonging to a human's personal account, on a team accountIt carries that person's access, disappears when they leave, and attributes every call to them rather than to the integration.

Check before you paste it

The token page shows Scopes: Read (not Read/Write).
The token has an expiry date.
Test connection shows around 40 tools, not 8.
Calling account returns the email of the account you expected.