hostinger-api-mcp 1.23.0 → 1.25.0

package/.github/workflows/build-release.yaml

@@ -117,3 +117,31 @@ jobs:
 
       - name: Publish to MCP Registry
         run: ./mcp-publisher publish
+
+  notify-failure:
+    needs: [release, publish-npmjs, release-github, publish-mcp]
+    if: failure()
+    runs-on: ubuntu-latest
+    steps:
+      - name: Notify Slack on release failure
+        uses: slackapi/slack-github-action@v2.1.0
+        with:
+          errors: true
+          webhook: ${{ secrets.PLATFORM_INCIDENT_SLACK_CHANNEL_WEBHOOK }}
+          webhook-type: incoming-webhook
+          payload: |
+            text: ":rotating_light: Release failed in ${{ github.repository }}"
+            blocks:
+              - type: section
+                text:
+                  type: mrkdwn
+                  text: |
+                    :rotating_light: *Release failed:* `${{ github.repository }}`
+                    *Commit:* <${{ github.server_url }}/${{ github.repository }}/commit/${{ github.sha }}|${{ github.sha }}>
+              - type: actions
+                elements:
+                  - type: button
+                    text:
+                      type: plain_text
+                      text: "View failed run"
+                    url: "${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}"

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "1.23.0",
+  "version": "1.25.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.23.0",
+  "version": "1.25.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.23.0",
+  "version": "1.25.0",
   "packages": [
     {
       "registryType": "npm",
       "identifier": "hostinger-api-mcp",
-      "version": "1.23.0",
+      "version": "1.25.0",
       "transport": {
         "type": "stdio"
       },

package/skills/headless/SKILL.md

@@ -1,18 +1,18 @@
 ---
 name: hostinger-headless
-description: "Build, connect, or iterate on a website hosted on Hostinger — provision hosting and a domain, optionally seed an ecommerce store with a real hosted checkout, build the frontend, deploy, and verify. Requires an authenticated Hostinger MCP session (see entry/skill.md). Triggers: build me a site on Hostinger, deploy this to Hostinger, connect this project to Hostinger, add a store to my Hostinger site, update my Hostinger site."
+description: "Build, connect, or iterate on a website hosted on Hostinger — provision hosting and a domain, optionally seed an ecommerce store with a real hosted checkout or a WordPress content backend (headless CMS/blog), build the frontend, deploy, and verify. Requires an authenticated Hostinger MCP session (see entry/skill.md). Triggers: build me a site on Hostinger, deploy this to Hostinger, connect this project to Hostinger, add a store to my Hostinger site, add a blog to my Hostinger site, update my Hostinger site."
 ---
 
 # Hostinger Headless
 
 This skill turns a prompt into a live website on Hostinger. Its job is to own the full run: check the account, provision hosting and a domain, seed the backend (an ecommerce store when the intent calls for selling), build the frontend, deploy it, and verify the result.
 
-The frontend is built ad-hoc to the user's intent — there is no template library. The backend pieces are real Hostinger products: web hosting (static or Node.js), domains and DNS, and Hostinger Ecommerce with its public Storefront API and hosted checkout.
+The frontend is built ad-hoc to the user's intent — there is no template library. The backend pieces are real Hostinger products: web hosting (static or Node.js), domains and DNS, Hostinger Ecommerce with its public Storefront API and hosted checkout, and WordPress as a headless CMS/blog backend read through the public WP REST API.
 
 ## Preconditions
 
 1. An authenticated Hostinger MCP session — the entry skill's bootstrap handled this. If MCP tools fail with auth errors, send the user back through `entry/skill.md`.
-2. The Hostinger MCP tools for **hosting** (and **ecommerce**, when the run involves a store). Tool availability varies per user — product groups can be toggled in the Hostinger Connector, and some clients cap the number of exposed tools. When a needed tool is missing, ask the user to enable that product group (or configure the scoped binary, e.g. `hostinger-hosting-mcp`) rather than improvising around it.
+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.
 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
@@ -27,13 +27,14 @@ If signals conflict, ask the user — don't guess.
 
 ## The run
 
-1. **Discovery** — from the prompt (and the project on disk for connect/iterate), infer: does this run need a store (any buy/sell/product intent → yes)? What brand, copy, and structure does the site need? What stack fits — plain static HTML/CSS/JS for simple sites (default), a static-output framework build, or a Node.js app when SSR or server code is genuinely required? Prefer static: it deploys fastest and has no build-failure surface. Ask the user only what you cannot infer.
+1. **Discovery** — from the prompt (and the project on disk for connect/iterate), infer: does this run need a store (any buy/sell/product intent → yes)? Does it need owner-managed content — a blog, news, or anything the owner edits without a redeploy (→ WordPress backend; static copy that rarely changes does not qualify)? What brand, copy, and structure does the site need? What stack fits — plain static HTML/CSS/JS for simple sites (default), a static-output framework build, or a Node.js app when SSR or server code is genuinely required? Prefer static: it deploys fastest and has no build-failure surface. Ask the user only what you cannot infer.
 2. **Setup** (`references/SETUP.md`) — plan check, then provision the website on a free subdomain (or the user's own domain) and wait until it's ready.
 3. **Store** (`references/STORE.md`, only when commerce is needed) — resolve or create the store and its `custom` sales channel, seed products/shipping/payment, and note the `sales_channel_id` for the frontend.
-4. **Build** — create or wire the frontend. For store runs, follow the frontend contract in `references/STORE.md` (catalog fetched at runtime from the public Storefront API, cart in `localStorage`, client-side checkout — never embed an API token in the site).
-5. **Deploy** (`references/DEPLOYMENT.md`) — archive and deploy via the matching hosting tool, polling build logs for Node.js runs.
-6. **Verify** — curl the live URL for a 200 and a piece of real page copy; for store runs, confirm a checkout POST returns a redirect URL. Show the user the live URL and where to manage things (hPanel: https://hpanel.hostinger.com, and the store dashboard for commerce).
-7. **Record** — write `.hostinger/site.json` into the project: `{ "domain", "username", "type": "static"|"nodejs", "sales_channel_id"?, "store_id"? }`. This is what makes future runs resolve as `iterate`.
+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).
+6. **Deploy** (`references/DEPLOYMENT.md`) — archive and deploy via the matching hosting tool, 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`.
 
 Run non-interactively wherever possible. The exceptions that must involve the user: the paid-plan confirmation, anything that costs money (a domain purchase, a new subscription), and picking between genuinely equal options the prompt doesn't decide.
 
@@ -43,6 +44,7 @@ Run non-interactively wherever possible. The exceptions that must involve the us
 | --- | --- |
 | Plan check + website/domain provisioning | `references/SETUP.md` |
 | Store: seed the backend + the frontend API contract | `references/STORE.md` |
+| WordPress: headless CMS/blog backend + the frontend read contract | `references/WORDPRESS.md` |
 | Deploy: static vs Node.js, archive rules, logs, verify | `references/DEPLOYMENT.md` |
 
 ## Where the how comes from

package/skills/headless/entry/skill.md

@@ -1,6 +1,6 @@
 ---
 name: hostinger-headless-entry
-description: "Build a complete website on Hostinger from a single prompt — hosting, domain, and (optionally) a store with real checkout. The deterministic first steps — verifying the Hostinger MCP server and signing in — are handled by a single bootstrap script; the agent then installs the full skill and hands the run to it. Triggers: build me a site, create a website, make me a website, online store, I want to sell X, start a business online, launch a site, ecommerce, portfolio, business website, sell online, online shop, connect this project to Hostinger, host this on Hostinger, deploy this to Hostinger."
+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
@@ -73,7 +73,7 @@ npx skills add hostinger/api-mcp-server --yes
 
 If the installer is unavailable, fetch the files directly instead — the full set is listed in the skill folder at `https://github.com/hostinger/api-mcp-server/tree/main/skills/headless`.
 
-Then open `headless/SKILL.md` and follow it. That skill owns the rest of the run — it resolves the operation (create / connect / iterate), checks the account has a usable hosting plan, provisions the website and domain, seeds the store when commerce is requested, builds, deploys, and verifies.
+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, or deploy by hand here — the skill does all of that (`references/SETUP.md`, `references/DEPLOYMENT.md`, `references/STORE.md`). This entry stops at signed in.
+- 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/DEPLOYMENT.md

@@ -20,7 +20,7 @@ For anything that needs a server or a server-side build (Express, Next.js, NestJ
 
 ## WordPress → `hosting_importWordpressWebsite` / plugin & theme tools
 
-Only when the user explicitly wants WordPress. Site imports take an archive plus a `.sql` dump and can run for several minutes.
+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.)
 
 ## Verify (every deploy)
 

package/skills/headless/references/WORDPRESS.md

@@ -0,0 +1,51 @@
+# 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 tool groups; ask the user to enable them in the Hostinger Connector if tools 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**: `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`.
+
+## 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.

package/src/core/runtime.js

@@ -29,7 +29,7 @@ const SECURITY_SCHEMES = {
 
 /**
  * MCP Server for Hostinger API
- * Generated from OpenAPI spec version 1.21.0
+ * Generated from OpenAPI spec version 1.22.0
  */
 class MCPServer {
   constructor({ name, version, tools }) {

package/src/core/runtime.ts

@@ -52,7 +52,7 @@ const SECURITY_SCHEMES: Record<string, SecurityScheme> = {
 
 /**
  * MCP Server for Hostinger API
- * Generated from OpenAPI spec version 1.21.0
+ * Generated from OpenAPI spec version 1.22.0
  */
 class MCPServer {
   private readonly name: string;

package/src/core/tools/all.js

@@ -1197,7 +1197,8 @@ export default [
           "description": "Filter catalog items by category",
           "enum": [
             "DOMAIN",
-            "VPS"
+            "VPS",
+            "EMAIL"
           ]
         },
         "name": {

package/src/core/tools/all.ts

@@ -1211,7 +1211,8 @@ const tools: OpenApiTool[] = [
           "description": "Filter catalog items by category",
           "enum": [
             "DOMAIN",
-            "VPS"
+            "VPS",
+            "EMAIL"
           ]
         },
         "name": {

package/src/core/tools/billing.js

@@ -13,7 +13,8 @@ export default [
           "description": "Filter catalog items by category",
           "enum": [
             "DOMAIN",
-            "VPS"
+            "VPS",
+            "EMAIL"
           ]
         },
         "name": {

package/src/core/tools/billing.ts

@@ -27,7 +27,8 @@ const tools: OpenApiTool[] = [
           "description": "Filter catalog items by category",
           "enum": [
             "DOMAIN",
-            "VPS"
+            "VPS",
+            "EMAIL"
           ]
         },
         "name": {

package/src/servers/agency-hosting.js

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

package/src/servers/agency-hosting.ts

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

package/src/servers/all.js

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

package/src/servers/all.ts

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

package/src/servers/billing.js

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

package/src/servers/billing.ts

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

package/src/servers/dns.js

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

package/src/servers/dns.ts

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

package/src/servers/domains.js

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

package/src/servers/domains.ts

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

package/src/servers/ecommerce.js

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

package/src/servers/ecommerce.ts

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

package/src/servers/horizons.js

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

package/src/servers/horizons.ts

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

package/src/servers/hosting.js

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

package/src/servers/hosting.ts

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

package/src/servers/mail.js

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

package/src/servers/mail.ts

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

package/src/servers/reach.js

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

package/src/servers/reach.ts

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

package/src/servers/vps.js

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

package/src/servers/vps.ts

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

package/src/servers/wordpress.js

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

package/src/servers/wordpress.ts

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