Hostinger MCP

Hostinger MCP — Operational Skill

Managing 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. See references/installation.md.

Tool names match the upstream package. The catalog and workflows use the official hostinger-api-mcp tool names. Always treat the live mcp__hostinger*__* tools as the source of truth if Hostinger changes them (see "Versioning and source of truth" below).

Quick Route

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.

Safety rules (read before every operation)

1. 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".

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

Confirmation pattern

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.

Multi-account — working with multiple Hostinger accounts

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).

Rules

• Identify the account before every operation. Single account connected → use it. Multiple → determine which from the request; if unclear, stop and ask. If a resource name unambiguously identifies one account you may infer, but state which account you're operating on.
• IDs don't cross accounts. A VM/domain/subscription ID from one connection is valid only against that connection. Never pass it to another.
• Never reuse a token across accounts. Each connection has its own HOSTINGER_API_TOKEN; don't assume the same token works elsewhere.
• Per-account confirmation. A write confirmation on one account never applies to another — each write on a new account gets a fresh confirmation block (including the account line).
• Cross-account reads are fine. For broad "which account owns example.com?" questions, run the same read on each connection separately and tag each result with the account name. Never run a broad write across accounts without individual confirmation for each.

Authentication — quick overview

• HOSTINGER_API_TOKEN (default). A Bearer token generated in hPanel, passed to the MCP server via env. This is the standard path.
• OAuth 2.0 PKCE (interactive alternative). Available on stdio transport only, via 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.

Versioning and source of truth

• Tool names match the upstream package. The tool names and categories here are taken from the official hostinger-api-mcp package.
• The live MCP wins if Hostinger changes them. If a tool name or capability differs from what's documented, the live mcp__hostinger*__* tools connected in Claude are the source of truth — check them and update the catalog accordingly.
• Every write tool goes through the confirmation pattern. W = single confirmation; W! = double-confirmation for destructive ops (any *delete*, VPS_recreateVirtualMachineV1, DNS_resetDNSRecordsV1 on production), per references/tools-catalog.md. Money-spending ops additionally require cost-confirmation.