Connect DigitalOcean

The whole setup

1. DigitalOcean control panel → API → Tokens → Generate New Token.
2. Name it prodpeek. Set an expiry. Scopes: Read. Not Read/Write.
3. Copy it.
4. 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

Screenshot pending — the steps above stand on their own.