Bring your agent.

Add the DanubeData MCP server to Claude Code, with a token made for the agent in place of YOUR_TOKEN:

claude mcp add --transport http danubedata "https://danubedata.ro/mcp" --header "Authorization: Bearer YOUR_TOKEN"

Type /mcp in Claude Code: danubedata should show Connected. Cursor, VS Code, Codex and OpenCode take the same address; their configuration is on the MCP server page.

Then ask in plain language:

Create a PostgreSQL database called agent-db in fsn1 on the smallest plan. Wait until it is ready, then give me its connection endpoint. Do not print the password.

The agent finds the plan with database_plans, starts the database with database_create, and polls database_get until status_details.operation.terminal is true. Each tool call is one API request made with your token, so the token's abilities are the limit.

Install the current DanubeData CLI:
npm install -g @danubedata/cli

Use the scoped API token already present in DANUBE_TOKEN. Never print it or write it to a file.

Create this small stack, keeping --json on every command:
danube database create --name agent-db --provider postgresql --datacenter fsn1 --profile <available-profile> --database-name app --json
danube cache create --name agent-cache --provider valkey --datacenter fsn1 --profile <available-profile> --json
danube storage buckets create --name agent-assets --region fsn1 --versioning --json

After every command, parse { success, data, error, meta }. If success is false, branch on error.code and error.retryable instead of parsing prose.

Database and cache creation return resource receipts before those services are ready. Poll both resources by repeating:
danube database get agent-db --json
danube cache get agent-cache --json

For each resource, read status_details.operation.terminal. If it is false, wait five seconds and poll again. Never infer completion from a status string; treat an unknown state as still running. When terminal is true, require operation.state to be succeeded before using the resource. If it failed, stop and report the structured error.

If another command returns a separate operation ID, run:
danube operations wait <operation-id> --json
Continue only when terminal: true.

Only after the database and cache operations have succeeded, print their connection endpoints and the bucket endpoint. Treat credentials as secrets and do not persist them.

Use the API token already present in DANUBEDATA_API_TOKEN. Never embed it in Terraform configuration.

Create Terraform configuration with the published provider:

terraform {
  required_providers {
    danubedata = {
      source  = "AdrianSilaghi/danubedata"
      version = "~> 0.3"
    }
  }
}

provider "danubedata" {}

Consult the provider registry for the current schemas, then declare one danubedata_database, one danubedata_cache, and one danubedata_storage_bucket. Do not guess resource attributes.

Run:
terraform init
terraform plan

Stop and show me the plan for approval. Do not run terraform apply until I explicitly approve the plan. After approval, apply exactly the reviewed configuration.