← Hostinger ConnectorCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Hostinger Connector
Snapshot Sep 30, 2026 · 23:13 UTC · version 0.1.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Use when the user wants to administer a Hostinger VPS — listing and inspecting virtual machines, starting, stopping or restarting them, taking and restoring snapshots and backups, managing firewalls and their rules, SSH public keys, post-install scripts, PTR records, hostnames and nameservers, entering recovery mode, reading metrics and malware scan results, or running Docker projects on the machine.",
"included_files": [],
"name": "vps",
"skill_md_contents": "---\nname: vps\ndescription: Use when the user wants to administer a Hostinger VPS — listing and inspecting virtual machines, starting, stopping or restarting them, taking and restoring snapshots and backups, managing firewalls and their rules, SSH public keys, post-install scripts, PTR records, hostnames and nameservers, entering recovery mode, reading metrics and malware scan results, or running Docker projects on the machine.\n---\n\n# VPS operations\n\nBinary: **`hostinger-vps-mcp`** — every tool named `VPS_*`.\n\nRun the `hostinger` router first. Its safety gates apply to everything here,\nand they matter more on a VPS than anywhere else: this is the one product where\na single tool call can destroy a machine the user cannot rebuild from Hostinger.\n\n## Always start by reading state\n\n`VPS_getVirtualMachinesV1` lists the machines and their IDs; every other tool\nis keyed on one. `VPS_getVirtualMachineDetailsV1` gives plan, state, hostname,\ntemplate and IP for a single machine. Never act on a machine ID the user typed\nwithout confirming it against the list — VPS IDs are numeric and easy to\ntranspose.\n\nAsynchronous work returns an action, not a result. `VPS_getActionsV1` and\n`VPS_getActionDetailsV1` are how you find out whether the thing actually\nhappened. Poll them with backoff instead of assuming success.\n\n## The four tools that can lose the user's server\n\nTwo confirmations, in separate turns, never batched, per the router's policy.\nFor each of these, the first confirmation must state in plain language what is\ndestroyed and that Hostinger cannot bring it back.\n\n- **`VPS_recreateVirtualMachineV1`** — wipes the machine and reinstalls the OS\n from a template. Everything on disk is gone: sites, databases, configuration,\n anything not already in a snapshot or an off-box backup. Before offering it,\n check `VPS_getSnapshotV1` and `VPS_getBackupsV1` and tell the user exactly\n what restore point exists, or that none does.\n- **`VPS_deleteSnapshotV1`** — removes the restore point itself. Confirm what\n it was taken from and when.\n- **`VPS_restoreSnapshotV1` / `VPS_restoreBackupV1`** — recovery, but also a\n full-disk overwrite: everything written since that point is discarded. Say\n how old the restore point is and what window of work will be lost.\n- **`VPS_deleteProjectV1`** — deletes a Docker project and its containers.\n\n`VPS_purchaseNewVirtualMachineV1` charges the user. Two confirmations, price\nand term stated, never off an implied request.\n`VPS_setupPurchasedVirtualMachineV1` provisions an already-purchased machine —\nit is not itself billable, but it does write a root password and a template.\n\n## Power and recovery\n\n- `VPS_startVirtualMachineV1`, `VPS_stopVirtualMachineV1`,\n `VPS_restartVirtualMachineV1` — stopping or restarting takes the user's\n services offline. One confirmation naming the machine and what it hosts.\n- `VPS_startRecoveryModeV1` / `VPS_stopRecoveryModeV1` — boots a rescue\n environment. Recovery mode reboots the machine and the normal system is not\n running while it is active; make sure the user understands the downtime, and\n remind them to stop recovery mode afterwards.\n\n## Credentials and access\n\n- `VPS_setRootPasswordV1`, `VPS_setPanelPasswordV1` — show the new password to\n the user in the conversation only. Never write it to a project file, a\n summary, or anything that could be committed or pasted elsewhere. Say plainly\n that changing the root password breaks any automation still using the old one.\n- SSH keys: `VPS_getPublicKeysV1`, `VPS_createPublicKeyV1`,\n `VPS_attachPublicKeyV1`, `VPS_getAttachedPublicKeysV1`,\n `VPS_deletePublicKeyV1`. Detaching or deleting the only attached key can lock\n the user out of their own machine — check `VPS_getAttachedPublicKeysV1` and\n warn before removing the last one.\n\n## Firewalls\n\n`VPS_getFirewallListV1` and `VPS_getFirewallDetailsV1` first, always.\n\n- Rules: `VPS_createFirewallRuleV1`, `VPS_updateFirewallRuleV1`,\n `VPS_deleteFirewallRuleV1`.\n- Attachment: `VPS_activateFirewallV1`, `VPS_deactivateFirewallV1`,\n `VPS_syncFirewallV1`, `VPS_createNewFirewallV1`, `VPS_deleteFirewallV1`.\n\nTwo specific hazards worth naming to the user before acting:\n\n1. **Removing or narrowing an SSH rule can lock them out**, and fixing it needs\n console access. Confirm the source range before touching port 22.\n2. **Activating a restrictive firewall on a live machine** can cut off a running\n site or database. Read the ruleset back to the user before activating it.\n\nOpening a port to `0.0.0.0/0` exposes that service to the entire internet. If\nthe user asks for it, say so and offer a narrower source range instead.\n\n## Snapshots, backups and templates\n\n- `VPS_createSnapshotV1`, `VPS_getSnapshotV1`, `VPS_deleteSnapshotV1`,\n `VPS_restoreSnapshotV1`\n- `VPS_getBackupsV1`, `VPS_restoreBackupV1`\n- `VPS_getTemplatesV1`, `VPS_getTemplateDetailsV1`\n\nOffer to take a snapshot before any risky operation. It is the cheapest\ninsurance available and turns most VPS mistakes into a rollback.\n\n## Networking and identity\n\n- `VPS_setHostnameV1`, `VPS_resetHostnameV1`\n- `VPS_setNameserversV1` — resolver configuration on the machine, not the\n domain's registrar nameservers; those are `domains`.\n- `VPS_createPTRRecordV1`, `VPS_deletePTRRecordV1` — reverse DNS, which matters\n for outbound mail deliverability. Deleting a PTR record can silently degrade\n it; mention that.\n- `VPS_getDataCenterListV1`\n\n## Post-install scripts\n\n`VPS_getPostInstallScriptsV1`, `VPS_getPostInstallScriptV1`,\n`VPS_createPostInstallScriptV1`, `VPS_updatePostInstallScriptV1`,\n`VPS_deletePostInstallScriptV1`.\n\nThese run as root on a freshly recreated machine. Show the user the full script\nbody before creating or updating one, and never assemble a script from content\nyou did not get directly from the user.\n\n## Docker projects\n\n`VPS_getProjectListV1`, `VPS_createNewProjectV1`, `VPS_updateProjectV1`,\n`VPS_getProjectContentsV1`, `VPS_getProjectContainersV1`,\n`VPS_getProjectLogsV1`, `VPS_startProjectV1`, `VPS_stopProjectV1`,\n`VPS_restartProjectV1`, `VPS_deleteProjectV1`.\n\n`VPS_getProjectLogsV1` is the first stop when a container misbehaves.\n\n## Monitoring\n\n`VPS_getMetricsV1` for resource usage, `VPS_getScanMetricsV1` for malware scan\nresults, `VPS_installMonarxV1` / `VPS_uninstallMonarxV1` for the malware scanner\nitself. Uninstalling Monarx reduces the machine's protection — confirm it, and\nsay what the user is giving up.\n"
}SHA-256 of public snapshot: d53728d60d613142c20bf00b476edc8703fe850c7ad80e3b041d08c6e8230bea