The same audited API — for machines too
Connect claude.ai or ChatGPT to your org over MCP, or teach a coding agent the CLI. Every call — human, connector, or agent — rides the identical role-gated API: reads are free, writes are plan-first, and the one genuinely destructive operation is never covered by auto-apply — unless explicitly approved, it parks for an ADMIN to review. There is no privileged AI-only path.
Connect claude.ai or ChatGPT
The MCP endpoint is one URL: https://cp.sproobo.com/mcp. Add it as a connector and Sproobo handles the rest over OAuth 2.1 — no key to copy and paste.
Add the connector
Paste https://cp.sproobo.com/mcp into claude.ai's or ChatGPT's connector settings. The client discovers everything else itself: Sproobo's protected-resource and authorization-server metadata documents (RFC 9728 / RFC 8414) at its .well-known endpoints, then registers itself as a public OAuth client on the fly (RFC 7591 dynamic client registration — unauthenticated but rate-limited, and it can only mint a public client, never a client secret).
Sign in
You're redirected to sign in to Sproobo (if you aren't already), then to a one-screen consent page naming the connecting client and asking which of your organizations it should act in.
Approve, scoped to your role
Approving mints the connector a token pair — a 1-hour access token and a 30-day refresh token, both rotating — bound to your account in that org. It can do only what you personally can do there: reads free, writes plan-first, nothing above your own role.
Revoke anytime
Team & Access → Connectors lists every connected client (name, connecting user, token prefix, created, last used). An ADMIN can revoke any row on the spot — immediately and irreversibly; the client must reconnect and consent again.
Every authorization grant uses PKCE (S256) — a stolen authorization code is useless without the verifier. Refresh tokens rotate on every use; presenting one that was already used is treated as a theft signal and revokes that entire token lineage, not just the one token. Both /oauth/register and /oauth/token are rate-limited per client/IP.
Resolving a connector's OAuth access token looks up your live org role on every call — a role change or removal takes effect on your very next call, not at the token's next refresh. See Team, orgs & billing for minting a scoped sk_ API key instead — a longer-lived credential better suited to CI or a single script than an interactive connector.
The tool catalog: three tiers
Every tool call — human, sk_ key, or connector token — passes through the same role gate the dashboard uses. Three autonomy tiers, matching exactly what's registered:
Reads — always free
| Tool | What it returns | Min role |
|---|---|---|
| list_servers | The org's servers (id, name, status). | VIEWER |
| list_apps / get_app | Apps, and one app's detail. | VIEWER |
| list_services / get_service | Backing services. | VIEWER |
| list_deployments / get_deployment / tail_deployment | Deployment history, and a live build/deploy log tail. | VIEWER |
| list_backups | Backup tasks. | VIEWER |
| list_secrets | Secret/env var NAMES only — never values. | VIEWER |
| diagnose | Fused health read for a server, service, or app — the composite that replaces chaining five separate reads by hand. | VIEWER |
| whoami | The org and role this credential resolves to. | VIEWER |
| tail_logs | Live container logs off a running server (round-trips to the agent). | MEMBER |
tail_logs is the one exception at MEMBER rather than VIEWER — it's the only “read” that reaches out to a live agent rather than reading only what the control plane already has stored.
Writes — plan-first
A write call without approve:true never mutates anything — it returns a typed PLAN (a one-line summary of what applying it would do). Re-issue the identical call with approve:true to apply it.
| Tool | What it does | Min role |
|---|---|---|
| deploy_app | Off-box build + blue-green swap + health gate + auto-rollback. | MEMBER |
| rollback_app | Roll back to a specific prior release. | MEMBER |
| safe_rollback | Roll back to the confirmed last-good release — no release id needed. | MEMBER |
| provision_and_deploy_app | Create an app (apex+www ingress + cert) on a server and deploy it, in one call. | MEMBER |
| create_service | Provision a new backing service. | MEMBER |
| set_secret / set_secrets / delete_secret | Set one, bulk-set many (one atomic write), or delete an app secret. | MEMBER |
| set_app_tag | Set or clear an app's internal label. | MEMBER |
| reconnect_app_github | Re-link (or unlink) an app's GitHub App installation. | MEMBER |
| enroll_server | Register a new server and return its bootstrap one-liner. | ADMIN |
enroll_server also refuses a resource-scoped key outright, even an ADMIN one — it creates a brand-new server, and a key already scoped to one server or project has nothing existing to expand it against. Only an unscoped key can call it, the same rule the CLI's own sproobo enroll enforces.
Destructive — always human-approved
Exactly one tool is destructive, and the non-destructive auto-apply opt-in below never covers it:
| Tool | What it does | Min role |
|---|---|---|
| upgrade_service | In-place major-version engine swap, restored from a verified backup that's resolved server-side — never passed in the call's arguments. | ADMIN |
Called without approve:true, it parks as a pending approval: the dashboard's AI approvals page lists it for any ADMIN to review the exact arguments and Apply or Reject — applying re-runs the identical audited tool, no privileged bypass.
Plan-first mechanics
- Reads run immediately; they never mutate anything.
- Non-destructive writes default to plan-first. A key minted in the dashboard can opt into auto-applying non-destructive writes — connector (OAuth) tokens never get this opt-in, only an sk_ key minted with it explicitly. Passing approve:true on the call itself applies it immediately regardless of that opt-in.
- The key-level auto-apply opt-in never covers destructive writes — only an explicit approve:true on the call itself (from a sufficiently privileged caller) applies one. The safe pattern — and what the CLI and the agent skill both follow — is to submit the plan-only call and let it park for a human to review, rather than passing approve:true without the human explicitly asking for that exact destructive action in the moment.
Same identity, same audit trail
Every applied AI/MCP write is tagged actorType: ai in the org's audit log, sitting right alongside the human dashboard actions and CLI writes it's interleaved with — nothing about the record's shape marks it as second-class or hides it from an audit export. Every write also carries a correlation id (an idempotency key); reusing it on a retried call replays the stored result instead of re-applying, so a flaky network retry from an agent can't double-deploy or double-write a secret.
MCP-native clients
A tool that already speaks MCP — an IDE, another agent runtime — doesn't need the connector OAuth flow at all: sproobo mcp runs a stdio bridge to your org using the CLI's own stored credential, and sproobo mcp config prints the client-config JSON snippet to wire it in. Same tool catalog, same role gate, same audit trail as everything above.
Next
- Scoped sk_ API keys and the four org roles — Team, orgs & billing.
- Teach a coding agent to drive the CLI directly inside your repo — The Agent Skill.
- Every command the skill (and you) can run — CLI reference.