Introducing the DanubeData MCP Server: Your AI Agent, Connected to Your Cloud

DanubeData now runs an MCP server. Connect Claude Code, Cursor, VS Code, Codex or OpenCode with an API token, and your agent can create, inspect and fix real infrastructure through typed tools: nearly every operation of the API, limited by the token you give it.

Adrian Silaghi

6 min read

8 views

mcpmodel-context-protocolai-agentsclaude-codecursorcodexvs-codeopencodeapilaunch

AI coding agents are good at infrastructure work, until they have to learn your cloud. Every new session starts the same way: read the API docs, guess at the request shapes, get a 422, try again. A customer asked us for exactly that: typed, discoverable tools, so an agent knows what it can do the moment it connects.

That is what we are launching today. DanubeData now runs an MCP server, open to every account. Point your agent at one address and it gets nearly every operation of the DanubeData API as a typed tool, with nothing to install.

What it is

MCP, the Model Context Protocol, is how AI clients such as Claude Code, Cursor, VS Code, Codex and OpenCode discover and call tools. Our server lives at https://danubedata.ro/mcp, speaks Streamable HTTP, and takes an API token as a bearer header.

Behind it is the same public API you already use. The tools are generated from the specification that also drives our API reference, so a new endpoint becomes a tool as soon as it ships. Today that means tools such as vps_create, database_list, storage_buckets_create and operations_get, a couple of hundred in all, grouped into toolsets such as VPS, databases, caches, object storage, Rapids containers, static sites, snapshots, firewalls and monitoring.

Connect your client

Create an API token for the agent on Security, API tokens, then add the server. In Claude Code:

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

Type /mcp in Claude Code and danubedata should show Connected. Cursor, VS Code, Codex and OpenCode take the same address; the MCP server page has every client's configuration, ready to copy.

Signed in, it is even shorter: the AI agents card on Security, API tokens creates the token, lets you choose the tools, and writes the configuration for your client.

Ask for the outcome

Once connected, you describe what you need and the agent finds the tools:

  • "Create a PostgreSQL database for staging and tell me when it is ready." The agent picks a plan with database_plans, starts the database with database_create, and polls database_get until the operation is finished.
  • "Why does my Rapids container keep restarting?" serverless_diagnose correlates status, revisions, events and logs into findings with a suggested fix.
  • "Snapshot the production database before I run the migration." One call to snapshots_database_create.
  • "Which of my servers is nearly idle right now?" vps_list, then vps_metrics for each, which reads its current usage.

Every answer from the API starts with the HTTP status and the API path, such as 201 Created · POST /api/v1/database, followed by the API's own JSON. When a call is refused, the result says what to do next: a 404 names the tool that lists the valid IDs, and a 422 names the fields to fix. The agent does not have to guess what happened.

Your token is the boundary

The MCP server adds no powers of its own. Each tool call is an API call made with the token you give the agent, so the agent can do exactly what that token can do, and nothing more.

  • Scope the token. Lock it to one project and tick only the abilities the job needs. A token with vps:read but not vps:write can look at servers and cannot change them.
  • Make it read-only. Add read_only=1 to the address and the server enforces it: tools that change something are not listed and cannot be called.
  • Load only what the task needs. ?toolsets=vps,database lists only those groups, which also keeps the tool list short for clients that send every tool with each request.
  • Mind what the model sees. Everything a tool returns reaches the model your client uses. Leave the password abilities, such as database:credentials, off the token unless the agent has to read passwords. A Rapids container's environment variables come back with their values to any token that can read or change the container, so keep secrets the agent should not see out of them, or leave both serverless:read and serverless:write off its token. Tools that return a password, a key, a connection string, environment values or logs say so in their description.
  • Retry without duplicates. Tools for routes that accept an idempotency key take an idempotency_key argument, so a retried create replays the first answer instead of making a second resource.

Good to know

  • It costs nothing on its own. Most tools need a payment method on file for the project; without one, a call answers 402 and says so. What an agent creates is billed like anything you create yourself, by the hour, and each tool call counts as one request against your project's API rate limit.
  • OAuth-only clients cannot connect yet. Custom connectors in claude.ai and ChatGPT sign in through OAuth; the server takes an API token for now.
  • A few things stay outside MCP. Uploading a ZIP to deploy a container or a static site build is a job for the danube CLI, and partner sub-accounts are managed through the REST API.

Get started

The MCP server is open to every account today. Read the setup guide, see the MCP server page, or create an account, add a payment method and connect your agent. We would love to hear what you build with it.

Browse all articles

Ready to get started?

Deploy your infrastructure in minutes with DanubeData's managed services.