Install
openclaw skills install @benkalsky/hostinger-mcpOperational guide for managing Hostinger infrastructure — VPS, websites/hosting, domains, DNS, email marketing (Reach), and billing — via the official Hostinger MCP server (npm hostinger-api-mcp), across one or several Hostinger accounts. Use whenever the user mentions Hostinger, hPanel, a Hostinger VPS, a Hostinger-hosted site, Hostinger domains/DNS, domain purchase/transfer/lock, Hostinger email/Reach contacts, or Hostinger billing/subscriptions. Any write operation (create/update/delete/recreate a VPS, change firewall/DNS, purchase a domain or VPS, change a subscription or payment method, deploy/import a site) requires explicit confirmation of the target resource and intended action — and the cost, for money-spending operations — before execution.
openclaw skills install @benkalsky/hostinger-mcpManaging Hostinger infrastructure — VPS, hosting, domains, DNS, Reach, billing — through the official Hostinger MCP server.
Connection / tool loading: This skill targets the official Hostinger MCP server, which runs as a LOCAL npm process (
hostinger-api-mcp, Node.js v24+) — not a hosted URL. The server exposes 127 tools split across category binaries. Load only the category binaries you need for the task — do not load all 127 tools at once. The binaries:
hostinger-vps-mcp— 62 (VPS)hostinger-hosting-mcp— 22 (websites/hosting)hostinger-domains-mcp— 18 (domains)hostinger-reach-mcp— 10 (email marketing)hostinger-dns-mcp— 8 (DNS)hostinger-billing-mcp— 7 (billing)hostinger-api-mcp— all 127 (everything; use only when a task genuinely spans categories)Default to the smallest set covering the task. A pure DNS edit needs only
hostinger-dns-mcp(8 tools), not the full 127. Seereferences/installation.md.Tool names match the upstream package. The catalog and workflows use the official
hostinger-api-mcptool names. Always treat the livemcp__hostinger*__*tools as the source of truth if Hostinger changes them (see "Versioning and source of truth" below).
| Intent | Load |
|---|---|
| Initial installation/configuration of the MCP server | references/installation.md |
| Don't know which tool exists / searching for a tool by name | references/tools-catalog.md |
| VPS operations (create, firewall, snapshot, recreate, etc.) | references/workflows-vps.md |
| Multiple Hostinger accounts / multi-account configuration | references/installation.md (Multi-account section) |
Load only what's needed. Match the binary to the task (see Connection above), and don't load the full catalog just to "list my VPSes" — call VPS_getVirtualMachinesV1 directly.
Identify the account first (multi-account). Each Hostinger account is a separate MCP connection with its own prefix (mcp__hostinger-<account>__*). Resource IDs are NOT interchangeable between accounts — VM ID 123456 in account A is a different resource (or nonexistent) in account B. Before every call, verify which account it belongs to. If it's unclear which account is meant, stop and ask — don't guess, and don't run across all of them "to be safe".
Write operations require explicit confirmation. Before any write tool, present: the account, the tool name, the target resource (ID + name), the parameters, and the expected impact. Wait for an explicit "yes". One confirmation ≠ blanket consent for further operations, and a confirmation on one account never carries to another.
Money-spending operations require cost-confirmation. domains_purchaseNewDomainV1, VPS_purchaseNewVirtualMachineV1, enabling billing auto-renewal, and billing_setDefaultPaymentMethodV1 spend real money (now or on the next renewal). Confirm the cost AND the account before executing.
Destructive operations double-confirm (W!). Any *delete* tool, VPS_recreateVirtualMachineV1 (reinstalls the OS, wipes all data), and DNS_resetDNSRecordsV1 on production require confirmation of both the operation and the specific target.
Multiple workloads per VPS. A single VPS may host several sites/services. VPS_stopVirtualMachineV1, VPS_restartVirtualMachineV1, and VPS_recreateVirtualMachineV1 affect everything on it. Make the user aware of what runs on the VM before any VPS-level operation.
Credentials. Each account uses its own HOSTINGER_API_TOKEN — full account access, with no per-tool permission at the MCP layer. Never print the token in responses. If the user asks to see it, refer them to hPanel.
Read-only by default. For "show / check / list", pick the read-only tool (e.g. VPS_getVirtualMachinesV1, domains_getDomainListV1, DNS_getDNSRecordsV1). Never suggest a destructive operation unless explicitly asked.
Before executing a write, present a block like this:
🔒 Confirm operation?
Account: clientA (mcp__hostinger-clientA-vps)
Tool: VPS_recreateVirtualMachineV1
Target: vps-prod-01 (ID: 123456)
Impact: reinstalls the OS and WIPES ALL DATA on the VM
Proceed? (yes / no / check for a snapshot first)
For money-spending operations, add an Estimated cost: line:
🔒 Confirm operation?
Account: clientA (mcp__hostinger-clientA-domains)
Tool: domains_purchaseNewDomainV1
Target: example.co.il (new registration)
Estimated cost: <price> for <term>
Impact: charges the account's default payment method
Proceed? (yes / no)
Wait for an explicit "yes" — implied consent is not enough. The account line is mandatory when more than one account is connected; it prevents executing on the wrong account.
Token-per-connection. Each account connects as a separate MCP connection with its own HOSTINGER_API_TOKEN, and appears in Claude with its own prefix:
mcp__hostinger-clientA__VPS_getVirtualMachinesV1
mcp__hostinger-clientB__domains_getDomainListV1
mcp__hostinger-clientA-dns__DNS_getDNSRecordsV1
Name each connection hostinger-<account> — or, when loading per-category binaries, hostinger-<account>-<category> (e.g. hostinger-clientA-vps, hostinger-clientA-dns).
HOSTINGER_API_TOKEN; don't assume the same token works elsewhere.HOSTINGER_API_TOKEN (default). A Bearer token generated in hPanel, passed to the MCP server via env. This is the standard path.hostinger-api-mcp --login.The token has full account access — every action the account can perform in hPanel. There is no granular / per-tool permission at the MCP layer: any connected client can call any tool. Treat it like a password and never print it in responses. If the user asks to see it, refer them to hPanel.
Never put a token's value on a command line when helping a user set this up. It lands in their shell history, is visible in ps to every other user on the machine while the command runs, and claude mcp add then stores the resolved value in ~/.claude.json in plaintext. Pass a quoted placeholder instead — -e 'HOSTINGER_API_TOKEN=${HOSTINGER_API_TOKEN:-}' — and keep the value in the environment Claude Code starts with; Claude Code expands it at launch. See "Handling the token safely" in references/installation.md, which also covers the OAuth credential file and what to do if a token may have been exposed (revoke and regenerate in hPanel — nothing narrower exists).
For the full connection and multi-account setup, see references/installation.md.
hostinger-api-mcp package.mcp__hostinger*__* tools connected in Claude are the source of truth — check them and update the catalog accordingly.*delete*, VPS_recreateVirtualMachineV1, DNS_resetDNSRecordsV1 on production), per references/tools-catalog.md. Money-spending ops additionally require cost-confirmation.