Manage Cubes from Claude with MCP

@krovacloud/mcp exposes Krova Cloud as a set of tools an AI agent can call over the Model Context Protocol. Once it is connected you can ask for "my running cubes", or "a 2 vCPU Ubuntu cube in US", and the client calls the API for you instead of you opening the dashboard.

The MCP server reference covers the tool surface. This page is the setup, end to end, including the two things that are easy to get wrong.

Step 1 — Create an API key

In your space, go to Space settings → API Keys → Generate key, and give it a name that says where it will live, like claude-desktop.

Copy the key immediately. It is shown once, at the moment it is created. Afterwards the dashboard only displays its prefix, and there is no way to reveal the rest — if you lose it, generate a new one and delete the old.

A key carries your own permissions in that space. Anyone holding it can act as you there, including deleting Cubes. Put it in your client's config file, not in a repository, and generate a separate key per machine so you can revoke one without disturbing the others.

Step 2 — You also need the space ID

This is the step people miss. The API key authenticates you, but it does not say which space to act on — an account can have several. Set both:

• KROVA_API_KEY — the key from Step 1.
• KROVA_SPACE_ID — the space to work in.

The space ID is in your dashboard URL: everything between the host and the next slash, e.g. https://krova.cloud/<space-id>/cubes.

Without it the server starts, connects and lists its tools quite happily — and then every call fails with "No spaceId provided and no default configured". Nothing is broken; it just does not know where to look. You can also pass spaceId per call, which is what you want if you work across several spaces.

Step 3 — Add the server to your client

MCP clients share the same shape of configuration. For Claude Desktop this goes in claude_desktop_config.json; for Claude Code and Cursor, in the equivalent MCP config for your project or user:

{
  "mcpServers": {
    "krova": {
      "command": "npx",
      "args": ["-y", "@krovacloud/mcp"],
      "env": {
        "KROVA_API_KEY": "kro_your_key_here",
        "KROVA_SPACE_ID": "your_space_id"
      }
    }
  }
}

Restart the client afterwards — most read MCP configuration only at startup. npx fetches the package on first run, so the first start is slower than later ones.

Step 4 — Check it connected

Ask the client to list your Cubes. A working connection returns your real Cubes with their status, image and hourly cost. If instead you get a general answer about what Krova is, the tools are not connected and the model is answering from memory — check the client's MCP status panel rather than rephrasing the question.

The server exposes tools across Cubes, domains, snapshots, TCP mappings, regions, images and pricing — enough to do most of what the dashboard does.

What to be careful about

The tool set includes destructive operations — delete_cube, restore_cube, delete_domain. An agent that can create a Cube can also remove one, and it is working with your permissions.

• Keep approval prompts on for tool calls, at least until you trust the setup. Read what a call will do before allowing it.
• Use a separate space for anything experimental, so the key cannot reach production Cubes at all.
• Revoke keys you are not using. Deleting a key from Space settings takes effect immediately.

Next steps

• MCP server reference — the full tool list and their arguments.
• API keys — scopes, rotation, and the REST API behind all of this.
• CLI — the same operations from a terminal, if you would rather type than ask.