Update to Hostinger Connector

{
  "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.",
  "included_files": [],
  "name": "hostinger",
  "skill_md_contents": "---\nname: hostinger\ndescription: 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.\n---\n\n# Hostinger — router\n\nYou are a coding agent with shell access. This skill gets the session to a\nknown-good, connected, authenticated state and then routes to a specialist. It\ndoes not perform Hostinger operations itself.\n\n**You do the setup, not the user.** Run the phases below yourself. The user\nshould only ever have to do two things: restart the app once if servers had to\nbe added, and click **Allow** in the browser once to sign in. Never hand them a\nlist of commands to run.\n\nSkip straight to Routing when a Hostinger tool call has already succeeded in\nthis session.\n\n## Phase 0 — Node\n\nThe Hostinger MCP server requires **Node 20 or newer**.\n\n```bash\nnode -v\n```\n\nIf that errors or reports below 20, tell the user how to fix it and stop — do\nnot work around it:\n\n- macOS: `brew install node`, or `nvm install 22 && nvm use 22`\n- Linux: `nvm install 22 && nvm use 22`, or the distribution's Node 20+ package\n- Windows: `winget install OpenJS.NodeJS.LTS`\n\n## Phase 1 — Is every Hostinger server registered?\n\nDo **not** decide this from the tools the current task happens to need. Check\nwhether all nine Hostinger servers are registered, by reading the config:\n\n```bash\ngrep -o 'mcp_servers\\.hostinger-[a-z-]*' ~/.codex/config.toml | sort -u\n```\n\nThe names are `hostinger-hosting`, `hostinger-wordpress`,\n`hostinger-agency-hosting`, `hostinger-domains`, `hostinger-dns`,\n`hostinger-vps`, `hostinger-ecommerce`, `hostinger-reach`, `hostinger-billing` —\nnine at the time of writing, and the package may have added more since. See\n*MCP binaries* at the end for how to check.\n\n- **All nine present** → go to Phase 3.\n- **Any missing** → Phase 2, and register *every* missing one, not just the one\n  this task needs.\n\nDo not substitute shell commands or direct API calls for a missing tool.\n\n## Phase 2 — Register all of them at once\n\nRegister the Hostinger MCP servers in the shared Codex MCP configuration. The\nChatGPT desktop app, Codex CLI and the IDE extension all read the same config, so\nthis is done once per machine.\n\n**Register all nine, in one pass, even when the task needs one.** New servers\nare only picked up when the host restarts. Registering just what the immediate\nrequest needs means the user restarts again the next time they ask for something\nin a different area — deploy, then domains, then a store, a restart each time.\nThat is the single worst thing this skill can do to them. One write, one restart,\neverything works from then on.\n\nNever tell the user \"I added the missing module, restart and ask again\" more than\nonce in the life of a machine. If you find yourself about to, you registered too\nnarrowly the first time.\n\n**Preferred path — `codex` CLI.** It is often not on `PATH` even when a Codex\nhost is installed. On macOS the ChatGPT desktop app bundles it at\n`/Applications/ChatGPT.app/Contents/Resources/codex`. Look in both places:\n\n```bash\ncommand -v codex || ls /Applications/ChatGPT.app/Contents/Resources/codex\n```\n\nIf you find it, add every server that Phase 1 reported missing:\n\n```bash\nfor g in hosting wordpress agency-hosting domains dns vps ecommerce reach billing; do\n  codex mcp add \"hostinger-$g\" \\\n    --env \"USER_AGENT=plugin;codex;openai-plugin;0.1.0\" \\\n    -- npx --package=hostinger-api-mcp@latest \"hostinger-$g-mcp\"\ndone\n```\n\n`npx --package=` resolves the binary out of the package at launch, so nothing has\nto be installed globally. Do not run `npm install -g` and do not escalate with\n`sudo`. Adding a server that already exists may error — that is harmless, keep\ngoing with the rest.\n\n`USER_AGENT` is appended to the `User-Agent` header the server sends to the\nHostinger API, and it is how Hostinger attributes traffic to the client it came\nfrom. Set it on every block you create. Keep the value exactly as written above,\nand never overwrite a different `USER_AGENT` that another Hostinger client\nalready put in the config.\n\n**Fallback — edit the config directly.** Only when `codex` cannot be found\nanywhere. Prefer the CLI whenever it exists: it makes a surgical edit, while\nhand-editing risks damaging a file the user's other tools depend on.\n\nThe file is `~/.codex/config.toml` (`%USERPROFILE%\\.codex\\config.toml` on\nWindows). **Back it up first**, and tell the user where the backup is:\n\n```bash\ncp ~/.codex/config.toml ~/.codex/config.toml.bak\n```\n\nThen **append only**. These rules are absolute:\n\n- Add a block **only** for a server name that is not already in the file.\n- If a `[mcp_servers.hostinger-*]` block already exists, **leave it byte for\n  byte alone** — even when it looks different from the example below, has extra\n  keys, or seems wrong. Other Hostinger tooling writes keys this skill does not\n  know about, such as `enabled` and a `USER_AGENT` used for attribution, and\n  dropping them silently breaks things elsewhere.\n- Never normalise, reformat, reorder, or re-emit existing blocks to match the\n  example. The example is a template for **new** blocks only.\n- Never delete a block, and never touch a `[mcp_servers.*]` entry for a\n  non-Hostinger server.\n\n```toml\n[mcp_servers.hostinger-hosting]\ncommand = \"npx\"\nargs = [\"--package=hostinger-api-mcp@latest\", \"hostinger-hosting-mcp\"]\nenabled = true\n\n[mcp_servers.hostinger-hosting.env]\nPATH = \"<the value of $PATH in this shell>\"\n```\n\n**The `env.PATH` line is not optional.** The host spawns MCP servers with a\nminimal environment that often does not include the directory holding `node` and\n`npx`, so a server registered without it starts and immediately dies with\n`npx: command not found`. Read the current `PATH` with `echo $PATH` and write\nthat literal value in. Setting `env` replaces the inherited environment for that\nserver rather than extending it, so `PATH` has to be spelled out in full. Every\nblock you add needs its own `.env` — do not add a server without one.\n\n**Verify the edit did not lose anything.** Before telling the user to restart,\ncompare the block headers against the backup:\n\n```bash\ndiff <(grep '^\\[mcp_servers' ~/.codex/config.toml.bak) \\\n     <(grep '^\\[mcp_servers' ~/.codex/config.toml)\n```\n\nEvery line should be an addition. If anything was **removed**, you rewrote\ninstead of appending: restore with\n`cp ~/.codex/config.toml.bak ~/.codex/config.toml`, tell the user plainly what\nhappened, and use the `codex` CLI instead. Do not attempt the hand-edit a second\ntime.\n\n**If the host refuses the tool count.** All of them together expose a lot of\ntools, and some hosts cap how many they will load. If that happens, do not go\nback to registering one at a time — set `enabled = false` on the categories the\nuser does not need (`hostinger-reach`, `hostinger-billing` and\n`hostinger-agency-hosting` are the usual first candidates), leave the blocks in\nplace, and tell the user which ones you turned off and that flipping one back on\nis a config edit plus one restart. This mirrors the category toggles in the\nHostinger Connector.\n\nVerify by reading the file back, or with `codex mcp list` if you have the CLI.\n\n**Then ask for the one restart.** New MCP servers are picked up when the host\nstarts, not while it is running. Tell the user plainly which servers you added\nand that the app needs a restart — in the ChatGPT desktop app, save and select\n**Restart**; in the IDE extension, **Restart extension**; in the CLI, start a\nnew session. Say that after the restart they should repeat their original\nrequest, and that sign-in happens on its own at that point.\n\nStop here. Do not claim the task is done, and do not try to work around the\nmissing tools in the meantime.\n\n## Phase 3 — Sign in\n\nDo not run a login command, and do not ask the user for a token. The server\nhandles OAuth itself: on the first tool call with no valid stored credentials it\nopens the Hostinger sign-in page in the browser and waits.\n\nTrigger it with a cheap read-only call — `hosting_listWebsitesV1` is a good one,\nand its output you need anyway.\n\n- **It returns data.** Already authenticated, from stored credentials or a\n  `HOSTINGER_API_TOKEN` in the environment. Continue.\n- **A browser window opens.** Tell the user a Hostinger consent screen has\n  opened and to click **Allow**. Then wait — the call completes on its own once\n  they do. Nothing else is required of them, and credentials are reused by every\n  later session. The OAuth callback lands on localhost, so sign-in must finish\n  on this machine.\n- **It fails with an auth error and no browser opened.** Report the error\n  verbatim and stop. Do not improvise a parallel setup by hand.\n\nExpired credentials are refreshed automatically, and a dead refresh token falls\nback to the same browser flow. Either way it is transparent — never pre-empt it\nwith a manual login step.\n\n## Safety policy — applies to every Hostinger skill\n\nThese gates are a product decision, not a suggestion. Follow them even when the\nuser asks you to hurry, says they already agreed, or calls the confirmation\nunnecessary. If the user applies time pressure, say plainly that the gate stays\nand continue at the same pace.\n\n**One confirmation before any write.** State the operation, the affected\nresource, and the account it belongs to. \"Create the subdomain `cms.example.com`\non account `u123456789`?\" — not \"Shall I proceed?\".\n\n**Two confirmations, never batched, for anything destructive or billable.**\nDestructive means data that cannot be recovered from Hostinger: deleting a\nwebsite, database, WordPress installation, store, marketing contact, VPS\nsnapshot, DNS zone, or WHOIS profile; resetting DNS records; recreating a VPS.\nBillable means anything that charges the user: buying a domain or a VPS, placing\nor renewing an order. Also treat **disabling auto-renewal** this way — nothing is\ncharged, but the service lapses, and for a domain that loss is permanent. For\nthese:\n\n1. First confirmation states what will be lost or charged, in plain language\n   and with the specific resource named. Not \"this is destructive\" but\n   \"this permanently deletes the website `example.com` and its databases;\n   Hostinger cannot restore them\".\n2. Second confirmation is a separate turn, after the user has answered the\n   first. Never bundle several destructive operations into one approval, and\n   never carry an approval forward to a different resource.\n\n**Never purchase anything the user did not explicitly ask for by name.** A\nrequest to \"get my site online\" does not authorise buying a domain or a plan.\nQuote the price, name the item, and get an explicit yes.\n\n**Read before write.** List the current state and show it to the user before\nchanging it. Most Hostinger tools are keyed on a `username` and a `domain` that\nmust come from a list call, not from a guess.\n\n## Routing\n\nThe six specialists match the six product categories in the Hostinger\nConnector, so what the user can toggle there maps one-to-one onto what a skill\ncan do here.\n\n| The user wants to… | Skill |\n| --- | --- |\n| Deploy a site; provision hosting; manage PHP, databases, cron, caching, subdomains; install or operate WordPress; Agency Plan websites | `websites` |\n| Buy, transfer, lock, or configure a domain; edit DNS records | `domains` |\n| See subscriptions, auto-renewal, payment methods, prices; order or renew a product | `subscriptions-and-payments` |\n| Manage marketing contacts, groups and segments in Hostinger Reach | `email-marketing` |\n| Create a Hostinger store, add products, set shipping, wire a custom storefront | `ecommerce` |\n| Create, snapshot, firewall, or recover a VPS | `vps` |\n\nIf a request spans two specialists — \"deploy this site on a domain I want to\nbuy\" — run them in sequence, applying each one's gates. Do not merge their\nconfirmations.\n\nTwo product areas have **no** skill here: **mailboxes** (creating mail accounts,\nforwarders, autoreplies) and **Horizons**. If the user asks for those, say\nplainly that this plugin does not cover them and point them at hPanel, rather\nthan improvising with another binary.\n\n## MCP binaries\n\nTools reach the agent through scoped MCP servers. Each specialist names the\nbinaries it needs. All of them ship in the single npm package\n`hostinger-api-mcp`, so every binary is reachable through one `npx --package=`\ninvocation:\n\n| Binary | Used by |\n| --- | --- |\n| `hostinger-hosting-mcp` | `websites` |\n| `hostinger-wordpress-mcp` | `websites` |\n| `hostinger-agency-hosting-mcp` | `websites` (Agency Plan only) |\n| `hostinger-domains-mcp` | `domains` |\n| `hostinger-dns-mcp` | `domains` |\n| `hostinger-vps-mcp` | `vps` |\n| `hostinger-ecommerce-mcp` | `ecommerce` |\n| `hostinger-reach-mcp` | `email-marketing` |\n| `hostinger-billing-mcp` | `subscriptions-and-payments` |\n\nThis table is for knowing which binary holds a tool, **not** for deciding what to\nregister — Phase 2 registers all nine together so the user restarts once. Note\nthat a single skill can span several binaries: `websites` reaches into three and\n`domains` needs both of its own, which is another reason not to register\npiecemeal.\n\nThe unscoped `hostinger-api-mcp` exposes every group at once, including the mail\nand Horizons groups no skill here covers. Prefer the scoped binaries: they keep\nthe tool list small enough for the host to expose in full, and some hosts cap how\nmany tools they will load.\n\n**Do not treat any list here as closed.** Hostinger ships new tools regularly,\nand new product groups occasionally. A tool that exists but is not named in a\nskill is still a tool you should use when it fits — the lists are orientation, not\nan allowlist. Conversely, a tool named in a skill may have been renamed or\nremoved; if a call fails because the tool does not exist, say so and adapt rather\nthan insisting. The authoritative list of binaries is whatever the package ships:\n\n```bash\nnpm view hostinger-api-mcp bin\n```\n\nIf that shows a `hostinger-<something>-mcp` this skill does not mention, it is a\nproduct group added after this plugin was written. Register it the same way, tell\nthe user it exists, and treat the absence of a matching skill as a gap in the\nplugin rather than a reason to avoid the product.\n"
}