hostinger-api-mcp 3.17.3 → 3.18.0

package/src/core/skills.ts

@@ -23,10 +23,10 @@ const skills: Skill[] = [
     "resources": [
       {
         "uri": "skill://audit-hosting/SKILL.md",
-        "digest": "sha256:158701817cf090fc41bc833eefb54378909900eeaa684f219ed8389d94207091",
-        "size": 5472,
+        "digest": "sha256:70ec5534c0deae4c33176488b8667e11d2ab6f60ae8c363cce04701bcc3c5ae0",
+        "size": 5596,
         "mimeType": "text/markdown",
-        "text": "---\nname: audit-hosting\ndescription: \"Audit a Hostinger web hosting account (Shared, Cloud and Agency plans) and report what needs attention: every plan and website, SSL problems, broken or vulnerable WordPress installs, failed Node.js builds and vulnerable npm packages, databases and Agency Plan orders near their limits, and hosting plans about to lapse. Read-only; produces a prioritised to-do list and names the skill that fixes each item. Triggers: what do I have on Hostinger, audit my hosting, check all my websites, what needs attention, health check my sites, are any of my sites broken, which of my sites are insecure.\"\n---\n\n# Audit hosting\n\nRead-only from start to finish. The output is a report; every fix is a separate, confirmed step through another skill.\n\n## Calling the operations\n\n- Read the `inputSchema` that `search` returns before the first call of each operation. If a name below is rejected as unknown, `search` for what the step does (e.g. \"ssl status\").\n- Batch reads with `multi-execute`, up to 20 steps a batch. Batches chain operations from one server only — the Hostinger Connector runs `hosting`, `wordpress`, `agency-hosting` and `billing` as separate servers. When a product group is switched off, skip its checks and say which were skipped.\n- Page every list until `meta.total` is covered.\n- Leave `hosting_php_get` out — it is large and says nothing about account health.\n\n## 1. Inventory\n\nOne batch per server:\n\n- `hosting_orders_list` with `statuses: [\"active\", \"suspended\"]`. `cloud_*` plan names are Cloud; the rest (`hostinger_premium_*`, `hostinger_business_*`, …) are Shared.\n- `hosting_websites_list` — every Shared and Cloud website with `website_type`, `username`, `order_id` and `is_enabled` (false means suspended).\n- `wordpress_installations_list` with `ownership: \"all\"` — `id`, `is_valid`, `validation_error`.\n- `agency-hosting_orders_list` and `agency-hosting_websites_list-plan` — Agency orders and sites (`details.uid`, `details.type`, `details.domains`, `details.state`).\n\nTell the user the size (plans, websites, WordPress installs) before the checks. For large accounts offer to scope the audit to one order or domain.\n\n## 2. Checks\n\nPer Shared and Cloud website (skip `builder` and `horizons`):\n\n- `hosting_ssl_status` — flag `failed` (with `last_error`), `expired`, `not_installed` on a custom domain, `is_https_redirect_enabled: false`, and `expires_at` within 30 days when `is_lifetime` is false. Lifetime certificates renew on their own.\n- Node.js sites: `hosting_get-deployment` (latest build failed? `build.state`) and `hosting_nodejs_list-vulnerabilities` with `severities: [\"critical\", \"high\"]`.\n\nPer hosting account (`username`): `hosting_databases_list` — flag `disk_usage_mb` above 80% of `max_size_mb`.\n\nPer WordPress install: `wordpress_installations_show-core-version` (core vulnerabilities) and `wordpress_plugins_list-installed` (vulnerable plugins and pending updates).\n\nPer Agency order: `agency-hosting_metrics_list-order-resource-usage` with `time_frame_hours: 168` and `agency-hosting_metrics_list-plan-order-disk-usage` with `time_frame_days: 7` — flag usage above 80% of the plan quota and name the heaviest websites.\n\nPer Agency site: `agency-hosting_ssl_website-status` for each custom domain in `details.domains`; flag `details.state` other than `active`.\n\nPlans about to lapse (billing product): `billing_subscriptions_list`, joined to hosting orders on `subscription_id` — flag `not_renewing`, or `is_auto_renewed: false` with `expires_at` within 30 days. Every site on that plan goes down with it.\n\nFrom outside, for each custom domain:\n\n```bash\ncurl -sS -o /dev/null -w \"%{http_code}\\n\" --max-time 15 https://DOMAIN/\ncurl -sSI --max-time 15 https://DOMAIN/ | grep -i \"^platform\"\n```\n\nNo `platform: hostinger` header means the domain does not reach this hosting.\n\n## 3. Report\n\n```\n# Hosting audit\n3 plans (2 Shared, 1 Cloud) + 1 Agency · 14 websites (6 WordPress, 3 Node.js, 5 other) · 4 Agency sites\n\n## Fix now\n- shop.example.com — latest Node.js build failed 2 days ago → troubleshoot-website\n- blog.example.com — contact-form-x 5.2 has a known vulnerability, fixed in 5.3 → maintain-wordpress\n\n## Soon\n- example.org — Business plan expires in 12 days, auto-renew off → renew in hPanel\n- Agency order 1000000001 — 86% of disk quota, mostly client-a.com\n\n## Worth knowing\n- 4 WordPress installs have pending plugin updates → maintain-wordpress\n\n## Healthy\ndocs.example.com, portfolio.example.com, …\n```\n\n- **Fix now:** site down or not reaching Hostinger, failed latest build, invalid WordPress install, SSL `failed` or `expired`, critical vulnerabilities, suspended website.\n- **Soon:** high vulnerabilities, a plan lapsing within 30 days, usage above 80% of a quota, HTTPS redirect off, non-lifetime certificates expiring.\n- **Worth knowing:** pending updates, inactive plugins with vulnerabilities.\n\nEach item names the evidence and the skill that fixes it: `troubleshoot-website`, `maintain-wordpress`, `connect-domain` or `deploy-to-hosting`. Patchable npm vulnerabilities on GitHub-deployed sites can be fixed with `hosting_nodejs_patch-vulnerabilities`, which opens a pull request — offer it, do not run it as part of the audit.\n\n## Not available through the API\n\nCPU and memory usage for Shared and Cloud plans, website backup status, and PHP error logs. Mention them once at the end so the user knows what the audit could not see.\n"
+        "text": "---\nname: audit-hosting\ndescription: \"Audit a Hostinger web hosting account (Shared, Cloud and Agency plans) and report what needs attention: every plan and website, SSL problems, broken or vulnerable WordPress installs, failed Node.js builds and vulnerable npm packages, databases and Agency Plan orders near their limits, and hosting plans about to lapse. Read-only; produces a prioritised to-do list and names the skill that fixes each item. Triggers: what do I have on Hostinger, audit my hosting, check all my websites, what needs attention, health check my sites, are any of my sites broken, which of my sites are insecure.\"\n---\n\n# Audit hosting\n\nRead-only from start to finish. The output is a report; every fix is a separate, confirmed step through another skill.\n\n## Calling the operations\n\n- Read the `inputSchema` that `search` returns before the first call of each operation. If a name below is rejected as unknown, `search` for what the step does (e.g. \"ssl status\").\n- Batch reads with `multi-execute`, up to 20 steps a batch. Batches chain operations from one server only — the Hostinger Connector runs `hosting`, `wordpress`, `agency-hosting` and `billing` as separate servers. When a product group is switched off, skip its checks and say which were skipped.\n- Page every list until `meta.total` is covered.\n- Leave `hosting_php_get` out — it is large and says nothing about account health.\n\n## 1. Inventory\n\nOne batch per server:\n\n- `hosting_orders_list` with `statuses: [\"active\", \"suspended\"]`. `cloud_*` plan names are Cloud; the rest (`hostinger_premium_*`, `hostinger_business_*`, …) are Shared.\n- `hosting_websites_list` — every Shared and Cloud website with `website_type`, `username`, `order_id` and `is_enabled` (false means suspended).\n- `wordpress_installations_list` with `ownership: \"all\"` — `id`, `is_valid`, `validation_error`.\n- `agency-hosting_orders_list` and `agency-hosting_websites_list-plan` — Agency orders and sites (`details.uid`, `details.type`, `details.domains`, `details.state`).\n\nTell the user the size (plans, websites, WordPress installs) before the checks. For large accounts offer to scope the audit to one order or domain.\n\n## 2. Checks\n\nPer Shared and Cloud website (skip `builder` and `horizons`):\n\n- `hosting_websites_get-settings` — in `ssl`, flag `failed` (with `last_error`), `expired`, `not_installed` on a custom domain, `is_https_redirect_enabled: false`, and `expires_at` within 30 days when `is_lifetime` is false; lifetime certificates renew on their own. In `cache`, flag `is_cacheless_mode_enabled: true` (development mode left on) and `is_enabled: false`.\n- Node.js sites: `hosting_get-deployment` (latest build failed? `build.state`) and `hosting_nodejs_list-vulnerabilities` with `severities: [\"critical\", \"high\"]`.\n\nPer hosting account (`username`): `hosting_databases_list` — flag `disk_usage_mb` above 80% of `max_size_mb`.\n\nPer WordPress install: `wordpress_installations_show-core-version` (core vulnerabilities) and `wordpress_plugins_list-installed` (vulnerable plugins and pending updates).\n\nPer Agency order: `agency-hosting_metrics_list-order-resource-usage` with `time_frame_hours: 168` and `agency-hosting_metrics_list-plan-order-disk-usage` with `time_frame_days: 7` — flag usage above 80% of the plan quota and name the heaviest websites.\n\nPer Agency site: `agency-hosting_ssl_website-status` for each custom domain in `details.domains`; flag `details.state` other than `active`.\n\nPlans about to lapse (billing product): `billing_subscriptions_list`, joined to hosting orders on `subscription_id` — flag `not_renewing`, or `is_auto_renewed: false` with `expires_at` within 30 days. Every site on that plan goes down with it.\n\nFrom outside, for each custom domain:\n\n```bash\ncurl -sS -o /dev/null -w \"%{http_code}\\n\" --max-time 15 https://DOMAIN/\ncurl -sSI --max-time 15 https://DOMAIN/ | grep -i \"^platform\"\n```\n\nNo `platform: hostinger` header means the domain does not reach this hosting.\n\n## 3. Report\n\n```\n# Hosting audit\n3 plans (2 Shared, 1 Cloud) + 1 Agency · 14 websites (6 WordPress, 3 Node.js, 5 other) · 4 Agency sites\n\n## Fix now\n- shop.example.com — latest Node.js build failed 2 days ago → troubleshoot-website\n- blog.example.com — contact-form-x 5.2 has a known vulnerability, fixed in 5.3 → maintain-wordpress\n\n## Soon\n- example.org — Business plan expires in 12 days, auto-renew off → renew in hPanel\n- Agency order 1000000001 — 86% of disk quota, mostly client-a.com\n\n## Worth knowing\n- 4 WordPress installs have pending plugin updates → maintain-wordpress\n\n## Healthy\ndocs.example.com, portfolio.example.com, …\n```\n\n- **Fix now:** site down or not reaching Hostinger, failed latest build, invalid WordPress install, SSL `failed` or `expired`, critical vulnerabilities, suspended website.\n- **Soon:** high vulnerabilities, a plan lapsing within 30 days, usage above 80% of a quota, HTTPS redirect off, non-lifetime certificates expiring.\n- **Worth knowing:** pending updates, inactive plugins with vulnerabilities.\n\nEach item names the evidence and the skill that fixes it: `troubleshoot-website`, `maintain-wordpress`, `connect-domain` or `deploy-to-hosting`. Patchable npm vulnerabilities on GitHub-deployed sites can be fixed with `hosting_nodejs_patch-vulnerabilities`, which opens a pull request — offer it, do not run it as part of the audit.\n\n## Not available through the API\n\nCPU and memory usage for Shared and Cloud plans, website backup status, and PHP error logs. Mention them once at the end so the user knows what the audit could not see.\n"
       }
     ]
   },
@@ -39,10 +39,10 @@ const skills: Skill[] = [
     "resources": [
       {
         "uri": "skill://connect-domain/SKILL.md",
-        "digest": "sha256:cba4378a8f69bb896b8049771c931e6ccedda7482113253f03f92fe822d5af97",
-        "size": 6923,
+        "digest": "sha256:f864ecc8a8aaf67408d3838b1e6962a7e5d717a52febea04553a9692709cfed4",
+        "size": 6993,
         "mimeType": "text/markdown",
-        "text": "---\nname: connect-domain\ndescription: \"Connect a custom domain to a website on Hostinger web hosting (Shared, Cloud or Agency plans) end to end: attach the domain to the site, point DNS at Hostinger without breaking existing email or verification records, install SSL, turn on the HTTPS redirect, and verify it resolves. Handles domains registered at Hostinger or elsewhere, moving a site off its free *.hostingersite.com subdomain, subdomains and aliases. Triggers: connect my domain, point my domain to my site, use my own domain, move off the free subdomain, add a subdomain, park a domain, add a domain alias, my domain is not working.\"\n---\n\n# Connect a domain\n\nGet a domain serving a Hostinger website over HTTPS. The one rule that matters most: records that already work — email (`MX`), SPF, DKIM and verification `TXT` records — must survive every DNS change.\n\n## Calling the operations\n\n- Read the `inputSchema` that `search` returns before the first call of each operation. If a name below is rejected as unknown, `search` for what the step does (e.g. \"dns records\").\n- Batch reads with `multi-execute`; values pass between steps as `$steps.<i>.<path>`. Batches chain operations from one server only — the Hostinger Connector runs `hosting`, `agency-hosting`, `domains` and `dns` as separate servers. When `search` cannot find an operation, ask the user to enable that product group in the Connector.\n- Every write here changes what the public sees. State the change and get a yes before each one.\n\n## 1. Gather the facts (read-only)\n\n- **Website.** `hosting_websites_list` with `domain` (Shared and Cloud; substring match, so take the exact entry) and `agency-hosting_websites_list-plan` with `domain` (Agency). Keep `username` and `order_id`, or `details.uid` and `details.ipv4`. When the domain has no website yet, find the site the user means — often a `*.hostingersite.com` one — or the order to create it on (`hosting_orders_list`, `agency-hosting_orders_list`).\n- **Registration.** `domains_portfolio_get` succeeds only for domains registered at Hostinger; its `name_servers` show who runs DNS. Hostinger's own nameservers end in `dns-parking.com`.\n- **Live DNS**, to know what must be kept:\n\n```bash\ndig +short NS DOMAIN; dig +short A DOMAIN; dig +short CNAME www.DOMAIN\ndig +short MX DOMAIN; dig +short TXT DOMAIN; dig +short CAA DOMAIN\n```\n\n## 2. Attach the domain to hosting\n\nShared and Cloud:\n\n- **New website on the domain.** For a domain outside this account run `hosting_domains_verify-ownership` first. When `is_accessible` is false, give the user the `TXT` record it returns to add next to the existing ones, then verify again (propagation takes up to ~10 minutes). Create with `hosting_websites_create` (`domain` without `www.`, `order_id`), then poll `hosting_websites_list-setups` with `domain` every 10–15 s until `status: completed`.\n- **Moving a site off its free subdomain.** Shared and Cloud websites cannot be renamed through the API. Either create a website on the real domain and redeploy the project there (the `deploy-to-hosting` skill) — required for WordPress, which keeps its URL in the database — or, for static sites, park the domain on the existing site with `hosting_domains_create-website-parked`.\n- **Alias** (a second domain showing the same site): `hosting_domains_create-website-parked`.\n- **Subdomain** (`shop.example.com`): `hosting_domains_create-website-subdomain`. `www` belongs to the main domain — do not create it as a subdomain.\n\nAgency Plan:\n\n- `agency-hosting_domains_link-to-website` adds a domain to the site.\n- `agency-hosting_domains_change-website` replaces the primary domain, for example the free subdomain. The old name stops serving at once — confirm first.\n\n## 3. Point DNS at Hostinger\n\n**DNS already at Hostinger** (nameservers end in `dns-parking.com`): creating the website normally writes the records. Read the zone with `dns_records_list`; when `@` and `www` already point at the site, change nothing. Before any edit, note the newest `dns_snapshots_list` entry — `dns_snapshots_restore` rolls back to it.\n\n`dns_records_update` defaults to `overwrite: true`, which deletes every existing record with the same name and type. Adding a `TXT` at `@` that way wipes SPF and verification records. Send `overwrite: false` when adding; use `true` only to replace one record set on purpose, and run `dns_records_validate` on the same payload first.\n\n**DNS elsewhere** (registered at Hostinger with other nameservers, or registered elsewhere). Two options — let the user choose:\n\n- **Switch nameservers to Hostinger.** Hostinger then manages every record. First copy each record the current DNS serves beyond the website — `MX`, `TXT`, service `CNAME`s — into the Hostinger zone with `dns_records_update` (`overwrite: false`); otherwise email breaks when the nameservers flip. Hostinger's nameserver pairs differ between domains (`ns1`/`ns2.dns-parking.com`, `solar`/`lunar.dns-parking.com` and others), so use the pair hPanel shows for this domain, never a guessed one. For Hostinger-registered domains apply it with `domains_portfolio_update-nameservers`; otherwise the user changes it at their registrar.\n- **Keep the current DNS provider** and change only the web records: `A` for `@` and `CNAME` (or `A`) for `www`. Agency sites point at `details.ipv4`. Shared and Cloud sites point at the targets in the Hostinger zone for the domain (`dns_records_list`) or, when that zone does not exist, the IP hPanel shows for the website. The user makes this change at their DNS provider.\n\n## 4. SSL and HTTPS\n\nStart only once `dig` shows the domain resolving to Hostinger — the certificate authority checks the domain against the server.\n\n- Shared and Cloud: `hosting_ssl_status`. When it is not `active`, call `hosting_ssl_install` and poll the status until `active` (or `failed` with `last_error`), then `hosting_ssl_toggle-https-redirect` with `is_enabled: true` (it returns 422 until a certificate exists).\n- Agency: `agency-hosting_ssl_install-website` for each domain, then poll `agency-hosting_ssl_website-status`. A domain allows three setups per seven days and one request a minute — install once DNS is right and never loop.\n- A `CAA` record at the apex that does not allow `letsencrypt.org` blocks issuance; the user adds `0 issue \"letsencrypt.org\"` beside the existing ones.\n\n## 5. Verify\n\n```bash\ndig +short A DOMAIN; dig +short A www.DOMAIN\ncurl -sSI https://DOMAIN/ | grep -i -E \"^(HTTP|platform|location)\"\ncurl -sSI http://DOMAIN/ | grep -i -E \"^(HTTP|location)\"\ndig +short MX DOMAIN\n```\n\nDone when both names resolve to Hostinger, HTTPS answers with `platform: hostinger`, HTTP redirects to HTTPS, and `MX` still matches step 1. Nameserver changes can take up to 24–48 hours to reach every resolver; when records are still old, report what is pending and the command to re-check instead of polling for hours.\n"
+        "text": "---\nname: connect-domain\ndescription: \"Connect a custom domain to a website on Hostinger web hosting (Shared, Cloud or Agency plans) end to end: attach the domain to the site, point DNS at Hostinger without breaking existing email or verification records, install SSL, turn on the HTTPS redirect, and verify it resolves. Handles domains registered at Hostinger or elsewhere, moving a site off its free *.hostingersite.com subdomain, subdomains and aliases. Triggers: connect my domain, point my domain to my site, use my own domain, move off the free subdomain, add a subdomain, park a domain, add a domain alias, my domain is not working.\"\n---\n\n# Connect a domain\n\nGet a domain serving a Hostinger website over HTTPS. The one rule that matters most: records that already work — email (`MX`), SPF, DKIM and verification `TXT` records — must survive every DNS change.\n\n## Calling the operations\n\n- Read the `inputSchema` that `search` returns before the first call of each operation. If a name below is rejected as unknown, `search` for what the step does (e.g. \"dns records\").\n- Batch reads with `multi-execute`; values pass between steps as `$steps.<i>.<path>`. Batches chain operations from one server only — the Hostinger Connector runs `hosting`, `agency-hosting`, `domains` and `dns` as separate servers. When `search` cannot find an operation, ask the user to enable that product group in the Connector.\n- Every write here changes what the public sees. State the change and get a yes before each one.\n\n## 1. Gather the facts (read-only)\n\n- **Website.** `hosting_websites_list` with `domain` (Shared and Cloud; substring match, so take the exact entry) and `agency-hosting_websites_list-plan` with `domain` (Agency). Keep `username` and `order_id`, or `details.uid` and `details.ipv4`. When the domain has no website yet, find the site the user means — often a `*.hostingersite.com` one — or the order to create it on (`hosting_orders_list`, `agency-hosting_orders_list`).\n- **Registration.** `domains_portfolio_get` succeeds only for domains registered at Hostinger; its `name_servers` show who runs DNS. Hostinger's own nameservers end in `dns-parking.com`.\n- **Live DNS**, to know what must be kept:\n\n```bash\ndig +short NS DOMAIN; dig +short A DOMAIN; dig +short CNAME www.DOMAIN\ndig +short MX DOMAIN; dig +short TXT DOMAIN; dig +short CAA DOMAIN\n```\n\n## 2. Attach the domain to hosting\n\nShared and Cloud:\n\n- **New website on the domain.** For a domain outside this account run `hosting_domains_verify-ownership` first. When `is_accessible` is false, give the user the `TXT` record it returns to add next to the existing ones, then verify again (propagation takes up to ~10 minutes). Create with `hosting_websites_create` (`domain` without `www.`, `order_id`), then poll `hosting_websites_list-setups` with `domain` every 10–15 s until `status: completed`.\n- **Moving a site off its free subdomain.** Shared and Cloud websites cannot be renamed through the API. Either create a website on the real domain and redeploy the project there (the `deploy-to-hosting` skill) — required for WordPress, which keeps its URL in the database — or, for static sites, park the domain on the existing site with `hosting_domains_create-website-parked`.\n- **Alias** (a second domain showing the same site): `hosting_domains_create-website-parked`.\n- **Subdomain** (`shop.example.com`): `hosting_domains_create-website-subdomain`. `www` belongs to the main domain — do not create it as a subdomain.\n\nAgency Plan:\n\n- `agency-hosting_domains_link-to-website` adds a domain to the site.\n- `agency-hosting_domains_change-website` replaces the primary domain, for example the free subdomain. The old name stops serving at once — confirm first.\n\n## 3. Point DNS at Hostinger\n\n**DNS already at Hostinger** (nameservers end in `dns-parking.com`): creating the website normally writes the records. Read the zone with `dns_records_list`; when `@` and `www` already point at the site, change nothing. Before any edit, note the newest `dns_snapshots_list` entry — `dns_snapshots_restore` rolls back to it.\n\n`dns_records_update` defaults to `overwrite: true`, which deletes every existing record with the same name and type. Adding a `TXT` at `@` that way wipes SPF and verification records. Send `overwrite: false` when adding; use `true` only to replace one record set on purpose, and run `dns_records_validate` on the same payload first.\n\n**DNS elsewhere** (registered at Hostinger with other nameservers, or registered elsewhere). Two options — let the user choose:\n\n- **Switch nameservers to Hostinger.** Hostinger then manages every record. First copy each record the current DNS serves beyond the website — `MX`, `TXT`, service `CNAME`s — into the Hostinger zone with `dns_records_update` (`overwrite: false`); otherwise email breaks when the nameservers flip. Hostinger's nameserver pairs differ between domains (`ns1`/`ns2.dns-parking.com`, `solar`/`lunar.dns-parking.com` and others), so use the pair hPanel shows for this domain, never a guessed one. For Hostinger-registered domains apply it with `domains_portfolio_update-nameservers`; otherwise the user changes it at their registrar.\n- **Keep the current DNS provider** and change only the web records: `A` for `@` and `CNAME` (or `A`) for `www`. Agency sites point at `details.ipv4`. Shared and Cloud sites point at the targets in the Hostinger zone for the domain (`dns_records_list`) or, when that zone does not exist, the IP hPanel shows for the website. The user makes this change at their DNS provider.\n\n## 4. SSL and HTTPS\n\nStart only once `dig` shows the domain resolving to Hostinger — the certificate authority checks the domain against the server.\n\n- Shared and Cloud: `ssl` in `hosting_websites_get-settings`. When `ssl.status` is not `active`, call `hosting_ssl_install` and poll `hosting_websites_get-settings` until it is `active` (or `failed` with `last_error`), then `hosting_websites_update-settings` with `httpsRedirect: true` (it changes nothing until the certificate is `active`).\n- Agency: `agency-hosting_ssl_install-website` for each domain, then poll `agency-hosting_ssl_website-status`. A domain allows three setups per seven days and one request a minute — install once DNS is right and never loop.\n- A `CAA` record at the apex that does not allow `letsencrypt.org` blocks issuance; the user adds `0 issue \"letsencrypt.org\"` beside the existing ones.\n\n## 5. Verify\n\n```bash\ndig +short A DOMAIN; dig +short A www.DOMAIN\ncurl -sSI https://DOMAIN/ | grep -i -E \"^(HTTP|platform|location)\"\ncurl -sSI http://DOMAIN/ | grep -i -E \"^(HTTP|location)\"\ndig +short MX DOMAIN\n```\n\nDone when both names resolve to Hostinger, HTTPS answers with `platform: hostinger`, HTTP redirects to HTTPS, and `MX` still matches step 1. Nameserver changes can take up to 24–48 hours to reach every resolver; when records are still old, report what is pending and the command to re-check instead of polling for hours.\n"
       }
     ]
   },
@@ -55,10 +55,10 @@ const skills: Skill[] = [
     "resources": [
       {
         "uri": "skill://deploy-to-hosting/SKILL.md",
-        "digest": "sha256:88b2961fb48b2441c13e361d471117518b2afb4d0d49d143208e89bdf5971d22",
-        "size": 16056,
+        "digest": "sha256:07a2958d0a2f1f03f66276b057d244cb2db7c61837b01d34d3ba9539c2a2681b",
+        "size": 16048,
         "mimeType": "text/markdown",
-        "text": "---\nname: deploy-to-hosting\ndescription: \"Deploy an existing project to a website on Hostinger web hosting (Shared, Cloud or Agency plans) and keep it deployed: picks the right deploy for static sites, Node.js apps (Next.js, Nuxt, Express, Vite and similar), PHP apps and WordPress plugins or themes, sets up auto-deploy from GitHub or GitLab, manages Node.js environment variables and MySQL databases, and verifies the live site. Triggers: deploy this project, deploy to Hostinger, push my app live, redeploy, set up auto-deploy, connect my GitHub repo, add environment variables, my app needs a database, deploy my WordPress plugin or theme.\"\n---\n\n# Deploy to hosting\n\nShip a project that already exists — on disk or in a Git repository — to a Hostinger website. Building a new site from a prompt (design, store, blog) is the `hostinger-headless` skill; this one takes code as it is.\n\n## Calling the operations\n\n- Read the `inputSchema` that `search` returns before the first call of each operation. If a name below is rejected as unknown, `search` for what the step does (e.g. \"deploy static\").\n- Batch reads with `multi-execute`; values pass between steps as `$steps.<i>.<path>`. Batches chain operations from one server only — the Hostinger Connector runs `hosting`, `wordpress` and `agency-hosting` as separate servers.\n- Every deploy overwrites the website's current contents. Confirm the target domain with the user before the first deploy to a site that already has content.\n\n## 0. If a shell and the Hostinger CLI are available\n\n`hostinger up` does steps 1 to 3 in one call and is the shortest path when you can run commands and the `hostinger` CLI is installed (`brew install hostinger/tap/hostinger`), signed in and has `hostinger up`: it finds or creates the website, detects the type, packs the directory (honouring `.gitignore`; skipping `node_modules`, `.git`, `.env` files, credentials and private keys, and listing symlinks it does not follow), uploads, deploys or builds, waits for the build and links the directory in `.hostinger/site.json`, the same file this skill uses. Nothing is asked without a terminal.\n\n```\nhostinger up <dir> --domain <domain> --yes --format json     # existing website; --yes only after the user agreed to replace its content\nhostinger up <dir> --create --format json                    # new website on the only plan, free subdomain\nhostinger up <dir> --domain <domain> --dry-run                # the plan as JSON, changes nothing: show it to the user before a first deploy (overwritesContent: the real run needs --yes)\nhostinger up <dir> --domain <domain> --type nodejs --app-type next --output-directory .next --build-script build --node-version 22 --yes --format json\nhostinger up <dir> --domain <domain> --no-wait --format json  # returns buildUuid at once; poll with `hostinger hosting nodejs build <domain> <uuid>`\n```\n\nRun it from the project directory: the link is written in the current directory, with `path` naming `<dir>`. The JSON result has `url`, `data.type`, `data.buildUuid`, `data.buildState`, `data.skippedFiles` and, on failure, `error`. Shared and Cloud plans only; for Agency plans, archives and WordPress plugins or themes, use the operations below. The MCP's `hosting_deploy` does the same work when there is no shell.\n\n## 1. Pick the target website\n\n- `.hostinger/site.json` in the project: reuse its `domain` and `username` (or `website_uid`). The CLI's `hostinger up` and `hostinger link` write the same file and keep any fields you add while it names the same website (linking another website starts it afresh); its `type` may be `static`, `nodejs` or `php`.\n- Otherwise look the domain up with `hosting_websites_list` (Shared and Cloud; substring match — take the exact entry) and `agency-hosting_websites_list-plan` (Agency; keep `details.uid`).\n- No website yet:\n  - Shared and Cloud: take a domain (the user's own, or `hosting_domains_generate-free-subdomain`) and an `order_id` from `hosting_orders_list`, then `hosting_websites_create`. `datacenter_code` is needed only for the first website on a new plan (first entry of `hosting_datacenters_list`). Poll `hosting_websites_list-setups` with `domain` every 10–15 s until `status: completed` — uploads and deploys return 404 or 409 before that.\n  - Agency: `agency-hosting_website-setups_create` with `flavor: \"php-fpm\"` (plus `type: \"node-static\"` for built frontends), `settings.php.version` from `agency-hosting_php_list-versions-for-order` and `datacenter_code` from `agency-hosting_datacenters_list`. Poll `agency-hosting_website-setups_status` until `completed`; it returns the `website_uid`.\n- Node.js apps run on Business and Cloud plans (`hostinger_business_*`, `cloud_*` in `hosting_orders_list`). On other plans, build locally and deploy the output as a static site.\n\n## 2. Choose the deploy\n\n**Shared and Cloud, on the local `hostinger-api-mcp` server:** one operation does every deploy — `hosting_deploy` with `domain` and either `path` (a directory on this machine) or `git: { repository: \"owner/name\", branch }`. Given a directory it detects what the project is, packs it itself (it skips `node_modules`, `.git` and `.env` files, listing the `.env` ones as `skippedFiles` so you can set their values with `hosting_nodejs_replace-environment-variables`; it does not read `.gitignore`, so keep build output out of the directory) and does the upload, build and Git setup. Do not archive the directory or call upload and build operations by hand.\n\n| Project | `hosting_deploy` treats it as |\n| --- | --- |\n| Plain HTML/CSS/JS, or a framework's static build output | `static` — extracts as-is |\n| `package.json` with a build script, a start script or a server dependency (Next.js, Nuxt, Express, Vite…) | `nodejs` — starts a build, returns `buildUuid` |\n| PHP code, no build step | `static` |\n| WordPress plugin folder (a `Plugin Name:` header) or theme folder (`Theme Name:` in `style.css`) | `wordpress-plugin` / `wordpress-theme`; `activate: true` activates a theme |\n| A whole WordPress site from elsewhere | `wordpress-site`, with `databaseDump` — see the `migrate-to-hosting` skill |\n\n- Pass `type` to override detection. It is required for an archive (an archive cannot be inspected) and when a directory matches more than one WordPress type, which `hosting_deploy` rejects as ambiguous.\n- Node.js build settings come from the project; detection covers the framework and the build script. Set `appType`, `outputDirectory`, `buildScript`, `entryFile`, `nodeVersion` (default 22), `rootDirectory` or `packageManager` when it is wrong. A TypeScript or other compiled server app always needs `entryFile` set to the built file (for example `dist/server.js`): detection only guesses a root-level file, and the build fails with \"Entry file not found\". The entry file is relative to the root directory for express, fastify, hono, react-router and other, and to the output directory for nest, nuxt, nitro, astro and svelte-kit (`main.js`, not `dist/main.js`); Next.js ignores it. Per-framework values are in the Hostinger docs under Node.js (Supported Frameworks, Build Settings).\n- Static, PHP, plugin and theme deploys are live when the call returns. A WordPress site import only starts (`status: import_started`) and finishes extracting a few minutes later; do not report it complete or verify it before then. Node.js builds run on the server: see step 3.\n\n**Agency:** the website's type decides (`agency-hosting_websites_get`): sites created as `node-static` take `agency-hosting_deploy-node-static-website`, which runs the build when the project has one; every other site takes `agency-hosting_deploy-php-application`, which extracts the archive as-is. They deploy archives, synchronously: the site is live when the call returns. WordPress plugins and themes on Agency sites are installed from wp-admin.\n\nArchive rules for Agency (name archives `name_YYYYMMDD_HHMMSS.zip`) and for archives you build yourself:\n\n- **Static:** build locally first. `index.html` must be at the archive root, not inside a folder: `cd dist && zip -r ../site_20260101_120000.zip .`\n- **Node.js source:** no `node_modules/`, no build output (`dist/`, `.next/`, `build/`), no `.env*`, nothing matched by `.gitignore`; 50 MB at most. `git archive --format=zip -o app_20260101_120000.zip HEAD` produces exactly the committed files — mention that uncommitted changes are left out.\n\n`hosting_deploy` with `path` and the `agency-hosting_deploy-*` operations read files from this machine, so only the local server has them. The hosted server (`mcp.hostinger.com`) has `hosting_deploy` for Git repositories only (step 4) and `hosting_get-deployment` (step 3); to deploy files from this machine there, upload them yourself as below.\n\n### Without the local deploy operations (local files on the hosted server; Agency on either server)\n\n1. Get upload credentials: `hosting_files_generate-upload-url` (`username`, `domain`); Agency: `agency-hosting_files_generate-upload-url` (`website_uid`). Both return `url`, `auth_key` and `rest_auth_key`, which authenticate the upload instead of the API token.\n2. Upload each file with TUS, where `DEST` is its path in the website's storage:\n\n```bash\nSIZE=$(wc -c < \"$FILE\" | tr -d ' ')\ncurl -sS -X POST \"$URL/$DEST?override=true\" -H \"X-Auth: $AUTH_KEY\" -H \"X-Auth-Rest: $REST_AUTH_KEY\" -H \"Tus-Resumable: 1.0.0\" -H \"Upload-Length: $SIZE\" -H \"Upload-Offset: 0\"\ncurl -sS -X PATCH \"$URL/$DEST?override=true\" -H \"X-Auth: $AUTH_KEY\" -H \"X-Auth-Rest: $REST_AUTH_KEY\" -H \"Tus-Resumable: 1.0.0\" -H \"Content-Type: application/offset+octet-stream\" -H \"Upload-Offset: 0\" --data-binary \"@$FILE\"\n```\n\n   The first call returns `201`, the second `204` with an `Upload-Offset` header equal to the file size. `override=true` makes a retry safe.\n3. Deploy from the uploaded files (`RANDOM8` is any fresh 8-character string, e.g. `$(LC_ALL=C tr -dc 'a-z0-9' < /dev/urandom | head -c 8)`):\n\n| Project | `DEST` | Then |\n| --- | --- | --- |\n| Static or PHP | `site.zip` | `hosting_websites_deploy-static-site-archive` with `archive_path: \"site.zip\"` |\n| Node.js | `app.zip` | `hosting_nodejs_build-settings-from-archive` with `archive_path: \"app.zip\"`, then `hosting_nodejs_start-build` with those settings, `source_type: \"archive\"` and `source_options.archive_path: \"app.zip\"` |\n| WordPress plugin | every file, as `wp-content/plugins/SLUG-RANDOM8/<path in the plugin>` | `wordpress_plugins_deploy` with `slug` and `plugin_path: \"SLUG-RANDOM8\"` |\n| WordPress theme | every file, as `wp-content/themes/SLUG-RANDOM8/<path in the theme>` | `wordpress_themes_deploy` with `slug`, `theme_path: \"SLUG-RANDOM8\"` and optional `is_activated` |\n| Agency, extracted as-is | `.h5g/site.zip` | `agency-hosting_files_import-website-from-archive` with `archive_name: \"site.zip\"` |\n| Agency `node-static` | `.h5g/RANDOM8/app.zip` | `agency-hosting_websites_build-nodejs-assets` with `archive_path: \".h5g/RANDOM8\"` — the directory, not the file |\n\n## 3. Node.js builds\n\n`hosting_deploy` returns a `buildUuid` at once; the build runs on the server and takes minutes. Track it — and a build started with `hosting_nodejs_start-build` after an upload — with `hosting_get-deployment` (`domain`, optionally `buildUuid`; the latest build by default), polling every 10–20 s until `build.state` is `completed` or `failed`. It returns the build, its log and the stored build settings; pass the previous `logs.lines` as `fromLine` to read only new output.\n\n- Failed build: the response already carries `analysis` (fetched once per build; the API allows 5 a minute).\n- Wrong detection (framework, `output_directory`, or an entry file inside the build output, such as `dist/server.js` for a compiled app): deploy again with `appType`, `outputDirectory`, `buildScript` or `entryFile` set. An archive deploy sends its settings with the request and leaves the stored ones alone; a Git deploy also stores these values, so later pushes build with them.\n\nLocal files on the hosted server, deployed from an upload (step 2):\n\n- Wrong detection: run `hosting_nodejs_start-build` again with explicit values, `source_type: \"archive\"` and `source_options.archive_path` set to the archive's file name in the document root (check it is there with `hosting_files_list-website-and-directories`). Store the same values with `hosting_nodejs_update-build-settings`.\n- To review detected settings before any build: upload the archive with `hosting_files_generate-upload-url` (the TUS steps are in its description), then `hosting_nodejs_build-settings-from-archive`.\n\n## 4. Auto-deploy from Git\n\nOn both the local and the hosted server, `hosting_deploy` with `git: { repository: \"owner/name\", branch }` does all of it: it finds the Git installation that can reach the repository and deploys it as the `type` you give. Always pass `type: \"static\"` or `\"nodejs\"` unless the site already runs a Node.js app (or you pass Node.js settings such as `appType`): a new site is not detected as Node.js, and a Node.js repository deployed as static would publish its source. Then:\n- **PHP and static sites:** saves the auto-deployment settings, which deploys the branch immediately and again on every push;\n- **Node.js sites:** starts a build of the branch with the stored build settings; later pushes build the same way. When none are stored, they are detected from the branch's `package.json` and stored for those pushes; pass `appType`, `nodeVersion`, `outputDirectory`, `buildScript` or `entryFile` to override them (a compiled app still needs `entryFile`).\n\nWith no active installation it stops and says so: the user connects GitHub or GitLab once in hPanel under Websites → Manage → Advanced → Git; there is no API for that step. Confirm with `hosting_get-deployment`, which returns the stored `gitAutoDeployment`.\n\nAgency Plan sites have no Git operations; deploy archives.\n\n## 5. Environment variables (Node.js)\n\n`hosting_nodejs_replace-environment-variables` replaces the whole set — anything not sent is deleted.\n\n1. `hosting_nodejs_list-environment-variables` for the current keys. Values come back as `********`; never send those back.\n2. Build the full set: every current key plus the new ones, with real values from the project's `.env` or the user. When the real value of an existing key is unknown, ask — do not drop it.\n3. Send it once; the app restarts. Values baked in at build time (Next.js `NEXT_PUBLIC_*`, Vite `VITE_*`) need a new `hosting_nodejs_start-build`.\n\nKeys use uppercase letters, digits and underscores. Never commit `.env` files or repeat secret values back to the user.\n\n## 6. Database\n\n- **Node.js:** `hosting_databases_setup-website` creates a MySQL database and writes `DB_HOST`, `DB_PORT`, `DB_NAME`, `DB_USER`, `DB_PASSWORD` and `DATABASE_URL` into the environment, then restarts the app. The password is generated and never returned. It fails with 422 when any of those keys exists — remove them first with the step 5 replace.\n- **PHP:** `hosting_databases_create` with `name`, `user`, a strong generated `password` and `website_domain`; read the prefixed full name back from `hosting_databases_list`. The app reads credentials from a config file on the server that stays out of Git, and connects to `localhost` or `127.0.0.1`.\n- **Agency:** `agency-hosting_databases_create-website`; the app connects to `localhost`.\n- The `srvNNNN.hstgr.io` host from `hosting_databases_list` is only for connections from outside Hostinger — never put it in the deployed app.\n\n## 7. Verify and record\n\n```bash\ncurl -s -o /dev/null -w \"%{http_code}\\n\" https://DOMAIN/\ncurl -s https://DOMAIN/ | grep -o \"TEXT THE PROJECT RENDERS\"\n```\n\nA `200` alone can be a placeholder page; match real copy. A new site may serve a default page briefly — clear it with `hosting_cache_clear-website` and retry before calling the deploy failed.\n\nWrite `.hostinger/site.json` in the project so later runs reuse the target: `{ \"domain\", \"username\" or \"website_uid\", \"type\": \"static\" | \"nodejs\" | \"php\" }`, keeping any fields already there.\n"
+        "text": "---\nname: deploy-to-hosting\ndescription: \"Deploy an existing project to a website on Hostinger web hosting (Shared, Cloud or Agency plans) and keep it deployed: picks the right deploy for static sites, Node.js apps (Next.js, Nuxt, Express, Vite and similar), PHP apps and WordPress plugins or themes, sets up auto-deploy from GitHub or GitLab, manages Node.js environment variables and MySQL databases, and verifies the live site. Triggers: deploy this project, deploy to Hostinger, push my app live, redeploy, set up auto-deploy, connect my GitHub repo, add environment variables, my app needs a database, deploy my WordPress plugin or theme.\"\n---\n\n# Deploy to hosting\n\nShip a project that already exists — on disk or in a Git repository — to a Hostinger website. Building a new site from a prompt (design, store, blog) is the `hostinger-headless` skill; this one takes code as it is.\n\n## Calling the operations\n\n- Read the `inputSchema` that `search` returns before the first call of each operation. If a name below is rejected as unknown, `search` for what the step does (e.g. \"deploy static\").\n- Batch reads with `multi-execute`; values pass between steps as `$steps.<i>.<path>`. Batches chain operations from one server only — the Hostinger Connector runs `hosting`, `wordpress` and `agency-hosting` as separate servers.\n- Every deploy overwrites the website's current contents. Confirm the target domain with the user before the first deploy to a site that already has content.\n\n## 0. If a shell and the Hostinger CLI are available\n\n`hostinger up` does steps 1 to 3 in one call and is the shortest path when you can run commands and the `hostinger` CLI is installed (`brew install hostinger/tap/hostinger`), signed in and has `hostinger up`: it finds or creates the website, detects the type, packs the directory (honouring `.gitignore`; skipping `node_modules`, `.git`, `.env` files, credentials and private keys, and listing symlinks it does not follow), uploads, deploys or builds, waits for the build and links the directory in `.hostinger/site.json`, the same file this skill uses. Nothing is asked without a terminal.\n\n```\nhostinger up <dir> --domain <domain> --yes --format json     # existing website; --yes only after the user agreed to replace its content\nhostinger up <dir> --create --format json                    # new website on the only plan, free subdomain\nhostinger up <dir> --domain <domain> --dry-run                # the plan as JSON, changes nothing: show it to the user before a first deploy (overwritesContent: the real run needs --yes)\nhostinger up <dir> --domain <domain> --type nodejs --app-type next --output-directory .next --build-script build --node-version 22 --yes --format json\nhostinger up <dir> --domain <domain> --no-wait --format json  # returns buildUuid at once; poll with `hostinger hosting nodejs build <domain> <uuid>`\n```\n\nRun it from the project directory: the link is written in the current directory, with `path` naming `<dir>`. The JSON result has `url`, `data.type`, `data.buildUuid`, `data.buildState`, `data.skippedFiles` and, on failure, `error`. Shared and Cloud plans only; for Agency plans, archives and WordPress plugins or themes, use the operations below. The MCP's `hosting_deploy` does the same work when there is no shell.\n\n## 1. Pick the target website\n\n- `.hostinger/site.json` in the project: reuse its `domain` and `username` (or `website_uid`). The CLI's `hostinger up` and `hostinger link` write the same file and keep any fields you add while it names the same website (linking another website starts it afresh); its `type` may be `static`, `nodejs` or `php`.\n- Otherwise look the domain up with `hosting_websites_list` (Shared and Cloud; substring match — take the exact entry) and `agency-hosting_websites_list-plan` (Agency; keep `details.uid`).\n- No website yet:\n  - Shared and Cloud: take a domain (the user's own, or `hosting_domains_generate-free-subdomain`) and an `order_id` from `hosting_orders_list`, then `hosting_websites_create`. `datacenter_code` is needed only for the first website on a new plan (first entry of `hosting_datacenters_list`). Poll `hosting_websites_list-setups` with `domain` every 10–15 s until `status: completed` — uploads and deploys return 404 or 409 before that.\n  - Agency: `agency-hosting_website-setups_create` with `flavor: \"php-fpm\"` (plus `type: \"node-static\"` for built frontends), `settings.php.version` from `agency-hosting_php_list-versions-for-order` and `datacenter_code` from `agency-hosting_datacenters_list`. Poll `agency-hosting_website-setups_status` until `completed`; it returns the `website_uid`.\n- Node.js apps run on Business and Cloud plans (`hostinger_business_*`, `cloud_*` in `hosting_orders_list`). On other plans, build locally and deploy the output as a static site.\n\n## 2. Choose the deploy\n\n**Shared and Cloud, on the local `hostinger-api-mcp` server:** one operation does every deploy — `hosting_deploy` with `domain` and either `path` (a directory on this machine) or `git: { repository: \"owner/name\", branch }`. Given a directory it detects what the project is, packs it itself (it skips `node_modules`, `.git` and `.env` files, listing the `.env` ones as `skippedFiles` so you can set their values with `hosting_nodejs_replace-environment-variables`; it does not read `.gitignore`, so keep build output out of the directory) and does the upload, build and Git setup. Do not archive the directory or call upload and build operations by hand.\n\n| Project | `hosting_deploy` treats it as |\n| --- | --- |\n| Plain HTML/CSS/JS, or a framework's static build output | `static` — extracts as-is |\n| `package.json` with a build script, a start script or a server dependency (Next.js, Nuxt, Express, Vite…) | `nodejs` — starts a build, returns `buildUuid` |\n| PHP code, no build step | `static` |\n| WordPress plugin folder (a `Plugin Name:` header) or theme folder (`Theme Name:` in `style.css`) | `wordpress-plugin` / `wordpress-theme`; `activate: true` activates a theme |\n| A whole WordPress site from elsewhere | `wordpress-site`, with `databaseDump` — see the `migrate-to-hosting` skill |\n\n- Pass `type` to override detection. It is required for an archive (an archive cannot be inspected) and when a directory matches more than one WordPress type, which `hosting_deploy` rejects as ambiguous.\n- Node.js build settings come from the project; detection covers the framework and the build script. Set `appType`, `outputDirectory`, `buildScript`, `entryFile`, `nodeVersion` (default 22), `rootDirectory` or `packageManager` when it is wrong. A TypeScript or other compiled server app always needs `entryFile` set to the built file (for example `dist/server.js`): detection only guesses a root-level file, and the build fails with \"Entry file not found\". The entry file is relative to the root directory for express, fastify, hono, react-router and other, and to the output directory for nest, nuxt, nitro, astro and svelte-kit (`main.js`, not `dist/main.js`); Next.js ignores it. Per-framework values are in the Hostinger docs under Node.js (Supported Frameworks, Build Settings).\n- Static, PHP, plugin and theme deploys are live when the call returns. A WordPress site import only starts (`status: import_started`) and finishes extracting a few minutes later; do not report it complete or verify it before then. Node.js builds run on the server: see step 3.\n\n**Agency:** the website's type decides (`agency-hosting_websites_get`): sites created as `node-static` take `agency-hosting_deploy-node-static-website`, which runs the build when the project has one; every other site takes `agency-hosting_deploy-php-application`, which extracts the archive as-is. They deploy archives, synchronously: the site is live when the call returns. WordPress plugins and themes on Agency sites are installed from wp-admin.\n\nArchive rules for Agency (name archives `name_YYYYMMDD_HHMMSS.zip`) and for archives you build yourself:\n\n- **Static:** build locally first. `index.html` must be at the archive root, not inside a folder: `cd dist && zip -r ../site_20260101_120000.zip .`\n- **Node.js source:** no `node_modules/`, no build output (`dist/`, `.next/`, `build/`), no `.env*`, nothing matched by `.gitignore`; 50 MB at most. `git archive --format=zip -o app_20260101_120000.zip HEAD` produces exactly the committed files — mention that uncommitted changes are left out.\n\n`hosting_deploy` with `path` and the `agency-hosting_deploy-*` operations read files from this machine, so only the local server has them. The hosted server (`mcp.hostinger.com`) has `hosting_deploy` for Git repositories only (step 4) and `hosting_get-deployment` (step 3); to deploy files from this machine there, upload them yourself as below.\n\n### Without the local deploy operations (local files on the hosted server; Agency on either server)\n\n1. Get upload credentials: `hosting_files_generate-upload-url` (`username`, `domain`); Agency: `agency-hosting_files_generate-upload-url` (`website_uid`). Both return `url`, `auth_key` and `rest_auth_key`, which authenticate the upload instead of the API token.\n2. Upload each file with TUS, where `DEST` is its path in the website's storage:\n\n```bash\nSIZE=$(wc -c < \"$FILE\" | tr -d ' ')\ncurl -sS -X POST \"$URL/$DEST?override=true\" -H \"X-Auth: $AUTH_KEY\" -H \"X-Auth-Rest: $REST_AUTH_KEY\" -H \"Tus-Resumable: 1.0.0\" -H \"Upload-Length: $SIZE\" -H \"Upload-Offset: 0\"\ncurl -sS -X PATCH \"$URL/$DEST?override=true\" -H \"X-Auth: $AUTH_KEY\" -H \"X-Auth-Rest: $REST_AUTH_KEY\" -H \"Tus-Resumable: 1.0.0\" -H \"Content-Type: application/offset+octet-stream\" -H \"Upload-Offset: 0\" --data-binary \"@$FILE\"\n```\n\n   The first call returns `201`, the second `204` with an `Upload-Offset` header equal to the file size. `override=true` makes a retry safe.\n3. Deploy from the uploaded files (`RANDOM8` is any fresh 8-character string, e.g. `$(LC_ALL=C tr -dc 'a-z0-9' < /dev/urandom | head -c 8)`):\n\n| Project | `DEST` | Then |\n| --- | --- | --- |\n| Static or PHP | `site.zip` | `hosting_websites_deploy-static-site-archive` with `archive_path: \"site.zip\"` |\n| Node.js | `app.zip` | `hosting_nodejs_build-settings-from-archive` with `archive_path: \"app.zip\"`, then `hosting_nodejs_start-build` with those settings, `source_type: \"archive\"` and `source_options.archive_path: \"app.zip\"` |\n| WordPress plugin | every file, as `wp-content/plugins/SLUG-RANDOM8/<path in the plugin>` | `wordpress_plugins_deploy` with `slug` and `plugin_path: \"SLUG-RANDOM8\"` |\n| WordPress theme | every file, as `wp-content/themes/SLUG-RANDOM8/<path in the theme>` | `wordpress_themes_deploy` with `slug`, `theme_path: \"SLUG-RANDOM8\"` and optional `is_activated` |\n| Agency, extracted as-is | `.h5g/site.zip` | `agency-hosting_files_import-website-from-archive` with `archive_name: \"site.zip\"` |\n| Agency `node-static` | `.h5g/RANDOM8/app.zip` | `agency-hosting_websites_build-nodejs-assets` with `archive_path: \".h5g/RANDOM8\"` — the directory, not the file |\n\n## 3. Node.js builds\n\n`hosting_deploy` returns a `buildUuid` at once; the build runs on the server and takes minutes. Track it — and a build started with `hosting_nodejs_start-build` after an upload — with `hosting_get-deployment` (`domain`, optionally `buildUuid`; the latest build by default), polling every 10–20 s until `build.state` is `completed` or `failed`. It returns the build, its log and the stored build settings; pass the previous `logs.lines` as `fromLine` to read only new output.\n\n- Failed build: the response already carries `analysis` (fetched once per build; the API allows 5 a minute).\n- Wrong detection (framework, `output_directory`, or an entry file inside the build output, such as `dist/server.js` for a compiled app): deploy again with `appType`, `outputDirectory`, `buildScript` or `entryFile` set. An archive deploy sends its settings with the request and leaves the stored ones alone; a Git deploy also stores these values, so later pushes build with them.\n\nLocal files on the hosted server, deployed from an upload (step 2):\n\n- Wrong detection: run `hosting_nodejs_start-build` again with explicit values, `source_type: \"archive\"` and `source_options.archive_path` set to the archive's file name in the document root (check it is there with `hosting_files_list-website-and-directories`). Store the same values with `hosting_nodejs_update-build-settings`.\n- To review detected settings before any build: upload the archive with `hosting_files_generate-upload-url` (the TUS steps are in its description), then `hosting_nodejs_build-settings-from-archive`.\n\n## 4. Auto-deploy from Git\n\nOn both the local and the hosted server, `hosting_deploy` with `git: { repository: \"owner/name\", branch }` does all of it: it finds the Git installation that can reach the repository and deploys it as the `type` you give. Always pass `type: \"static\"` or `\"nodejs\"` unless the site already runs a Node.js app (or you pass Node.js settings such as `appType`): a new site is not detected as Node.js, and a Node.js repository deployed as static would publish its source. Then:\n- **PHP and static sites:** saves the auto-deployment settings, which deploys the branch immediately and again on every push;\n- **Node.js sites:** starts a build of the branch with the stored build settings; later pushes build the same way. When none are stored, they are detected from the branch's `package.json` and stored for those pushes; pass `appType`, `nodeVersion`, `outputDirectory`, `buildScript` or `entryFile` to override them (a compiled app still needs `entryFile`).\n\nWith no active installation it stops and says so: the user connects GitHub or GitLab once in hPanel under Websites → Manage → Advanced → Git; there is no API for that step. Confirm with `hosting_get-deployment`, which returns the stored `gitAutoDeployment`.\n\nAgency Plan sites have no Git operations; deploy archives.\n\n## 5. Environment variables (Node.js)\n\n`hosting_nodejs_replace-environment-variables` replaces the whole set — anything not sent is deleted.\n\n1. `hosting_nodejs_list-environment-variables` for the current keys. Values come back as `********`; never send those back.\n2. Build the full set: every current key plus the new ones, with real values from the project's `.env` or the user. When the real value of an existing key is unknown, ask — do not drop it.\n3. Send it once; the app restarts. Values baked in at build time (Next.js `NEXT_PUBLIC_*`, Vite `VITE_*`) need a new `hosting_nodejs_start-build`.\n\nKeys use uppercase letters, digits and underscores. Never commit `.env` files or repeat secret values back to the user.\n\n## 6. Database\n\n- **Node.js:** `hosting_databases_setup-website` creates a MySQL database and writes `DB_HOST`, `DB_PORT`, `DB_NAME`, `DB_USER`, `DB_PASSWORD` and `DATABASE_URL` into the environment, then restarts the app. The password is generated and never returned. It fails with 422 when any of those keys exists — remove them first with the step 5 replace.\n- **PHP:** `hosting_databases_create` with `name`, `user`, a strong generated `password` and `website_domain`; read the prefixed full name back from `hosting_databases_list`. The app reads credentials from a config file on the server that stays out of Git, and connects to `localhost` or `127.0.0.1`.\n- **Agency:** `agency-hosting_databases_create-website`; the app connects to `localhost`.\n- The `srvNNNN.hstgr.io` host from `hosting_databases_list` is only for connections from outside Hostinger — never put it in the deployed app.\n\n## 7. Verify and record\n\n```bash\ncurl -s -o /dev/null -w \"%{http_code}\\n\" https://DOMAIN/\ncurl -s https://DOMAIN/ | grep -o \"TEXT THE PROJECT RENDERS\"\n```\n\nA `200` alone can be a placeholder page; match real copy. A new site may serve a default page briefly — clear it with `hosting_cache_clear` and retry before calling the deploy failed.\n\nWrite `.hostinger/site.json` in the project so later runs reuse the target: `{ \"domain\", \"username\" or \"website_uid\", \"type\": \"static\" | \"nodejs\" | \"php\" }`, keeping any fields already there.\n"
       }
     ]
   },
@@ -315,10 +315,10 @@ const skills: Skill[] = [
     "resources": [
       {
         "uri": "skill://troubleshoot-website/SKILL.md",
-        "digest": "sha256:4d0c9df2d9f11ab9bf11e94c0ae5e4b91a225eb50f52ad61cd680130caa3ff9c",
-        "size": 9622,
+        "digest": "sha256:7b44bc7cb4f0d92c6837e6a3ea6051a5b2bbad1e70671b8368c2ef7d9ad1b05f",
+        "size": 9723,
         "mimeType": "text/markdown",
-        "text": "---\nname: troubleshoot-website\ndescription: \"Diagnose and fix a website on Hostinger web hosting (Shared, Cloud or Agency plans) that is down, slow, erroring, insecure or failing to build. Checks the site from outside, reads builds, runtime logs, WordPress health, SSL, cache and PHP settings through the Hostinger MCP, names the cause with evidence, and applies the fix once the user agrees. Triggers: my site is down, site not loading, 500 / 502 / 503 error, white screen, error establishing a database connection, site is slow, SSL or certificate warning, not secure, changes not showing, Node.js build failed, app keeps crashing.\"\n---\n\n# Troubleshoot a website\n\nOne website and one symptom in; a named cause, the evidence for it, and a fix out. Stay read-only until the cause is stated and the user agrees to the fix.\n\n## Calling the operations\n\n- Read the `inputSchema` that `search` returns before the first call of each operation. If a name below is rejected as unknown, `search` for what the step does (e.g. \"ssl status\").\n- Batch reads with `multi-execute` and pass values between steps with `$steps.<i>.<path>`, e.g. `\"$steps.0.data.0.username\"`. A batch stops at its first failure.\n- The Hostinger Connector runs each product as its own MCP server (`hosting`, `wordpress`, `agency-hosting`, `domains`, `dns`), so a batch can only chain operations from one server. When `search` cannot find an operation, that product group is switched off in the Connector — ask the user to enable it.\n\n## 1. Find the website\n\nRun both lookups, and keep the result for every later call:\n\n- `hosting_websites_list` with `domain` — Shared and Cloud plans. The filter is a substring match, so take the entry whose `domain` is exactly the one asked about. Keep `username`, `order_id` and `website_type`; every `hosting_*` and `wordpress_*` call is keyed on `username` + `domain`.\n- `agency-hosting_websites_list-plan` with `domain` — Agency Plan. Keep `details.uid` (the `website_uid` of every `agency-hosting_*` call), `details.type`, `details.ipv4` and `details.domains`.\n\nNeither finds it: the domain is not a website on this account — say so and show where it points (step 2).\n\n## 2. Look at it from outside\n\nRun these alongside step 1:\n\n```bash\ncurl -sS -o /dev/null -w \"%{http_code} ttfb=%{time_starttransfer}s %{redirect_url}\\n\" https://DOMAIN/\ncurl -sSI https://DOMAIN/\ndig +short NS DOMAIN; dig +short A DOMAIN; dig +short CAA DOMAIN\n```\n\n- Hostinger responses carry `platform: hostinger` and `panel: hpanel`. Without them, or with DNS pointing elsewhere, traffic is not reaching this hosting — hand over to the `connect-domain` skill.\n- Certificate or TLS errors → [SSL](#ssl).\n- `5xx`, a blank page or an error page → [By website type](#3-by-website-type).\n- `200` with old content → cache: `hosting_cache_clear-website` (also purges the Hostinger CDN; pass `directory` for WordPress in a subfolder), plus `wordpress_litespeed-cache_purge-lite-speed` for WordPress; Agency: `agency-hosting_cache_clear-website`.\n- Slow first byte → [Slow site](#slow-site). Behind the Hostinger CDN, `x-hcdn-upstream-rt` is the origin's own response time in seconds; a small value there means the server is not the bottleneck.\n\n## 3. By website type\n\n`website_type` (Shared/Cloud) or `details.type` (Agency) picks the branch. `builder` and `horizons` sites are not managed by these operations — send the user to hPanel.\n\n### Node.js (`nodejs`)\n\nBatch `hosting_get-deployment` (the latest build with its log, failure analysis and stored settings), `hosting_nodejs_runtime-logs` (`period: \"1h\"`, `levels: [\"ERROR\", \"WARN\"]`) and `hosting_nodejs_list-environment-variables` (keys only; values always come back masked).\n\n- Latest build `failed`: `hosting_get-deployment` already holds the `analysis` (fetched once per build — the API re-runs it on every call and allows 5 a minute). A wrongly detected framework, output directory or missing `entry_file` is the usual cause: compare the returned `buildSettings` with the project and deploy again with corrected `appType`, `outputDirectory`, `buildScript` or `entryFile`; a Git deploy stores them, so pushes build correctly too. A site deployed on the hosted server from uploaded files has no `hosting_deploy` to repeat: rebuild through `hosting_nodejs_start-build` with the corrected values and store them with `hosting_nodejs_update-build-settings`.\n- Build `completed` but the app errors: read the runtime logs; entries older than `last_deployed_at` belong to the previous deploy. A variable the code reads but the key list lacks is fixed with the `deploy-to-hosting` skill's environment step. `Access denied for user '…'@'::1'` means the app connects to `localhost` — `DB_HOST` must be `127.0.0.1`.\n- Hung process: `hosting_nodejs_restart-application` (restarts without rebuilding).\n\n### WordPress (`wordpress`)\n\n`wordpress_installations_list` with `username` and `domain` gives the install `id` — the `software` parameter of every `wordpress_*` call. Batch `wordpress_installations_check-if-are-valid` (`software_ids: [id]`, `force: true`), `wordpress_plugins_list-installed` and `wordpress_maintenance_show-status`.\n\n- Invalid install: `validation_error` names the problem.\n- Broken after a plugin or theme change: deactivate suspects one at a time with `wordpress_plugins_deactivate` (queued — allow a few seconds), re-run the step 2 check after each, and reactivate with `wordpress_plugins_activate` any that were not the cause.\n- Maintenance page stuck: `wordpress_maintenance_toggle` with `enabled: false`.\n- \"Error establishing a database connection\": `hosting_databases_list` with `domain`; corrupted tables are fixed by `hosting_databases_repair` (runs in the background). `wp-config.php` cannot be read through the API because files with secrets are refused — for credential checks hand the user `hosting_databases_phpmyadmin-link`.\n- Memory or upload-size errors → [PHP](#php).\n\n### Static or PHP (`other`)\n\n- `403` or `404` at `/`: `hosting_files_list-website-and-directories` with `max_depth: 1`. `index.html` or `index.php` must sit at the document root; finding it one folder down means the archive was packed a level too deep — redeploy it flat with the `deploy-to-hosting` skill.\n- Read `.htaccess` or other config with `hosting_files_website-content`.\n- PHP errors → [PHP](#php).\n\n### PHP\n\n`hosting_php_get` returns every extension and option (around 25 KB), so call it only for PHP problems. `hosting_php_update-version` switches versions. `hosting_php_update-options` silently caps values at the plan maximum (`max` in `hosting_php_get`), so read the applied value back. Agency: `agency-hosting_php_list-options-for-website`, then `agency-hosting_php_replace-website-options` — a full replace, so send every custom option that should stay.\n\n### Agency Plan sites\n\n`agency-hosting_websites_get` shows state and quotas, `agency-hosting_websites_list-processes` shows failed jobs (SSL setup, backups), and `agency-hosting_wordpress_settings` shows core version, LiteSpeed, object cache and maintenance mode. When `wordpress_installations_list` does not return the site, plugins are managed from wp-admin.\n\n## SSL\n\nShared and Cloud, `hosting_ssl_status`:\n\n- `not_installed` or `failed` (`last_error` says why): the domain must resolve to Hostinger, and any CAA record must allow `letsencrypt.org`, before `hosting_ssl_install` can succeed. Poll the status until `active` or `failed`.\n- `installing` or `waiting_for_retry`: wait — another install request returns 422.\n- Free `*.hostingersite.com` subdomains use a platform certificate; installing returns 422 by design.\n- Browser still warns while the certificate is `active`: turn on the redirect with `hosting_ssl_toggle-https-redirect` when `is_https_redirect_enabled` is false, otherwise the page loads `http://` assets (mixed content) that the app has to change.\n\nAgency, `agency-hosting_ssl_website-status` for each domain: every domain allows three certificate setups per seven days and one request a minute. Check `agency-hosting_websites_list-processes` before `agency-hosting_ssl_install-website` or `agency-hosting_ssl_reinstall-website`, and never retry in a loop.\n\n## Slow site\n\n- WordPress: `wordpress_litespeed-cache_show-lite-speed-status` and `wordpress_object-cache_show-memcached-status`. Turning on Memcached with `wordpress_object-cache_toggle-memcached` is the usual quick win.\n- Other sites: server caching may be off or development mode left on, and neither has a read operation. `hosting_cache_toggle-website` with `enabled: true` does nothing when caching is already on; `hosting_cache_toggle-cacheless` with `enabled: false` turns development mode off.\n- PHP 7.x runs markedly slower than 8.x; propose a supported 8.x version from `hosting_php_get` when the app allows it.\n- Agency: `agency-hosting_metrics_list-order-resource-usage` with `time_frame_hours: 24` shows CPU, memory and processes per website against the plan quota.\n- Shared and Cloud have no CPU or memory metrics in the API. When the evidence points at resource limits, send the user to hPanel's resource usage page.\n\n## Apply the fix\n\nState the cause, the evidence and the single change proposed, and make it only after the user agrees. Then re-run the step 2 check, polling any queued job first, to show the symptom is gone. When the fix needs something the API cannot do, say so and name the hPanel page.\n\n## Not available through the API\n\n- Website backups and restores — hPanel's Backups page.\n- CPU, memory and process usage for Shared and Cloud plans.\n- PHP error and access logs.\n"
+        "text": "---\nname: troubleshoot-website\ndescription: \"Diagnose and fix a website on Hostinger web hosting (Shared, Cloud or Agency plans) that is down, slow, erroring, insecure or failing to build. Checks the site from outside, reads builds, runtime logs, WordPress health, SSL, cache and PHP settings through the Hostinger MCP, names the cause with evidence, and applies the fix once the user agrees. Triggers: my site is down, site not loading, 500 / 502 / 503 error, white screen, error establishing a database connection, site is slow, SSL or certificate warning, not secure, changes not showing, Node.js build failed, app keeps crashing.\"\n---\n\n# Troubleshoot a website\n\nOne website and one symptom in; a named cause, the evidence for it, and a fix out. Stay read-only until the cause is stated and the user agrees to the fix.\n\n## Calling the operations\n\n- Read the `inputSchema` that `search` returns before the first call of each operation. If a name below is rejected as unknown, `search` for what the step does (e.g. \"ssl status\").\n- Batch reads with `multi-execute` and pass values between steps with `$steps.<i>.<path>`, e.g. `\"$steps.0.data.0.username\"`. A batch stops at its first failure.\n- The Hostinger Connector runs each product as its own MCP server (`hosting`, `wordpress`, `agency-hosting`, `domains`, `dns`), so a batch can only chain operations from one server. When `search` cannot find an operation, that product group is switched off in the Connector — ask the user to enable it.\n\n## 1. Find the website\n\nRun both lookups, and keep the result for every later call:\n\n- `hosting_websites_list` with `domain` — Shared and Cloud plans. The filter is a substring match, so take the entry whose `domain` is exactly the one asked about. Keep `username`, `order_id` and `website_type`; every `hosting_*` and `wordpress_*` call is keyed on `username` + `domain`.\n- `agency-hosting_websites_list-plan` with `domain` — Agency Plan. Keep `details.uid` (the `website_uid` of every `agency-hosting_*` call), `details.type`, `details.ipv4` and `details.domains`.\n\nNeither finds it: the domain is not a website on this account — say so and show where it points (step 2).\n\n## 2. Look at it from outside\n\nRun these alongside step 1:\n\n```bash\ncurl -sS -o /dev/null -w \"%{http_code} ttfb=%{time_starttransfer}s %{redirect_url}\\n\" https://DOMAIN/\ncurl -sSI https://DOMAIN/\ndig +short NS DOMAIN; dig +short A DOMAIN; dig +short CAA DOMAIN\n```\n\n- Hostinger responses carry `platform: hostinger` and `panel: hpanel`. Without them, or with DNS pointing elsewhere, traffic is not reaching this hosting — hand over to the `connect-domain` skill.\n- Certificate or TLS errors → [SSL](#ssl).\n- `5xx`, a blank page or an error page → [By website type](#3-by-website-type).\n- `200` with old content → cache: `hosting_cache_clear` (also purges the Hostinger CDN; pass `directory` for WordPress in a subfolder), plus `wordpress_litespeed-cache_purge-lite-speed` for WordPress; Agency: `agency-hosting_cache_clear-website`.\n- Slow first byte → [Slow site](#slow-site). Behind the Hostinger CDN, `x-hcdn-upstream-rt` is the origin's own response time in seconds; a small value there means the server is not the bottleneck.\n\n## 3. By website type\n\n`website_type` (Shared/Cloud) or `details.type` (Agency) picks the branch. `builder` and `horizons` sites are not managed by these operations — send the user to hPanel.\n\n### Node.js (`nodejs`)\n\nBatch `hosting_get-deployment` (the latest build with its log, failure analysis and stored settings), `hosting_nodejs_runtime-logs` (`period: \"1h\"`, `levels: [\"ERROR\", \"WARN\"]`) and `hosting_nodejs_list-environment-variables` (keys only; values always come back masked).\n\n- Latest build `failed`: `hosting_get-deployment` already holds the `analysis` (fetched once per build — the API re-runs it on every call and allows 5 a minute). A wrongly detected framework, output directory or missing `entry_file` is the usual cause: compare the returned `buildSettings` with the project and deploy again with corrected `appType`, `outputDirectory`, `buildScript` or `entryFile`; a Git deploy stores them, so pushes build correctly too. A site deployed on the hosted server from uploaded files has no `hosting_deploy` to repeat: rebuild through `hosting_nodejs_start-build` with the corrected values and store them with `hosting_nodejs_update-build-settings`.\n- Build `completed` but the app errors: read the runtime logs; entries older than `last_deployed_at` belong to the previous deploy. A variable the code reads but the key list lacks is fixed with the `deploy-to-hosting` skill's environment step. `Access denied for user '…'@'::1'` means the app connects to `localhost` — `DB_HOST` must be `127.0.0.1`.\n- Hung process: `hosting_nodejs_restart-application` (restarts without rebuilding).\n\n### WordPress (`wordpress`)\n\n`wordpress_installations_list` with `username` and `domain` gives the install `id` — the `software` parameter of every `wordpress_*` call. Batch `wordpress_installations_check-if-are-valid` (`software_ids: [id]`, `force: true`), `wordpress_plugins_list-installed` and `wordpress_maintenance_show-status`.\n\n- Invalid install: `validation_error` names the problem.\n- Broken after a plugin or theme change: deactivate suspects one at a time with `wordpress_plugins_deactivate` (queued — allow a few seconds), re-run the step 2 check after each, and reactivate with `wordpress_plugins_activate` any that were not the cause.\n- Maintenance page stuck: `wordpress_maintenance_toggle` with `enabled: false`.\n- \"Error establishing a database connection\": `hosting_databases_list` with `domain`; corrupted tables are fixed by `hosting_databases_repair` (runs in the background). `wp-config.php` cannot be read through the API because files with secrets are refused — for credential checks hand the user `hosting_databases_phpmyadmin-link`.\n- Memory or upload-size errors → [PHP](#php).\n\n### Static or PHP (`other`)\n\n- `403` or `404` at `/`: `hosting_files_list-website-and-directories` with `max_depth: 1`. `index.html` or `index.php` must sit at the document root; finding it one folder down means the archive was packed a level too deep — redeploy it flat with the `deploy-to-hosting` skill.\n- Read `.htaccess` or other config with `hosting_files_website-content`.\n- PHP errors → [PHP](#php).\n\n### PHP\n\n`hosting_php_get` returns every extension and option (around 25 KB), so call it only for PHP problems. `hosting_php_update-version` switches versions. `hosting_php_update-options` silently caps values at the plan maximum (`max` in `hosting_php_get`), so read the applied value back. Agency: `agency-hosting_php_list-options-for-website`, then `agency-hosting_php_replace-website-options` — a full replace, so send every custom option that should stay.\n\n### Agency Plan sites\n\n`agency-hosting_websites_get` shows state and quotas, `agency-hosting_websites_list-processes` shows failed jobs (SSL setup, backups), and `agency-hosting_wordpress_settings` shows core version, LiteSpeed, object cache and maintenance mode. When `wordpress_installations_list` does not return the site, plugins are managed from wp-admin.\n\n## SSL\n\nShared and Cloud, `ssl` in `hosting_websites_get-settings`:\n\n- `not_installed` or `failed` (`last_error` says why): the domain must resolve to Hostinger, and any CAA record must allow `letsencrypt.org`, before `hosting_ssl_install` can succeed. Poll `hosting_websites_get-settings` until `ssl.status` is `active` or `failed`.\n- `installing` or `waiting_for_retry`: wait — another install request returns 422.\n- Free `*.hostingersite.com` subdomains use a platform certificate; installing returns 422 by design.\n- Browser still warns while the certificate is `active`: turn on the redirect with `hosting_websites_update-settings` (`httpsRedirect: true`) when `is_https_redirect_enabled` is false, otherwise the page loads `http://` assets (mixed content) that the app has to change.\n\nAgency, `agency-hosting_ssl_website-status` for each domain: every domain allows three certificate setups per seven days and one request a minute. Check `agency-hosting_websites_list-processes` before `agency-hosting_ssl_install-website` or `agency-hosting_ssl_reinstall-website`, and never retry in a loop.\n\n## Slow site\n\n- WordPress: `wordpress_litespeed-cache_show-lite-speed-status` and `wordpress_object-cache_show-memcached-status`. Turning on Memcached with `wordpress_object-cache_toggle-memcached` is the usual quick win.\n- Other sites: server caching may be off or development mode left on. `hosting_websites_get-settings` shows both in `cache` (`is_enabled`, `is_cacheless_mode_enabled`); fix them with `hosting_websites_update-settings` (`cache: true`, `cachelessMode: false`). Development mode takes a few minutes to turn off.\n- PHP 7.x runs markedly slower than 8.x; propose a supported 8.x version from `hosting_php_get` when the app allows it.\n- Agency: `agency-hosting_metrics_list-order-resource-usage` with `time_frame_hours: 24` shows CPU, memory and processes per website against the plan quota.\n- Shared and Cloud have no CPU or memory metrics in the API. When the evidence points at resource limits, send the user to hPanel's resource usage page.\n\n## Apply the fix\n\nState the cause, the evidence and the single change proposed, and make it only after the user agrees. Then re-run the step 2 check, polling any queued job first, to show the symptom is gone. When the fix needs something the API cannot do, say so and name the hPanel page.\n\n## Not available through the API\n\n- Website backups and restores — hPanel's Backups page.\n- CPU, memory and process usage for Shared and Cloud plans.\n- PHP error and access logs.\n"
       }
     ]
   }

package/src/core/tools/all.js

@@ -173,6 +173,131 @@ export default [
     "handlerMethod": "handleHostingGetDeployment",
     "group": "hosting"
   },
+  {
+    "name": "hosting_websites_get-settings",
+    "title": "Get website SSL, CDN and cache settings",
+    "annotations": {
+      "title": "Get website SSL, CDN and cache settings",
+      "readOnlyHint": true,
+      "destructiveHint": false
+    },
+    "topic": "hosting",
+    "description": "Read a website's SSL certificate, HTTPS redirect, CDN and server cache settings in one call. ssl is the SSL status as hosting_ssl_status returns it: the certificate status (active, installing, waiting_for_retry, failed, expired or not_installed) and provider, whether it is a lifetime certificate, whether HTTP is redirected to HTTPS, when it expires and the last installation error. cdn.is_enabled says whether the Hostinger CDN serves the website. cache.is_enabled says whether server-side caching is on, and cache.is_cacheless_mode_enabled whether development (cacheless) mode bypasses it. Use it before hosting_websites_update-settings, and to follow an SSL installation started by hosting_ssl_install: poll until ssl.status is active or failed, with growing pauses. A section that cannot be read comes back as { error } and the others are still returned; cache is null with a cacheNote when cache status is not available. To install or remove a certificate use hosting_ssl_install or hosting_ssl_uninstall. Works for Shared and Cloud hosting websites.",
+    "method": "",
+    "path": "",
+    "inputSchema": {
+      "type": "object",
+      "properties": {
+        "domain": {
+          "type": "string",
+          "description": "Domain name of the website, exactly as listed on the account and without www. (e.g., example.com)"
+        }
+      },
+      "required": [
+        "domain"
+      ]
+    },
+    "security": [],
+    "custom": true,
+    "replacesHidden": true,
+    "templateFile": "get-website-settings.template.js",
+    "templateFileTS": "get-website-settings.template.ts",
+    "handlerMethod": "handleHostingWebsitesGetSettings",
+    "group": "hosting"
+  },
+  {
+    "name": "hosting_websites_update-settings",
+    "title": "Update website HTTPS redirect, CDN and cache settings",
+    "annotations": {
+      "title": "Update website HTTPS redirect, CDN and cache settings",
+      "readOnlyHint": false,
+      "destructiveHint": true
+    },
+    "topic": "hosting",
+    "description": "Change a website's HTTPS redirect, CDN and server cache settings in one call. Pass only the settings to change, at least one. Settings are applied in the order cache, cachelessMode, cdn, httpsRedirect, and the call stops at the first failure. applied lists the settings that were changed. When a setting fails, the call returns an error whose text is the same JSON: failed names the setting and why, and skipped lists the ones not attempted; a multi-execute batch stops there too. Turning httpsRedirect on needs an active SSL certificate: the call checks it first and changes nothing when there is none. Install one with hosting_ssl_install and wait until hosting_websites_get-settings shows ssl.status active. cachelessMode is applied in the background and takes effect within a few minutes; enabling the CDN changes DNS records, so visitors are served through it after a few minutes of propagation. Certificates are not installed or removed here: use hosting_ssl_install and hosting_ssl_uninstall. Read the current values with hosting_websites_get-settings. Works for Shared and Cloud hosting websites.",
+    "method": "",
+    "path": "",
+    "inputSchema": {
+      "type": "object",
+      "properties": {
+        "domain": {
+          "type": "string",
+          "description": "Domain name of the website, exactly as listed on the account and without www. (e.g., example.com)"
+        },
+        "cache": {
+          "type": "boolean",
+          "description": "Turn server-side caching on (true) or off (false). Keep it on for production websites; to bypass it while developing, use cachelessMode instead."
+        },
+        "cachelessMode": {
+          "type": "boolean",
+          "description": "Turn development (cacheless) mode on (true) or off (false). While it is on nothing is cached, so changes show at once; turn it off when done. Applied in the background within a few minutes."
+        },
+        "cdn": {
+          "type": "boolean",
+          "description": "Turn the Hostinger CDN on (true) or off (false). Changes DNS records; propagation takes a few minutes. Cannot be turned off for platform-managed domains (*.hostingersite.com)."
+        },
+        "httpsRedirect": {
+          "type": "boolean",
+          "description": "Redirect HTTP to HTTPS (true) or stop redirecting (false). Turning it on needs an active SSL certificate (see hosting_ssl_install)."
+        }
+      },
+      "required": [
+        "domain"
+      ]
+    },
+    "security": [],
+    "custom": true,
+    "replacesHidden": true,
+    "templateFile": "update-website-settings.template.js",
+    "templateFileTS": "update-website-settings.template.ts",
+    "handlerMethod": "handleHostingWebsitesUpdateSettings",
+    "group": "hosting"
+  },
+  {
+    "name": "hosting_cache_clear",
+    "title": "Clear website cache",
+    "annotations": {
+      "title": "Clear website cache",
+      "readOnlyHint": false,
+      "destructiveHint": true
+    },
+    "topic": "hosting",
+    "description": "Clear a website's server cache (the hosting server's page cache) and Hostinger CDN cache, so updated content shows at once. By default (scope: all) it clears the server cache and, when the CDN is on, purges the CDN too. scope: cdn purges only the CDN edge cache and leaves the server cache alone; that fails with 422 when the CDN is off. For a WordPress site installed in a subdirectory, pass directory to clear that installation's cache (only with scope all). This does not purge the WordPress LiteSpeed Cache plugin: that is a separate WordPress operation (wordpress_litespeed-cache_purge-lite-speed). To turn caching or the CDN on or off use hosting_websites_update-settings. Works for Shared and Cloud hosting websites.",
+    "method": "",
+    "path": "",
+    "inputSchema": {
+      "type": "object",
+      "properties": {
+        "domain": {
+          "type": "string",
+          "description": "Domain name of the website, exactly as listed on the account and without www. (e.g., example.com)"
+        },
+        "scope": {
+          "type": "string",
+          "enum": [
+            "all",
+            "cdn"
+          ],
+          "description": "What to clear: all (default) clears the server cache and, when the CDN is on, the CDN too; cdn purges only the CDN edge cache and fails when the CDN is off.",
+          "default": "all"
+        },
+        "directory": {
+          "type": "string",
+          "description": "WordPress installed in a subdirectory: its directory relative to the website root (e.g., blog), to clear that installation's cache. Only when scope is all; default the website root."
+        }
+      },
+      "required": [
+        "domain"
+      ]
+    },
+    "security": [],
+    "custom": true,
+    "replacesHidden": true,
+    "templateFile": "clear-cache.template.js",
+    "templateFileTS": "clear-cache.template.ts",
+    "handlerMethod": "handleHostingCacheClear",
+    "group": "hosting"
+  },
   {
     "name": "agency-hosting_deploy-node-static-website",
     "title": "Deploy node-static website",
@@ -6277,7 +6402,8 @@ export default [
         "apiToken": []
       }
     ],
-    "group": "hosting"
+    "group": "hosting",
+    "hidden": true
   },
   {
     "name": "hosting_cache_status",
@@ -6312,7 +6438,8 @@ export default [
         "apiToken": []
       }
     ],
-    "group": "hosting"
+    "group": "hosting",
+    "hidden": true
   },
   {
     "name": "hosting_cache_toggle-cacheless",
@@ -6353,7 +6480,8 @@ export default [
         "apiToken": []
       }
     ],
-    "group": "hosting"
+    "group": "hosting",
+    "hidden": true
   },
   {
     "name": "hosting_cache_toggle-website",
@@ -6394,7 +6522,8 @@ export default [
         "apiToken": []
       }
     ],
-    "group": "hosting"
+    "group": "hosting",
+    "hidden": true
   },
   {
     "name": "hosting_cdn_disable",
@@ -6429,7 +6558,8 @@ export default [
         "apiToken": []
       }
     ],
-    "group": "hosting"
+    "group": "hosting",
+    "hidden": true
   },
   {
     "name": "hosting_cdn_enable",
@@ -6464,7 +6594,8 @@ export default [
         "apiToken": []
       }
     ],
-    "group": "hosting"
+    "group": "hosting",
+    "hidden": true
   },
   {
     "name": "hosting_cdn_purge-cache",
@@ -6500,7 +6631,8 @@ export default [
         "apiToken": []
       }
     ],
-    "group": "hosting"
+    "group": "hosting",
+    "hidden": true
   },
   {
     "name": "hosting_cdn_status",
@@ -6535,7 +6667,8 @@ export default [
         "apiToken": []
       }
     ],
-    "group": "hosting"
+    "group": "hosting",
+    "hidden": true
   },
   {
     "name": "hosting_cron-jobs_list",
@@ -9632,7 +9765,8 @@ export default [
         "apiToken": []
       }
     ],
-    "group": "hosting"
+    "group": "hosting",
+    "hidden": true
   },
   {
     "name": "hosting_ssl_toggle-https-redirect",
@@ -9673,7 +9807,8 @@ export default [
         "apiToken": []
       }
     ],
-    "group": "hosting"
+    "group": "hosting",
+    "hidden": true
   },
   {
     "name": "hosting_ssl_uninstall",
@@ -14424,6 +14559,41 @@ export default [
     ],
     "group": "reach"
   },
+  {
+    "name": "reach_integrations_connect-ecommerce-store",
+    "title": "Connect Ecommerce store",
+    "annotations": {
+      "title": "Connect Ecommerce store",
+      "readOnlyHint": false,
+      "destructiveHint": false
+    },
+    "description": "Connect one of the customer's eCommerce stores to the profile, so Reach receives its\ncustomers and orders.\n\nTake `store_id` from the list eCommerce stores endpoint. Fails with not found\n(`ECOMMERCE_STORE_NOT_FOUND`) when the store is not one of the customer's own stores, also\nwhen the eCommerce service cannot be reached. Fails with a conflict\n(`ECOMMERCE_CONNECTION_ALREADY_EXISTS`) when the store is connected to any profile or this\nprofile already has a store - to move a store to another plan, disconnect it from the\nprofile that holds it first.",
+    "method": "POST",
+    "path": "/api/reach/v1/profiles/{profileUuid}/ecommerce/stores/{storeId}",
+    "inputSchema": {
+      "type": "object",
+      "properties": {
+        "profileUuid": {
+          "type": "string",
+          "description": "Profile uuid parameter"
+        },
+        "storeId": {
+          "type": "string",
+          "description": "Hostinger eCommerce store ID, as returned by the eCommerce stores list"
+        }
+      },
+      "required": [
+        "profileUuid",
+        "storeId"
+      ]
+    },
+    "security": [
+      {
+        "apiToken": []
+      }
+    ],
+    "group": "reach"
+  },
   {
     "name": "reach_integrations_disconnect-ecommerce-store",
     "title": "Disconnect Ecommerce store",
@@ -14433,7 +14603,7 @@ export default [
       "destructiveHint": true,
       "idempotentHint": true
     },
-    "description": "Disconnect an eCommerce store from the profile.\n\nReach stops receiving the store's customers and orders, and its products and coupons are\nremoved from Reach; contacts and past orders stay. Take `store_id` from the list eCommerce\nstores endpoint; for a store that is `connected_to_other_profile`, call this with that\nprofile. Also succeeds when the store is not connected to this profile, so success is not\nproof that anything was disconnected. Confirm the store and the plan with the customer\nbefore calling.",
+    "description": "Disconnect an eCommerce store from the profile.\n\nReach stops receiving the store's customers and orders, and its products and coupons are\nremoved from Reach; contacts and past orders stay. Take `store_id` from the list eCommerce\nstores endpoint; for a store that is `connected_to_other_profile`, call this with that\nprofile. Also succeeds when the store is not connected to this profile, so success is not\nproof that anything was disconnected. To move the store to another plan, connect it to the\nnew profile afterwards. Confirm the store and the plan with the customer before calling.",
     "method": "DELETE",
     "path": "/api/reach/v1/profiles/{profileUuid}/ecommerce/stores/{storeId}",
     "inputSchema": {
@@ -14468,7 +14638,7 @@ export default [
       "readOnlyHint": true,
       "destructiveHint": false
     },
-    "description": "Get all of the customer's Hostinger eCommerce stores, each with its `store_id` and\n`connection_status` for the profile in the path.\n\nA store is connected to at most one profile. `connected_to_other_profile` does not name that\nprofile - call this for each profile to find it. The list is empty, not an error, when the\neCommerce service cannot be reached. Pass `store_id` to the disconnect eCommerce store\nendpoint. Connecting an AI Website Builder site connects the store selling on it.",
+    "description": "Get all of the customer's Hostinger eCommerce stores, each with its `store_id` and\n`connection_status` for the profile in the path.\n\nA store is connected to at most one profile. `connected_to_other_profile` does not name that\nprofile - call this for each profile to find it. The list is empty, not an error, when the\neCommerce service cannot be reached. Pass `store_id` to the connect or disconnect eCommerce\nstore endpoint.",
     "method": "GET",
     "path": "/api/reach/v1/profiles/{profileUuid}/ecommerce/stores",
     "inputSchema": {