Is it safe to let an AI agent provision real infrastructure?

Yes, with scoped tokens. Issue a token with the narrowest scope the agent needs (e.g. services:read for monitoring agents, services:write only when you genuinely want it to create resources), set a low rate-limit-rpm, and set an expiry. You can revoke any token from the dashboard and it stops working at once.

Can I use this with an MCP server?

Yes. We ship a first-party MCP server (@rarecloudio/mcp-server) that wraps the API with first-class tools, so an agent can read and manage your infrastructure through Claude Code, Claude Desktop or Cursor. A generic HTTP MCP server that lets you set request headers can also call our /v1/* endpoints with a Bearer token. Pin the agent to a single token + low scope so a prompt-injection attack can't escalate.

What about budget runaway, what if the agent provisions 100 servers?

Two safeguards: (1) your account limits cap how much can run at once, and new accounts can only create what their balance covers for a month; (2) per-token rate limits cap the number of mutating calls per minute. Set token-level guardrails; trust agents like you'd trust an intern.

Using a VPS API from AI agents (Claude, Cursor, your own)

AI coding agents are no longer just generating files in your editor. They run tools, search the web, edit code, execute shells, and increasingly: provision infrastructure. Claude Code can terraform apply, Cursor can call out to APIs, your own agent built on the Anthropic SDK can do whatever you give it tools to do.

If your VPS provider has a clean API, this means the agent can:

Spin up a new VPS for a temporary task and tear it down
Snapshot before a deploy and roll back if a test fails
Read invoice + credit data to summarize cost trends
Reset a stuck server, attach a volume, rotate an IP

RareCloud's API was designed with agent use cases in mind. This guide explains the shape and the safety story.

The API surface in one paragraph

Every endpoint is under https://api.rarecloud.io/v1/*. Auth is Authorization: Bearer rc_pat_.... Responses are { "ok": true, "data": ... } on success, { "ok": false, "error": { "code": "...", "message": "..." } } on failure. Errors carry stable machine-readable code fields so agents can branch on them.

OpenAPI spec lives at https://console.rarecloud.io/openapi.json. Feed it to your agent as a tool definition and you get auto-generated tools for every endpoint.

Token scopes that matter for agents

Don't issue a full-access token to an agent. Issue scoped tokens:

Catalog is public, no token or scope needed to read products, plans, regions and images. A "what could we deploy" agent can read pricing with no credentials at all.
services:read, list and inspect existing services. Safe for monitoring / status-summary agents.
services:write, create, modify, destroy services. Powerful. Issue with a low rate limit and a short expiry.
billing:read, read invoices, credit balance, payment history. Safe for cost-analysis agents.
billing:write, top up credit, change payment methods. Almost never give this to an agent.
account:read, profile, contact info. Mostly safe.
account:write, change profile, change passwords. Almost never give this to an agent.

For a "deploy a test VPS, run my test suite, tear it down" agent, the right token scopes are services:read and services:write (the catalog is public, so no scope is needed to read plans). Nothing else. Scopes match exactly: services:write does not include services:read, and the agent needs both to create a server and then check on it.

Common patterns

Pattern 1: query before action

Agents reason better when they see ground truth. Before any services:write call, the agent should query services:read to confirm the current state matches its mental model.

1. GET /v1/services                  → see what exists
2. GET /v1/catalog/listings/cloud-vm  → see what's available
3. POST /v1/services                 → create with chosen plan
4. GET /v1/services/{id}             → confirm it provisioned

If the OpenAPI spec is loaded as the agent's tool catalog, this flow tends to happen on its own: agents read before they write when the read tool is available.

Pattern 2: short-lived, least-privilege tokens

Mint a token scoped to exactly what the run needs, give it an expiry, and cap its request rate. You do this in the console (Account → API tokens): token management needs a signed-in dashboard session, so an agent holding a token can never mint itself a stronger one. Every token carries a list of scopes, an optional expiry date and a rate limit from 1 to 600 requests a minute (the default is 60). When the run finishes, revoke it.

A token that can only touch services, only for an hour, only ten calls a minute, is a small blast radius even if the agent gets hijacked.

Pattern 3: confirm the cost before committing

Put the confirmation in the agent loop. Have it look up the chosen plan's price from the (public) catalog, ask the API whether the order would go through, show the user exactly what it's about to create and what it will cost, and only POST after approval.

GET  /v1/catalog/listings/cloud-vm  → read the price of the chosen plan
POST /v1/services/preflight         → same body as the order: would it be accepted?
[agent shows "will create a g-2vcpu-8gb server, €14.99/month" to the user]
[user approves]
POST /v1/services                  → actually does it

POST /v1/services/preflight runs the same balance check as the real order as a dry run: nothing is created, held or charged. When the answer is no, it says why (an unpaid invoice, a balance that does not cover the first month) and, where it applies, gives the add-funds or pay-invoice link for the human. It needs services:write, the same scope as the order it previews.

Pattern 4: retry without duplicates

Networks drop. If a POST /v1/services times out, the agent cannot know whether the server was created. Send an Idempotency-Key header on every create, a fresh value per operation (a UUID is ideal), and send the same value again when retrying the same request. The API runs it at most once and answers the retry with the original result, marked Idempotent-Replayed: true. Keys are kept for 24 hours. A one-time secret from the first answer, such as a console password, is not repeated in the replay.

Two more signals worth wiring in: a 429 or a 503 BACKEND_UNAVAILABLE comes with a Retry-After header, so wait that many seconds before trying again (for a create, with the same key). Some creates finish in the background: a load balancer answers at once with status pending and needs a few minutes, so the agent should poll GET /v1/load-balancers/{id} until it is active rather than create another one.

Pattern 5: fence off what agents must not touch

In the console, any single resource (a server, a cluster, a volume, a domain) can have its API access switched off. Tokens and agents can still list and read it, but every change, and every read of its credentials, is refused with 403 RESOURCE_PROTECTED. Objects carry apiAccess (full or read_only), and GET /v1/api-access lists the read-only ones in one call, so an agent can check before it plans. Only a signed-in human can turn access back on: no token can flip the switch.

Hooking up with an MCP server

The Model Context Protocol (MCP) is the standard way to give agents access to tools. There are two paths:

First-party RareCloud MCP: we ship @rarecloudio/mcp-server with first-class tool definitions for the API surface, and it handles the patterns above for you: check_order before a deploy, an idempotency key on every create, and tools that spend or delete refuse to run until the user confirms. This is more ergonomic than the generic fetch path because the tool descriptions are tuned for LLM consumption (with examples, error shapes, and best-practice notes baked in). Drop it into Claude Code, Claude Desktop or Cursor, give it a scoped token, and the agent can read and manage your infrastructure.

Generic HTTP MCP: alternatively, an MCP server that can send HTTP requests with custom headers can call our API. Configure it with the Bearer token and the agent can call anything in the OpenAPI spec. (A plain URL fetcher that cannot set an Authorization header only reaches the public catalog.)

Safety: the budget runaway problem

The headline fear: "what if the agent provisions 100 servers and I owe €10,000?"

Four layers of defense:

Account limits. Every account has resource limits (vCPU, RAM, instances, volumes), so a runaway loop hits a wall long before it reaches 100 servers. A new account also prepays: until it has made two payments and is at least 38 days old, its balance has to cover the first month of everything it runs plus the new order, so on a new account an agent cannot order more than the balance covers. Cloud servers are billed by the hour, and a month never costs more than their monthly price. And you hear about it early: a spending alert flags the month in the console when spend passes the amount you set, and a credit alert emails you when your balance covers fewer days than the number you choose.
Per-token rate limits. Each token has a rateLimitRpm (default 60 requests/min); you can set it as low as you like for a purely passive monitoring agent. The limit is counted per API area (services, billing and so on), and mutations count against it too, so a runaway loop is bounded in throughput, not just in spend.
Scoped, expiring, revocable tokens. A services:write token can't touch billing or your account. Give it an expiry, and revoke it the instant a run looks wrong; revocation takes effect immediately.
Read-only resources. Switch API access off for the resources that matter most and no token can change them, whatever its scopes.

Combined, whatever an agent with a services:write token does when it goes off the rails is bounded by your limits, visible in the audit log, and deletable.

If you're building an agent against our API today, open a support ticket from your dashboard. Your feedback shapes the roadmap.