@hostinger/mcp 3.2.2 → 3.3.1

package/src/servers/agency-hosting.js

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

package/src/servers/agency-hosting.ts

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

package/src/servers/agent-readiness.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/agent-readiness.js';
 
-startServer({ name: 'hostinger-agent-readiness-mcp', version: '3.2.2', tools });
+startServer({ name: 'hostinger-agent-readiness-mcp', version: '3.3.1', tools });

package/src/servers/agent-readiness.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/agent-readiness.js';
 
-startServer({ name: 'hostinger-agent-readiness-mcp', version: '3.2.2', tools });
+startServer({ name: 'hostinger-agent-readiness-mcp', version: '3.3.1', tools });

package/src/servers/all.js

@@ -5,4 +5,4 @@ import tools from '../core/tools/all.js';
 import instructions from '../core/instructions.js';
 import skills from '../core/skills.js';
 
-startServer({ name: 'hostinger-api-mcp', version: '3.2.2', tools, instructions, skills });
+startServer({ name: 'hostinger-api-mcp', version: '3.3.1', tools, instructions, skills });

package/src/servers/all.ts

@@ -5,4 +5,4 @@ import tools from '../core/tools/all.js';
 import instructions from '../core/instructions.js';
 import skills from '../core/skills.js';
 
-startServer({ name: 'hostinger-api-mcp', version: '3.2.2', tools, instructions, skills });
+startServer({ name: 'hostinger-api-mcp', version: '3.3.1', tools, instructions, skills });

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: '3.2.2', tools });
+startServer({ name: 'hostinger-billing-mcp', version: '3.3.1', 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: '3.2.2', tools });
+startServer({ name: 'hostinger-billing-mcp', version: '3.3.1', 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: '3.2.2', tools });
+startServer({ name: 'hostinger-dns-mcp', version: '3.3.1', 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: '3.2.2', tools });
+startServer({ name: 'hostinger-dns-mcp', version: '3.3.1', 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: '3.2.2', tools });
+startServer({ name: 'hostinger-domains-mcp', version: '3.3.1', 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: '3.2.2', tools });
+startServer({ name: 'hostinger-domains-mcp', version: '3.3.1', 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: '3.2.2', tools });
+startServer({ name: 'hostinger-ecommerce-mcp', version: '3.3.1', 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: '3.2.2', tools });
+startServer({ name: 'hostinger-ecommerce-mcp', version: '3.3.1', 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: '3.2.2', tools });
+startServer({ name: 'hostinger-horizons-mcp', version: '3.3.1', 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: '3.2.2', tools });
+startServer({ name: 'hostinger-horizons-mcp', version: '3.3.1', tools });

package/src/servers/hosting.js

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

package/src/servers/hosting.ts

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

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: '3.2.2', tools });
+startServer({ name: 'hostinger-mail-mcp', version: '3.3.1', 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: '3.2.2', tools });
+startServer({ name: 'hostinger-mail-mcp', version: '3.3.1', 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: '3.2.2', tools });
+startServer({ name: 'hostinger-reach-mcp', version: '3.3.1', 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: '3.2.2', tools });
+startServer({ name: 'hostinger-reach-mcp', version: '3.3.1', 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: '3.2.2', tools });
+startServer({ name: 'hostinger-vps-mcp', version: '3.3.1', 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: '3.2.2', tools });
+startServer({ name: 'hostinger-vps-mcp', version: '3.3.1', 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: '3.2.2', tools });
+startServer({ name: 'hostinger-wordpress-mcp', version: '3.3.1', 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: '3.2.2', tools });
+startServer({ name: 'hostinger-wordpress-mcp', version: '3.3.1', tools });

package/skills/headless/entry/skill.md

@@ -1,79 +0,0 @@
----
-name: hostinger-headless-entry
-description: "Build a complete website on Hostinger from a single prompt — hosting, domain, and (optionally) a store with real checkout or a blog/CMS the owner edits in WordPress. 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, blog, business website, sell online, online shop, add a blog to my site, 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, sets up a WordPress content backend when the owner needs to edit content themselves, builds, deploys, and verifies.
-
-- Don't provision hosting, create stores, install WordPress, or deploy by hand here — the skill does all of that (`references/SETUP.md`, `references/DEPLOYMENT.md`, `references/STORE.md`, `references/WORDPRESS.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/DATABASE.md

@@ -1,49 +0,0 @@
-# Database and runtime — MySQL hosts, env vars, and what to poll
-
-Use this when the app needs MySQL, or when a deploy "succeeded" but the app cannot reach its database. Everything here uses the **hosting** MCP operations; Agency Plan differences are at the end.
-
-## 1. Create the database
-
-1. `hosting_databases_create` on the site's `username` with a database name, a user and a password you generate — name and user are prefixed with the account username automatically.
-2. Read the full, prefixed `name` and `user` back from `hosting_databases_list`; every other database operation wants the full name.
-3. Do not print the password to the user once it is stored, and never commit it.
-
-## 2. Which host the app connects to
-
-| Where the code runs | Host | Port | Why |
-| --- | --- | --- | --- |
-| PHP on the website | `localhost` or `127.0.0.1` | 3306 | `localhost` uses the MySQL socket; both are granted |
-| Node.js on the website | `127.0.0.1` | 3306 | `localhost` may resolve to IPv6 `::1`, and not every database user has that grant |
-| Outside Hostinger (a laptop, another server) | the `host` from `hosting_databases_list` (`srvNNNN.hstgr.io`) | 3306 | needs `hosting_databases_create-remote-connection` for that client's IP first — never `%`, it opens the database to every address on the internet |
-
-Do not put the remote `host` into the deployed app — it has no grant for connections that come from the server itself.
-
-## 3. Hand credentials to the app
-
-- **Node.js:** environment variables via `hosting_nodejs_replace-environment-variables`. Conventional keys: `DB_HOST=127.0.0.1`, `DB_PORT=3306`, `DB_NAME`, `DB_USER`, `DB_PASSWORD`, plus `DATABASE_URL=mysql://USER:PASSWORD@127.0.0.1:3306/NAME` for ORMs that want one string — URL-encode `USER` and `PASSWORD` there (`encodeURIComponent`), or a password containing `@`, `:`, `/` or `#` breaks the URL. The call is a **full replace**: list the current keys with `hosting_nodejs_list-environment-variables` (values come back masked as `********` — never copy those), then send the complete set with real values. Saving restarts the process; frameworks that bake variables into the build (Next.js, `NEXT_PUBLIC_*`) need a new `hosting_nodejs_start-build` afterwards.
-- **PHP:** a config file on the server that the app reads (its own `config.php`, WordPress's `wp-config.php`). Ship it with the deploy, keep it out of git.
-- **Never** in client-side JavaScript, in a committed `.env`, or in chat replies.
-
-## 4. What is asynchronous, and what to poll
-
-| You called | Poll this until | Typical wait |
-| --- | --- | --- |
-| `hosting_websites_create` | `hosting_websites_list-setups` with the domain reports `status: completed` | up to a few minutes |
-| `hosting_deploy` of a Node.js app | `hosting_get-deployment` reports a `completed` or `failed` build | minutes |
-| `hosting_nodejs_start-build` (hosted server, which has no `hosting_deploy`) | `hosting_nodejs_build` state is `completed` or `failed` | minutes |
-| `wordpress_installations_install`, plugin/theme/core jobs | `wordpress_installations_list` lists the install | 1–2 minutes |
-| `hosting_databases_repair`, `hosting_websites_delete` | nothing to poll — runs in the background | minutes |
-| `agency-hosting_website-setups_create` | `agency-hosting_website-setups_status` with `setup_uuid` is `completed` | minutes |
-
-Poll with backoff (a few seconds, then tens of seconds). A queued response is not a failure, and re-sending the write does not speed it up.
-
-## 5. When the app is up but broken
-
-- Build failed: `hosting_get-deployment` returns the logs and a diagnosis together (hosted server: `hosting_nodejs_build-logs` for the raw log, `hosting_nodejs_analyse-failed-build` for a diagnosis).
-- Build passed, app errors: `hosting_nodejs_runtime-logs` with a `period` such as `1h`; entries before `last_deployed_at` belong to the previous deploy.
-- `Access denied for user 'x'@'::1'`: the app used `localhost` from Node.js — set `DB_HOST` to `127.0.0.1`.
-- PHP limits (memory, upload size): `hosting_php_get`, then `hosting_php_update-options`.
-
-## Agency Plan websites (`agency-hosting_*`)
-
-`agency-hosting_databases_create-website` creates the database and its single user; the user is granted on `localhost`, so the PHP app connects to `localhost`. Deploys are synchronous there — `agency-hosting_deploy-php-application` returns when the site is live. Other jobs (SSL, backups) show up in `agency-hosting_websites_list-processes`.

package/skills/headless/references/DEPLOYMENT.md

@@ -1,34 +0,0 @@
-# Deployment — getting the build live
-
-Match the deploy method to what the project actually is — this is the single most common failure point.
-
-On the local `hostinger-api-mcp` server one operation does every deploy: `hosting_deploy` with `domain` and `path` (the project directory; it detects the type, packs the files itself; it skips `node_modules`, `.git` and `.env` files, reporting the `.env` ones as `skippedFiles` (set their values with `hosting_nodejs_replace-environment-variables`); it does not read `.gitignore`, so keep build output out of the directory) or `git: { repository, branch }` with `type: "static"` or `"nodejs"` (a new site is not yet detected as Node.js). It reads files from this machine, so the hosted server (`mcp.hostinger.com`) does not have it: there, upload the files and deploy from the upload as described in the `deploy-to-hosting` skill ("Without the local deploy operations"). Agency Plan sites deploy through the Agency operations listed there as well.
-
-## Static site → `hosting_deploy` (detected as `static`)
-
-For pre-built files only: plain HTML/CSS/JS, or the **build output** of a framework (run the build locally first, then pass the output directory as `path`).
-
-- `index.html` must be at the **root** of that directory — not nested inside a folder.
-- Deployment is effectively immediate — verify right after.
-
-## Node.js app → `hosting_deploy` (detected as `nodejs`)
-
-For anything that needs a server or a server-side build (Express, Next.js, NestJS, SSR frameworks). Pass the project's **source** directory, not the output: the install and build run on Hostinger.
-
-- The call returns a `buildUuid` and the build runs on the server. Track it with `hosting_get-deployment` (`domain`) until `build.state` is `completed` or `failed`; on failure the response carries the logs and an analysis — fix, and deploy again. Poll with backoff: builds take minutes, not seconds.
-- When the framework, output directory or entry file is detected wrong, pass `appType`, `outputDirectory`, `buildScript` or `entryFile` to `hosting_deploy`. A TypeScript or other compiled server app always needs `entryFile` set to the built file (for example `dist/server.js`).
-
-## WordPress → `hosting_deploy` with `type: "wordpress-site"` / plugin & theme directories
-
-Only when the user explicitly wants a WordPress *site* migrated or themed. A site import takes the site directory plus `databaseDump` (a `.sql` file) and can run for several minutes; a plugin or theme directory is detected from its header (`activate: true` activates a theme). (WordPress as a headless content backend behind an agent-built frontend is a different flow — that's `WORDPRESS.md`, installed fresh via the API, not imported here.)
-
-## 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_cache_clear-website`) 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

@@ -1,35 +0,0 @@
-# Setup — plan check and website provisioning
-
-Everything here uses the **hosting** MCP operations. 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_websites_list` — if it returns websites, the account has a working plan; note any existing `order_id` and `username` for step 2.
-2. Otherwise `hosting_orders_list` — look for an order in a usable state. A fresh order that has never hosted a website still works; note its `order_id`.
-3. Agency Plan orders are not in that list: check `agency-hosting_orders_list` too. An active Agency order is a usable plan — create the website with `agency-hosting_website-setups_create` and poll `agency-hosting_website-setups_status` until `completed` (it returns the `website_uid`), then deploy with the Agency operations in the `deploy-to-hosting` skill.
-4. 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_domains_generate-free-subdomain` returns a `*.hostingersite.com` domain. No verification needed. Tell the user a custom domain can be connected later.
-- **User-owned domain:** `hosting_domains_verify-ownership` 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_availability_check`, state the price, and get an explicit yes before `domains_portfolio_purchase` (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_websites_create { domain, order_id }` — `datacenter_code` is required only for the first website on a brand-new plan (pick the first entry from `hosting_datacenters_list`).
-2. **Poll** `hosting_websites_list-setups` filtered by the domain every 10–15 s until `status` is `completed`. The site shows up in `hosting_websites_list` before its setup finishes, and uploads, deploys and database calls return 404 or 409 until then. Creation takes up to a few minutes — don't fail fast.
-3. Note the site's `username` — deployment and database operations 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:** when the app needs MySQL, follow `DATABASE.md` — creating it, which host each runtime connects to (Node.js must use `127.0.0.1`), and handing the credentials to the app without hard-coding them.
-- **DNS records:** the DNS operations (`dns_records_update` etc.) for custom-domain records; take a snapshot (`dns_snapshots_list` context) before destructive changes.

package/skills/headless/references/STORE.md

@@ -1,52 +0,0 @@
-# Store — Hostinger Ecommerce with a custom storefront
-
-**Primary source:** execute `ecommerce_miscellaneous_custom-storefront-setup-instructions` 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 operations 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_stores_list` → `ecommerce_sales-channels_list`. 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_sales-channels_create`, or create a store with `ecommerce_stores_create` (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_stores_metadata` (`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_products_create-physical` / `ecommerce_products_create-digital`, `ecommerce_payments_enable-manual-method`, and `ecommerce_shipping_set-store` (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_sales-channels_update { store_id, sales_channel_id, url }`.
-
-If the ecommerce operations 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/skills/headless/references/WORDPRESS.md

@@ -1,51 +0,0 @@
-# WordPress — headless CMS and blog backend
-
-Use WordPress when the site has **owner-managed content**: a blog, news, articles, or any content the owner must edit without a developer or a redeploy. The frontend stays agent-built and is deployed like any other run; WordPress runs separately as the content backend, and the owner writes in wp-admin.
-
-**When NOT to use this:** static copy that rarely changes (an about page, a services list, a brochure site) — bake that into the frontend. Installing WordPress for content the owner will never edit adds a moving part for nothing. Any buy/sell intent is `STORE.md`, not this file.
-
-Everything in Setup uses the **hosting** and **wordpress** MCP operation groups; ask the user to enable them in the Hostinger Connector if operations are missing.
-
-## Mental model
-
-Two surfaces, like the store recipe:
-
-| Surface | Base URL | Auth | Use for |
-| --- | --- | --- | --- |
-| WP REST API | `https://CMS_DOMAIN/wp-json/wp/v2` | none for published content (open CORS) | frontend reads: posts, pages, media, categories |
-| Management (MCP tools + wp-admin) | Hostinger API / wp-admin | authenticated | install WP, plugins, cache; the owner writes content |
-
-- Published content is publicly readable and the REST API allows cross-origin browser reads — a static frontend on another domain fetches it directly at runtime.
-- Drafts, previews, and **writes need authentication** (WP application passwords). Never put credentials of any kind in the frontend; a public site only needs the anonymous read path.
-
-## Setup (management tools)
-
-1. **Check for an existing installation first**: `wordpress_installations_list` filtered by the site's username/domain. Reuse a valid install when the user agrees — never overwrite one silently.
-2. **Choose where WordPress lives.** Default: a dedicated subdomain of the site, e.g. `cms.<domain>` — create it with `hosting_domains_create-website-subdomain` so the main domain stays free for the frontend. A separate free-subdomain website (per `SETUP.md`) also works when the plan allows another website.
-3. **Install**: `wordpress_installations_install` on that domain. The call only queues the job — **poll** `wordpress_installations_list` until the installation appears (typically 1–2 minutes). Don't proceed on the queued response alone.
-4. **Hand the owner their editor**: mint a one-click wp-admin link with `wordpress_login_create-links` and show it to the user. Content authoring happens in wp-admin — the skill does not seed posts (there is no anonymous write path, by design). The fresh install ships with a sample post, which is enough to build and verify the frontend against.
-5. **Caching** (recommended before finishing): enable the object cache with `wordpress_object-cache_toggle-memcached`; after config changes, purge with `wordpress_litespeed-cache_purge-lite-speed`.
-
-## Frontend contract
-
-All paths relative to `https://CMS_DOMAIN/wp-json/wp/v2`. Non-obvious rules:
-
-- **Fetch at runtime, not build time** — content changes whenever the owner publishes; baking it into a static build defeats the purpose. Client-side fetch on page load is fine (CORS is open).
-- List posts with `/posts?per_page=10&_embed` — `_embed` inlines featured images (`_embedded['wp:featuredmedia'][0].source_url`), authors, and terms; without it you get IDs that need extra requests.
-- Post bodies are **rendered HTML**: use `title.rendered` / `content.rendered` / `excerpt.rendered` and render them as HTML — do not treat them as plain text and do not try to restyle their inner markup beyond CSS.
-- Single post by slug: `/posts?slug=my-post` — returns an **array** (take the first element); there is no direct slug path.
-- Pagination comes from the `X-WP-Total` / `X-WP-TotalPages` response headers, not the body.
-- Only **published** content is returned anonymously. An empty list is a normal state — the frontend must render it gracefully, not error.
-- SEO is the frontend's job: page titles, meta tags, and the sitemap come from the frontend build, not from WordPress plugins.
-
-## Verify
-
-```bash
-curl -s -o /dev/null -w "%{http_code}\n" "https://CMS_DOMAIN/wp-json/wp/v2/posts?per_page=1"
-```
-
-Expect 200 with a JSON array. Then confirm the deployed frontend renders the sample post (or a clean empty state), and show the user two links: the live site and the wp-admin login for writing content.
-
-## Record
-
-Add `"cms_domain"` to `.hostinger/site.json` (see `SKILL.md` §Record) so iterate runs know a WordPress backend exists and reuse it instead of installing again.