Shopify

The canonical Shopify route separates theme source, documentation and validation, store data, customer commerce, and publication authority instead of treating “Shopify MCP” as one connection.

Recommendation

Use the shopify-commerce skill for Liquid theme, landing-page, product-page, Admin GraphQL, and store CLI work. Use Shopify Hydrogen for headless React storefront architecture. The current default for a theme change is:

brand + store facts -> current theme -> official docs/schema validation -> development theme -> section-by-section implementation -> Theme Check + browser/commerce/a11y proof -> explicit publish approval

The useful idea in the saved article is not “connect one all-powerful MCP.” It is that agents become more reliable when brand context, current source, operational tools, and specialist instructions live beside the project. Current Shopify surfaces make the boundaries clearer than the article did.

Interface Boundaries

The Dev MCP's no-auth local server is deliberately documentation/schema oriented. Store context belongs to authenticated Shopify CLI or a project-owned app, with minimum scopes and a separate approval boundary for writes.

Current Source Snapshot

Checked on 2026-08-11:

The official toolkit is not imported wholesale into Kevin's runtime. It is large, has overlapping skills, requires shell/network access for search and validation, and sends telemetry by default. Its documentation says events can contain the invoking prompt, search material, validated code and results, model/client, session, and tool-use identifiers. Use a pinned project installation only after that egress is accepted or OPT_OUT_INSTRUMENTATION=true is set. The local shopify-commerce skill preserves the workflow without silently enabling those hooks.

The third-party Liquid skills remain a watched source, not discarded knowledge. Their theme structure, CSS/JavaScript, and accessibility material reinforces the local procedure, but absent redistribution terms block vendoring or installation.

What The Saved Article Contributes

The X Article, with 1,119 likes and 3,105 bookmarks in the frozen record, supplies valuable empirical observations:

• split store-data access from theme-file operations;
• put brand and theme facts beside the agent;
• concrete visual references outperform vague blank-slate prompts;
• work section by section on complex pages;
• listicle-like pages are easier than dense product-detail experiences.

Its own follow-up is the most important counterexample: the author did not use the setup for client landing-page or CRO work because it was not yet good enough. The workflow therefore retains the observations while rejecting the leap from promising experiment to production method. Subjective visual scores are not quality proof, and conversion language is not CRO evidence.

Agent Contract

Before acting, freeze repository/branch, store domain, theme ID/state, resources, data boundary, authority, preview, backup, rollback, and approver. Inspect the current theme and brand/product truth. For theme work, default to a development or unpublished theme; preserve JSON templates, editable sections/blocks/presets, translations, responsive media, variants/cart states, accessibility, and bounded JavaScript. Use minimum Admin scopes and keep customer/order/payment data out of prompts and receipts.

Proof requires code/schema validation where admitted, Theme Check, an exact-store preview, desktop/mobile visual review, keyboard/focus/zoom/reduced-motion checks, product/variant/cart/error/localization behavior, performance inspection, clean diff, rollback, and human approval before publish. CRO changes require an actual experiment contract and measured decision rule.

Failure Modes

• giving a generic MCP broad store credentials;
• confusing Dev MCP documentation access with Admin data access;
• modifying or publishing the live theme during exploration;
• copying a reference page without authorization;
• hard-coding a page instead of preserving merchant editability;
• sending secrets or customer data through prompts, telemetry, screenshots, or capture artifacts;
• accepting one screenshot, an AI score, likes, or bookmarks as production proof;
• installing an unlicensed or unaudited third-party skill because its examples are useful;
• calling a visual variant “higher converting” without an experiment.

---

Timeline

• 2026-08-11 | Replayed the saved Shopify agent-landing-page article against current official CLI, AI Toolkit, Dev MCP, theme architecture, and accessibility sources. Added a single canonical owner and executable skill, preserved the third-party Liquid source as a license-blocked watch, and separated docs/validation, theme source, Admin data, customer commerce, and publication authority. Source: X/@oliviercroguy article; Shopify developer documentation; Shopify-AI-Toolkit exact revision; local skill audit, 2026-08-11