Skip to main content
Glama
Sign In
hcloud-mcp

hcloud-mcp

by Xodus-CO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

create_storage_box_subaccount

Create a restricted storage box subaccount with a separate login limited to a chosen home directory and shared quota, then poll the action until completion.

Instructions

Create a subaccount: a separate login restricted to home_directory inside the box (shares the box's quota). Username is assigned by Hetzner (-subN). Returns {subaccount: {id, storage_box}, action}; Returns an Action; poll get_storage_box_action until status is success, then get_storage_box_subaccount for details

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>",
      "home_directory": "<home_directory>",
      "password": "<password>"
    },
    "name": "create_storage_box_subaccount"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesStorage Box ID
nameNoDefaults to the generated username
labelsNo
passwordYesPassword policy: 12-128 chars from a-z A-Z ÄÖÜäöüß 0-9 ^°!§$%/()=?+#-.,;:~*@{}_& with at least one upper case letter, lower case letter, digit and special character; must not appear in known data breaches. Generate a strong random one; never echo it back to the user unless they asked for it
descriptionNo
home_directoryYesHome directory relative to the main account root, e.g. "backups/app1". Created if missing
access_settingsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.1

TDQS

A4/5.0
Behavior4/5

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

Annotations only declare write/openWorld/non-idempotent; the description adds the crucial async behavior (an Action must be polled to completion) and the server-side username assignment the caller cannot control. It omits permission requirements and whether the subaccount login is immediately usable after the action succeeds.

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

Conciseness3/5

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

Purpose is correctly front-loaded, but the return-value statement is duplicated and self-inconsistent ('Returns {subaccount: {id, storage_box}, action}; Returns an Action'), and the whole thing is one run-on sentence with semicolon chaining that obscures the ordering of follow-up steps.

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?

For a 7-parameter, nested-object creation tool with no output schema, the description covers the essential gaps: what gets created, automatic naming, async completion, and the retrieval step. Missing only credential/permission prerequisites and whether default access settings apply when access_settings is omitted.

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 coverage is 57%, and the description mainly clarifies the generated-username behavior that interacts with the optional 'name' parameter and the home_directory scoping. labels, description, and the access_settings flags are left entirely to the schema, so the description only partially compensates for the coverage gap.

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?

States a specific verb and resource ('Create a subaccount') and immediately defines what that resource is: a separate login scoped to home_directory that shares the box's quota. It also discloses that the username is server-assigned with a recognizable pattern (<box-username>-subN), which distinguishes this from creating a top-level storage box.

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

Usage Guidelines4/5

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

Gives explicit post-invocation workflow: the call returns an Action, so poll get_storage_box_action until status is success, then call get_storage_box_subaccount for details. It does not name when to prefer this over siblings such as update_storage_box_subaccount_access_settings, but the create-vs-update distinction is clear from the verb.

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