Skip to main content
Glama
Sign In
VPSnet

VPSnet

by bacarrdy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Reinstall OS

reinstall_os
Destructive

Reinstalls the operating system on a VPS or dedicated server using a selected OS version, requiring explicit confirmation because it erases existing data and snapshots.

Instructions

Reinstall OS on a VPS or qualified dedicated server. WARNING: destroys existing data; confirm with the user before reinstalling. Cloud VPS and Firecracker VPS: reinstall also deletes existing snapshots, so they cannot provide rollback after reinstall. Read get_os_options.snapshotDeletion first; when snapshots exist, set confirmSnapshotDelete to true only after the user explicitly confirms their deletion. A pending snapshot action blocks reinstall until it finishes. Container VPS has no snapshots. Dedicated servers erase every disk and have no snapshot rollback; get_os_options reports dedicated=true and confirmRequired=true. Pass confirmReinstall=true only after the user explicitly approves reinstalling that exact dedicated server and losing all disk data. Use an account public sshKey ID from list_ssh_keys or an optional rootPassword, never both. If neither is supplied, a dedicated server reuses its installed key when available; otherwise VPSnet generates a password. Password rules: 6-40 chars, alphanumeric, uppercase + lowercase + digit. Dedicated reinstall returns a reinstall job ID. VPS reinstall returns a noty UUID for acceptance; follow get_service_history for completion. Acceptance is not completion. OAuth requires services:reinstall; API keys require full access.

Input Schema

NameRequiredDescriptionDefault
sshKeyNoAccount public SSH key ID from list_ssh_keys. Mutually exclusive with rootPassword. Dedicated: omitted reuses the installed key when one exists.
orderNoYesTenant-owned service order number: 1-64 ASCII letters, digits or hyphens, e.g. VP12345 or VP12345-1
osVersionYesOS version ID from get_os_options
rootPasswordNoNew root password for VPS or dedicated reinstall; mutually exclusive with sshKey. Omit to reuse a dedicated server's installed key when available, otherwise the backend generates a password. 6-40 chars, alphanumeric, uppercase + lowercase + digit.
confirmReinstallNoDedicated only: true only after explicit user approval to reinstall this exact server and erase all its disks; never inferred or defaulted.
confirmSnapshotDeleteNoCloud VPS and Firecracker VPS only: set true only after the user explicitly confirms deletion of the existing snapshots shown by get_os_options.snapshotDeletion. They cannot provide rollback after reinstall. Never inferred or enabled automatically.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.3.19
    • changedInput schema / properties / rootPassword / description
      Previous value: -"New root password (auto-generated if omitted). 6-40 chars, alphanumeric, must contain uppercase + lowercase + digit"New value: +"New root password for VPS or dedicated reinstall; mutually exclusive with sshKey. Omit to reuse a dedicated server's installed key when available, otherwise the backend generates a password. 6-40 chars, alphanumeric, uppercase + lowercase + digit."
    • changedInput schema / properties / sshKey / description
      Previous value: -"Dedicated only: account SSH key ID from list_ssh_keys; omitted reuses the installed key."New value: +"Account public SSH key ID from list_ssh_keys. Mutually exclusive with rootPassword. Dedicated: omitted reuses the installed key when one exists."
  2. First observedv2.3.16

TDQS

A4.9/5.0
Behavior5/5

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

Although annotations already mark the tool destructive, the description adds crucial detail beyond them: existing data is destroyed, snapshots may be deleted, dedicated servers erase every disk, snapshots cannot roll back after reinstall, and acceptance is not completion. It also discloses OAuth/API key permission requirements and the difference between dedicated and VPS return behavior.

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

Conciseness4/5

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

The description is front-loaded with purpose and the destructive warning, and most sentences carry operational value. It is dense and somewhat long, with minor repetition around data loss and password rules that the schema already documents, but the complexity of a destructive reinstall justifies most of the detail.

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?

There is no output schema, yet the description explains the return shapes: dedicated reinstall returns a job ID, VPS reinstall returns a noty UUID, and completion must be tracked separately. Combined with permission requirements, server-type distinctions, and dependency tools, it gives the agent enough context to call the tool correctly.

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

Parameters5/5

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

Schema coverage is 100%, but the description still adds meaningful cross-parameter and workflow semantics: sshKey and rootPassword are mutually exclusive, omitted credentials have different fallback behavior on dedicated servers, and the confirmation flags must never be inferred. It also explains that osVersion comes from get_os_options and ties confirmSnapshotDelete to get_os_options.snapshotDeletion.

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 first sentence states a specific verb and resource: "Reinstall OS on a VPS or qualified dedicated server." It immediately distinguishes applicable server types and makes clear this is not a generic update or provisioning action. An agent can identify the operation without opening the schema.

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

Usage Guidelines5/5

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

The description gives explicit preconditions and routing: read get_os_options.snapshotDeletion first, use list_ssh_keys for SSH keys, and follow get_service_history for completion. It explains when confirmSnapshotDelete and confirmReinstall are required and when reinstall is blocked by a pending snapshot action.

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