Skip to main content
Glama
hostkey-cloud

hostkey-mcp-server

Official
by hostkey-cloud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

reinstall_server

Destructive

Reinstall the operating system on an existing server, erasing all disk data. Requires confirmation and hostname verification; async status via check_task.

Instructions

Reinstall OS on an existing server (simplified path via eq/order_instance with id). DESTRUCTIVE: all disk data will be erased. Requires HOSTKEY_ALLOW_DESTRUCTIVE=1 in the server environment, confirm=true, and re-entering the server's current hostname. Async: status via check_task.

Input Schema

NameRequiredDescriptionDefault
idYesServer ID
os_idYesNew OS ID from list_os (0 + own_os=1 — no OS install)
own_osNo1 — do not install OS
confirmYesRequired (=true) to start reinstall
soft_idNoSoftware ID from list_software
ssh_keyNoPublic SSH key for root
hostnameYesCurrent server hostname — confirms the correct server is selected
root_passYesNew root password
deploy_notifyNo
post_install_scriptNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.0.3
    • changedInput schema / properties / confirm / description
      Previous value: -"Обязателен (=true) для запуска переустановки"New value: +"Required (=true) to start reinstall"
    • changedInput schema / properties / hostname / description
      Previous value: -"Текущий hostname сервера — служит подтверждением, что сервер выбран верно"New value: +"Current server hostname — confirms the correct server is selected"
    • changedInput schema / properties / id / description
      Previous value: -"ID сервера"New value: +"Server ID"
    • changedInput schema / properties / os_id / description
      Previous value: -"ID новой ОС из list_os (0 + own_os=1 — без установки ОС)"New value: +"New OS ID from list_os (0 + own_os=1 — no OS install)"
    • changedInput schema / properties / own_os / description
      Previous value: -"1 — не устанавливать ОС"New value: +"1 — do not install OS"
    • changedInput schema / properties / root_pass / description
      Previous value: -"Новый пароль root"New value: +"New root password"
    • changedInput schema / properties / soft_id / description
      Previous value: -"ID ПО из list_software"New value: +"Software ID from list_software"
    • changedInput schema / properties / ssh_key / description
      Previous value: -"Публичный SSH-ключ для root"New value: +"Public SSH key for root"
  2. First observedv1.0.1

TDQS

A4.3/5.0
Behavior5/5

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

Goes well past the destructiveHint annotation by spelling out that all disk data is erased, the required environment flag, the confirm gate, the hostname-matching safeguard, and the asynchronous execution model with check_task polling. This is exactly the extra context an agent needs before firing a destructive operation.

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?

Three tight sentences: action first, then the destructive warning, then prerequisites and async handling. No filler, and the riskiest information is surfaced early.

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

Completeness5/5

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

For a destructive, non-idempotent, no-output-schema tool, the description covers impact, gating requirements, and result-checking path. Nothing material is missing 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 coverage is 80%, so most parameters are already documented. The description reinforces confirm and hostname semantics but adds little syntax or format detail (e.g., os_id/own_os interaction, ssh_key vs root_pass) beyond the schema.

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

Purpose4/5

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

States a specific verb+resource ('Reinstall OS on an existing server') and notes the simplified implementation path. It does not explicitly contrast with the sibling create_reinstall_task, but the destructive reinstall action is unmistakable.

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 concrete preconditions for invocation (HOSTKEY_ALLOW_DESTRUCTIVE=1, confirm=true, re-entering the current hostname) and routes to check_task for status. It stops short of stating when to prefer this over create_reinstall_task.

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