hostinger-api-mcp 1.17.0 → 1.18.0

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "1.17.0",
+  "version": "1.18.0",
   "description": "Hostinger API — manage domains, DNS, hosting, VPS, billing and more from Gemini CLI.",
   "mcpServers": {
     "hostinger": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "1.17.0",
+  "version": "1.18.0",
   "mcpName": "io.github.hostinger/hostinger-api-mcp",
   "description": "MCP server for Hostinger API",
   "repository": {

package/server.json

@@ -6,12 +6,12 @@
     "url": "https://github.com/hostinger/api-mcp-server",
     "source": "github"
   },
-  "version": "1.17.0",
+  "version": "1.18.0",
   "packages": [
     {
       "registryType": "npm",
       "identifier": "hostinger-api-mcp",
-      "version": "1.17.0",
+      "version": "1.18.0",
       "transport": {
         "type": "stdio"
       },

package/skills/headless/SKILL.md

@@ -0,0 +1,53 @@
+---
+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, build the frontend, deploy, and verify. Requires an authenticated Hostinger MCP session (see entry/skill.md). Triggers: build me a site on Hostinger, deploy this to Hostinger, connect this project to Hostinger, add a store 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, and Hostinger Ecommerce with its public Storefront API and hosted checkout.
+
+## Preconditions
+
+1. An authenticated Hostinger MCP session — the entry skill's bootstrap handled this. If MCP tools fail with auth errors, send the user back through `entry/skill.md`.
+2. The Hostinger MCP tools for **hosting** (and **ecommerce**, when the run involves a store). Tool availability varies per user — product groups can be toggled in the Hostinger Connector, and some clients cap the number of exposed tools. When a needed tool is missing, 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)? 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 the website on a free subdomain (or the user's own domain) and wait until it's ready.
+3. **Store** (`references/STORE.md`, only when commerce is needed) — resolve or create the store and its `custom` sales channel, seed products/shipping/payment, and note the `sales_channel_id` for the frontend.
+4. **Build** — create or wire the frontend. For store runs, follow the frontend contract in `references/STORE.md` (catalog fetched at runtime from the public Storefront API, cart in `localStorage`, client-side checkout — never embed an API token in the site).
+5. **Deploy** (`references/DEPLOYMENT.md`) — archive and deploy via the matching hosting tool, polling build logs for Node.js runs.
+6. **Verify** — curl the live URL for a 200 and a piece of real page copy; for store runs, confirm a checkout POST returns a redirect URL. Show the user the live URL and where to manage things (hPanel: https://hpanel.hostinger.com, and the store dashboard for commerce).
+7. **Record** — write `.hostinger/site.json` into the project: `{ "domain", "username", "type": "static"|"nodejs", "sales_channel_id"?, "store_id"? }`. This is what makes future runs resolve as `iterate`.
+
+Run non-interactively wherever possible. The exceptions that must involve the user: the paid-plan confirmation, anything that costs money (a domain purchase, a new subscription), and picking between genuinely equal options the prompt doesn't decide.
+
+## Paths
+
+| What | Path |
+| --- | --- |
+| Plan check + website/domain provisioning | `references/SETUP.md` |
+| Store: seed the backend + the frontend API contract | `references/STORE.md` |
+| Deploy: static vs Node.js, archive rules, logs, verify | `references/DEPLOYMENT.md` |
+
+## Where the how comes from
+
+The MCP tool descriptions are authoritative for request shapes — read them before calling. Two live sources supersede anything written here when they disagree:
+
+- The ecommerce MCP tool `ecommerce_getCustomStorefrontSetupInstructionsV1` returns the current storefront integration guide from the server — call it at the start of any store run.
+- The Hostinger API reference at https://developers.hostinger.com describes every endpoint behind the tools.

package/skills/headless/entry/bootstrap.mjs

@@ -0,0 +1,109 @@
+#!/usr/bin/env node
+// Hostinger Headless — bootstrap.
+// Verifies the Hostinger MCP server is reachable and drives the OAuth sign-in,
+// emitting one JSON event per line on stdout so a coding agent can relay
+// progress to the user. No filesystem writes besides what the MCP itself
+// stores (OAuth credentials); no network calls of its own.
+import { spawn, spawnSync } from 'node:child_process';
+import { existsSync, readFileSync } from 'node:fs';
+import path from 'node:path';
+import os from 'node:os';
+
+// ── tiny event protocol (one JSON object per line) ───────────────────────────
+const emit = (event, extra = {}) =>
+  process.stdout.write(JSON.stringify({ event, ...extra }) + '\n');
+const fail = (event, extra = {}) => {
+  emit(event, { ok: false, ...extra });
+  process.exit(1);
+};
+
+// ── platform-safe binary names (npm/npx are .cmd on Windows) ─────────────────
+const isWin = process.platform === 'win32';
+const bin = (name) => (isWin ? `${name}.cmd` : name);
+// Run the MCP via npx — no global install, always the latest published version.
+const MCP = [bin('npx'), '-y', 'hostinger-api-mcp@latest'];
+
+function capture(cmd, args) {
+  const r = spawnSync(cmd, args, { encoding: 'utf8', shell: false });
+  return { status: r.status ?? 1, out: `${r.stdout || ''}${r.stderr || ''}`, error: r.error };
+}
+
+// ── 1. MCP server reachable ──────────────────────────────────────────────────
+function checkMcp() {
+  const r = capture(MCP[0], [...MCP.slice(1), '--version']);
+  if (r.status !== 0) fail('mcp_unreachable', { detail: r.out.trim().slice(0, 400) });
+  // npx interleaves "npm notice …" lines, so pick the first semver-looking token.
+  const version = (r.out.match(/\d+\.\d+\.\d+[^\s]*/) || [])[0] || r.out.trim().split('\n').pop();
+  emit('mcp_ok', { version });
+}
+
+// ── 2. Existing auth? ────────────────────────────────────────────────────────
+// An env token always wins (the MCP bypasses OAuth entirely when it is set).
+// Otherwise stored OAuth credentials mean a previous sign-in can be reused —
+// the MCP refreshes expired tokens automatically on the first tool call.
+function existingAuth() {
+  if (process.env.HOSTINGER_API_TOKEN || process.env.API_TOKEN) {
+    return 'api_token';
+  }
+  const base = isWin ? (process.env.APPDATA || os.homedir()) : path.join(os.homedir(), '.config');
+  const credsPath = path.join(base, 'hostinger-mcp', 'credentials.json');
+  if (existsSync(credsPath)) {
+    try {
+      const creds = JSON.parse(readFileSync(credsPath, 'utf8'));
+      if (creds.refresh_token || (creds.access_token && creds.expires_at > Date.now())) {
+        return 'oauth_cached';
+      }
+    } catch {
+      /* unreadable credentials — fall through to a fresh login */
+    }
+  }
+  return null;
+}
+
+// ── 3. Login (human-in-the-loop browser flow) ────────────────────────────────
+// `hostinger-api-mcp --login` opens the Hostinger sign-in page and listens on
+// an ephemeral localhost port for the OAuth callback, so the browser must run
+// on this same machine. It prints the sign-in URL to stderr with a stable
+// prefix — forward it so the agent can show it if the browser didn't open.
+function login() {
+  return new Promise((resolve) => {
+    const child = spawn(MCP[0], [...MCP.slice(1), '--login'], { shell: false });
+    let diag = '';
+    let urlSent = false;
+    const collect = (chunk) => {
+      diag = (diag + chunk).slice(-2000);
+      if (!urlSent) {
+        const m = diag.match(/Opening browser for sign-in:\s*\n\s*(https?:\/\/\S+)/);
+        if (m) {
+          urlSent = true;
+          emit('awaiting_user', {
+            verificationUri: m[1],
+            note: 'A browser window should have opened. If not, open this URL manually on this machine and sign in.',
+          });
+        }
+      }
+    };
+    child.stderr?.on('data', collect);
+    child.stdout?.on('data', collect);
+    child.on('close', (code) => {
+      if (code === 0 && /Sign-in successful/i.test(diag)) {
+        emit('logged_in', { method: 'oauth' });
+        resolve();
+        return;
+      }
+      const detail = diag.trim().slice(-1500) || `--login exited (code ${code}) with no output.`;
+      fail('login_failed', { code, detail });
+    });
+    child.on('error', (e) => fail('login_failed', { detail: String(e) }));
+  });
+}
+
+// ── main ─────────────────────────────────────────────────────────────────────
+checkMcp();
+const method = existingAuth();
+if (method) {
+  emit('logged_in', { method });
+} else {
+  await login();
+}
+emit('success');

package/skills/headless/entry/skill.md

@@ -0,0 +1,79 @@
+---
+name: hostinger-headless-entry
+description: "Build a complete website on Hostinger from a single prompt — hosting, domain, and (optionally) a store with real checkout. The deterministic first steps — verifying the Hostinger MCP server and signing in — are handled by a single bootstrap script; the agent then installs the full skill and hands the run to it. Triggers: build me a site, create a website, make me a website, online store, I want to sell X, start a business online, launch a site, ecommerce, portfolio, business website, sell online, online shop, connect this project to Hostinger, host this on Hostinger, deploy this to Hostinger."
+---
+
+# Hostinger Headless Skill — cold-start entry
+
+You are a coding agent, and this is a skill for you to execute. Follow the phases below in order — do not summarize them. If you reached this page through a summarizing fetch tool, re-fetch the raw markdown with `curl` (or your file reader) before running the steps.
+
+This entry gets a cold environment to the point where the real skill can run, then hands off:
+
+1. Bootstrap (deterministic, scripted). A single script verifies the Hostinger MCP server is reachable and handles sign-in, so the run starts from a known-good, authenticated state. You just run it and relay its events.
+2. Hand off (agentic). Install the skill, then open `headless/SKILL.md` and follow it — it resolves the operation (create / connect / iterate) and owns the whole build.
+
+Three starting points come through here, all handled the same way — run the bootstrap, then hand off:
+
+- new — a prompt with no project (empty CWD)
+- connect — an existing frontend not yet on Hostinger
+- iterate — a project already deployed to Hostinger (`.hostinger/site.json` present)
+
+The bootstrap only verifies the MCP and signs you in, so it is safe to run in every case (an existing session just reports `logged_in`).
+
+## Phase 0 — Node (the one manual prerequisite)
+
+The Hostinger MCP server requires Node ≥ 20. Check it:
+
+```bash
+node -v
+```
+
+If that errors (Node not installed) or prints a version below 20, install or upgrade Node and re-check — do not try to work around it:
+
+- macOS: `brew install node` (or `nvm install 22 && nvm use 22`)
+- Linux: `nvm install 22 && nvm use 22` (or your distro's Node 20+ package)
+- Windows: `winget install OpenJS.NodeJS.LTS` (or download from nodejs.org)
+
+## Phase 1 — Run the bootstrap (deterministic)
+
+Download the bootstrap script, then run it. It verifies the MCP server and handles sign-in, emitting one JSON event per line on stdout. Run it as a background/streaming process and relay its events to the user.
+
+The script is safe and inspectable: it only checks the MCP server via `npx` and drives the OAuth sign-in (a browser flow with a localhost callback) — no other network calls, no filesystem writes. Read it first if your sandbox flags externally-downloaded code.
+
+```bash
+# macOS/Linux:
+curl -fsSL -O https://raw.githubusercontent.com/hostinger/api-mcp-server/main/skills/headless/entry/bootstrap.mjs
+# Windows PowerShell:
+iwr https://raw.githubusercontent.com/hostinger/api-mcp-server/main/skills/headless/entry/bootstrap.mjs -OutFile bootstrap.mjs
+
+node bootstrap.mjs
+```
+
+### Relay these events
+
+The script emits one JSON object per line:
+
+| Event | What to do |
+| --- | --- |
+| `mcp_ok` | MCP server reachable — continue. |
+| `logged_in` | Already authenticated (env token or a previous sign-in) — continue. |
+| `awaiting_user` (`verificationUri`) | A browser window should have opened on the user's machine. Show the URL in plain prose and wait for the user to finish signing in. The OAuth callback lands on a localhost port, so the sign-in must be completed on this same machine. |
+| `success` | Bootstrap done — continue to Phase 2. |
+| `mcp_unreachable` / `login_failed` (with `detail`) | Stop and show the user the `detail`. Do not improvise a parallel setup by hand. |
+
+If the environment has a `HOSTINGER_API_TOKEN` set (for example CI), the bootstrap reports `logged_in` immediately — no browser needed.
+
+## Phase 2 — Install the skill and hand off
+
+Install the Hostinger skills locally so your agent reads files directly with no network calls:
+
+```bash
+npx skills add hostinger/api-mcp-server --yes
+```
+
+If the installer is unavailable, fetch the files directly instead — the full set is listed in the skill folder at `https://github.com/hostinger/api-mcp-server/tree/main/skills/headless`.
+
+Then open `headless/SKILL.md` and follow it. That skill owns the rest of the run — it resolves the operation (create / connect / iterate), checks the account has a usable hosting plan, provisions the website and domain, seeds the store when commerce is requested, builds, deploys, and verifies.
+
+- Don't provision hosting, create stores, or deploy by hand here — the skill does all of that (`references/SETUP.md`, `references/DEPLOYMENT.md`, `references/STORE.md`). This entry stops at signed in.
+- You're already authenticated from Phase 1, so every Hostinger MCP tool call will work without prompting again.

package/skills/headless/references/DEPLOYMENT.md

@@ -0,0 +1,34 @@
+# Deployment — getting the build live
+
+Match the deploy method to what the project actually is — this is the single most common failure point.
+
+## Static site → `hosting_deployStaticWebsite`
+
+For pre-built files only: plain HTML/CSS/JS, or the **build output** of a framework (run the build locally first).
+
+- The archive (zip/tar) must have `index.html` at its **root** — not nested inside a folder.
+- Name it `name_YYYYMMDD_HHMMSS.zip`; pass `removeArchive: true` to clean up after upload.
+- Deployment is effectively immediate — verify right after.
+
+## Node.js app → `hosting_deployJsApplication`
+
+For anything that needs a server or a server-side build (Express, Next.js, NestJS, SSR frameworks).
+
+- Archive the **source**, not the output: exclude `node_modules/`, `dist/`, `.next/`, `build/`, and everything matched by `.gitignore`. The install and build run on Hostinger.
+- Hard cap: **50 MB** archive.
+- The upload starts a build. Track it with `hosting_listJsDeployments`; on failure pull `hosting_showJsDeploymentLogs`, fix, and redeploy. Poll with backoff — builds take minutes, not seconds.
+
+## WordPress → `hosting_importWordpressWebsite` / plugin & theme tools
+
+Only when the user explicitly wants WordPress. Site imports take an archive plus a `.sql` dump and can run for several minutes.
+
+## Verify (every deploy)
+
+```bash
+curl -s -o /dev/null -w "%{http_code}\n" https://YOURDOMAIN/
+curl -s https://YOURDOMAIN/ | grep -o "SOME_REAL_HEADLINE_TEXT"
+```
+
+Replace the grep target with copy you actually rendered — a 200 alone can be a placeholder page. A freshly created site may serve a default page for a short while; if content doesn't match, clear the cache (`hosting_clearWebsiteCacheV1`) and retry before assuming the deploy failed. For store runs, also run the checkout verification in `STORE.md`.
+
+When the site is live, report the URL and remind the user the site is managed from hPanel (https://hpanel.hostinger.com).

package/skills/headless/references/SETUP.md

@@ -0,0 +1,34 @@
+# Setup — plan check and website provisioning
+
+Everything here uses the **hosting** MCP tools. If they're missing, ask the user to enable the Websites product group in the Hostinger Connector (or use the `hostinger-hosting-mcp` scoped binary).
+
+## 1. Plan check (gate — run this first)
+
+A website can only be created on an active hosting plan.
+
+1. `hosting_listWebsitesV1` — if it returns websites, the account has a working plan; note any existing `order_id` and `username` for step 2.
+2. Otherwise `hosting_listOrdersV1` — look for an order in a usable state. A fresh order that has never hosted a website still works; note its `order_id`.
+3. If there is no usable order: **stop and tell the user** that an active Hostinger hosting plan is required to deploy, link https://www.hostinger.com/web-hosting, and offer to continue building the site locally in the meantime. When they confirm the purchase, re-run this check.
+
+Never purchase a plan, domain, or any paid item without the user explicitly approving that specific purchase.
+
+## 2. Choose the domain
+
+- **Default: free subdomain.** `hosting_generateAFreeSubdomainV1` returns a `*.hostingersite.com` domain. No verification needed. Tell the user a custom domain can be connected later.
+- **User-owned domain:** `hosting_verifyDomainOwnershipV1` first. If not accessible, relay the TXT record it returns, remind them propagation can take ~10 minutes, and re-verify before continuing.
+- **New domain purchase:** only on explicit request — check availability with `domains_checkDomainAvailabilityV1`, state the price, and get an explicit yes before `domains_purchaseNewDomainV1` (needs the domains product group).
+
+## 3. Create the website and wait for it
+
+Generating a subdomain does **not** create a website — deploying straight to it fails with `No website found for domain`. The working sequence:
+
+1. `hosting_createWebsiteV1 { domain, order_id }` — `datacenter_code` is required only for the first website on a brand-new plan (pick the first entry from `hosting_listAvailableDatacentersV1`).
+2. **Poll** `hosting_listWebsitesV1` filtered by the domain until the site appears. Creation takes up to a few minutes — poll with backoff, don't fail fast.
+3. Note the site's `username` — deployment and database tools are keyed on it.
+
+If the domain already has a website (an `iterate` run, or the user pointed at an existing site), skip creation entirely.
+
+## 4. Optional extras (only when the run needs them)
+
+- **Database:** `hosting_createAccountDatabaseV1` for Node.js apps that need MySQL; pass the credentials to the app via its environment/config, never hard-coded into client-side code.
+- **DNS records:** the DNS tools (`DNS_updateDNSRecordsV1` etc.) for custom-domain records; take a snapshot (`DNS_getDNSSnapshotListV1` context) before destructive changes.

package/skills/headless/references/STORE.md

@@ -0,0 +1,52 @@
+# Store — Hostinger Ecommerce with a custom storefront
+
+**Primary source:** call `ecommerce_getCustomStorefrontSetupInstructionsV1` at the start of every store run — it returns the current, server-maintained integration guide, and it supersedes this file wherever they disagree. This file carries the essentials so the run can be planned before that call, and a fallback when the ecommerce tools aren't enabled.
+
+## Mental model
+
+Two API surfaces — don't mix them:
+
+| Surface | Base URL | Auth | Use for |
+| --- | --- | --- | --- |
+| Storefront Core V2 | `https://api-ecommerce.hostinger.com/v2` | none (public, open CORS) | read products/variants, checkout — called from the browser |
+| Management (MCP tools) | Hostinger API | authenticated | create stores/products/shipping/payments |
+
+- A **store** (`store_*`) has **sales channels** (`scha_*`). The Storefront API is keyed on the **`sales_channel_id`** of a `custom`-type channel — not the store id. Managed channels (e.g. `quick-link`) cannot be used here, and only `custom` channels are API-creatable.
+- **Prices are integers in minor units** (`2900` = €29.00 → divide by `10^decimal_digits`) and live on **variants**, not products.
+- **Security boundary:** storefront reads and checkout are public and run client-side — **never embed a Hostinger API token in the storefront**. Only the management/hosting side (MCP tools) is authenticated.
+
+## Backend setup (management tools)
+
+1. Resolve the `custom` sales channel: `ecommerce_getStoresV1` → `ecommerce_listSalesChannelsV1`. If a `custom` channel already exists, confirm with the user that it's the one to use; otherwise add one to the existing store with `ecommerce_createCustomSalesChannelV1`, or create a store with `ecommerce_createStoreV1` (with a `custom` sales channel) when no suitable store exists. Set the channel `url` to the storefront's public domain at creation when it's already known.
+2. For checkout to work the store needs all three: ≥ 1 product, ≥ 1 payment method, ≥ 1 shipping zone. Payment, shipping, and currency are store-level — check `ecommerce_getStoreMetadataV1` (`has_payment_methods` and `has_shipping` must be `true`; the same response carries `default_currency` with `code`, `decimal_digits`, `template` — read it here rather than guessing). Products are **per sales channel** — verify by listing products for the resolved channel on the Storefront API and confirming the list is non-empty. Seed what's missing with `ecommerce_createPhysicalProductV1` / `ecommerce_createDigitalProductV1`, `ecommerce_enableManualPaymentMethodV1`, and `ecommerce_setStoreShippingV1` (price `0` = free shipping) — confirming with the user before writing to a store that already has real data.
+3. After deploy, point the channel at the live site: `ecommerce_updateSalesChannelV1 { store_id, sales_channel_id, url }`.
+
+If the ecommerce tools aren't available, ask the user to enable the Ecommerce product group in the Hostinger Connector — or to provide the `sales_channel_id` directly, after which the public endpoints suffice for the frontend work.
+
+## Frontend contract
+
+The OpenAPI schema for the Storefront API is at `https://api-ecommerce.hostinger.com/v2/docs.json` — fetch it for exact endpoint shapes. Non-obvious rules the schema won't spell out:
+
+- **Fetch the catalog at runtime, not build time** — client-side fetch on page load (CORS is open). Baking products into a static build makes the site stale on the first catalog edit. (SSR / Node.js hosting may fetch it server-side per request.)
+- Each variant has a **`prices[]` array** (one entry per currency) — read `prices[0].amount` / `prices[0].sale_amount` (minor units) and `prices[0].currency` (which carries `decimal_digits` and the `template` whose `$1` placeholder you replace when formatting). There is **no** top-level `amount` on a variant.
+- Product detail resolves by **product id** only; a slug returns 404 (map slug→id from the list endpoint). `limit` max is 100 on list endpoints (else 400).
+- Filter variants with `product_ids[]=...`; the unfiltered variant list is eventually-consistent right after catalog edits.
+- Cart lives in the site (e.g. `localStorage`): persist only `variant_id` + `quantity`, resolve display data from the live catalog — never a saved copy — then send everything in one checkout call:
+
+```
+POST /channels/{sales_channel_id}/checkout
+{ "items":[{ "variant_id":"variant_01...", "quantity":1 }],
+  "success_url":"https://YOURDOMAIN/checkout/success/",
+  "cancel_url":"https://YOURDOMAIN/checkout/cancel/",
+  "locale":"en" }
+```
+
+`success_url`/`cancel_url` are required — build them from `window.location.origin` and make sure both pages exist. The response is `{ url, cart_token }`; redirect the browser to `url` (Hostinger's hosted checkout).
+
+A multi-step cart alternative exists (`POST /channels/{sales_channel_id}/carts`, `PATCH /carts/{cart_id}`, `POST /carts/{cart_id}/line-items`, `PUT /carts/{cart_id}/shipping-method`, `POST /carts/{cart_id}/complete`) — the single checkout call suffices for a simple buy flow.
+
+## Verify
+
+- A `POST` to the checkout endpoint returns a `url` — test it directly with curl before calling the run done.
+- The `success_url`/`cancel_url` pages return 200 (`curl -s -o /dev/null -w "%{http_code}" https://YOURDOMAIN/checkout/success/`).
+- Open the live site, add to cart, and confirm the redirect to `https://checkout.hostinger.com`.

package/src/servers/agency-hosting.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/agency-hosting.js';
 
-startServer({ name: 'hostinger-agency-hosting-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-agency-hosting-mcp', version: '1.18.0', tools });

package/src/servers/agency-hosting.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/agency-hosting.js';
 
-startServer({ name: 'hostinger-agency-hosting-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-agency-hosting-mcp', version: '1.18.0', tools });

package/src/servers/all.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/all.js';
 
-startServer({ name: 'hostinger-api-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-api-mcp', version: '1.18.0', tools });

package/src/servers/all.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/all.js';
 
-startServer({ name: 'hostinger-api-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-api-mcp', version: '1.18.0', tools });

package/src/servers/billing.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/billing.js';
 
-startServer({ name: 'hostinger-billing-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-billing-mcp', version: '1.18.0', tools });

package/src/servers/billing.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/billing.js';
 
-startServer({ name: 'hostinger-billing-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-billing-mcp', version: '1.18.0', tools });

package/src/servers/dns.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/dns.js';
 
-startServer({ name: 'hostinger-dns-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-dns-mcp', version: '1.18.0', tools });

package/src/servers/dns.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/dns.js';
 
-startServer({ name: 'hostinger-dns-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-dns-mcp', version: '1.18.0', tools });

package/src/servers/domains.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/domains.js';
 
-startServer({ name: 'hostinger-domains-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-domains-mcp', version: '1.18.0', tools });

package/src/servers/domains.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/domains.js';
 
-startServer({ name: 'hostinger-domains-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-domains-mcp', version: '1.18.0', tools });

package/src/servers/ecommerce.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/ecommerce.js';
 
-startServer({ name: 'hostinger-ecommerce-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-ecommerce-mcp', version: '1.18.0', tools });

package/src/servers/ecommerce.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/ecommerce.js';
 
-startServer({ name: 'hostinger-ecommerce-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-ecommerce-mcp', version: '1.18.0', tools });

package/src/servers/horizons.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/horizons.js';
 
-startServer({ name: 'hostinger-horizons-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-horizons-mcp', version: '1.18.0', tools });

package/src/servers/horizons.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/horizons.js';
 
-startServer({ name: 'hostinger-horizons-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-horizons-mcp', version: '1.18.0', tools });

package/src/servers/hosting.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/hosting.js';
 
-startServer({ name: 'hostinger-hosting-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-hosting-mcp', version: '1.18.0', tools });

package/src/servers/hosting.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/hosting.js';
 
-startServer({ name: 'hostinger-hosting-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-hosting-mcp', version: '1.18.0', tools });

package/src/servers/mail.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/mail.js';
 
-startServer({ name: 'hostinger-mail-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-mail-mcp', version: '1.18.0', tools });

package/src/servers/mail.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/mail.js';
 
-startServer({ name: 'hostinger-mail-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-mail-mcp', version: '1.18.0', tools });

package/src/servers/reach.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/reach.js';
 
-startServer({ name: 'hostinger-reach-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-reach-mcp', version: '1.18.0', tools });

package/src/servers/reach.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/reach.js';
 
-startServer({ name: 'hostinger-reach-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-reach-mcp', version: '1.18.0', tools });

package/src/servers/vps.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/vps.js';
 
-startServer({ name: 'hostinger-vps-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-vps-mcp', version: '1.18.0', tools });

package/src/servers/vps.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/vps.js';
 
-startServer({ name: 'hostinger-vps-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-vps-mcp', version: '1.18.0', tools });

package/src/servers/wordpress.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/wordpress.js';
 
-startServer({ name: 'hostinger-wordpress-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-wordpress-mcp', version: '1.18.0', tools });

package/src/servers/wordpress.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/wordpress.js';
 
-startServer({ name: 'hostinger-wordpress-mcp', version: '1.17.0', tools });
+startServer({ name: 'hostinger-wordpress-mcp', version: '1.18.0', tools });