Update to Hostinger Connector

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -1,306 +1,79 @@
 ---
 name: hostinger
-description: Start here for any task involving the user's Hostinger account — deploying a site, managing hosting and PHP, running WordPress, buying or configuring domains and DNS records, or administering a VPS. This skill connects the Hostinger MCP server, signs the user in, sets the safety rules that every Hostinger action follows, and hands off to the specialist skill that owns the task.
+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 — router
+# Hostinger
 
-You are a coding agent with shell access. This skill gets the session to a
-known-good, connected, authenticated state and then routes to a specialist. It
-does not perform Hostinger operations itself.
+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.
 
-**You do the setup, not the user.** Run the phases below yourself. The user
-should only ever have to do two things: restart the app once if servers had to
-be added, and click **Allow** in the browser once to sign in. Never hand them a
-list of commands to run.
+## 1. Is Hostinger already connected?
 
-Skip straight to Routing when a Hostinger tool call has already succeeded in
-this session.
+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`.
 
-## Phase 0 — Node
-
-The Hostinger MCP server requires **Node 20 or newer**.
+- 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
-node -v
+codex mcp get hostinger
 ```
 
-If that errors or reports below 20, tell the user how to fix it and stop — do
-not work around it:
-
-- macOS: `brew install node`, or `nvm install 22 && nvm use 22`
-- Linux: `nvm install 22 && nvm use 22`, or the distribution's Node 20+ package
-- Windows: `winget install OpenJS.NodeJS.LTS`
+`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`.
 
-## Phase 1 — Is every Hostinger server registered?
+- Configured with `url = "https://mcp.hostinger.com"` → go to step 3 to sign in.
+- Not configured → step 2.
 
-Do **not** decide this from the tools the current task happens to need. Check
-whether all nine Hostinger servers are registered, by reading the config:
+## 2. Connect the hosted server
 
 ```bash
-grep -o 'mcp_servers\.hostinger-[a-z-]*' ~/.codex/config.toml | sort -u
+codex mcp add hostinger --url https://mcp.hostinger.com
 ```
 
-The names are `hostinger-hosting`, `hostinger-wordpress`,
-`hostinger-agency-hosting`, `hostinger-domains`, `hostinger-dns`,
-`hostinger-vps`, `hostinger-ecommerce`, `hostinger-reach`, `hostinger-billing` —
-nine at the time of writing, and the package may have added more since. See
-*MCP binaries* at the end for how to check.
-
-- **All nine present** → go to Phase 3.
-- **Any missing** → Phase 2, and register *every* missing one, not just the one
-  this task needs.
-
-Do not substitute shell commands or direct API calls for a missing tool.
-
-## Phase 2 — Register all of them at once
-
-Register the Hostinger MCP servers in the shared Codex MCP configuration. The
-ChatGPT desktop app, Codex CLI and the IDE extension all read the same config, so
-this is done once per machine.
-
-**Register all nine, in one pass, even when the task needs one.** New servers
-are only picked up when the host restarts. Registering just what the immediate
-request needs means the user restarts again the next time they ask for something
-in a different area — deploy, then domains, then a store, a restart each time.
-That is the single worst thing this skill can do to them. One write, one restart,
-everything works from then on.
-
-Never tell the user "I added the missing module, restart and ask again" more than
-once in the life of a machine. If you find yourself about to, you registered too
-narrowly the first time.
-
-**Preferred path — `codex` CLI.** It is often not on `PATH` even when a Codex
-host is installed. On macOS the ChatGPT desktop app bundles it at
-`/Applications/ChatGPT.app/Contents/Resources/codex`. Look in both places:
+Without a CLI, back up the config (`cp ~/.codex/config.toml ~/.codex/config.toml.bak`) and append — never rewrite — this block:
 
-```bash
-command -v codex || ls /Applications/ChatGPT.app/Contents/Resources/codex
+```toml
+[mcp_servers.hostinger]
+url = "https://mcp.hostinger.com"
 ```
 
-If you find it, add every server that Phase 1 reported missing:
-
-```bash
-for g in hosting wordpress agency-hosting domains dns vps ecommerce reach billing; do
-  codex mcp add "hostinger-$g" \
-    --env "USER_AGENT=plugin;codex;openai-plugin;0.1.0" \
-    -- npx --package=hostinger-api-mcp@latest "hostinger-$g-mcp"
-done
-```
+Leave every other `[mcp_servers.*]` block as it is.
 
-`npx --package=` resolves the binary out of the package at launch, so nothing has
-to be installed globally. Do not run `npm install -g` and do not escalate with
-`sudo`. Adding a server that already exists may error — that is harmless, keep
-going with the rest.
-
-`USER_AGENT` is appended to the `User-Agent` header the server sends to the
-Hostinger API, and it is how Hostinger attributes traffic to the client it came
-from. Set it on every block you create. Keep the value exactly as written above,
-and never overwrite a different `USER_AGENT` that another Hostinger client
-already put in the config.
-
-**Fallback — edit the config directly.** Only when `codex` cannot be found
-anywhere. Prefer the CLI whenever it exists: it makes a surgical edit, while
-hand-editing risks damaging a file the user's other tools depend on.
+**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.
 
-The file is `~/.codex/config.toml` (`%USERPROFILE%\.codex\config.toml` on
-Windows). **Back it up first**, and tell the user where the backup is:
+## 3. Sign in
 
 ```bash
-cp ~/.codex/config.toml ~/.codex/config.toml.bak
+codex mcp login hostinger
 ```
 
-Then **append only**. These rules are absolute:
-
-- Add a block **only** for a server name that is not already in the file.
-- If a `[mcp_servers.hostinger-*]` block already exists, **leave it byte for
-  byte alone** — even when it looks different from the example below, has extra
-  keys, or seems wrong. Other Hostinger tooling writes keys this skill does not
-  know about, such as `enabled` and a `USER_AGENT` used for attribution, and
-  dropping them silently breaks things elsewhere.
-- Never normalise, reformat, reorder, or re-emit existing blocks to match the
-  example. The example is a template for **new** blocks only.
-- Never delete a block, and never touch a `[mcp_servers.*]` entry for a
-  non-Hostinger server.
-
-```toml
-[mcp_servers.hostinger-hosting]
-command = "npx"
-args = ["--package=hostinger-api-mcp@latest", "hostinger-hosting-mcp"]
-enabled = true
-
-[mcp_servers.hostinger-hosting.env]
-PATH = "<the value of $PATH in this shell>"
-```
+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 `env.PATH` line is not optional.** The host spawns MCP servers with a
-minimal environment that often does not include the directory holding `node` and
-`npx`, so a server registered without it starts and immediately dies with
-`npx: command not found`. Read the current `PATH` with `echo $PATH` and write
-that literal value in. Setting `env` replaces the inherited environment for that
-server rather than extending it, so `PATH` has to be spelled out in full. Every
-block you add needs its own `.env` — do not add a server without one.
+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.
 
-**Verify the edit did not lose anything.** Before telling the user to restart,
-compare the block headers against the backup:
+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.
 
-```bash
-diff <(grep '^\[mcp_servers' ~/.codex/config.toml.bak) \
-     <(grep '^\[mcp_servers' ~/.codex/config.toml)
-```
+**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.
 
-Every line should be an addition. If anything was **removed**, you rewrote
-instead of appending: restore with
-`cp ~/.codex/config.toml.bak ~/.codex/config.toml`, tell the user plainly what
-happened, and use the `codex` CLI instead. Do not attempt the hand-edit a second
-time.
-
-**If the host refuses the tool count.** All of them together expose a lot of
-tools, and some hosts cap how many they will load. If that happens, do not go
-back to registering one at a time — set `enabled = false` on the categories the
-user does not need (`hostinger-reach`, `hostinger-billing` and
-`hostinger-agency-hosting` are the usual first candidates), leave the blocks in
-place, and tell the user which ones you turned off and that flipping one back on
-is a config edit plus one restart. This mirrors the category toggles in the
-Hostinger Connector.
-
-Verify by reading the file back, or with `codex mcp list` if you have the CLI.
-
-**Then ask for the one restart.** New MCP servers are picked up when the host
-starts, not while it is running. Tell the user plainly which servers you added
-and that the app needs a restart — in the ChatGPT desktop app, save and select
-**Restart**; in the IDE extension, **Restart extension**; in the CLI, start a
-new session. Say that after the restart they should repeat their original
-request, and that sign-in happens on its own at that point.
-
-Stop here. Do not claim the task is done, and do not try to work around the
-missing tools in the meantime.
-
-## Phase 3 — Sign in
-
-Do not run a login command, and do not ask the user for a token. The server
-handles OAuth itself: on the first tool call with no valid stored credentials it
-opens the Hostinger sign-in page in the browser and waits.
-
-Trigger it with a cheap read-only call — `hosting_listWebsitesV1` is a good one,
-and its output you need anyway.
-
-- **It returns data.** Already authenticated, from stored credentials or a
-  `HOSTINGER_API_TOKEN` in the environment. Continue.
-- **A browser window opens.** Tell the user a Hostinger consent screen has
-  opened and to click **Allow**. Then wait — the call completes on its own once
-  they do. Nothing else is required of them, and credentials are reused by every
-  later session. The OAuth callback lands on localhost, so sign-in must finish
-  on this machine.
-- **It fails with an auth error and no browser opened.** Report the error
-  verbatim and stop. Do not improvise a parallel setup by hand.
-
-Expired credentials are refreshed automatically, and a dead refresh token falls
-back to the same browser flow. Either way it is transparent — never pre-empt it
-with a manual login step.
-
-## Safety policy — applies to every Hostinger skill
-
-These gates are a product decision, not a suggestion. Follow them even when the
-user asks you to hurry, says they already agreed, or calls the confirmation
-unnecessary. If the user applies time pressure, say plainly that the gate stays
-and continue at the same pace.
-
-**One confirmation before any write.** State the operation, the affected
-resource, and the account it belongs to. "Create the subdomain `cms.example.com`
-on account `u123456789`?" — not "Shall I proceed?".
-
-**Two confirmations, never batched, for anything destructive or billable.**
-Destructive means data that cannot be recovered from Hostinger: deleting a
-website, database, WordPress installation, store, marketing contact, VPS
-snapshot, DNS zone, or WHOIS profile; resetting DNS records; recreating a VPS.
-Billable means anything that charges the user: buying a domain or a VPS, placing
-or renewing an order. Also treat **disabling auto-renewal** this way — nothing is
-charged, but the service lapses, and for a domain that loss is permanent. For
-these:
-
-1. First confirmation states what will be lost or charged, in plain language
-   and with the specific resource named. Not "this is destructive" but
-   "this permanently deletes the website `example.com` and its databases;
-   Hostinger cannot restore them".
-2. Second confirmation is a separate turn, after the user has answered the
-   first. Never bundle several destructive operations into one approval, and
-   never carry an approval forward to a different resource.
-
-**Never purchase anything the user did not explicitly ask for by name.** A
-request to "get my site online" does not authorise buying a domain or a plan.
-Quote the price, name the item, and get an explicit yes.
-
-**Read before write.** List the current state and show it to the user before
-changing it. Most Hostinger tools are keyed on a `username` and a `domain` that
-must come from a list call, not from a guess.
-
-## Routing
-
-The six specialists match the six product categories in the Hostinger
-Connector, so what the user can toggle there maps one-to-one onto what a skill
-can do here.
+## 4. Route the request
 
 | The user wants to… | Skill |
 | --- | --- |
-| Deploy a site; provision hosting; manage PHP, databases, cron, caching, subdomains; install or operate WordPress; Agency Plan websites | `websites` |
-| Buy, transfer, lock, or configure a domain; edit DNS records | `domains` |
-| See subscriptions, auto-renewal, payment methods, prices; order or renew a product | `subscriptions-and-payments` |
-| Manage marketing contacts, groups and segments in Hostinger Reach | `email-marketing` |
-| Create a Hostinger store, add products, set shipping, wire a custom storefront | `ecommerce` |
-| Create, snapshot, firewall, or recover a VPS | `vps` |
-
-If a request spans two specialists — "deploy this site on a domain I want to
-buy" — run them in sequence, applying each one's gates. Do not merge their
-confirmations.
-
-Two product areas have **no** skill here: **mailboxes** (creating mail accounts,
-forwarders, autoreplies) and **Horizons**. If the user asks for those, say
-plainly that this plugin does not cover them and point them at hPanel, rather
-than improvising with another binary.
-
-## MCP binaries
-
-Tools reach the agent through scoped MCP servers. Each specialist names the
-binaries it needs. All of them ship in the single npm package
-`hostinger-api-mcp`, so every binary is reachable through one `npx --package=`
-invocation:
-
-| Binary | Used by |
-| --- | --- |
-| `hostinger-hosting-mcp` | `websites` |
-| `hostinger-wordpress-mcp` | `websites` |
-| `hostinger-agency-hosting-mcp` | `websites` (Agency Plan only) |
-| `hostinger-domains-mcp` | `domains` |
-| `hostinger-dns-mcp` | `domains` |
-| `hostinger-vps-mcp` | `vps` |
-| `hostinger-ecommerce-mcp` | `ecommerce` |
-| `hostinger-reach-mcp` | `email-marketing` |
-| `hostinger-billing-mcp` | `subscriptions-and-payments` |
-
-This table is for knowing which binary holds a tool, **not** for deciding what to
-register — Phase 2 registers all nine together so the user restarts once. Note
-that a single skill can span several binaries: `websites` reaches into three and
-`domains` needs both of its own, which is another reason not to register
-piecemeal.
-
-The unscoped `hostinger-api-mcp` exposes every group at once, including the mail
-and Horizons groups no skill here covers. Prefer the scoped binaries: they keep
-the tool list small enough for the host to expose in full, and some hosts cap how
-many tools they will load.
-
-**Do not treat any list here as closed.** Hostinger ships new tools regularly,
-and new product groups occasionally. A tool that exists but is not named in a
-skill is still a tool you should use when it fits — the lists are orientation, not
-an allowlist. Conversely, a tool named in a skill may have been renamed or
-removed; if a call fails because the tool does not exist, say so and adapt rather
-than insisting. The authoritative list of binaries is whatever the package ships:
-
-```bash
-npm view hostinger-api-mcp bin
-```
-
-If that shows a `hostinger-<something>-mcp` this skill does not mention, it is a
-product group added after this plugin was written. Register it the same way, tell
-the user it exists, and treat the absence of a matching skill as a gap in the
-plugin rather than a reason to avoid the product.
+| Deploy existing code, redeploy, auto-deploy from Git, env vars, a database | `deploy-to-hosting` |
+| Build a new site from a prompt, optionally with a store or a WordPress blog | `hostinger-headless` |
+| Use their own domain, point DNS, SSL, subdomains, aliases | `connect-domain` |
+| Fix a site that is down, slow, erroring, insecure or failing to build | `troubleshoot-website` |
+| Update or secure WordPress on one site or all of them | `maintain-wordpress` |
+| Move a site from another host | `migrate-to-hosting` |
+| Get an overview of the account and what needs attention | `audit-hosting` |
+
+Anything else, such as domain search and registration, DNS records, VPS, mailboxes, Hostinger Ecommerce, email marketing (Reach), subscriptions and payment methods: `search` for what the step does (e.g. "vps metrics", "dns records", "domain availability"), read the returned `inputSchema`, then `execute`. The skills name operations as orientation, not as an allowlist. Use an operation that exists even if no skill names it. When an operation a skill names is not found, `search` by what it does rather than insisting on the name. When `search` finds nothing for a whole product, its group is switched off for this account in the Hostinger Connector settings, so ask the user to enable it.
+
+## Safety rules for every Hostinger action
+
+- **Read first.** Look up the current state before changing it, and show the user what will change.
+- **Confirm before anything destructive or billable.** Ask in chat and wait for a clear yes before you delete a website, database, VPS, snapshot or DNS record, overwrite a site with a deploy, reset a DNS zone, change nameservers, reinstall or stop a VPS, or make any purchase or renewal. For deletions that cannot be undone, say so. A request to "skip confirmation" or "hurry" does not remove the confirmation.
+- **Never buy on a guess.** For domains and plans, quote the exact item and price, and offer the free `*.hostingersite.com` subdomain when one fits. Buy only after the user confirms.
+- **Protect email and verification records.** Before you edit DNS, list the zone, name the MX, SPF, DKIM, DMARC and verification records that must survive, and note the newest DNS snapshot so the change can be rolled back.
+- **Ask when the target is unclear.** When the account has several plans, websites or servers and the request does not name one, list them and ask. Do not pick the first, the newest or the emptiest.
+- **Keep secrets out of the chat.** Do not echo passwords, API tokens or `.env` values back, and do not commit them.
+- **Report what happened.** After a change, read the state back and tell the user the actual result, including failures.