Hostinger Connector

View saved version →

---
name: domains
description: Use when the user wants to work with domain names or DNS at Hostinger — checking availability and buying a domain, reading domain details and renewal dates, changing nameservers, setting up forwarding, managing registrar lock, WHOIS privacy and WHOIS contact profiles, getting an authorization code for a transfer, and reading, editing, validating, resetting or restoring DNS records.
---

# Domains and DNS

This skill spans **two** binaries. They are separate installs and separate tool
groups; loading one does not give you the other.

| Binary | Covers |
| --- | --- |
| `hostinger-domains-mcp` | registration, nameservers, forwarding, lock, privacy, WHOIS, transfers |
| `hostinger-dns-mcp` | DNS zone records and snapshots |

If the user's request touches both — "point my new domain at my site" — say up
front that both binaries are needed, and stop if only one is loaded rather than
half-completing the task.

Run the `hostinger` router first. Its safety gates apply to everything here.

## Buying a domain — the one billable path

`domains_purchaseNewDomainV1` charges the user. It requires the router's
two-confirmation billable gate, and it must never run off an implied request.
"Get my site online" is not permission to buy a domain; suggest the free
`*.hostingersite.com` subdomain from `websites` first and let the user
choose.

1. `domains_checkDomainAvailabilityV1` — check the exact name.
2. State the **price and the term** to the user, and the fact that domain
   registrations are generally non-refundable.
3. First confirmation, naming the domain and the price.
4. Second confirmation in a separate turn.
5. `domains_purchaseNewDomainV1` needs a WHOIS profile — see below.

## WHOIS profiles

Registries require registrant contact data. `domains_createWHOISProfileV1`
stores it; `domains_getWHOISProfileListV1` and `domains_getWHOISProfileV1` read
it back; `domains_getWHOISProfileUsageV1` shows which domains use a profile.
`domains_setWHOISProfileAsDefaultV1` marks one as the default for future
purchases, per TLD; `domains_unsetDefaultWHOISProfileV1` clears that. Setting a
default means later purchases silently reuse those contact details — say which
profile you are making the default, and never set one the user has not seen.

This is personal data — a real name, address, email and phone. Collect only
what the registry requires, take it from the user directly, and never copy it
into project files, commits or summaries. `domains_deleteWHOISProfileV1` fails
or orphans domains if the profile is still in use, so check usage first.

`domains_enablePrivacyProtectionV1` hides those details from public WHOIS;
`domains_disablePrivacyProtectionV1` exposes them again. Disabling is a privacy
regression — say so explicitly and get a confirmation, even though nothing is
destroyed.

## Reading state

- `domains_getDomainListV1` — every domain on the account.
- `domains_getDomainDetailsV1` — status, expiry, nameservers, lock and privacy
  state for one domain. Run this before changing anything.
- `domains_getDomainRenewalInformationV1` — renewal date and pricing.
- `v2_getDomainVerificationsDIRECT` — domain verification records.

## Nameservers, forwarding and lock

- `domains_updateDomainNameserversV1` — **this is the highest-blast-radius tool
  in the skill.** Pointing nameservers away from Hostinger takes the domain's
  entire DNS zone out of service: website, email, everything. Show the current
  nameservers from `domains_getDomainDetailsV1`, spell out what will stop
  resolving, and confirm before changing them. Propagation takes up to 24–48
  hours and is not instantly reversible.
- Forwarding: `domains_getDomainForwardingV1`,
  `domains_createDomainForwardingV1`, `domains_updateDomainForwardingV1`,
  `domains_deleteDomainForwardingV1`.
- Registrar lock: `domains_enableDomainLockV1`, `domains_disableDomainLockV1`.
  The lock exists to prevent unauthorised transfers. **Disabling it is a
  security downgrade** — only do it as a deliberate step in a transfer the user
  is actively performing, and offer to re-enable it afterwards.

## Transfers

`domains_getDomainAuthorizationCodeV1` returns the EPP/auth code that lets
another registrar take the domain. Treat it as a secret: show it to the user in
the conversation, never write it to a file, and never include it in a summary.
Track incoming transfers with `domains_getTransferListV1` and
`domains_getTransferV1`.

## DNS records

Read first: `DNS_getDNSRecordsV1`. Validate before you commit:
`DNS_validateDNSRecordsV1` checks a record set without applying it — use it on
every non-trivial change, because a bad zone is a live outage.

`DNS_updateDNSRecordsV1` applies changes. Be explicit with the user about what
each record does, and remember that TTL governs how long a mistake persists in
resolver caches.

### Snapshots are the safety net — use them

`DNS_getDNSSnapshotListV1` and `DNS_getDNSSnapshotV1` read historical zone
states; `DNS_restoreDNSSnapshotV1` rolls back to one. **Take stock of the
current snapshot list before any destructive record change**, and tell the user
which snapshot they can roll back to. This turns an outage into a two-minute
fix.

### The two destructive DNS tools

Both need two confirmations, never batched:

- `DNS_deleteDNSRecordsV1` — removes specific records. Name each record being
  deleted, with its type and value, not "the selected records".
- `DNS_resetDNSRecordsV1` — discards the entire zone and returns it to
  Hostinger defaults. This will break custom mail routing (MX, SPF, DKIM,
  DMARC), verification records for third-party services, and any subdomain
  pointing elsewhere. State that plainly, list what is currently in the zone,
  and confirm the snapshot the user can restore from before running it.

Restoring a snapshot is itself a full-zone overwrite. It is the recovery path,
but it discards every change made since that snapshot — confirm it the same way.

View saved version →

---
name: ecommerce
description: Use when the user wants a Hostinger online store — creating a store, adding physical or digital products, setting flat-rate shipping, enabling a manual payment method, checking whether the store is ready to take orders, and creating or updating a custom sales channel so a frontend you built can serve the catalog and a hosted checkout. Not for WooCommerce, which is a WordPress plugin.
---

# Ecommerce

Binary: **`hostinger-ecommerce-mcp`** — every tool named `ecommerce_*`.

Run the `hostinger` router first. Its safety gates apply to everything here.

**This is a Hostinger store, not WooCommerce.** WooCommerce is a WordPress
plugin and is managed through the WordPress tools in `websites`. If the user has
a WooCommerce site and asks for products, they mean that one — say so rather than
creating a second, unrelated store here.

## Order of operations

The steps depend on each other, and doing them out of order produces a store
that looks finished but cannot take an order:

1. `ecommerce_getStoresV1` — **check for an existing store first.** Never create
   a second store for an account that already has one unless the user says
   that is what they want.
2. `ecommerce_createStoreV1` — creates the store and a primary sales channel
   alongside it.
3. Products: `ecommerce_createPhysicalProductV1` or
   `ecommerce_createDigitalProductV1`. Each creates a published product with a
   single variant. A digital product takes an optional external download link.
4. `ecommerce_setStoreShippingV1` — flat-rate shipping, creating the zone if it
   does not exist. **Physical products need this**; without it a customer cannot
   complete checkout. Digital products do not.
5. `ecommerce_enableManualPaymentMethodV1` — lets the store accept orders without
   an online payment provider. See the warning below.
6. `ecommerce_getStoreMetadataV1` — readiness check: whether payment methods and
   shipping are configured, plus the default currency. **Run this before telling
   the user the store is live**, and report what it says rather than assuming.

## Currency and prices

Products are priced in the **store currency**, which comes from
`ecommerce_getStoreMetadataV1`. Read it before creating a product — a price
entered against the wrong currency is a live mispricing that customers can order
against. Confirm the currency with the user when creating the first product.

## Manual payment is not online payment

`ecommerce_enableManualPaymentMethodV1` means the store accepts an order and the
merchant collects money **some other way** — a bank transfer, cash on delivery,
an invoice. Nothing is charged automatically. Say that explicitly when enabling
it, because "payments enabled" reads as "customers can pay by card" and it does
not. Connecting a real payment provider happens in hPanel, not through these
tools.

## Custom sales channels — for a frontend you built

A custom sales channel is how a separately deployed frontend serves the store's
catalog while checkout, orders and shipping stay with Hostinger.

- `ecommerce_listSalesChannelsV1` — existing channels and their metadata.
- `ecommerce_createCustomSalesChannelV1` — create one for a frontend you built.
- `ecommerce_updateSalesChannelV1` — change the merchant-facing `name` and the
  public `url`, which is returned as the channel's `domain`.
- `ecommerce_getCustomStorefrontSetupInstructionsV1` — **read this before writing
  any frontend code.** It returns the actual, current integration steps as
  Markdown. Follow them rather than reconstructing an integration from memory;
  the contract can change and the instructions are authoritative.

The channel `url` must be the address the storefront is really served from. A
mismatch breaks the checkout hand-off, which fails at the worst possible moment —
after the customer has picked something.

## Products are published immediately

Both create tools produce a **published** product. There is no draft state here,
so a product created to try something out is publicly visible and orderable the
moment it exists. Confirm name, price and currency before creating, and do not
create throwaway test products on a store that is taking real orders.

## The destructive one

`ecommerce_deleteStoreV1` soft-deletes a store: the underlying data is preserved
but the store is marked deleted, which takes the storefront and its checkout
offline. Two confirmations, never batched. Name the store, say what stops working
— the storefront, any custom sales channel pointing at it, and the ability to
take orders — and say that undoing it is a support request, not a tool call.

## Full tool list

Stores: `ecommerce_getStoresV1`, `ecommerce_createStoreV1`,
`ecommerce_getStoreMetadataV1`, `ecommerce_deleteStoreV1`

Products: `ecommerce_createPhysicalProductV1`,
`ecommerce_createDigitalProductV1`

Checkout: `ecommerce_setStoreShippingV1`,
`ecommerce_enableManualPaymentMethodV1`

Sales channels: `ecommerce_listSalesChannelsV1`,
`ecommerce_createCustomSalesChannelV1`, `ecommerce_updateSalesChannelV1`,
`ecommerce_getCustomStorefrontSetupInstructionsV1`

View saved version →

---
name: email-marketing
description: Use when the user wants to work with Hostinger Reach, their email marketing product — listing and creating contacts, importing contacts in bulk, organising them into groups, building segments with custom criteria, reading segment membership, listing marketing profiles, and checking whether a sending domain's MX, SPF, DKIM and DMARC records are configured. Not for mailboxes or reading mail.
---

# Email marketing (Reach)

Binary: **`hostinger-reach-mcp`** — every tool named `reach_*`.

Run the `hostinger` router first. Its safety gates apply to everything here.

This is **marketing contacts and segments**, not email hosting. Creating a
mailbox, forwarding, or an autoreply is a different product and is not covered by
any skill in this plugin — say so rather than reaching for another binary.

## Start from the profile

Everything is scoped to a Reach profile. `reach_listProfilesV1` lists them; take
the identifier from there rather than guessing, and if there are several, ask
which one before writing anything.

`reach_getProfileDomainDNSStatusV1` reports the MX, SPF, DKIM and DMARC state for
the profile's sending domain. **Check this before the user sends anything to a
real list** — a domain missing SPF or DKIM gets its mail filtered as spam, and
that damages the domain's reputation in a way that is slow to undo. Fixing the
records themselves is the `domains` skill.

## Reading contacts, groups and segments

- `reach_listContactsV1` — paginated, filterable by group and subscription
  status. Respect the subscription status: an unsubscribed contact is a request
  the user is legally obliged to honour, not a row to work around.
- `reach_listContactGroupsV1` — groups the contacts are organised into.
- `reach_listSegmentsV1`, `reach_getSegmentDetailsV1` — segments and one
  segment's definition.
- `reach_listSegmentContactsV1`, `reach_listProfileSegmentContactsV1` — who is
  actually in a segment. Use these to show the user the size and shape of an
  audience *before* they act on it.

## Personal data — the constraint that shapes this whole skill

Contacts are named people with email addresses, and in many jurisdictions that
is regulated personal data. Treat it accordingly:

- **Never write contact data into project files, commits, deploy archives, or a
  summary that could be pasted elsewhere.** Show it in the conversation to the
  user who asked, and nowhere else.
- **Never import a list the user cannot account for.** Before
  `reach_createNewContactsV1`, ask where the addresses came from and confirm the
  people consented to marketing email. If the answer is a scraped list, a
  purchased list, or "found it somewhere", decline and say why: it is a legal
  problem for the user and it will burn their sending domain.
- **Never invent contacts.** Do not fabricate names or addresses to fill out a
  test, and do not derive an address from a pattern (`firstname@company.com`).
- **Do not enrich.** Adding data about a contact from another source is not what
  the user asked for and is exactly what data protection rules restrict.

## Writes

- `reach_createANewContactV1` — one contact. Read back the name, email and group
  before creating it.
- `reach_createNewContactsV1` — bulk. State **how many** contacts, which group
  they land in, and where the list came from, then take one confirmation. A bulk
  import is the highest-volume write in this skill; a mistake here is visible to
  every recipient.
- `reach_createANewContactSegmentV1` — a segment definition. Show the criteria in
  plain language and say roughly who it will match; a criterion the user misread
  means the wrong audience gets the next campaign.

## The destructive one

`reach_deleteAContactV1` **permanently removes a contact** from the email
marketing system, by UUID. Two confirmations, never batched:

1. First names the contact — email address and name, resolved from
   `reach_listContactsV1`, not the raw UUID the user pasted. State that the
   contact and their history cannot be restored.
2. Second in a separate turn.

Never delete more than one contact per approval, and never carry an approval
forward to another contact. If the user wants a contact to stop receiving mail,
unsubscribing is usually what they mean — check before deleting.

## Full tool list

Profiles: `reach_listProfilesV1`, `reach_getProfileDomainDNSStatusV1`

Contacts: `reach_listContactsV1`, `reach_createANewContactV1`,
`reach_createNewContactsV1`, `reach_deleteAContactV1`,
`reach_listContactGroupsV1`

Segments: `reach_listSegmentsV1`, `reach_createANewContactSegmentV1`,
`reach_getSegmentDetailsV1`, `reach_listSegmentContactsV1`,
`reach_listProfileSegmentContactsV1`

View saved version →

---
name: hostinger
description: Start here for any task involving the user's Hostinger account — deploying a site, managing hosting and PHP, running WordPress, buying or configuring domains and DNS records, or administering a VPS. This skill connects the Hostinger MCP server, signs the user in, sets the safety rules that every Hostinger action follows, and hands off to the specialist skill that owns the task.
---

# Hostinger — router

You are a coding agent with shell access. This skill gets the session to a
known-good, connected, authenticated state and then routes to a specialist. It
does not perform Hostinger operations itself.

**You do the setup, not the user.** Run the phases below yourself. The user
should only ever have to do two things: restart the app once if servers had to
be added, and click **Allow** in the browser once to sign in. Never hand them a
list of commands to run.

Skip straight to Routing when a Hostinger tool call has already succeeded in
this session.

## Phase 0 — Node

The Hostinger MCP server requires **Node 20 or newer**.

```bash
node -v
```

If that errors or reports below 20, tell the user how to fix it and stop — do
not work around it:

- macOS: `brew install node`, or `nvm install 22 && nvm use 22`
- Linux: `nvm install 22 && nvm use 22`, or the distribution's Node 20+ package
- Windows: `winget install OpenJS.NodeJS.LTS`

## Phase 1 — Is every Hostinger server registered?

Do **not** decide this from the tools the current task happens to need. Check
whether all nine Hostinger servers are registered, by reading the config:

```bash
grep -o 'mcp_servers\.hostinger-[a-z-]*' ~/.codex/config.toml | sort -u
```

The names are `hostinger-hosting`, `hostinger-wordpress`,
`hostinger-agency-hosting`, `hostinger-domains`, `hostinger-dns`,
`hostinger-vps`, `hostinger-ecommerce`, `hostinger-reach`, `hostinger-billing` —
nine at the time of writing, and the package may have added more since. See
*MCP binaries* at the end for how to check.

- **All nine present** → go to Phase 3.
- **Any missing** → Phase 2, and register *every* missing one, not just the one
  this task needs.

Do not substitute shell commands or direct API calls for a missing tool.

## Phase 2 — Register all of them at once

Register the Hostinger MCP servers in the shared Codex MCP configuration. The
ChatGPT desktop app, Codex CLI and the IDE extension all read the same config, so
this is done once per machine.

**Register all nine, in one pass, even when the task needs one.** New servers
are only picked up when the host restarts. Registering just what the immediate
request needs means the user restarts again the next time they ask for something
in a different area — deploy, then domains, then a store, a restart each time.
That is the single worst thing this skill can do to them. One write, one restart,
everything works from then on.

Never tell the user "I added the missing module, restart and ask again" more than
once in the life of a machine. If you find yourself about to, you registered too
narrowly the first time.

**Preferred path — `codex` CLI.** It is often not on `PATH` even when a Codex
host is installed. On macOS the ChatGPT desktop app bundles it at
`/Applications/ChatGPT.app/Contents/Resources/codex`. Look in both places:

```bash
command -v codex || ls /Applications/ChatGPT.app/Contents/Resources/codex
```

If you find it, add every server that Phase 1 reported missing:

```bash
for g in hosting wordpress agency-hosting domains dns vps ecommerce reach billing; do
  codex mcp add "hostinger-$g" \
    --env "USER_AGENT=plugin;codex;openai-plugin;0.1.0" \
    -- npx --package=hostinger-api-mcp@latest "hostinger-$g-mcp"
done
```

`npx --package=` resolves the binary out of the package at launch, so nothing has
to be installed globally. Do not run `npm install -g` and do not escalate with
`sudo`. Adding a server that already exists may error — that is harmless, keep
going with the rest.

`USER_AGENT` is appended to the `User-Agent` header the server sends to the
Hostinger API, and it is how Hostinger attributes traffic to the client it came
from. Set it on every block you create. Keep the value exactly as written above,
and never overwrite a different `USER_AGENT` that another Hostinger client
already put in the config.

**Fallback — edit the config directly.** Only when `codex` cannot be found
anywhere. Prefer the CLI whenever it exists: it makes a surgical edit, while
hand-editing risks damaging a file the user's other tools depend on.

The file is `~/.codex/config.toml` (`%USERPROFILE%\.codex\config.toml` on
Windows). **Back it up first**, and tell the user where the backup is:

```bash
cp ~/.codex/config.toml ~/.codex/config.toml.bak
```

Then **append only**. These rules are absolute:

- Add a block **only** for a server name that is not already in the file.
- If a `[mcp_servers.hostinger-*]` block already exists, **leave it byte for
  byte alone** — even when it looks different from the example below, has extra
  keys, or seems wrong. Other Hostinger tooling writes keys this skill does not
  know about, such as `enabled` and a `USER_AGENT` used for attribution, and
  dropping them silently breaks things elsewhere.
- Never normalise, reformat, reorder, or re-emit existing blocks to match the
  example. The example is a template for **new** blocks only.
- Never delete a block, and never touch a `[mcp_servers.*]` entry for a
  non-Hostinger server.

```toml
[mcp_servers.hostinger-hosting]
command = "npx"
args = ["--package=hostinger-api-mcp@latest", "hostinger-hosting-mcp"]
enabled = true

[mcp_servers.hostinger-hosting.env]
PATH = "<the value of $PATH in this shell>"
```

**The `env.PATH` line is not optional.** The host spawns MCP servers with a
minimal environment that often does not include the directory holding `node` and
`npx`, so a server registered without it starts and immediately dies with
`npx: command not found`. Read the current `PATH` with `echo $PATH` and write
that literal value in. Setting `env` replaces the inherited environment for that
server rather than extending it, so `PATH` has to be spelled out in full. Every
block you add needs its own `.env` — do not add a server without one.

**Verify the edit did not lose anything.** Before telling the user to restart,
compare the block headers against the backup:

```bash
diff <(grep '^\[mcp_servers' ~/.codex/config.toml.bak) \
     <(grep '^\[mcp_servers' ~/.codex/config.toml)
```

Every line should be an addition. If anything was **removed**, you rewrote
instead of appending: restore with
`cp ~/.codex/config.toml.bak ~/.codex/config.toml`, tell the user plainly what
happened, and use the `codex` CLI instead. Do not attempt the hand-edit a second
time.

**If the host refuses the tool count.** All of them together expose a lot of
tools, and some hosts cap how many they will load. If that happens, do not go
back to registering one at a time — set `enabled = false` on the categories the
user does not need (`hostinger-reach`, `hostinger-billing` and
`hostinger-agency-hosting` are the usual first candidates), leave the blocks in
place, and tell the user which ones you turned off and that flipping one back on
is a config edit plus one restart. This mirrors the category toggles in the
Hostinger Connector.

Verify by reading the file back, or with `codex mcp list` if you have the CLI.

**Then ask for the one restart.** New MCP servers are picked up when the host
starts, not while it is running. Tell the user plainly which servers you added
and that the app needs a restart — in the ChatGPT desktop app, save and select
**Restart**; in the IDE extension, **Restart extension**; in the CLI, start a
new session. Say that after the restart they should repeat their original
request, and that sign-in happens on its own at that point.

Stop here. Do not claim the task is done, and do not try to work around the
missing tools in the meantime.

## Phase 3 — Sign in

Do not run a login command, and do not ask the user for a token. The server
handles OAuth itself: on the first tool call with no valid stored credentials it
opens the Hostinger sign-in page in the browser and waits.

Trigger it with a cheap read-only call — `hosting_listWebsitesV1` is a good one,
and its output you need anyway.

- **It returns data.** Already authenticated, from stored credentials or a
  `HOSTINGER_API_TOKEN` in the environment. Continue.
- **A browser window opens.** Tell the user a Hostinger consent screen has
  opened and to click **Allow**. Then wait — the call completes on its own once
  they do. Nothing else is required of them, and credentials are reused by every
  later session. The OAuth callback lands on localhost, so sign-in must finish
  on this machine.
- **It fails with an auth error and no browser opened.** Report the error
  verbatim and stop. Do not improvise a parallel setup by hand.

Expired credentials are refreshed automatically, and a dead refresh token falls
back to the same browser flow. Either way it is transparent — never pre-empt it
with a manual login step.

## Safety policy — applies to every Hostinger skill

These gates are a product decision, not a suggestion. Follow them even when the
user asks you to hurry, says they already agreed, or calls the confirmation
unnecessary. If the user applies time pressure, say plainly that the gate stays
and continue at the same pace.

**One confirmation before any write.** State the operation, the affected
resource, and the account it belongs to. "Create the subdomain `cms.example.com`
on account `u123456789`?" — not "Shall I proceed?".

**Two confirmations, never batched, for anything destructive or billable.**
Destructive means data that cannot be recovered from Hostinger: deleting a
website, database, WordPress installation, store, marketing contact, VPS
snapshot, DNS zone, or WHOIS profile; resetting DNS records; recreating a VPS.
Billable means anything that charges the user: buying a domain or a VPS, placing
or renewing an order. Also treat **disabling auto-renewal** this way — nothing is
charged, but the service lapses, and for a domain that loss is permanent. For
these:

1. First confirmation states what will be lost or charged, in plain language
   and with the specific resource named. Not "this is destructive" but
   "this permanently deletes the website `example.com` and its databases;
   Hostinger cannot restore them".
2. Second confirmation is a separate turn, after the user has answered the
   first. Never bundle several destructive operations into one approval, and
   never carry an approval forward to a different resource.

**Never purchase anything the user did not explicitly ask for by name.** A
request to "get my site online" does not authorise buying a domain or a plan.
Quote the price, name the item, and get an explicit yes.

**Read before write.** List the current state and show it to the user before
changing it. Most Hostinger tools are keyed on a `username` and a `domain` that
must come from a list call, not from a guess.

## Routing

The six specialists match the six product categories in the Hostinger
Connector, so what the user can toggle there maps one-to-one onto what a skill
can do here.

| The user wants to… | Skill |
| --- | --- |
| Deploy a site; provision hosting; manage PHP, databases, cron, caching, subdomains; install or operate WordPress; Agency Plan websites | `websites` |
| Buy, transfer, lock, or configure a domain; edit DNS records | `domains` |
| See subscriptions, auto-renewal, payment methods, prices; order or renew a product | `subscriptions-and-payments` |
| Manage marketing contacts, groups and segments in Hostinger Reach | `email-marketing` |
| Create a Hostinger store, add products, set shipping, wire a custom storefront | `ecommerce` |
| Create, snapshot, firewall, or recover a VPS | `vps` |

If a request spans two specialists — "deploy this site on a domain I want to
buy" — run them in sequence, applying each one's gates. Do not merge their
confirmations.

Two product areas have **no** skill here: **mailboxes** (creating mail accounts,
forwarders, autoreplies) and **Horizons**. If the user asks for those, say
plainly that this plugin does not cover them and point them at hPanel, rather
than improvising with another binary.

## MCP binaries

Tools reach the agent through scoped MCP servers. Each specialist names the
binaries it needs. All of them ship in the single npm package
`hostinger-api-mcp`, so every binary is reachable through one `npx --package=`
invocation:

| Binary | Used by |
| --- | --- |
| `hostinger-hosting-mcp` | `websites` |
| `hostinger-wordpress-mcp` | `websites` |
| `hostinger-agency-hosting-mcp` | `websites` (Agency Plan only) |
| `hostinger-domains-mcp` | `domains` |
| `hostinger-dns-mcp` | `domains` |
| `hostinger-vps-mcp` | `vps` |
| `hostinger-ecommerce-mcp` | `ecommerce` |
| `hostinger-reach-mcp` | `email-marketing` |
| `hostinger-billing-mcp` | `subscriptions-and-payments` |

This table is for knowing which binary holds a tool, **not** for deciding what to
register — Phase 2 registers all nine together so the user restarts once. Note
that a single skill can span several binaries: `websites` reaches into three and
`domains` needs both of its own, which is another reason not to register
piecemeal.

The unscoped `hostinger-api-mcp` exposes every group at once, including the mail
and Horizons groups no skill here covers. Prefer the scoped binaries: they keep
the tool list small enough for the host to expose in full, and some hosts cap how
many tools they will load.

**Do not treat any list here as closed.** Hostinger ships new tools regularly,
and new product groups occasionally. A tool that exists but is not named in a
skill is still a tool you should use when it fits — the lists are orientation, not
an allowlist. Conversely, a tool named in a skill may have been renamed or
removed; if a call fails because the tool does not exist, say so and adapt rather
than insisting. The authoritative list of binaries is whatever the package ships:

```bash
npm view hostinger-api-mcp bin
```

If that shows a `hostinger-<something>-mcp` this skill does not mention, it is a
product group added after this plugin was written. Register it the same way, tell
the user it exists, and treat the absence of a matching skill as a gap in the
plugin rather than a reason to avoid the product.

View saved version →

---
name: subscriptions-and-payments
description: Use when the user wants to see or manage what they pay Hostinger for — listing subscriptions and their renewal state, enabling or disabling auto-renewal, renewing a subscription, browsing the product catalog with prices, listing payment methods and setting a default, or placing an order for a Hostinger product. Every write here costs the user money or affects whether their services stay online.
---

# Subscriptions and payments

Binary: **`hostinger-billing-mcp`** — every tool named `billing_*`.

Run the `hostinger` router first. Its safety gates apply here more than
anywhere else in the product: **this is the only skill that can charge the
user's card.** Read the billable gate below before any write.

## The reading half is safe — start there

- `billing_getSubscriptionListV1` — every subscription on the account, with
  status and renewal state. This is the answer to "what am I paying for?" and
  "when does X expire?".
- `billing_getCatalogItemListV1` — orderable products and prices. **Prices are
  in cents**, as integers with no decimal point: `1099` is €10.99. Convert
  before showing a price to the user, and never quote the raw integer.
- `billing_getPaymentMethodListV1` — methods available for new orders. Show the
  last digits and type; never echo full card data even if a field contains it.

Answer read-only questions from these three and stop. Do not offer a purchase the
user did not ask for.

## The billable gate

`billing_createPurchaseOrderV1` and `billing_renewSubscriptionV1` **place real
orders against a real payment method.** `billing_createPurchaseOrderV1` is the
broadest tool in the whole Hostinger catalog — it can order any product — which
makes it the one most likely to do expensive damage from a vague request.

Before either of them:

1. `billing_getCatalogItemListV1` for the exact item and its price. Never order
   an item the user named loosely — "the cheapest plan", "whatever works" — get
   a specific catalog item first and read the name back.
2. State **item, term and total in currency**, converted from cents, plus which
   payment method will be charged from `billing_getPaymentMethodListV1`.
3. **First confirmation** naming all of that, and saying that hosting and domain
   purchases are generally non-refundable.
4. **Second confirmation in a separate turn**, after the user answers the first.
   Never batch several items into one approval, and never carry an approval
   forward to a different item, term or quantity.

Never place an order to unblock your own work. If a task stalls because a plan
or a domain is missing, say so, quote what it would cost, and stop. "Get my site
online" is not authorisation to buy anything.

## Auto-renewal — small calls, large consequences

- `billing_enableAutoRenewalV1` — future charges will happen without asking.
  Say that plainly and name the subscription and its renewal amount.
- `billing_disableAutoRenewalV1` — **the service will expire at the end of the
  current term.** For hosting that means the website goes offline; for a domain
  it means the registration lapses and the name can be taken by someone else,
  which is not reversible after the redemption window. Name the subscription and
  the date it would lapse, and confirm.

Both are one confirmation, but the confirmation has to state the consequence, not
just the toggle.

## Payment methods

- `billing_setDefaultPaymentMethodV1` — changes what future orders and renewals
  charge. One confirmation naming the method.
- `billing_deletePaymentMethodV1` — **check for dependencies first.** Removing
  the method that active auto-renewals depend on means those renewals fail
  silently and services lapse. Read `billing_getSubscriptionListV1` and
  `billing_getPaymentMethodListV1`, say which subscriptions would be left without
  a working method, and take two confirmations if any would.

Never help the user *add* a payment method through these tools — there is no tool
for it, and card details must never pass through the conversation. Point them at
hPanel.

## Handling money data

Prices are integer cents. Subscription and order responses may carry billing
identifiers and partial payment details. Show the user only what they asked for,
never write any of it into a project file or a commit, and never include it in a
summary that could be pasted elsewhere.

## Full tool list

Reads: `billing_getSubscriptionListV1`, `billing_getCatalogItemListV1`,
`billing_getPaymentMethodListV1`

Billable: `billing_createPurchaseOrderV1`, `billing_renewSubscriptionV1`

Renewal state: `billing_enableAutoRenewalV1`, `billing_disableAutoRenewalV1`

Payment methods: `billing_setDefaultPaymentMethodV1`,
`billing_deletePaymentMethodV1`

View saved version →

---
name: vps
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.
---

# VPS operations

Binary: **`hostinger-vps-mcp`** — every tool named `VPS_*`.

Run the `hostinger` router first. Its safety gates apply to everything here,
and they matter more on a VPS than anywhere else: this is the one product where
a single tool call can destroy a machine the user cannot rebuild from Hostinger.

## Always start by reading state

`VPS_getVirtualMachinesV1` lists the machines and their IDs; every other tool
is keyed on one. `VPS_getVirtualMachineDetailsV1` gives plan, state, hostname,
template and IP for a single machine. Never act on a machine ID the user typed
without confirming it against the list — VPS IDs are numeric and easy to
transpose.

Asynchronous work returns an action, not a result. `VPS_getActionsV1` and
`VPS_getActionDetailsV1` are how you find out whether the thing actually
happened. Poll them with backoff instead of assuming success.

## The four tools that can lose the user's server

Two confirmations, in separate turns, never batched, per the router's policy.
For each of these, the first confirmation must state in plain language what is
destroyed and that Hostinger cannot bring it back.

- **`VPS_recreateVirtualMachineV1`** — wipes the machine and reinstalls the OS
  from a template. Everything on disk is gone: sites, databases, configuration,
  anything not already in a snapshot or an off-box backup. Before offering it,
  check `VPS_getSnapshotV1` and `VPS_getBackupsV1` and tell the user exactly
  what restore point exists, or that none does.
- **`VPS_deleteSnapshotV1`** — removes the restore point itself. Confirm what
  it was taken from and when.
- **`VPS_restoreSnapshotV1` / `VPS_restoreBackupV1`** — recovery, but also a
  full-disk overwrite: everything written since that point is discarded. Say
  how old the restore point is and what window of work will be lost.
- **`VPS_deleteProjectV1`** — deletes a Docker project and its containers.

`VPS_purchaseNewVirtualMachineV1` charges the user. Two confirmations, price
and term stated, never off an implied request.
`VPS_setupPurchasedVirtualMachineV1` provisions an already-purchased machine —
it is not itself billable, but it does write a root password and a template.

## Power and recovery

- `VPS_startVirtualMachineV1`, `VPS_stopVirtualMachineV1`,
  `VPS_restartVirtualMachineV1` — stopping or restarting takes the user's
  services offline. One confirmation naming the machine and what it hosts.
- `VPS_startRecoveryModeV1` / `VPS_stopRecoveryModeV1` — boots a rescue
  environment. Recovery mode reboots the machine and the normal system is not
  running while it is active; make sure the user understands the downtime, and
  remind them to stop recovery mode afterwards.

## Credentials and access

- `VPS_setRootPasswordV1`, `VPS_setPanelPasswordV1` — show the new password to
  the user in the conversation only. Never write it to a project file, a
  summary, or anything that could be committed or pasted elsewhere. Say plainly
  that changing the root password breaks any automation still using the old one.
- SSH keys: `VPS_getPublicKeysV1`, `VPS_createPublicKeyV1`,
  `VPS_attachPublicKeyV1`, `VPS_getAttachedPublicKeysV1`,
  `VPS_deletePublicKeyV1`. Detaching or deleting the only attached key can lock
  the user out of their own machine — check `VPS_getAttachedPublicKeysV1` and
  warn before removing the last one.

## Firewalls

`VPS_getFirewallListV1` and `VPS_getFirewallDetailsV1` first, always.

- Rules: `VPS_createFirewallRuleV1`, `VPS_updateFirewallRuleV1`,
  `VPS_deleteFirewallRuleV1`.
- Attachment: `VPS_activateFirewallV1`, `VPS_deactivateFirewallV1`,
  `VPS_syncFirewallV1`, `VPS_createNewFirewallV1`, `VPS_deleteFirewallV1`.

Two specific hazards worth naming to the user before acting:

1. **Removing or narrowing an SSH rule can lock them out**, and fixing it needs
   console access. Confirm the source range before touching port 22.
2. **Activating a restrictive firewall on a live machine** can cut off a running
   site or database. Read the ruleset back to the user before activating it.

Opening a port to `0.0.0.0/0` exposes that service to the entire internet. If
the user asks for it, say so and offer a narrower source range instead.

## Snapshots, backups and templates

- `VPS_createSnapshotV1`, `VPS_getSnapshotV1`, `VPS_deleteSnapshotV1`,
  `VPS_restoreSnapshotV1`
- `VPS_getBackupsV1`, `VPS_restoreBackupV1`
- `VPS_getTemplatesV1`, `VPS_getTemplateDetailsV1`

Offer to take a snapshot before any risky operation. It is the cheapest
insurance available and turns most VPS mistakes into a rollback.

## Networking and identity

- `VPS_setHostnameV1`, `VPS_resetHostnameV1`
- `VPS_setNameserversV1` — resolver configuration on the machine, not the
  domain's registrar nameservers; those are `domains`.
- `VPS_createPTRRecordV1`, `VPS_deletePTRRecordV1` — reverse DNS, which matters
  for outbound mail deliverability. Deleting a PTR record can silently degrade
  it; mention that.
- `VPS_getDataCenterListV1`

## Post-install scripts

`VPS_getPostInstallScriptsV1`, `VPS_getPostInstallScriptV1`,
`VPS_createPostInstallScriptV1`, `VPS_updatePostInstallScriptV1`,
`VPS_deletePostInstallScriptV1`.

These run as root on a freshly recreated machine. Show the user the full script
body before creating or updating one, and never assemble a script from content
you did not get directly from the user.

## Docker projects

`VPS_getProjectListV1`, `VPS_createNewProjectV1`, `VPS_updateProjectV1`,
`VPS_getProjectContentsV1`, `VPS_getProjectContainersV1`,
`VPS_getProjectLogsV1`, `VPS_startProjectV1`, `VPS_stopProjectV1`,
`VPS_restartProjectV1`, `VPS_deleteProjectV1`.

`VPS_getProjectLogsV1` is the first stop when a container misbehaves.

## Monitoring

`VPS_getMetricsV1` for resource usage, `VPS_getScanMetricsV1` for malware scan
results, `VPS_installMonarxV1` / `VPS_uninstallMonarxV1` for the malware scanner
itself. Uninstalling Monarx reduces the machine's protection — confirm it, and
say what the user is giving up.

View saved version →

---
name: websites
description: Use for anything on a Hostinger hosting plan — deploying static sites and Node.js applications, provisioning websites and free subdomains, installing and operating WordPress with its plugins and themes, and managing PHP versions and extensions, MySQL databases, cron jobs, subdomains, parked domains and server-side caching. Also covers Agency Plan websites. Buying or configuring a domain name belongs to domains; a VPS belongs to vps.
---

# Websites

Everything that lives on a hosting plan. This is the largest area in the
product, and it spans **three** MCP binaries:

| Binary | Covers |
| --- | --- |
| `hostinger-hosting-mcp` | plans, websites, deploys, PHP, databases, cron, caching, subdomains |
| `hostinger-wordpress-mcp` | WordPress installs, plugins, themes, core, WP caching |
| `hostinger-agency-hosting-mcp` | Agency Plan (h5g) websites — a separate product with its own tools |

Their tools are all named `hosting_*`, `hosting_*` and
`agency-hosting_*` / `agencyHosting_*` respectively — note that the prefix does
not tell you which binary a tool is in. If a tool you need is missing, the
binary holding it is not loaded; say so rather than working around it.

Run the `hostinger` router first. Its safety gates apply to everything here.

## Pick the right product first

Ask this before anything else, because the tool sets do not overlap:

- **Regular hosting plan** — the common case. `hosting_listWebsitesV1` shows
  these. Everything in `references/SETUP.md`, `DEPLOYMENT.md` and
  `OPERATIONS.md` applies.
- **Agency Plan (h5g)** — a different product with parallel, non-interchangeable
  tools. `agency-hosting_listAgencyPlanOrdersV1` shows whether the account has
  one. See `references/AGENCY.md`. Never mix the two tool sets on one website.

## The shape of a run

1. **Plan check** — a website can only exist on an active hosting plan.
2. **Domain** — free subdomain by default, or verify a domain the user owns.
3. **Create the website** and wait for it to exist.
4. **Deploy** — static or Node.js, chosen by what the project actually is.
5. **Verify** — a 200 plus real page copy, not just a 200.

Steps 1–3 are in `references/SETUP.md`; 4–5 in `references/DEPLOYMENT.md`.
Day-two operations — PHP, databases, cron, caching, subdomains — are in
`references/OPERATIONS.md`. WordPress, including using it as a headless content
backend, is in `references/WORDPRESS.md`. Agency Plan work is in
`references/AGENCY.md`. Read the reference before running the step; the sequences
there encode failure modes that are not obvious from the tool descriptions.

## Things that will bite you

**A free subdomain is not a website.** `hosting_generateAFreeSubdomainV1`
returns a domain; deploying to it before `hosting_createWebsiteV1` fails with
`No website found for domain`. Create, then poll `hosting_listWebsitesV1` until
it appears.

**`username` is not the account email.** Almost every hosting tool is keyed on
the hosting account `username`, which comes from `hosting_listWebsitesV1`. Never
guess it, and never reuse one site's username for another.

**Static and Node.js deploys take opposite archives.**
`hosting_deployStaticWebsite` wants the *build output* with `index.html` at the
archive root. `hosting_deployJsApplication` wants the *source*, with
`node_modules/` and build output excluded, under 50 MB. Sending the wrong one
is the most common failure in this flow.

**Creation and builds are asynchronous.** `hosting_createWebsiteV1` and the
Node.js build both return before the work finishes. Poll with backoff —
websites take minutes, builds take longer. Do not report success off the
queued response.

**Three WordPress-shaped deploy tools are in the hosting binary, not the
WordPress one:** `hosting_importWordpressWebsite`,
`hosting_deployWordpressPlugin`, `hosting_deployWordpressTheme`. They are
file-upload deploys rather than WordPress management. Migrating an existing
WordPress site is a deploy and belongs here; installing WordPress fresh is in
`references/WORDPRESS.md`.

## Destructive tools

Two confirmations, never batched, per the router's policy:

- `hosting_deleteWebsiteV1` — removes the site, its files and its databases.
  Takes an explicit `confirm: true`; that flag is not a substitute for asking
  the user.
- `hosting_deleteAccountDatabaseV1` — drops the database and its remote
  connection rules.
- `hosting_deleteWordPressInstallationV1` — removes the installation and its
  content. Name the exact domain and installation.
- `agency-hosting_deleteAgencyPlanWebsiteV1`,
  `agency-hosting_deleteAgencyPlanWebsiteDatabaseV1` — same weight, see
  `references/AGENCY.md`.

Single confirmation naming the exact resource is enough for the recoverable
ones: `hosting_deleteAccountCronJobV1`, `hosting_deleteWebsiteSubdomainV1`,
`hosting_deleteWebsiteParkedDomainV1`,
`hosting_deleteDatabaseRemoteConnectionV1`,
`hosting_uninstallWordPressPluginsV1`, `hosting_uninstallWordPressThemesV1`,
`hosting_resetPHPExtensionsV1`, `agency-hosting_deleteAgencyPlanWebsiteCronJobV1`,
`agency-hosting_deleteAgencyPlanWebsiteDatabaseUserV1`.

`hosting_changeDatabasePasswordV1` is not destructive but it *is* breaking: any
site config still holding the old password stops working. Say that before
running it.

## Credentials

`hosting_createLoginLinksV1` and `hosting_getInstallationJWTTokenV1` mint
wp-admin access. `hosting_getPhpMyAdminLinkV1` mints database access. Show them
to the user who asked, never write them into a project file, and never include
them in a commit, a deploy archive, or a summary that might be pasted elsewhere.

## Full tool list — `hostinger-hosting-mcp`

Deployment: `hosting_deployStaticWebsite`, `hosting_deployJsApplication`,
`hosting_listJsDeployments`, `hosting_showJsDeploymentLogs`,
`hosting_importWordpressWebsite`, `hosting_deployWordpressPlugin`,
`hosting_deployWordpressTheme`

Node.js builds: `hosting_listNodeJSBuildsV1`,
`hosting_createNodeJSBuildFromArchiveV1`, `hosting_getNodeJSBuildLogsV1`,
`hosting_restartNode_jsApplicationV1`, `hosting_listNode_jsVulnerabilitiesV1`,
`hosting_patchNode_jsVulnerabilitiesV1`

Websites and plans: `hosting_listWebsitesV1`, `hosting_createWebsiteV1`,
`hosting_deleteWebsiteV1`, `hosting_listOrdersV1`,
`hosting_listAvailableDatacentersV1`, `hosting_generateAFreeSubdomainV1`,
`hosting_verifyDomainOwnershipV1`

Subdomains and parked domains: `hosting_listWebsiteSubdomainsV1`,
`hosting_createWebsiteSubdomainV1`, `hosting_deleteWebsiteSubdomainV1`,
`hosting_listWebsiteParkedDomainsV1`, `hosting_createWebsiteParkedDomainV1`,
`hosting_deleteWebsiteParkedDomainV1`

Databases: `hosting_listAccountDatabasesV1`, `hosting_createAccountDatabaseV1`,
`hosting_deleteAccountDatabaseV1`, `hosting_changeDatabasePasswordV1`,
`hosting_repairDatabaseV1`, `hosting_getPhpMyAdminLinkV1`,
`hosting_listDatabaseRemoteConnectionsV1`,
`hosting_createDatabaseRemoteConnectionV1`,
`hosting_deleteDatabaseRemoteConnectionV1`

PHP: `hosting_getPHPDetailsV1`, `hosting_getPHPInfoV1`,
`hosting_updatePHPVersionV1`, `hosting_updatePHPExtensionsV1`,
`hosting_updatePHPOptionsV1`, `hosting_resetPHPExtensionsV1`

Cron: `hosting_listAccountCronJobsV1`, `hosting_createAccountCronJobV1`,
`hosting_deleteAccountCronJobV1`, `hosting_getCronJobOutputV1`

Caching: `hosting_clearWebsiteCacheV1`, `hosting_toggleWebsiteCacheV1`,
`hosting_toggleCachelessModeV1`

The `hostinger-wordpress-mcp` and `hostinger-agency-hosting-mcp` tool lists are
in `references/WORDPRESS.md` and `references/AGENCY.md`.

Referenced files: 5