# Hostinger MCP

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

- Skill: `digitizers/hostinger-mcp` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add digitizers/hostinger-mcp`
- Raw SKILL.md: https://api.skillmd.com/api/skills/digitizers/hostinger-mcp/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- License: MIT
- Author: digitizers (https://skillmd.com/u/digitizers)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/digitizers/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

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

---

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