Update to Hostinger Connector

{
  "name": "ecommerce",
  "description": "Use when the user wants a Hostinger online store — creating a store, adding physical or digital products, setting flat-rate shipping, enabling a manual payment method, checking whether the store is ready to take orders, and creating or updating a custom sales channel so a frontend you built can serve the catalog and a hosted checkout. Not for WooCommerce, which is a WordPress plugin.",
  "included_files": [],
  "skill_md_contents": "---\nname: ecommerce\ndescription: Use when the user wants a Hostinger online store — creating a store, adding physical or digital products, setting flat-rate shipping, enabling a manual payment method, checking whether the store is ready to take orders, and creating or updating a custom sales channel so a frontend you built can serve the catalog and a hosted checkout. Not for WooCommerce, which is a WordPress plugin.\n---\n\n# Ecommerce\n\nBinary: **`hostinger-ecommerce-mcp`** — every tool named `ecommerce_*`.\n\nRun the `hostinger` router first. Its safety gates apply to everything here.\n\n**This is a Hostinger store, not WooCommerce.** WooCommerce is a WordPress\nplugin and is managed through the WordPress tools in `websites`. If the user has\na WooCommerce site and asks for products, they mean that one — say so rather than\ncreating a second, unrelated store here.\n\n## Order of operations\n\nThe steps depend on each other, and doing them out of order produces a store\nthat looks finished but cannot take an order:\n\n1. `ecommerce_getStoresV1` — **check for an existing store first.** Never create\n   a second store for an account that already has one unless the user says\n   that is what they want.\n2. `ecommerce_createStoreV1` — creates the store and a primary sales channel\n   alongside it.\n3. Products: `ecommerce_createPhysicalProductV1` or\n   `ecommerce_createDigitalProductV1`. Each creates a published product with a\n   single variant. A digital product takes an optional external download link.\n4. `ecommerce_setStoreShippingV1` — flat-rate shipping, creating the zone if it\n   does not exist. **Physical products need this**; without it a customer cannot\n   complete checkout. Digital products do not.\n5. `ecommerce_enableManualPaymentMethodV1` — lets the store accept orders without\n   an online payment provider. See the warning below.\n6. `ecommerce_getStoreMetadataV1` — readiness check: whether payment methods and\n   shipping are configured, plus the default currency. **Run this before telling\n   the user the store is live**, and report what it says rather than assuming.\n\n## Currency and prices\n\nProducts are priced in the **store currency**, which comes from\n`ecommerce_getStoreMetadataV1`. Read it before creating a product — a price\nentered against the wrong currency is a live mispricing that customers can order\nagainst. Confirm the currency with the user when creating the first product.\n\n## Manual payment is not online payment\n\n`ecommerce_enableManualPaymentMethodV1` means the store accepts an order and the\nmerchant collects money **some other way** — a bank transfer, cash on delivery,\nan invoice. Nothing is charged automatically. Say that explicitly when enabling\nit, because \"payments enabled\" reads as \"customers can pay by card\" and it does\nnot. Connecting a real payment provider happens in hPanel, not through these\ntools.\n\n## Custom sales channels — for a frontend you built\n\nA custom sales channel is how a separately deployed frontend serves the store's\ncatalog while checkout, orders and shipping stay with Hostinger.\n\n- `ecommerce_listSalesChannelsV1` — existing channels and their metadata.\n- `ecommerce_createCustomSalesChannelV1` — create one for a frontend you built.\n- `ecommerce_updateSalesChannelV1` — change the merchant-facing `name` and the\n  public `url`, which is returned as the channel's `domain`.\n- `ecommerce_getCustomStorefrontSetupInstructionsV1` — **read this before writing\n  any frontend code.** It returns the actual, current integration steps as\n  Markdown. Follow them rather than reconstructing an integration from memory;\n  the contract can change and the instructions are authoritative.\n\nThe channel `url` must be the address the storefront is really served from. A\nmismatch breaks the checkout hand-off, which fails at the worst possible moment —\nafter the customer has picked something.\n\n## Products are published immediately\n\nBoth create tools produce a **published** product. There is no draft state here,\nso a product created to try something out is publicly visible and orderable the\nmoment it exists. Confirm name, price and currency before creating, and do not\ncreate throwaway test products on a store that is taking real orders.\n\n## The destructive one\n\n`ecommerce_deleteStoreV1` soft-deletes a store: the underlying data is preserved\nbut the store is marked deleted, which takes the storefront and its checkout\noffline. Two confirmations, never batched. Name the store, say what stops working\n— the storefront, any custom sales channel pointing at it, and the ability to\ntake orders — and say that undoing it is a support request, not a tool call.\n\n## Full tool list\n\nStores: `ecommerce_getStoresV1`, `ecommerce_createStoreV1`,\n`ecommerce_getStoreMetadataV1`, `ecommerce_deleteStoreV1`\n\nProducts: `ecommerce_createPhysicalProductV1`,\n`ecommerce_createDigitalProductV1`\n\nCheckout: `ecommerce_setStoreShippingV1`,\n`ecommerce_enableManualPaymentMethodV1`\n\nSales channels: `ecommerce_listSalesChannelsV1`,\n`ecommerce_createCustomSalesChannelV1`, `ecommerce_updateSalesChannelV1`,\n`ecommerce_getCustomStorefrontSetupInstructionsV1`\n"
}