# Connect DigitalOcean to Prodpeek

Profile: `digitalocean/read-only` · connection kind: `http` · tier 2
Credential: DigitalOcean API token
Suggested URL: `https://apps.mcp.digitalocean.com/mcp`

Droplets, App Platform, databases, networking and DOKS. One connection per product area — DigitalOcean serves each from its own MCP endpoint.

## What you must not do

You cannot create this credential on the user's behalf — it needs their login and,
usually, an approval step. Walk them through it and verify the result. Never ask
them to paste the credential into the chat; it goes straight into Prodpeek's
console, which encrypts it at rest. One token is reused across every DigitalOcean connection — unlike GitHub, the scoping here is by endpoint, not by token. Use "Add another endpoint" on the first service card so the token is copied inside Prodpeek rather than pasted repeatedly.

## Grant exactly these permissions

- `Token scope: Read only` — Everything this profile allows, across every product area.

## Refuse these, and say why if the user asks for them

- `Full Access` — DigitalOcean's default when you create a token quickly, and it grants write to the entire account. Choose Read only deliberately.
- `Custom scopes with any create/update/delete` — The profile denies every write; the token should not hold them either.

## Verify before the credential is used

- The token row in the API panel reads 'Read only'.
- In Prodpeek, Test connection shows the delete/update tools under 'denied by policy'.

## Then, in Prodpeek

1. Services → Add a service → choose the profile `digitalocean/read-only`.
2. Connection kind `http`, URL `https://apps.mcp.digitalocean.com/mcp`.
3. Paste the credential. It is encrypted in the store and never shown again.
4. Run **Test connection**. It lists every tool the upstream advertises and how the
   profile classifies each one. Anything under "not in the policy" is denied by
   default — report that list rather than assuming it is fine.

## Full human walkthrough

## 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

1. In the DigitalOcean control panel: **API → Tokens → Generate New Token**.
2. Name it `prodpeek`, set an expiry, and choose **Read only** — not Full Access.
3. Copy the token.
4. In Prodpeek: **Services → Add a service → DigitalOcean**, paste the token, and
   point the URL at the area you want first (`apps`, `droplets`, …).
5. 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.
6. **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.