Hostinger Connector

View saved version →

---
name: audit-hosting
description: "Audit a Hostinger web hosting account (Shared, Cloud and Agency plans) and report what needs attention: every plan and website, SSL problems, broken or vulnerable WordPress installs, failed Node.js builds and vulnerable npm packages, databases and Agency Plan orders near their limits, and hosting plans about to lapse. Read-only; produces a prioritised to-do list and names the skill that fixes each item. Triggers: what do I have on Hostinger, audit my hosting, check all my websites, what needs attention, health check my sites, are any of my sites broken, which of my sites are insecure."
---

# Audit hosting

Read-only from start to finish. The output is a report; every fix is a separate, confirmed step through another skill.

## Calling the operations

- Read the `inputSchema` that `search` returns before the first call of each operation. If a name below is rejected as unknown, `search` for what the step does (e.g. "ssl status").
- Batch reads with `multi-execute`, up to 20 steps a batch. Batches chain operations from one server only — the Hostinger Connector runs `hosting`, `wordpress`, `agency-hosting` and `billing` as separate servers. When a product group is switched off, skip its checks and say which were skipped.
- Page every list until `meta.total` is covered.
- Leave `hosting_php_get` out — it is large and says nothing about account health.

## 1. Inventory

One batch per server:

- `hosting_orders_list` with `statuses: ["active", "suspended"]`. `cloud_*` plan names are Cloud; the rest (`hostinger_premium_*`, `hostinger_business_*`, …) are Shared.
- `hosting_websites_list` — every Shared and Cloud website with `website_type`, `username`, `order_id` and `is_enabled` (false means suspended).
- `wordpress_installations_list` with `ownership: "all"` — `id`, `is_valid`, `validation_error`.
- `agency-hosting_orders_list` and `agency-hosting_websites_list-plan` — Agency orders and sites (`details.uid`, `details.type`, `details.domains`, `details.state`).

Tell the user the size (plans, websites, WordPress installs) before the checks. For large accounts offer to scope the audit to one order or domain.

## 2. Checks

Per Shared and Cloud website (skip `builder` and `horizons`):

- `hosting_ssl_status` — flag `failed` (with `last_error`), `expired`, `not_installed` on a custom domain, `is_https_redirect_enabled: false`, and `expires_at` within 30 days when `is_lifetime` is false. Lifetime certificates renew on their own.
- Node.js sites: `hosting_nodejs_list-builds` with `per_page: 1` (latest build failed?) and `hosting_nodejs_list-vulnerabilities` with `severities: ["critical", "high"]`.

Per hosting account (`username`): `hosting_databases_list` — flag `disk_usage_mb` above 80% of `max_size_mb`.

Per WordPress install: `wordpress_installations_show-core-version` (core vulnerabilities) and `wordpress_plugins_list-installed` (vulnerable plugins and pending updates).

Per Agency order: `agency-hosting_metrics_list-order-resource-usage` with `time_frame_hours: 168` and `agency-hosting_metrics_list-plan-order-disk-usage` with `time_frame_days: 7` — flag usage above 80% of the plan quota and name the heaviest websites.

Per Agency site: `agency-hosting_ssl_website-status` for each custom domain in `details.domains`; flag `details.state` other than `active`.

Plans about to lapse (billing product): `billing_subscriptions_list`, joined to hosting orders on `subscription_id` — flag `not_renewing`, or `is_auto_renewed: false` with `expires_at` within 30 days. Every site on that plan goes down with it.

From outside, for each custom domain:

```bash
curl -sS -o /dev/null -w "%{http_code}\n" --max-time 15 https://DOMAIN/
curl -sSI --max-time 15 https://DOMAIN/ | grep -i "^platform"
```

No `platform: hostinger` header means the domain does not reach this hosting.

## 3. Report

```
# Hosting audit
3 plans (2 Shared, 1 Cloud) + 1 Agency · 14 websites (6 WordPress, 3 Node.js, 5 other) · 4 Agency sites

#

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: connect-domain
description: "Connect a custom domain to a website on Hostinger web hosting (Shared, Cloud or Agency plans) end to end: attach the domain to the site, point DNS at Hostinger without breaking existing email or verification records, install SSL, turn on the HTTPS redirect, and verify it resolves. Handles domains registered at Hostinger or elsewhere, moving a site off its free *.hostingersite.com subdomain, subdomains and aliases. Triggers: connect my domain, point my domain to my site, use my own domain, move off the free subdomain, add a subdomain, park a domain, add a domain alias, my domain is not working."
---

# Connect a domain

Get a domain serving a Hostinger website over HTTPS. The one rule that matters most: records that already work — email (`MX`), SPF, DKIM and verification `TXT` records — must survive every DNS change.

## Calling the operations

- Read the `inputSchema` that `search` returns before the first call of each operation. If a name below is rejected as unknown, `search` for what the step does (e.g. "dns records").
- Batch reads with `multi-execute`; values pass between steps as `$steps.<i>.<path>`. Batches chain operations from one server only — the Hostinger Connector runs `hosting`, `agency-hosting`, `domains` and `dns` as separate servers. When `search` cannot find an operation, ask the user to enable that product group in the Connector.
- Every write here changes what the public sees. State the change and get a yes before each one.

## 1. Gather the facts (read-only)

- **Website.** `hosting_websites_list` with `domain` (Shared and Cloud; substring match, so take the exact entry) and `agency-hosting_websites_list-plan` with `domain` (Agency). Keep `username` and `order_id`, or `details.uid` and `details.ipv4`. When the domain has no website yet, find the site the user means — often a `*.hostingersite.com` one — or the order to create it on (`hosting_orders_list`, `agency-hosting_orders_list`).
- **Registration.** `domains_portfolio_get` succeeds only for domains registered at Hostinger; its `name_servers` show who runs DNS. Hostinger's own nameservers end in `dns-parking.com`.
- **Live DNS**, to know what must be kept:

```bash
dig +short NS DOMAIN; dig +short A DOMAIN; dig +short CNAME www.DOMAIN
dig +short MX DOMAIN; dig +short TXT DOMAIN; dig +short CAA DOMAIN
```

## 2. Attach the domain to hosting

Shared and Cloud:

- **New website on the domain.** For a domain outside this account run `hosting_domains_verify-ownership` first. When `is_accessible` is false, give the user the `TXT` record it returns to add next to the existing ones, then verify again (propagation takes up to ~10 minutes). Create with `hosting_websites_create` (`domain` without `www.`, `order_id`), then poll `hosting_websites_list-setups` with `domain` every 10–15 s until `status: completed`.
- **Moving a site off its free subdomain.** Shared and Cloud websites cannot be renamed through the API. Either create a website on the real domain and redeploy the project there (the `deploy-to-hosting` skill) — required for WordPress, which keeps its URL in the database — or, for static sites, park the domain on the existing site with `hosting_domains_create-website-parked`.
- **Alias** (a second domain showing the same site): `hosting_domains_create-website-parked`.
- **Subdomain** (`shop.example.com`): `hosting_domains_create-website-subdomain`. `www` belongs to the main domain — do not create it as a subdomain.

Agency Plan:

- `agency-hosting_domains_link-to-website` adds a domain to the site.
- `agency-hosting_domains_change-website` replaces the primary domain, for example the free subdomain. The old name stops serving at once — confirm first.

## 3. Point DNS at Hostinger

**DNS already at Hostinger** (nameservers end in `dns-parking.com`): creating the website normally writes the records. Read the zone with `dns_records_list`; when `@` and `www` already point at the site, change nothing. Before any edit, not

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: deploy-to-hosting
description: "Deploy an existing project to a website on Hostinger web hosting (Shared, Cloud or Agency plans) and keep it deployed: picks the right deploy for static sites, Node.js apps (Next.js, Nuxt, Express, Vite and similar), PHP apps and WordPress plugins or themes, sets up auto-deploy from GitHub or GitLab, manages Node.js environment variables and MySQL databases, and verifies the live site. Triggers: deploy this project, deploy to Hostinger, push my app live, redeploy, set up auto-deploy, connect my GitHub repo, add environment variables, my app needs a database, deploy my WordPress plugin or theme."
---

# Deploy to hosting

Ship a project that already exists — on disk or in a Git repository — to a Hostinger website. Building a new site from a prompt (design, store, blog) is the `hostinger-headless` skill; this one takes code as it is.

## Calling the operations

- Read the `inputSchema` that `search` returns before the first call of each operation. If a name below is rejected as unknown, `search` for what the step does (e.g. "deploy static").
- Batch reads with `multi-execute`; values pass between steps as `$steps.<i>.<path>`. Batches chain operations from one server only — the Hostinger Connector runs `hosting`, `wordpress` and `agency-hosting` as separate servers.
- Every deploy overwrites the website's current contents. Confirm the target domain with the user before the first deploy to a site that already has content.

## 1. Pick the target website

- `.hostinger/site.json` in the project: reuse its `domain` and `username` (or `website_uid`).
- Otherwise look the domain up with `hosting_websites_list` (Shared and Cloud; substring match — take the exact entry) and `agency-hosting_websites_list-plan` (Agency; keep `details.uid`).
- No website yet:
  - Shared and Cloud: take a domain (the user's own, or `hosting_domains_generate-free-subdomain`) and an `order_id` from `hosting_orders_list`, then `hosting_websites_create`. `datacenter_code` is needed only for the first website on a new plan (first entry of `hosting_datacenters_list`). Poll `hosting_websites_list-setups` with `domain` every 10–15 s until `status: completed` — uploads and deploys return 404 or 409 before that.
  - Agency: `agency-hosting_website-setups_create` with `flavor: "php-fpm"` (plus `type: "node-static"` for built frontends), `settings.php.version` from `agency-hosting_php_list-versions-for-order` and `datacenter_code` from `agency-hosting_datacenters_list`. Poll `agency-hosting_website-setups_status` until `completed`; it returns the `website_uid`.
- Node.js apps run on Business and Cloud plans (`hostinger_business_*`, `cloud_*` in `hosting_orders_list`). On other plans, build locally and deploy the output as a static site.

## 2. Choose the deploy

Wrong method is the most common failure. Decide from the project on disk:

| Project | Shared / Cloud |
| --- | --- |
| Plain HTML/CSS/JS, or a framework's static build output | `hosting_deploy-static-website` |
| `package.json` with a build or a server (Next.js, Nuxt, Express, Vite…) | `hosting_deploy-js-application` |
| PHP code, no build step | `hosting_deploy-static-website` (extracts the archive as-is) |
| WordPress plugin or theme folder | `hosting_deploy-wordpress-plugin` / `hosting_deploy-wordpress-theme` (`activate` optional) |
| A whole WordPress site from elsewhere | the `migrate-to-hosting` skill |

On Agency the website's type decides (`agency-hosting_websites_get`): sites created as `node-static` take `agency-hosting_deploy-node-static-website`, which runs the build when the project has one; every other site takes `agency-hosting_deploy-php-application`, which extracts the archive as-is. WordPress plugins and themes on Agency sites are installed from wp-admin.

Archive rules (name archives `name_YYYYMMDD_HHMMSS.zip`):

- **Static:** build locally first. `index.html` must be at the archive root, not inside a folder: `cd dist && zip -r ../site_20260101_120000

Preview of the first 4,000 characters. Read full instructions →

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 

Preview of the first 4,000 characters. Read full instructions →

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 t

Preview of the first 4,000 characters. Read full instructions →

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 th

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: hostinger
description: "Start here for any task involving the user's Hostinger account. Connects the hosted Hostinger MCP server (https://mcp.hostinger.com) with browser sign-in, sets the safety rules every Hostinger action follows, and hands off to the skill that owns the task: deploying, connecting a domain, troubleshooting, WordPress upkeep, audits, migrations, building a new site, or direct operations on domains, DNS, VPS, email, ecommerce, email marketing and billing. Triggers: Hostinger, connect Hostinger, set up Hostinger, sign in to Hostinger, my Hostinger account, hPanel, my VPS, my domains, my DNS records, my Hostinger subscriptions."
---

# Hostinger

Get the session to a connected, signed-in state, then route the request. Do the setup yourself with the shell — the user should only have to approve a sign-in in the browser and, at most once, restart the app.

## 1. Is Hostinger already connected?

The Hostinger server exposes three tools: `search` (find operations; returns each one's `inputSchema`), `execute` (run one operation) and `multi-execute` (run up to 20 in order). The host may show them namespaced, e.g. `mcp__hostinger__search`.

- Hostinger tools are in the tool list → call `search` for "list websites" and `execute` it. A result means the session is ready: go to step 4.
- An empty tool list does not prove the server is missing — some hosts load MCP tools lazily. Check the configuration before adding anything:

```bash
codex mcp get hostinger
```

`codex` is often not on `PATH`. On macOS the ChatGPT app bundles it at `/Applications/ChatGPT.app/Contents/Resources/codex-cli/bin/codex`; use that path when `command -v codex` finds nothing. Without a CLI, look for `[mcp_servers.hostinger]` in `~/.codex/config.toml`.

- Configured with `url = "https://mcp.hostinger.com"` → go to step 3 to sign in.
- Not configured → step 2.

## 2. Connect the hosted server

```bash
codex mcp add hostinger --url https://mcp.hostinger.com
```

Without a CLI, back up the config (`cp ~/.codex/config.toml ~/.codex/config.toml.bak`) and append — never rewrite — this block:

```toml
[mcp_servers.hostinger]
url = "https://mcp.hostinger.com"
```

Leave every other `[mcp_servers.*]` block as it is.

**Older local servers.** Version 0.1.0 of this plugin registered local servers named `hostinger-hosting`, `hostinger-wordpress`, `hostinger-agency-hosting`, `hostinger-domains`, `hostinger-dns`, `hostinger-vps`, `hostinger-ecommerce`, `hostinger-reach` and `hostinger-billing` (run with `npx`). The hosted server replaces all of them and needs no Node.js. When `codex mcp list` shows any of them, tell the user and offer to remove them with `codex mcp remove <name>`. Only remove them after the user agrees; until then both sets work side by side.

## 3. Sign in

```bash
codex mcp login hostinger
```

This opens the Hostinger sign-in page in the browser. Tell the user to sign in with their Hostinger account and select **Allow**. The callback goes to this machine, so the sign-in must happen here. Tokens refresh automatically. Re-run the login only when calls fail with `401`.

The host picks up a newly added server when it starts. When step 2 added the server, ask the user to restart the app (or start a new Codex session), then continue in a new chat. Ask for this once. Do not add servers one by one with a restart for each.

When no shell is available (for example ChatGPT on the web), tell the user to add Hostinger themselves: create a custom MCP server in the app's connector settings with the URL `https://mcp.hostinger.com` and sign in when prompted.

**API token instead of a browser.** For CI and other headless machines, create a token in hPanel at https://hpanel.hostinger.com/api, export it as `HOSTINGER_API_TOKEN`, and register the server with `codex mcp add hostinger --url https://mcp.hostinger.com --bearer-token-env-var HOSTINGER_API_TOKEN`. Never ask the user to paste the token into the chat, and never write it into a file.

## 4. Route

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: hostinger-headless
description: "Build, connect, or iterate on a website hosted on Hostinger — provision hosting and a domain, optionally seed an ecommerce store with a real hosted checkout or a WordPress content backend (headless CMS/blog), build the frontend, deploy, and verify. Requires an authenticated Hostinger MCP session (see the hostinger skill). Triggers: build me a site on Hostinger, deploy this to Hostinger, connect this project to Hostinger, add a store to my Hostinger site, add a blog to my Hostinger site, update my Hostinger site."
---

# Hostinger Headless

This skill turns a prompt into a live website on Hostinger. Its job is to own the full run: check the account, provision hosting and a domain, seed the backend (an ecommerce store when the intent calls for selling), build the frontend, deploy it, and verify the result.

The frontend is built ad-hoc to the user's intent — there is no template library. The backend pieces are real Hostinger products: web hosting (static or Node.js), domains and DNS, Hostinger Ecommerce with its public Storefront API and hosted checkout, and WordPress as a headless CMS/blog backend read through the public WP REST API.

## Preconditions

1. An authenticated Hostinger MCP session — the hostinger skill handles this. If MCP tools fail with auth errors, run the `hostinger` skill's connection check.
2. The Hostinger MCP operations for **hosting** (plus **ecommerce** when the run involves a store, and **wordpress** when it involves a content backend). Operation availability varies per user — product groups can be toggled in the Hostinger Connector. When search cannot find a needed operation, ask the user to enable that product group (or configure the scoped binary, e.g. `hostinger-hosting-mcp`) rather than improvising around it.
3. An active hosting plan (checked in Setup §1). Hostinger hosting is a paid product: if the account has no usable plan, inform the user plainly that a subscription is required, link them to https://www.hostinger.com/web-hosting, and pause until they confirm the purchase. Do not treat this as an error — it is a normal step for new accounts. Everything that doesn't need hosting (planning, building the frontend locally) can proceed while they decide.

## Resolving the operation

Resolve by intent first, disk second — never let an empty directory override what the user is asking for. Check `iterate` first (it's decided by an unambiguous on-disk signal):

- `iterate` — a `.hostinger/site.json` is present in the project: the site is already deployed through this skill and the user wants changes. Reuse the recorded domain/site details; apply only the delta the new intent needs (edit frontend → redeploy; add a store → run `references/STORE.md` then redeploy). Never re-provision an existing site.
- `connect` — a frontend project already on disk (or brought in as a zip/export/URL) that is not yet on Hostinger, with language like "deploy this / host this on Hostinger / connect this project". Emptiness of the CWD at trigger time is not a create signal when a design is brought in from elsewhere.
- `create` — a new site from a prompt with nothing brought in: "build me a store / portfolio / site…".

If signals conflict, ask the user — don't guess.

## The run

1. **Discovery** — from the prompt (and the project on disk for connect/iterate), infer: does this run need a store (any buy/sell/product intent → yes)? Does it need owner-managed content — a blog, news, or anything the owner edits without a redeploy (→ WordPress backend; static copy that rarely changes does not qualify)? What brand, copy, and structure does the site need? What stack fits — plain static HTML/CSS/JS for simple sites (default), a static-output framework build, or a Node.js app when SSR or server code is genuinely required? Prefer static: it deploys fastest and has no build-failure surface. Ask the user only what you cannot infer.
2. **Setup** (`references/SETUP.md`) — plan check, then provision 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: maintain-wordpress
description: "Keep WordPress sites on Hostinger web hosting updated and secure: checks core, plugin and theme versions, known vulnerabilities and install health on one site or every site in the account, reports what needs doing, applies updates in a safe order, and confirms each site still loads. Also covers cache purges, the Memcached object cache, maintenance mode and one-click wp-admin login links. Triggers: update my WordPress, update plugins, are my WordPress sites secure, WordPress vulnerabilities, outdated plugins or themes, WordPress maintenance, speed up WordPress, log me into wp-admin."
---

# Maintain WordPress

Check first, report, then update only what the user approves — one site at a time, proving each still loads before moving to the next.

## Calling the operations

- Read the `inputSchema` that `search` returns before the first call of each operation. If a name below is rejected as unknown, `search` for what the step does (e.g. "wordpress plugins update").
- Batch reads with `multi-execute` (up to 20 steps a batch). Batches chain operations from one server only — the Hostinger Connector runs `wordpress`, `hosting` and `agency-hosting` as separate servers.
- Updates, activations, uninstalls and core changes are queued jobs: a success response means "queued". Poll the matching read operation every 10–20 s until the change shows; never re-send the write.

## 1. Find the installs

- One site: `wordpress_installations_list` with `domain` (substring match — take the exact entry). Every site: `wordpress_installations_list` without filters, adding `ownership: "all"` to include sites the user manages for others.
- Keep `id` (the `software` parameter of every `wordpress_*` call), `username`, `domain`, `directory`, `is_valid` and `validation_error`.
- Agency Plan WordPress sites come from `agency-hosting_websites_list-plan` with `website_types: ["wordpress"]`. When `wordpress_installations_list` does not include them, only `agency-hosting_wordpress_settings` and core version changes (`agency-hosting_wordpress_list-versions`, `agency-hosting_wordpress_change-version`) are available; plugins and themes are updated from wp-admin.

## 2. Check (read-only)

Per install:

- `wordpress_installations_show-core-version` — core version and the known vulnerabilities that affect it.
- `wordpress_installations_list-core-updates` — available core versions.
- `wordpress_plugins_list-installed` — `status`, `update` (the newer version, when there is one) and `vulnerabilities[]` with `fixed_in`.
- `wordpress_themes_list-installed` — the same for themes.

Four steps per install fit five installs in one batch. For an install with `is_valid: false`, run `wordpress_installations_check-if-are-valid` with `force: true` for a fresh reason and leave it out of updates — a broken install is the `troubleshoot-website` skill's job.

## 3. Report before changing anything

```
## example.com (WordPress 6.8.1)
Vulnerable: contact-form-x 5.2 → fixed in 5.3 (update available)
Vulnerable, inactive: old-slider 1.0 — no fix; uninstall recommended
Updates: core 6.8.1 → 6.8.3 (minor), 4 plugins, 1 theme
```

Vulnerable items come first. A vulnerable plugin without a fix, or an inactive one, is better removed with `wordpress_plugins_uninstall` than left installed — inactive code on disk can still be reached. Ask which updates to apply.

## 4. Back up first

The API has no backup operation. Before updating, ask the user to create a backup in hPanel or confirm the latest automatic one is recent enough. Say it plainly; the user may choose to go ahead without one.

## 5. Update, one site at a time

1. Plugins that fix a vulnerability — `wordpress_plugins_update` with their slugs.
2. The remaining approved plugins, then themes with `wordpress_themes_update`.
3. Core with `wordpress_installations_update-core`: `minor: true` for patch releases; a major `version` only when the user asks for it.

For a busy site the user may want `wordpress

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: migrate-to-hosting
description: "Move an existing website from another host to Hostinger web hosting (Shared, Cloud or Agency plans) without downtime: WordPress sites from a files archive and SQL dump, static and PHP sites from an archive, Node.js apps from source. Creates the website on the real domain, imports files and database, tests the copy before any DNS change, then switches the domain and SSL. Triggers: migrate my site to Hostinger, move my website from another host, transfer my WordPress site, import my website, switch hosting to Hostinger."
---

# Migrate to hosting

The old host keeps serving the site until the copy on Hostinger is proven to work. DNS moves last.

## Calling the operations

- Read the `inputSchema` that `search` returns before the first call of each operation. If a name below is rejected as unknown, `search` for what the step does (e.g. "import wordpress").
- Batch reads with `multi-execute`. Batches chain operations from one server only — the Hostinger Connector runs `hosting`, `wordpress`, `agency-hosting`, `domains` and `dns` as separate servers.
- Imports and deploys overwrite the target website's contents; confirm the target before each one.

## 1. What is being moved

Establish, asking only for what cannot be inferred:

- **Site type:** WordPress, static, PHP (with or without MySQL), or Node.js.
- **The export:**
  - WordPress — an archive of the whole WordPress root (including `wp-content` and `wp-config.php`) and a `.sql` dump.
  - PHP — a files archive, plus a `.sql` dump when the app has a database.
  - Static — the files. Node.js — the source or its Git repository.
  - Without one, the user exports it from the old host's panel, or over SSH: `tar -czf site.tar.gz -C /path/to/site .` and `mysqldump --single-transaction -u USER -p DBNAME > db.sql`.
- **The exact home URL** (`https`, with or without `www`) — WordPress keeps it in the database, so the new site must answer on the same one.
- **Current DNS**, to preserve what already works:

```bash
dig +short NS DOMAIN; dig +short A DOMAIN; dig +short MX DOMAIN; dig +short TXT DOMAIN
```

- **Cron jobs** on the old host — they do not move with the files.

## 2. Create the website on the real domain

Create the Hostinger website on the domain being migrated, not on a free subdomain: step 4 tests it by pointing only this machine at Hostinger, so nothing changes for visitors yet.

- Shared and Cloud: `hosting_domains_verify-ownership` first. When `is_accessible` is false, the user adds the returned `TXT` record at their current DNS provider, next to the existing ones, and verification is repeated. Then `hosting_websites_create` with `domain` and `order_id` (from `hosting_orders_list`), and poll `hosting_websites_list-setups` with `domain` every 10–15 s until `status: completed`.
- Agency: `agency-hosting_website-setups_create` with the `domain`, `flavor: "php-fpm"`, a `settings.php.version` matching the old host (options in `agency-hosting_php_list-versions-for-order`) and `datacenter_code` from `agency-hosting_datacenters_list`. Poll `agency-hosting_website-setups_status` until `completed` for the `website_uid`.

## 3. Import

`hosting_import-wordpress-website`, `hosting_deploy-static-website` and `agency-hosting_deploy-php-application` read files from this machine and exist only in the local `hostinger-api-mcp` server. On the hosted server (`mcp.hostinger.com`), upload the files first as described in the `deploy-to-hosting` skill ("Without the local deploy operations") and use the operation named in brackets below.

**WordPress, Shared and Cloud:** `hosting_import-wordpress-website` with `domain`, `archivePath` and `databaseDump` uploads both, extracts the files and imports the database; large sites take several minutes. [Upload `site.zip` and `dump.sql`, then `wordpress_installations_import-website` with `archive_path` and `sql_path`.] Then `wordpress_installations_detect` with `username` and poll `wordpress_installations_list` with 

Preview of the first 4,000 characters. Read full instructions →

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 

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: troubleshoot-website
description: "Diagnose and fix a website on Hostinger web hosting (Shared, Cloud or Agency plans) that is down, slow, erroring, insecure or failing to build. Checks the site from outside, reads builds, runtime logs, WordPress health, SSL, cache and PHP settings through the Hostinger MCP, names the cause with evidence, and applies the fix once the user agrees. Triggers: my site is down, site not loading, 500 / 502 / 503 error, white screen, error establishing a database connection, site is slow, SSL or certificate warning, not secure, changes not showing, Node.js build failed, app keeps crashing."
---

# Troubleshoot a website

One website and one symptom in; a named cause, the evidence for it, and a fix out. Stay read-only until the cause is stated and the user agrees to the fix.

## Calling the operations

- Read the `inputSchema` that `search` returns before the first call of each operation. If a name below is rejected as unknown, `search` for what the step does (e.g. "ssl status").
- Batch reads with `multi-execute` and pass values between steps with `$steps.<i>.<path>`, e.g. `"$steps.0.data.0.username"`. A batch stops at its first failure.
- The Hostinger Connector runs each product as its own MCP server (`hosting`, `wordpress`, `agency-hosting`, `domains`, `dns`), so a batch can only chain operations from one server. When `search` cannot find an operation, that product group is switched off in the Connector — ask the user to enable it.

## 1. Find the website

Run both lookups, and keep the result for every later call:

- `hosting_websites_list` with `domain` — Shared and Cloud plans. The filter is a substring match, so take the entry whose `domain` is exactly the one asked about. Keep `username`, `order_id` and `website_type`; every `hosting_*` and `wordpress_*` call is keyed on `username` + `domain`.
- `agency-hosting_websites_list-plan` with `domain` — Agency Plan. Keep `details.uid` (the `website_uid` of every `agency-hosting_*` call), `details.type`, `details.ipv4` and `details.domains`.

Neither finds it: the domain is not a website on this account — say so and show where it points (step 2).

## 2. Look at it from outside

Run these alongside step 1:

```bash
curl -sS -o /dev/null -w "%{http_code} ttfb=%{time_starttransfer}s %{redirect_url}\n" https://DOMAIN/
curl -sSI https://DOMAIN/
dig +short NS DOMAIN; dig +short A DOMAIN; dig +short CAA DOMAIN
```

- Hostinger responses carry `platform: hostinger` and `panel: hpanel`. Without them, or with DNS pointing elsewhere, traffic is not reaching this hosting — hand over to the `connect-domain` skill.
- Certificate or TLS errors → [SSL](#ssl).
- `5xx`, a blank page or an error page → [By website type](#3-by-website-type).
- `200` with old content → cache: `hosting_cache_clear-website` (also purges the Hostinger CDN; pass `directory` for WordPress in a subfolder), plus `wordpress_litespeed-cache_purge-lite-speed` for WordPress; Agency: `agency-hosting_cache_clear-website`.
- Slow first byte → [Slow site](#slow-site). Behind the Hostinger CDN, `x-hcdn-upstream-rt` is the origin's own response time in seconds; a small value there means the server is not the bottleneck.

## 3. By website type

`website_type` (Shared/Cloud) or `details.type` (Agency) picks the branch. `builder` and `horizons` sites are not managed by these operations — send the user to hPanel.

### Node.js (`nodejs`)

Batch `hosting_nodejs_list-builds` (`per_page: 3`), `hosting_nodejs_runtime-logs` (`period: "1h"`, `levels: ["ERROR", "WARN"]`) and `hosting_nodejs_list-environment-variables` (keys only; values always come back masked).

- Latest build `failed`: call `hosting_nodejs_analyse-failed-build` once for that build — every call re-runs the analysis and the limit is 5 a minute. When it returns nulls, read `hosting_nodejs_build-logs`. A wrongly detected framework, output directory or missing `entry_file` is the usual cause: compare `hosting_nodejs_build-settings` with the p

Preview of the first 4,000 characters. Read full instructions →

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_activate

Preview of the first 4,000 characters. Read full instructions →

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 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 5 — file references are metadata, not package contents.