Skip to main content
Glama
krovacloud

@krovacloud/mcp

Official
by krovacloud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create Cube

create_cube
Destructive

Provision a new Cube in a Krova Cloud Space with specified vCPU, RAM, disk, and SSH key. Starts hourly billing upon creation.

Instructions

Create (provision) a new Cube in a Space. Provisioning is asynchronous — the returned Cube begins in a pending state. Destructive/billable: creating a Cube starts hourly billing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesHuman-readable Cube name.
vcpuYesNumber of virtual CPUs. Default per-space cap is 16 (can be raised for your space).
imageYesOS image slug (see the list_images tool for valid values).
ramGbYesRAM in whole GiB. Default per-space cap is 32 GB (can be raised for your space).
diskGbYesDisk in GiB — minimum 10, in steps of 5. Default per-space cap is 100 GB (can be raised for your space).
regionNoOptional region slug (see the list_regions tool). Omit to let Krova Cloud auto-select a region with capacity.
spaceIdNoKrova Cloud Space id. Optional if KROVA_SPACE_ID is set as the server default.
userDataNoOptional cloud-init script (max 16 KiB).
sshPublicKeyYesSSH public key written to the Cube login user's authorized_keys at boot — ~/.ssh/authorized_keys for the ubuntu or debian user, /root/.ssh/authorized_keys on Cubes created before the default-user change. Use get_cube_ssh to learn which user a given Cube logs in as. Must start with ssh-ed25519, ssh-rsa, ecdsa-sha2-*, ssh-dss, or sk-*@openssh.com.
terminationProtectionNoOpt this Cube out of customer-initiated deletion. When true, `delete_cube` is rejected with 409 until you call `unprotect_cube`. Power-off, wake, restart, snapshot, and restore remain allowed regardless. Default false when omitted — agents must opt in deliberately.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.9
    • addedInput schema / properties / terminationProtection
      Added value: +{
+  "description": "Opt this Cube out of customer-initiated deletion. When true, `delete_cube` is rejected with 409 until you call `unprotect_cube`. Power-off, wake, restart, snapshot, and restore remain allowed regardless. Default false when omitted — agents must opt in deliberately.",
+  "type": "boolean"
+}
  2. First observedv0.3.6

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes beyond the annotations by disclosing that provisioning is asynchronous and the Cube starts in a pending state, and that it begins hourly billing. These are valuable behavioral details not captured in the annotations, and they align with destructiveHint=true.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with zero fluff. It front-loads the core purpose, then packs essential behavioral and cost warnings into the second sentence. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description explains the asynchronous return state, addressing the outcome. It also flags billable side effects. It doesn't discuss permissions or how to monitor pending progress, but combined with schema and annotations it is sufficiently complete for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 10 parameters thoroughly. The description adds no parameter-specific meaning, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create (provision) a new Cube in a Space' with a specific verb and resource, making the tool's purpose unambiguous. It is obviously distinct from sibling tools like delete_cube or create_snapshot, even without naming them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by defining what the tool does and adds relevant context about asynchronous provisioning and billing, but it does not explicitly compare with alternatives or state when not to use it. This is adequate but not explicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools