"Shopware" matching MCP tools:

• list-storesA

  UCP CheckerA

  List verified UCP storefronts across every platform, best-evidenced first. Use when the user wants to browse stores — e.g., "what stores can I shop at?" or "show me Wix stores". To find stores that sell something, prefer search-all. Each store carries what we have actually observed about it, not what it claims: - `transactable` — declares checkout and we have read its catalogue - `catalogued` — we have read its catalogue - `resolvable` — its endpoint resolves, we have not probed it yet - `declared` — a valid profile, nothing observed beyond it Filter by `platform` (shopify, wix, woocommerce, bigcommerce, shopware…). `category` narrows to the smaller set of deeply audited stores (see list-categories), so leave it out unless the user asks for a category. Developer previews and staging hosts are not listed.

  ConnectorNo auth

• sync_article_to_cmsA

  BlogSEOA

  Pushes the current content of a published (or published-in-draft) article to every connected CMS at once, overwriting the copy there (including edits made directly in the CMS) and clearing its Out of Sync state. A live article stays live, so the update is public as soon as it lands. Synchronous: returns once the CMS accepted the update (a few seconds; Shopware, Umbraco and BigCommerce finish in the background). Fails for articles that are not on a CMS yet: publish those with publish_article. Framer and webhook connections are never synced. Pass confirm=true once the user has approved; without it the tool only returns where the content would be published and whether it goes live. Pass website_id when the account has several websites (see get_account).

  Connector

  Destructive

  OAuth

• shop_requestA

  ecomdlyA

  Call the API of a connected e-shop (Shoptet, Upgates, Shopify, WPJ Shop, WooCommerce, PrestaShop, Shoper, Shopware, Magento, BigCommerce, IdoSell) — ecomdly adds the owner's API access, you never see or need the key. Follow the platform's skill (shop_list names it) for paths and limits, and for the job itself (product titles, descriptions, translations, prices, stock, feeds) a skill from the ecomdly catalog — search_skills first, before you change products. `path` is relative to the API (Shoptet: /api/orders?page=1, Upgates: /orders?page=1, Shopify: /graphql.json and WPJ Shop: /admin/graphql/ with a POST body {"query": …}, WooCommerce: /orders?per_page=50, PrestaShop: /orders?display=full, Shoper: /orders?limit=50, Shopware: /search/order with a POST body of criteria, Magento: /V1/orders?searchCriteria[pageSize]=50, BigCommerce: /v2/orders?limit=50 or /v3/catalog/products, IdoSell: /orders/orders/search with a POST body {"params": {…}}). Reading always works (GET, GraphQL queries, Shopify bulk queries, Shopware and IdoSell searches, a Shoper bulk of GETs); changes (other POST/PUT/PATCH/DELETE, GraphQL mutations) only where the owner allowed them on ecomdly, and only what the owner confirmed in this conversation. For a custom API you sign in yourself as its docs say, writing {{secret}} where the key goes (headers, path or body). Returns the status, the limit headers and the body (long bodies are cut — page through, or use a snapshot / bulk query).

  ConnectorNo auth

• site_consoleA

  AskYourStackA

  Run a site's own command line tool as the site's owner, in the site's folder: bin/console for Shopware 6 and PrestaShop, artisan for Laravel, drush for Drupal, cli/joomla.php for Joomla, ghost (ghost-cli) for Ghost (list_sites shows each site's console; Magento 2 has the magento tool and WordPress the wp tool). Pass the command and its options as args, like ["cache:clear"] or ["plugin:list", "--json"]. For a site in a Docker container it runs inside the container. Listing and status commands run straight away; uninstalling or deleting, anything that drops or resets the database, generating new keys, an admin login link and commands that run arbitrary PHP (tinker, php:eval) need approval. Symfony's console and artisan are run with --no-interaction; drush asks nothing only when you pass -y. Set background true for slow commands.

  Connector

  Destructive

  OAuth

• logsA

  AskYourStackA

  Read a log by name for a time window, with repeated messages counted once: how many different errors there are, how often each happened, when first and last, a sample of each (with the top of its stack trace) and the latest lines. Suited to finding what went wrong in a long log. log is one of: web-error (nginx and Apache error logs, each site's own included), php (PHP and PHP-FPM, and error_log files next to the code), site (the site's own application log, whatever kind it is: Shopware and PrestaShop var/log, Laravel storage/logs, Joomla and OpenCart logs), magento (exception.log and system.log of the site, plus how many error pages visitors saw), wordpress (wp-content/debug.log), database (MySQL/MariaDB error log), system (warnings and errors in the journal), mail, auth (logins). Or give path for any other log file. match keeps only entries holding that text.

  ConnectorOAuth

• get_playbookA

  AskYourStackA

  Step-by-step guide for a common job, written for you to follow. Available: add-site (A new domain on a server that already runs sites: its own user, folder, PHP pool, web server block, database, SSL and a check that the other sites were not touched.); backups (Scheduled database and file backups with rotation, an optional off-server copy, and a tested restore.); bot-attack (A shop or site is slow or flooded by bots (layered navigation, search, login, account sign-up, API): find what is hitting it and slow it down without blocking customers or search engines.); drupal (Check-up and common jobs for Drupal 9, 10 and 11 with drush: status, security updates, database updates, cache, cron, configuration.); email (Order confirmations, password resets and contact forms that land in spam or never arrive: check how the site sends, the domain's SPF, DKIM and DMARC records, the server's reputation, and move sending to a proper mail service when that is the fix.); failed-services (Services marked failed on a server: tell the ones left behind by sites that were removed (Virtualmin, Plesk and cPanel leave per-site units) from the ones that broke, fix the broken ones, remove the leftovers in one approved plan, and leave the server with no failed units.); ghost (Where Ghost keeps things, ghost-cli as the site's owner, updates and restarts, mail, the database, backups and the common faults.); hardening (Review and tighten an existing server's security without breaking what runs on it.); laravel (Check-up and common jobs for Laravel apps with artisan: environment, deploy steps, migrations, queues and the scheduler as services, logs.); magento-upgrade (Move a Magento or Mage-OS shop to a newer version or patch level: compatibility check of PHP, database, search and modules, a rehearsal on a copy, then the live upgrade in a short maintenance window with a way back.); magento (A full Magento Open Source (or Mage-OS) shop on one server: nginx, PHP-FPM, MariaDB, OpenSearch, Valkey/Redis, cron, SSL, production mode.); malware-cleanup (Contain, investigate and clean a compromised Magento or WordPress site, then close the way in and change every credential.); migrate (Migrate a Magento or WordPress site (or any folder) from one of the user's servers to another, with a short maintenance window and a way back.); other-shops (What is where and the common jobs for three more kinds of site AskYourStack finds: Joomla 4 and 5, OpenCart 3 and 4, and Magento 1 / OpenMage.); performance (Measure a slow shop or site from the server (response times, PHP workers, database, caches, bots, memory, disk), name the real causes with numbers and fix them in order of impact.); prestashop (Check-up and common jobs for PrestaShop 1.7, 8 and 9: cache, debug mode, modules, shop address and SSL, maintenance mode, updates, security.); publish-content (Turn SEO data (Search Console, SE Ranking, a Semrush or other report the user uploads) into a content plan, then write articles, landing pages or category texts and save them as drafts in WordPress or Magento for the user to review.); restore (Bring a site, some files or a database back from a backup or an AskYourStack snapshot, after saving the current state, into a scratch place first when there is any doubt.); seo-dashboard (A site's search performance over the last 90 days as one visual page set in the Inter typeface. Fixes only the basics; what to analyse and show is the AI's judgement.); seo-technical (Technical SEO of a shop or site from the server side (what Googlebot really crawls, errors it gets, robots, sitemaps, redirects, canonicals, speed), combined with Search Console, SE Ranking or the user's exported reports, then fixes on the server.); server-setup (Turn an empty VPS into a sane, updated, secured base before anything is installed on it.); shopware (Check-up and common jobs for Shopware 6: scheduled tasks and the message queue as services, cache, plugins, themes, indexing, updates.); site-checkup (A health and security review of a Magento or WordPress site already in production, with a prioritised list of fixes.); site-down (A shop or site that does not answer, shows an error page or a blank page: find which layer failed (DNS, certificate, web server, PHP, database, disk, memory), bring it back and say why it happened.); staging (A private copy of a live shop or site on the same server or another, with its own database and address, closed to search engines and with emails and payments switched off.); updates (Security updates of the system, WordPress core, plugins and themes, or Magento security patches, with a snapshot first, checks after and the reboot planned with the user.); whizzycommerce (How to work on a WhizzyCommerce shop connected on the Sites & Apps page: what to read first, how changes are proposed and confirmed, what applies at once (colours, fonts), orders, prices, translations, design and own themes, SEO fields and redirects, and what to leave to the merchant.); woocommerce (Check-up and common jobs for WordPress shops: orders, background tasks, WP-Cron, updates with the database step, speed, and what never to cache.); wordpress (WordPress with nginx, PHP-FPM, MariaDB, Redis object cache, wp-cli, system cron and SSL.)

  ConnectorOAuth

• list_sitesA

  AskYourStackA

  The sites on the server: Magento 2, OpenMage (Magento 1), WordPress and WooCommerce, PrestaShop, Shopware 6, Drupal, Joomla, OpenCart, Laravel and Ghost, wherever the hosting panel keeps them (found from the web server's own configuration too) and inside Docker containers when their files are mounted from the host. For each: kind, root folder, the folder the web server serves, domains, access logs, owner user, version, database name and table prefix (read from the site's own configuration; passwords are never shown), its command line tool if it has one (console, run with site_console), WooCommerce's version for a WordPress shop, and the container it runs in.

  ConnectorOAuth