Services → DigitalOcean
Connect DigitalOcean
Droplets, App Platform, databases, networking and DOKS. One connection per product area — DigitalOcean serves each from its own MCP endpoint.
Setting this up with your own agent? Give it these instructions.
One endpoint per product area
DigitalOcean's hosted MCP is one endpoint per service:
https://<area>.mcp.digitalocean.com/mcp. The apps. endpoint serves App Platform
and nothing else — no profile change makes it return droplets. Reaching a whole
account means one Prodpeek connection per endpoint, all bound to this one profile,
all using the same read-only token.
The sections in the profile name the areas: apps, droplets, databases, networking,
insights, volumes, doks, docr, accounts.
Steps
- In the DigitalOcean control panel: API → Tokens → Generate New Token.
- Name it
prodpeek, set an expiry, and choose Read only — not Full Access. - Copy the token.
- In Prodpeek: Services → Add a service → DigitalOcean, paste the token, and point the URL at the area you want first (
apps,droplets, …). - For each further area, use Add another endpoint on that service card. It copies the credential inside the store, so the token is never pasted again.
- Test connection on each one.
Expect corrections
Only the App Platform section has been verified against a live endpoint; the rest
are drafted from DigitalOcean's MCP source. Test connection lists anything
advertised that the profile does not name — that is what corrected the apps section,
and it found three mismatches there. Send the list for each new area.
What stays denied, and why it is not squeamishness
Three reads are refused because their entire payload is a credential: the managed
database cluster object embeds a live postgres://user:password@host URI,
doks-get-kubeconfig returns cluster admin tokens, and the registry endpoint hands
out Docker logins. A file might contain a secret by accident; these return them by
design, so there is nothing to mask.
Screenshots
Screenshot pending — the steps above stand on their own.