Update to Hostinger Connector

{
  "name": "domains",
  "description": "Use when the user wants to work with domain names or DNS at Hostinger — checking availability and buying a domain, reading domain details and renewal dates, changing nameservers, setting up forwarding, managing registrar lock, WHOIS privacy and WHOIS contact profiles, getting an authorization code for a transfer, and reading, editing, validating, resetting or restoring DNS records.",
  "included_files": [],
  "skill_md_contents": "---\nname: domains\ndescription: Use when the user wants to work with domain names or DNS at Hostinger — checking availability and buying a domain, reading domain details and renewal dates, changing nameservers, setting up forwarding, managing registrar lock, WHOIS privacy and WHOIS contact profiles, getting an authorization code for a transfer, and reading, editing, validating, resetting or restoring DNS records.\n---\n\n# Domains and DNS\n\nThis skill spans **two** binaries. They are separate installs and separate tool\ngroups; loading one does not give you the other.\n\n| Binary | Covers |\n| --- | --- |\n| `hostinger-domains-mcp` | registration, nameservers, forwarding, lock, privacy, WHOIS, transfers |\n| `hostinger-dns-mcp` | DNS zone records and snapshots |\n\nIf the user's request touches both — \"point my new domain at my site\" — say up\nfront that both binaries are needed, and stop if only one is loaded rather than\nhalf-completing the task.\n\nRun the `hostinger` router first. Its safety gates apply to everything here.\n\n## Buying a domain — the one billable path\n\n`domains_purchaseNewDomainV1` charges the user. It requires the router's\ntwo-confirmation billable gate, and it must never run off an implied request.\n\"Get my site online\" is not permission to buy a domain; suggest the free\n`*.hostingersite.com` subdomain from `websites` first and let the user\nchoose.\n\n1. `domains_checkDomainAvailabilityV1` — check the exact name.\n2. State the **price and the term** to the user, and the fact that domain\n   registrations are generally non-refundable.\n3. First confirmation, naming the domain and the price.\n4. Second confirmation in a separate turn.\n5. `domains_purchaseNewDomainV1` needs a WHOIS profile — see below.\n\n## WHOIS profiles\n\nRegistries require registrant contact data. `domains_createWHOISProfileV1`\nstores it; `domains_getWHOISProfileListV1` and `domains_getWHOISProfileV1` read\nit back; `domains_getWHOISProfileUsageV1` shows which domains use a profile.\n`domains_setWHOISProfileAsDefaultV1` marks one as the default for future\npurchases, per TLD; `domains_unsetDefaultWHOISProfileV1` clears that. Setting a\ndefault means later purchases silently reuse those contact details — say which\nprofile you are making the default, and never set one the user has not seen.\n\nThis is personal data — a real name, address, email and phone. Collect only\nwhat the registry requires, take it from the user directly, and never copy it\ninto project files, commits or summaries. `domains_deleteWHOISProfileV1` fails\nor orphans domains if the profile is still in use, so check usage first.\n\n`domains_enablePrivacyProtectionV1` hides those details from public WHOIS;\n`domains_disablePrivacyProtectionV1` exposes them again. Disabling is a privacy\nregression — say so explicitly and get a confirmation, even though nothing is\ndestroyed.\n\n## Reading state\n\n- `domains_getDomainListV1` — every domain on the account.\n- `domains_getDomainDetailsV1` — status, expiry, nameservers, lock and privacy\n  state for one domain. Run this before changing anything.\n- `domains_getDomainRenewalInformationV1` — renewal date and pricing.\n- `v2_getDomainVerificationsDIRECT` — domain verification records.\n\n## Nameservers, forwarding and lock\n\n- `domains_updateDomainNameserversV1` — **this is the highest-blast-radius tool\n  in the skill.** Pointing nameservers away from Hostinger takes the domain's\n  entire DNS zone out of service: website, email, everything. Show the current\n  nameservers from `domains_getDomainDetailsV1`, spell out what will stop\n  resolving, and confirm before changing them. Propagation takes up to 24–48\n  hours and is not instantly reversible.\n- Forwarding: `domains_getDomainForwardingV1`,\n  `domains_createDomainForwardingV1`, `domains_updateDomainForwardingV1`,\n  `domains_deleteDomainForwardingV1`.\n- Registrar lock: `domains_enableDomainLockV1`, `domains_disableDomainLockV1`.\n  The lock exists to prevent unauthorised transfers. **Disabling it is a\n  security downgrade** — only do it as a deliberate step in a transfer the user\n  is actively performing, and offer to re-enable it afterwards.\n\n## Transfers\n\n`domains_getDomainAuthorizationCodeV1` returns the EPP/auth code that lets\nanother registrar take the domain. Treat it as a secret: show it to the user in\nthe conversation, never write it to a file, and never include it in a summary.\nTrack incoming transfers with `domains_getTransferListV1` and\n`domains_getTransferV1`.\n\n## DNS records\n\nRead first: `DNS_getDNSRecordsV1`. Validate before you commit:\n`DNS_validateDNSRecordsV1` checks a record set without applying it — use it on\nevery non-trivial change, because a bad zone is a live outage.\n\n`DNS_updateDNSRecordsV1` applies changes. Be explicit with the user about what\neach record does, and remember that TTL governs how long a mistake persists in\nresolver caches.\n\n### Snapshots are the safety net — use them\n\n`DNS_getDNSSnapshotListV1` and `DNS_getDNSSnapshotV1` read historical zone\nstates; `DNS_restoreDNSSnapshotV1` rolls back to one. **Take stock of the\ncurrent snapshot list before any destructive record change**, and tell the user\nwhich snapshot they can roll back to. This turns an outage into a two-minute\nfix.\n\n### The two destructive DNS tools\n\nBoth need two confirmations, never batched:\n\n- `DNS_deleteDNSRecordsV1` — removes specific records. Name each record being\n  deleted, with its type and value, not \"the selected records\".\n- `DNS_resetDNSRecordsV1` — discards the entire zone and returns it to\n  Hostinger defaults. This will break custom mail routing (MX, SPF, DKIM,\n  DMARC), verification records for third-party services, and any subdomain\n  pointing elsewhere. State that plainly, list what is currently in the zone,\n  and confirm the snapshot the user can restore from before running it.\n\nRestoring a snapshot is itself a full-zone overwrite. It is the recovery path,\nbut it discards every change made since that snapshot — confirm it the same way.\n"
}