hostinger-api-mcp 1.63.4 → 2.1.0

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "1.63.4",
+  "version": "2.1.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.63.4",
+  "version": "2.1.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.63.4",
+  "version": "2.1.0",
   "packages": [
     {
       "registryType": "npm",
       "identifier": "@hostinger/mcp",
-      "version": "1.63.4",
+      "version": "2.1.0",
       "transport": {
         "type": "stdio"
       },

package/skills/headless/SKILL.md

@@ -12,7 +12,7 @@ The frontend is built ad-hoc to the user's intent — there is no template libra
 ## 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** (plus **ecommerce** when the run involves a store, and **wordpress** when it involves a content backend). 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.
+2. The Hostinger MCP operations for **hosting** (plus **ecommerce** when the run involves a store, and **wordpress** when it involves a content backend). Operation availability varies per user — product groups can be toggled in the Hostinger Connector. When search cannot find a needed operation, ask the user to enable that product group (or configure the scoped binary, e.g. `hostinger-hosting-mcp`) rather than improvising around it.
 3. An active hosting plan (checked in Setup §1). Hostinger hosting is a paid product: if the account has no usable plan, inform the user plainly that a subscription is required, link them to https://www.hostinger.com/web-hosting, and pause until they confirm the purchase. Do not treat this as an error — it is a normal step for new accounts. Everything that doesn't need hosting (planning, building the frontend locally) can proceed while they decide.
 
 ## Resolving the operation
@@ -32,7 +32,7 @@ If signals conflict, ask the user — don't guess.
 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. **Content backend** (`references/WORDPRESS.md`, only when owner-managed content is needed) — install WordPress on a dedicated subdomain, wait until it's ready, and hand the owner a wp-admin login link. The frontend reads it through the public WP REST API.
 5. **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). For content runs, follow the frontend contract in `references/WORDPRESS.md` (posts fetched at runtime from the WP REST API, rendered HTML bodies, graceful empty states). When the app needs MySQL, follow `references/DATABASE.md` (which host each runtime connects to, credentials via env vars or a server-side config file, never in the frontend).
-6. **Deploy** (`references/DEPLOYMENT.md`) — archive and deploy via the matching hosting tool, polling build logs for Node.js runs.
+6. **Deploy** (`references/DEPLOYMENT.md`) — archive and deploy via the matching hosting operation, polling build logs for Node.js runs.
 7. **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; for content runs, confirm the WP REST API returns 200 and the frontend renders posts. Show the user the live URL and where to manage things (hPanel: https://hpanel.hostinger.com, the store dashboard for commerce, wp-admin for content).
 8. **Record** — write `.hostinger/site.json` into the project: `{ "domain", "username", "type": "static"|"nodejs", "sales_channel_id"?, "store_id"?, "cms_domain"? }`. This is what makes future runs resolve as `iterate`.
 
@@ -50,7 +50,7 @@ Run non-interactively wherever possible. The exceptions that must involve the us
 
 ## 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 inputSchema returned by search is authoritative for request shapes — read it 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.
+- The ecommerce operation `ecommerce_miscellaneous_custom-storefront-setup-instructions` returns the current storefront integration guide from the server — execute it at the start of any store run.
+- The Hostinger API reference at https://developers.hostinger.com describes every endpoint behind the operations.

package/skills/headless/references/DATABASE.md

@@ -1,11 +1,11 @@
 # 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 tools; Agency Plan differences are at the end.
+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_createAccountDatabaseV1` 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_listAccountDatabasesV1`; every other database tool wants the full name.
+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
@@ -14,13 +14,13 @@ Use this when the app needs MySQL, or when a deploy "succeeded" but the app cann
 | --- | --- | --- | --- |
 | 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_listAccountDatabasesV1` (`srvNNNN.hstgr.io`) | 3306 | needs `hosting_createDatabaseRemoteConnectionV1` for that client's IP first — never `%`, it opens the database to every address on the internet |
+| 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_replaceNode_jsEnvironmentVariablesV1`. 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_listNode_jsEnvironmentVariablesV1` (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_startNode_jsBuildV1` afterwards.
+- **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.
 
@@ -28,22 +28,22 @@ Do not put the remote `host` into the deployed app — it has no grant for conne
 
 | You called | Poll this until | Typical wait |
 | --- | --- | --- |
-| `hosting_createWebsiteV1` | `hosting_listWebsitesV1` lists the domain | up to a few minutes |
-| `hosting_deployJsApplication` | `hosting_listJsDeployments` shows the build finished | minutes |
-| `hosting_startNode_jsBuildV1` | `hosting_getNode_jsBuildDetailsV1` state is `completed` or `failed` | minutes |
-| `hosting_installWordPressV1`, plugin/theme/core jobs | `hosting_listWordPressInstallationsV1` lists the install | 1–2 minutes |
-| `hosting_repairDatabaseV1`, `hosting_deleteWebsiteV1` | nothing to poll — runs in the background | minutes |
-| `agency-hosting_createANewWebsiteV1` | `agency-hosting_getWebsiteSetupStatusV1` with `setup_uuid` is `completed` | minutes |
+| `hosting_websites_create` | `hosting_websites_list` lists the domain | up to a few minutes |
+| `hosting_deploy-js-application` | `hosting_list-js-deployments` shows the build finished | minutes |
+| `hosting_nodejs_start-build` | `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_getNodeJSBuildLogsV1` for the raw log, `hosting_analyseFailedNode_jsBuildV1` for a diagnosis.
-- Build passed, app errors: `hosting_getNode_jsRuntimeLogsV1` with a `period` such as `1h`; entries before `last_deployed_at` belong to the previous deploy.
+- Build failed: `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_getPHPDetailsV1`, then `hosting_updatePHPOptionsV1`.
+- PHP limits (memory, upload size): `hosting_php_get`, then `hosting_php_update-options`.
 
 ## Agency Plan websites (`agency-hosting_*`)
 
-`agency-hosting_createWebsiteDatabaseV1` 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_deployPhpApplication` returns when the site is live. Other jobs (SSL, backups) show up in `agency-hosting_listWebsiteProcessesV1`.
+`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

@@ -2,7 +2,7 @@
 
 Match the deploy method to what the project actually is — this is the single most common failure point.
 
-## Static site → `hosting_deployStaticWebsite`
+## Static site → `hosting_deploy-static-website`
 
 For pre-built files only: plain HTML/CSS/JS, or the **build output** of a framework (run the build locally first).
 
@@ -10,15 +10,15 @@ For pre-built files only: plain HTML/CSS/JS, or the **build output** of a framew
 - 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`
+## Node.js app → `hosting_deploy-js-application`
 
 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.
+- The upload starts a build. Track it with `hosting_list-js-deployments`; on failure pull `hosting_show-js-deployment-logs`, fix, and redeploy. Poll with backoff — builds take minutes, not seconds.
 
-## WordPress → `hosting_importWordpressWebsite` / plugin & theme tools
+## WordPress → `hosting_import-wordpress-website` / plugin & theme operations
 
 Only when the user explicitly wants a WordPress *site* migrated or themed. Site imports take an archive plus a `.sql` dump and can run for several minutes. (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.)
 
@@ -29,6 +29,6 @@ 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`.
+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,34 +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).
+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_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`.
+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. 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).
+- **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_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.
+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` 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 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 tools (`DNS_updateDNSRecordsV1` etc.) for custom-domain records; take a snapshot (`DNS_getDNSSnapshotListV1` context) before destructive changes.
+- **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,6 +1,6 @@
 # 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.
+**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
 
@@ -17,11 +17,11 @@ Two API surfaces — don't mix them:
 
 ## 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 }`.
+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 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.
+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
 

package/skills/headless/references/WORDPRESS.md

@@ -4,7 +4,7 @@ Use WordPress when the site has **owner-managed content**: a blog, news, article
 
 **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 tool groups; ask the user to enable them in the Hostinger Connector if tools are missing.
+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
 
@@ -20,11 +20,11 @@ Two surfaces, like the store recipe:
 
 ## Setup (management tools)
 
-1. **Check for an existing installation first**: `hosting_listWordPressInstallationsV1` 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_createWebsiteSubdomainV1` 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**: `hosting_installWordPressV1` on that domain. The call only queues the job — **poll** `hosting_listWordPressInstallationsV1` 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 `hosting_createLoginLinksV1` 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 `hosting_toggleMemcachedObjectCacheV1`; after config changes, purge with `hosting_purgeLiteSpeedCacheV1`.
+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
 

package/src/core/catalog.js

@@ -0,0 +1,183 @@
+// Meta-tool logic for the consolidated MCP surface: search, execute and
+// multi-execute over a catalog of API operations. Pure functions only; the
+// runtime supplies the catalog and the function that performs a call.
+// Keep in sync with catalog.ts and with api-remote-mcp's PHP implementation.
+
+export const DEFAULT_SEARCH_LIMIT = 5;
+export const MAX_SEARCH_LIMIT = 20;
+export const MAX_STEPS = 20;
+
+const STEP_REF = /^\$steps\.(\d+)((?:\.[^.]+)*)$/;
+
+/** Bad input from the model: reported as an isError result, never a protocol error. */
+export class ToolInputError extends Error {
+    constructor(message) {
+        super(message);
+        this.name = 'ToolInputError';
+    }
+}
+
+const meta = (name, title, description, inputSchema, readOnly) => ({
+    name,
+    title,
+    description,
+    inputSchema,
+    annotations: { title, readOnlyHint: readOnly, destructiveHint: !readOnly },
+});
+
+export const META_TOOLS = [
+    meta('search', 'Search API operations',
+        "Find API operations by keyword. Returns the best matches, each with its operation name, hints and inputSchema. Pass a result's operation and params matching its inputSchema to execute or multi-execute.",
+        {
+            type: 'object',
+            properties: {
+                query: { type: 'string', description: 'Keywords, e.g. "list vps" or "dns records".' },
+                limit: { type: 'integer', minimum: 1, maximum: MAX_SEARCH_LIMIT, default: DEFAULT_SEARCH_LIMIT, description: 'Maximum number of results.' },
+            },
+            required: ['query'],
+        },
+        true),
+    meta('execute', 'Execute an API operation',
+        "Run one API operation found with search. params is a flat object holding the operation's path, query and body parameters as described by its inputSchema.",
+        {
+            type: 'object',
+            properties: {
+                operation: { type: 'string', description: 'Operation name returned by search.' },
+                params: { type: 'object', description: 'Parameters matching the operation inputSchema.' },
+            },
+            required: ['operation'],
+        },
+        false),
+    meta('multi-execute', 'Execute API operations in sequence',
+        'Run up to 20 API operations in order, stopping at the first failure. A params value that is exactly "$steps.<i>.<path>" is replaced by that value from the result of earlier step <i> (dot-separated keys; numbers index arrays), e.g. "$steps.0.0.id".',
+        {
+            type: 'object',
+            properties: {
+                steps: {
+                    type: 'array',
+                    minItems: 1,
+                    maxItems: MAX_STEPS,
+                    items: {
+                        type: 'object',
+                        properties: {
+                            operation: { type: 'string', description: 'Operation name returned by search.' },
+                            params: { type: 'object', description: 'Parameters; may contain "$steps.<i>.<path>" references.' },
+                        },
+                        required: ['operation'],
+                    },
+                },
+            },
+            required: ['steps'],
+        },
+        false),
+];
+
+const byteOrder = (a, b) => (a < b ? -1 : a > b ? 1 : 0);
+
+function toSummary(op) {
+    return {
+        operation: op.name,
+        title: op.title ?? op.name,
+        description: op.description ?? '',
+        group: op.group ?? null,
+        readOnly: op.annotations?.readOnlyHint === true,
+        destructive: op.annotations?.destructiveHint === true,
+        inputSchema: op.inputSchema,
+    };
+}
+
+export function searchOperations(operations, query, limit = DEFAULT_SEARCH_LIMIT) {
+    if (typeof query !== 'string') throw new ToolInputError('query must be a string');
+    const tokens = query.toLowerCase().split(/[^a-z0-9]+/).filter(Boolean);
+    if (tokens.length === 0) throw new ToolInputError('query must contain at least one letter or digit');
+    if (!Number.isInteger(limit) || limit < 1 || limit > MAX_SEARCH_LIMIT) {
+        throw new ToolInputError(`limit must be an integer from 1 to ${MAX_SEARCH_LIMIT}`);
+    }
+
+    return operations
+        .map(op => {
+            const name = op.name.toLowerCase();
+            const group = (op.group ?? '').toLowerCase();
+            const title = (op.title ?? '').toLowerCase();
+            const description = (op.description ?? '').toLowerCase();
+            let score = 0;
+            for (const t of tokens) {
+                if (name.includes(t)) score += 3;
+                if (group.includes(t)) score += 2;
+                if (title.includes(t)) score += 2;
+                if (description.includes(t)) score += 1;
+            }
+            return { op, score };
+        })
+        .filter(s => s.score > 0)
+        .sort((a, b) => b.score - a.score || byteOrder(a.op.name, b.op.name))
+        .slice(0, limit)
+        .map(s => toSummary(s.op));
+}
+
+export function renderSearch(query, results) {
+    return results.length > 0
+        ? JSON.stringify(results)
+        : `No operations matched "${query}". Try broader or different terms.`;
+}
+
+export function findOperation(operations, name, params) {
+    if (typeof name !== 'string' || !operations.has(name)) {
+        throw new ToolInputError(`Unknown operation "${name}". Use search to find operations.`);
+    }
+    if (params === null || typeof params !== 'object' || Array.isArray(params)) {
+        throw new ToolInputError('params must be an object');
+    }
+    const op = operations.get(name);
+    const missing = (op.inputSchema?.required ?? []).filter(k => params[k] === undefined || params[k] === null);
+    if (missing.length > 0) {
+        throw new ToolInputError(`Missing required parameter(s) for ${name}: ${missing.join(', ')}`);
+    }
+    return op;
+}
+
+export function resolveRefs(value, results, stepIndex) {
+    if (typeof value === 'string') {
+        const m = STEP_REF.exec(value);
+        if (!m) return value;
+        const i = Number(m[1]);
+        if (i >= stepIndex) {
+            throw new ToolInputError(`${value}: references must point to an earlier step`);
+        }
+        let current = results[i];
+        for (const segment of m[2].split('.').slice(1)) {
+            if (current === null || typeof current !== 'object' || !Object.hasOwn(current, segment)) {
+                throw new ToolInputError(`${value}: path not found in the result of step ${i}`);
+            }
+            current = current[segment];
+        }
+        return current;
+    }
+    if (Array.isArray(value)) return value.map(v => resolveRefs(v, results, stepIndex));
+    if (value !== null && typeof value === 'object') {
+        return Object.fromEntries(Object.entries(value).map(([k, v]) => [k, resolveRefs(v, results, stepIndex)]));
+    }
+    return value;
+}
+
+export async function runSteps(steps, runOne, formatError) {
+    if (!Array.isArray(steps) || steps.length === 0 || steps.length > MAX_STEPS) {
+        throw new ToolInputError(`steps must be an array of 1 to ${MAX_STEPS} items`);
+    }
+    const raw = [];
+    const results = [];
+    for (const [i, step] of steps.entries()) {
+        try {
+            if (step === null || typeof step !== 'object' || typeof step.operation !== 'string') {
+                throw new ToolInputError(`step ${i}: operation must be a string`);
+            }
+            const params = resolveRefs(step.params ?? {}, raw, i);
+            const result = await runOne(step.operation, params);
+            raw.push(result);
+            results.push({ step: i, operation: step.operation, result });
+        } catch (error) {
+            return { results, error: { step: i, message: formatError(error) } };
+        }
+    }
+    return { results };
+}