The Model Context Protocol is the open standard that lets AI assistants like Claude securely use external tools. Eevy exposes its entire optimization platform as an MCP server, so your own AI assistant can read your store’s performance and act on it.

Do I need to be a developer?

No. Install Eevy from the Shopify App Store, open Settings → API & Agents, and paste one URL into Claude. The login happens in your browser.

Can the AI break my store?

Risky actions are gated: proposals go to an approval queue by default, publishes are validated and reversible, everything is rate-limited and kill-switched, and experiments only promote changes that win on measured revenue.

Which AI assistants work?

Any MCP client: Claude (claude.ai, Desktop, Claude Code), Cursor, and others. OAuth-capable clients need only the URL; anything else can use an API key.

MCP access is included in every Eevy plan, including the free tier (up to 25,000 visitors/month).

MCP · Claude & AI agents

Run your store’s optimization from Claude

Eevy exposes its entire conversion engine — 104 tools — over the Model Context Protocol. Ask your AI where you’re losing money, launch experiments, approve improvements, and see causally proven ROI. No dashboard required.

Install free See all 104 tools

What it feels like

An example conversation — every tool chip is a real Eevy MCP tool.

Where is my store losing money right now?

get_store_funnel

3.1% of visitors reach checkout but only 1.9% complete it — your biggest leak is checkout drop-off, worth ≈ $4,200/mo. Your PDP add-to-cart rate is healthy (8.4%).

Anything Eevy can test to fix that?

propose_customized_variation

I proposed a trust-badge variant for your reviews section near the buy box. It’s now competing in your optimization engine — if it wins on revenue per visitor, it takes over automatically.

And what has Eevy actually earned me so far?

get_eevy_lift

Against your holdout control group: +6.2% revenue per visitor, ≈ $31,400 annualized. Measured causally, not projected.

What you can ask

“Audit my store’s conversion funnel and tell me where I’m losing money.”

Funnel breakdown with the weakest step quantified

get_store_funnel · get_product_performance

“Which of my sections is actually making money?”

Revenue per section, per competing variant

get_section_performance

“Propose a better layout for my reviews section and put it into testing.”

A new variant competing in the optimization engine

get_customization_schema · propose_customized_variation

“What has Eevy proven it added to my revenue?”

Causally measured lift, annualized

get_eevy_lift

“Show me pending optimization proposals and approve the good ones.”

Human-gated autonomous improvements

list_agent_proposals

“Start a holdout test so I can see Eevy’s true impact.”

A causal control-group experiment

start_eevy_lift_test

Connect in three steps

Install Eevy from the Shopify App Store (free tier available).
Open Settings → API & Agents in your Eevy dashboard — or skip this step entirely with OAuth.
Add the server to your client and log in when the browser asks:

Settings → Connectors → Add custom connector
URL: https://mcp.eevy.ai/api/mcp

claude mcp add --transport http eevy https://mcp.eevy.ai/api/mcp

{
  "mcpServers": {
    "eevy": {
      "type": "http",
      "url": "https://mcp.eevy.ai/api/mcp"
    }
  }
}

{
  "mcpServers": {
    "eevy": {
      "type": "http",
      "url": "https://mcp.eevy.ai/api/mcp",
      "headers": {
        "Authorization": "Bearer <YOUR_KEY>"
      }
    }
  }
}

Built so an agent can’t wreck your store

OAuth 2.1 with per-store consent
You approve exactly which store an assistant may touch — revocable anytime.
Human-approval gates
Consequential changes land in an approval queue by default; nothing risky ships silently.
Everything is an experiment
Changes compete for measured revenue per visitor — losers are retired automatically.
Rate limits, kill-switches, dry-runs
Abuse floors per credential, per-feature kill-switches, and dry-run modes on destructive tools.

Every tool, generated from the live server

104 tools · 3 guided workflows · 4 live resources. This reference is generated from the running MCP server — it cannot go stale.

Store analytics & insights

Funnel, product, and section performance read straight from the event warehouse.

get_content_performance: Read per-product CONTENT performance: for a product (or the top-N by traffic), the best- and worst-converting served content SET, with each set's measured visitors, conversions, cvr (0-1), rpv, plus the served dataset_id and item_count for the chosen data_type. Ranking is by measured per-served-variation CVR from BigQuery (each variation_id serves one content set; traffic is ~uniform) — the same surface the best-set analysis uses. DIRECTIONAL, not a significance test (use get_variant_performance_live for that). NOTE: Eevy measures at the served-SET level, not per individual review/UGC item — this returns the finest measured content granularity that exists. data_type: Reviews (default) or UGC. window: 7d|14d|30d|all (default 30d). limit (default 5, max 20) applies only when product_handle is omitted. Live query.
get_product_opportunities: Read a ranked list of the store's biggest CRO opportunities: products with meaningful traffic but a conversion and/or content GAP. Per product: viewers, converters, cvr, revenue, review_count, ugc_count, cvr_gap (how far below the store's median CVR), gaps[] tags ('no_content' | 'below_median_cvr' | 'thin_content'), a human reason, and an upside_score used for ranking. Upside = traffic weighted by (conversion gap vs the store median) + (content gap) — so a high-traffic product with no reviews/UGC OR a below-median converter both surface. DESCRIPTIVE heuristic, not a guaranteed-lift forecast: it tells you WHERE to add content or test, then prove any change with start_eevy_lift_test. min_viewers gates what counts as real traffic (default 30). window: 7d|14d|30d|all (default 30d). limit default 10, max 50. Live query.
get_product_performance: Read per-product performance from BigQuery: for each product handle, distinct PDP viewers, converters, cvr (0-1), revenue and rpv, ranked. Use to find best/worst converting products. cvr is the reliable metric; revenue/rpv are viewer-attributed (upper bound for multi-product buyers). sort: cvr|revenue|rpv|viewers (default cvr). limit (default 20, max 200). min_viewers cuts low-traffic noise. window: 7d|14d|30d|all (default 14d). Live query.
get_section_performance: Read per-section REVENUE TRUTH from BigQuery: for each Eevy section, each competing allele's distinct visitors, orders, cvr, aov and winsorized rpv, with the highest-rpv allele flagged as leader. This is the measured-revenue complement to get_variant_performance (GA belief). Most reliable for the 'products' placement (pass placement=products); other placements may return a note instead of data. Optional product_handle attributes only that product's orders. For significance use get_variant_performance_live. window: 7d|14d|30d|all (default 14d). Heaviest read (one live query per section).
get_store_funnel: Read the store-wide conversion funnel from BigQuery: distinct visitors at each step (product_views → add_to_carts → orders), each step's conversion %, plus dedup'd order count, winsorized-P95 revenue, AOV, and RPV (revenue/product_views). The 'how is this store doing overall' read. checkout_started/page_viewed are not tracked so are omitted. window: 7d|14d|30d|all (default 14d). Live query (may lag minutes).
get_value_summary: Read the store's zero-cost value receipt — 'what has Eevy been doing for me'. Returns three INDEPENDENT, honestly-labeled signals, each with its own causal flag and method: improvement_trajectory (observational — how the GA's fitness has moved over time), activity_receipt (factual — evolutions run, variations tested, content curated in the window), and directional_best_vs_rest (directional, NOT causal — the current leading variation's live RPV/CVR vs the pooled rest). No signal uses a holdout or control arm, so ZERO traffic is sacrificed to produce it and NONE claims Eevy 'caused' a lift — run start_eevy_lift_test (and read get_roi_summary) for a causal vs-no-Eevy number. Each signal is fail-soft: an empty/failing one is marked available=false with a reason and the others still return. Use this as the friendly retention receipt; use get_roi_summary for proven causal dollars and get_optimization_report for the operational what's-being-tested view.
get_variant_performance: Read which variation of each native section the GA currently favors. Per section: leading_variant_name, confidence (low|medium|high, grows with trials), and per variation {variant_name, variant_letter, ga_score (the GA's RPV-derived average fitness), trials, rank, is_leader}. This is the GA's CURRENT BELIEF, refreshed each evolution (~12h) — not a live per-variation significance test (use get_variant_performance_live for real traffic numbers). To act: give a lagging variation more time, or deactivate a persistently-low one with set_variation_status. Native sections only. Optional placement filter.
get_variant_performance_live: Read LIVE per-whole-layout-variation performance from BigQuery: real visitors, orders, cvr (0-1), rpv, aov per GrowthBook variation (annotated with its chromosome), plus a summary naming the leading variation (highest rpv with enough traffic) and whether its conversion rate beats the rest significantly (leader_vs_rest_cvr_pvalue < 0.05). This is real storefront data (may lag minutes) at the WHOLE-LAYOUT level — pair with get_variant_performance for the per-section view. Heavier than the other reads (live query). window: 7d|14d|30d|all (default 14d).
get_vertical_benchmark: Read how this store compares to its VERTICAL, using Eevy's anonymized cross-store learning network. Returns {vertical, network_patterns[] (which change-types/layouts tend to WIN for stores in this vertical — each with section_type, change_type, wins, losses, sample, win_rate, most-informative first), own_funnel (this store's product_views→add_to_carts→orders + CVR/RPV for context)}. Frames as 'across Eevy's network, stores like yours see these changes win X% at sample N — here's where you stand'. The patterns are POOLED ANONYMIZED aggregates by construction (a store-agnostic change fingerprint + win/loss counts — NO other store's identity, product, or content is ever exposed). Descriptive, NOT causal: a network win-rate is a prior, not a guarantee for this store. If the vertical has thin data it falls back to the all-verticals rollup (patterns_scope says which). window sizes the own_funnel only. Live query for the funnel; the network aggregate is precomputed daily.
get_winning_angles: Read cross-product content angles: which review attribute value (e.g. a grape variety, a benefit) converts above its products' baseline. Per angle: viewers, converters, observed_cvr, expected_cvr, lift_cvr (the headline — observed minus expected CVR), observed_rpv, lift_rpv. Sorted highest lift first. Read-only; precomputed by a weekly cron (empty until it has run / product profiles exist). Use it to decide what reviews/copy/guarantees to author. Defaults: limit=15, min_viewers=30.
learn_insights: Reference: what Eevy's insight signals mean (per-section GA belief, live per-layout BigQuery truth, cross-product winning angles, store funnel, per-product and per-section revenue), their freshness, and how to act on them. Read this before interpreting get_variant_performance / get_variant_performance_live / get_winning_angles / get_store_funnel / get_product_performance / get_section_performance.

Experiments & optimization engine

Inspect and steer the genetic-algorithm testing engine.

get_experiment_state: Read the store's live experiment: returns {sections}, each native section with its status (Live/Draft/Inactive) and its variations (exp_variation_id, allele, variant_name, active). Use this before set_section_status / set_variation_status / integrate_section.
integrate_section: Add a native section to the store's experiment (activates it and seeds its variations into the genome). Use get_experiment_state to see which sections are not yet integrated.
learn_experiment_control: Learn Eevy's GA model for agents: an experiment has native sections (each Live or Draft); a section has variations (alleles) that are active/inactive; the GA evolves which active variation wins per visitor. set_section_status / set_variation_status / integrate_section are DIRECT, LIVE changes to the storefront — there is no draft step. Read get_experiment_state first.
set_section_status: Take a native section LIVE on the storefront (live=true) or set it to draft (live=false). This is a direct, live change: it recompiles GrowthBook and refreshes the storefront. Use get_experiment_state to find section_id.
set_variation_status: Activate (active=true) or deactivate (active=false) a native variation so it competes in the GA (or stops). Direct, live: injects/removes the allele, recompiles GrowthBook, refreshes the storefront. Use get_experiment_state to find exp_variation_id.

Content: reviews, UGC, FAQs, images

Read, add, curate, and test the content competing in each section.

create_faq: Create a FAQ (first-party Q&A copy) for a product handle. answer_text is CommonMark markdown. Inert until you set_content_testing it on. No enrichment (linked review / AI summary) over MCP.
create_guarantee: Create a guarantee/USP item (first-party marketing copy: headline + optional subtext/tooltip/icon-preset/link). It is INERT until you set_content_testing it on. No image upload over MCP (media_type defaults to icon).
delete_faq: Delete a FAQ. If the FAQ is currently testing on a live section, toggle off testing first to free the variant letter cleanly.
delete_guarantee: Delete a guarantee/USP item. Blocked while the item is testing — call set_content_testing false first to free the variant letter cleanly.
learn_content: Learn the Eevy content model for agents: curation (list_content + set_content_testing) is supported for all listed types; authoring is limited to first-party copy (Guarantee, FAQ). Agents must NEVER fabricate reviews, UGC, or expert endorsements. set_content_testing is a direct, reversible, live change.
list_content: List a store's content items of one type with their GA testing status (id, label, testing, variant_letter, handle). Use this to see what content exists and which items currently compete in the GA. See learn_content for supported types. Paginated: pass limit (default 50, max 200) and cursor (from the previous page's next_cursor; omit for the first page). Returns {items, next_cursor, total}; next_cursor is empty on the last page.
list_untested_content: List NEW UNTESTED content (Reviews, UGC videos) that arrived via integrations/imports/uploads AFTER testing started for its product and is not yet competing in the GA pool. This is the polling half of the autonomous curation loop: poll this tool, judge each item's quality (signals worth checking: star rating, preview text length and substance, relevance to the product), then call set_content_testing with data_type + item_ids[] (1-100) to include the chosen items — one GrowthBook recompile per batch. Included items disappear from this list immediately; items removed after testing become 'tested' and are never re-listed as untested. Only products that already have at least one item testing are scanned — a product with nothing testing yet never appears here. Each item carries id, content_type (the data_type to pass to set_content_testing), product_handle, created_at, a ~120-char preview, and rating (Reviews only) — enough to decide without a per-item follow-up call. Paginated: pass limit (default 50, max 200) and cursor (from the previous page's next_cursor; omit for the first page). Returns {items, next_cursor, total}; next_cursor is empty on the last page.
media_branch: Traverse the media tree. Start with path='' for root, then 'products' (list product handles), 'products/<handle>' (that product's images as leaves), 'brand-assets' (list categories), 'brand-assets/category:<cat>' (assets in a category).
media_inspect: Return metadata and nearest neighbors for a single media asset identified by its media_ref (e.g. 'image:<id>' or 'brand:<uuid>').
media_search: Rank media assets by semantic similarity to a query. Use free text or 'similar to: <media_ref>' to find visually/semantically close assets. scope=all|products|brand-assets.
set_content_testing: Include (testing=true) or exclude (testing=false) existing content items from the store's live GA pool. Pass item_id for one item, or item_ids (1-100) to curate in bulk — the bulk path toggles every item through the same canonical core but recompiles GrowthBook ONCE at the end, and returns per-item {item_id, ok, error} results (a failing item never aborts the batch). Idempotent and reversible — this is the curation lever that decides which content competes. Changes take effect on the live storefront (the same action merchants take in the UI). To find newly-imported items worth including, poll list_untested_content and pass the winners here as one item_ids batch.
update_faq: Update a FAQ's question and/or answer_text. The faq_id and product_handle must match a FAQ that belongs to this store's experiment.
update_guarantee: Update a guarantee/USP item's copy fields (headline, subtext, tooltip, icon, link_url, tags). Headline edits are blocked while the item is testing — call set_content_testing false first.

Layouts & custom sections

Author and publish custom layouts and sections as competing variants.

create_custom_layout: Create a DRAFT custom layout for a native section. NOT yet live — call publish_custom_layout to take it live (auto) or queue it for merchant approval (gated), depending on the store's agent publish mode. Read learn_custom_code and learn_eevy_methods first. Fails if the section's a-z allele cap is reached.
create_custom_section: Create a DRAFT custom section (name, placement, bound_data_type, optional bound_tag, 1-26 variations). It is NOT published — a human publishes it in the Eevy studio. Read learn_custom_code and learn_eevy_methods first.
delete_custom_layout: Soft-delete a custom layout (set inactive, status=draft). The row and its allele reservation are kept. If it was live, this only affects MCP drafts — publish/unpublish remain human actions in the UI.
delete_custom_section: Soft-delete a custom section (set inactive, status=draft). Matches the studio's delete semantics; publish/unpublish remain human actions in the UI.
get_custom_layout: Get one custom layout (full html/css/javascript/config) scoped to the target store. Use this before update_custom_layout to read the current code.
get_custom_section: Get one custom section including all its variations (full html/css/javascript/config per variation), scoped to the target store.
get_native_layout_example: Return a real native Eevy layout for a section as a grounded reference to imitate: its data_type plus the HTML/CSS/JS of a built-in variation (which already declares the correct data-constant). Use this before authoring a custom layout/section for that data type.
learn_custom_code: Learn how to author Eevy custom layouts and custom sections: the layout-vs-section model, valid placements, allowed bound data types, the exact JS data-constant + bindable fields per data type, the escape-on-output rule, and the draft->human-publish workflow. Read this BEFORE creating or editing any custom layout/section.
learn_eevy_methods: Return the full eevy-methods (EevyM) building-block catalogue: every namespace and method with signature, purpose, code snippet, and tags. Compose custom layouts/sections from these helpers instead of reinventing carousels, escaping, icons, formatting, data-binding, or item-rendering.
list_custom_layouts: List this shop's custom layouts for one native section (requires section_id). Items are {id, section_id, allele, variant_name, status, is_active}, ordered by allele. Paginated: pass limit (default 50, max 200) and cursor (from the previous page's next_cursor; omit for the first page). Returns {items, next_cursor, total}; next_cursor is empty on the last page.
list_custom_sections: List this shop's custom sections. Items are {id, name, placement, bound_data_type, status, is_active, variation_count}, ordered by placement then gene index. Paginated: pass limit (default 50, max 200) and cursor (from the previous page's next_cursor; omit for the first page). Returns {items, next_cursor, total}; next_cursor is empty on the last page.
list_layout_sections: List the native Eevy sections in the target store's experiment that a custom layout can attach to. Returns {section_id, name, placement, data_type, has_active_native_variation, is_active}. data_type tells you which render contract (see learn_custom_code) applies. has_active_native_variation=false means your layout will render with store-wide (non per-product) data until a built-in layout is also live. is_active=false means the section is not currently active.
preview_custom_layout: Mint a signed 15-minute storefront preview URL for a DRAFT custom layout — see it rendered live before publish_custom_layout. The preview is UNCACHED and author-only: only the holder of the signed link sees the draft; real shoppers are unaffected. product_handle picks the product page for product-placement sections (omit to preview on any product). Returns {url, expires_at, note}.
publish_custom_layout: Take a custom layout live into the GA tournament. Behaviour depends on the store's agent publish mode: 'auto' takes it live immediately at GA-allocated traffic; 'gated' (default) queues it as pending for one-click merchant approval. Refused (with the findings) if the layout is not grounded in its data type OR contains blocking issues (e.g. unescaped innerHTML). Returns {status: 'live'|'pending', id, warning?}. When queued pending, follow the outcome with list_agent_proposals / get_agent_proposal (a rejection includes the merchant's reason).
unpublish_custom_layout: Remove a live custom layout from the GA tournament (kill switch): its allele is removed from the genome and it returns to draft. Safe to call on a non-live layout.
update_custom_layout: Edit a DRAFT custom layout's content (variant_name/html/css/javascript/config). The allele and section are immutable. Does not publish.
update_custom_section: Edit a DRAFT custom section. name/placement/bound_data_type/bound_tag are optional (omit to keep). If variations are provided they replace the set; include each variation's id to update it in place, omit id to add a new one. Does not publish.
validate_custom_code: Statically check custom layout/section code for a data type WITHOUT publishing: returns grounded=true/false (does the JS declare the data type's data-constant, so the renderer injects real data) plus advisory findings (e.g. unescaped innerHTML). Run this and fix grounded=false before you ask a human to publish — publish is hard-blocked on grounding.

Section customizations

Read and set every customization knob, with schema discovery.

get_customization_schema: Enumerate the customization knobs for a native Eevy section variant: its groups and fields (key, label, control type, default, and valid range/options) that set_variation_customizations can change. Pass variation_id (from get_variation_customizations) to get that variant's schema; omit it to list every variant that has a schema. The group structure IS the write shape: customizations[groupKey][fieldKey] = value (fields in a group with no groupKey are written at the top level). Custom/agent-authored layouts have no schema here.
get_variation_customizations: Read the customization blobs that skin a store's native section variations (the structured knobs behind the layout: CSS-var values, toggles, copy, per-tag presets). Returns each variation's variation_id (the write key), section context, active flag, and current customizations. Omit variation_id to survey the whole experiment, or pass one to fetch a single variation. There is no fixed schema yet — learn the key vocabulary by example from existing variations (cross-reference get_variant_performance_live to copy what is winning).
learn_customizations: Learn how Eevy section customizations work before reading or writing them with get_variation_customizations / set_variation_customizations.
set_variation_customizations: Apply a customization patch to one native section variation. The patch merges onto the variation's existing customizations at the FIELD level within each group: send customizations[groupKey][fieldKey] and only those fields change — the group's other fields are preserved. Top-level keys overwrite. Call get_customization_schema(variation_id) to see the exact groups and field keys. This is a DIRECT, live change — if the target variation is active, the storefront updates on the next render. Read get_variation_customizations first to learn the exact key vocabulary; do NOT invent keys, and never put scripts/raw HTML here (use the custom-layout tools for code). Returns the merged customizations.

Lift & proven ROI

Causal holdout tests and revenue receipts.

cancel_eevy_lift_test: Cancel the running Eevy lift holdout for a store (restores all visitors to the Eevy experience). Errors if no test is running.
get_eevy_lift: Read how much revenue Eevy adds to a store. Returns the CAUSAL holdout result when a validation test has produced a verdict (eevy vs no-Eevy control arm: RPV/CVR/AOV lift %, p-value, winner), otherwise a DIRECTIONAL best-layout-vs-rest estimate (clearly flagged non-causal). Includes an annualized $ impact projection and the store's holdout history. Use this to answer 'how valuable is Eevy here?'. Live query.
get_optimization_report: The one-call 'what is Eevy doing for this store' narrative. Returns {store_name, headline, active_tests[] (Live sections + how many variations are competing), not_yet_live_count (Draft sections built but not testing), proven_roi (causal-holdout revenue Eevy has PROVEN, same as get_roi_summary), recent_proposals[] (newest-first, capped at 10 — call list_agent_proposals for the full inbox) plus total_proposals/pending_approval_count, auto_improve (autonomous agent run-status, same as get_auto_improve_status), and account (tier/credits/beta/publish-mode, same as get_account_status). Composed entirely from those tools' own reads — no new computation — so figures always agree. Use this first when asked 'what has Eevy done / is Eevy working', then drill into the named tool for detail.
get_reallocation_opportunity: Estimate revenue left on the table by serving every GA variation EQUAL traffic. Method is honest out-of-sample: rank variations on an older window, then evaluate 'concentrate on those winners' against a fresh window of randomized traffic (so it's causal and free of winner's-curse). Returns the current (equal-weight) RPV, the leader's persistence, lift scenarios (concentrate on leader = optimistic, top-3 = conservative), an annualized $ gain range, and a significance call. window: 7d|14d|30d (default 14d; the rank window is the same length immediately before). Read-only — does NOT change serving.
get_roi_summary: Read the store's PROVEN incremental revenue from Eevy — the causal-holdout ROI. Returns {proven_lift_this_month_usd, proven_lift_trailing_12mo_usd, annualized_projection_usd, currency, per_test[], measuring[], as_of, methodology_note}. Only SIGNIFICANT positive verdicts (always-valid sequential RPV confidence sequence, raw AND winsorized) count toward the headline; inconclusive/running tests appear under 'measuring' and a control-won result is reported with negative $ — never inflated. Per-test $ is realized (added RPV × sessions actually exposed), the annualized figure is a labelled projection. Use this to answer 'how much has Eevy made this store?'. Live query.
start_eevy_lift_testbeta: Start an 80/20 randomized HOLDOUT to causally measure Eevy's revenue lift. WARNING: this is a live storefront change — the control fraction of visitors will see NO Eevy sections for the duration. treatment_pct 51-95 (default 80). Optional target_sessions (0 = auto from baseline CVR) and suppressed_section_ids (empty = hide all live sections for control). Fails if a test is already running. Read the result later with get_eevy_lift. Beta-gated.

Agent proposals & autonomy

Review, approve, and track autonomous optimization proposals.

get_agent_proposal: Get one custom-layout proposal by ID (tenancy-scoped): proposal_status (pending|approved|rejected|draft), timestamps, the reject reason when the merchant declined it, the layout's name/section/allele, and what will happen on approval. 'rejected' proposals can be edited (update_custom_layout) and re-published.
get_agent_publish_mode: Report whether agent go-live actions (custom-layout publish, addon start/graduate) auto-execute or queue for merchant approval. Returns {agent_publish_mode: 'gated'|'auto'}. 'gated' is the default — actions queue until the merchant approves. 'auto' means the agent executes them immediately without approval.
list_agent_proposals: List this store's agent-publish-queue proposals (custom layouts AND customized variations), newest first. Items are {id, kind: 'custom_layout'|'customized_variation', section_id, section_name, variant_name, allele, proposal_status, is_active, created_at, updated_at, rejected_at?, reject_reason?}. proposal_status: 'pending' (queued for merchant approval), 'approved' (live in the GA), 'rejected' (merchant declined — reject_reason says why, fix and re-publish). Each item carries 'origin' ('auto_improve' = queued by the autonomous auto-improve agent; empty = manual/interactive). Optional status filter, and optional origin filter (e.g. origin='auto_improve' to isolate the auto-improve agent's proposals). Use this after publish_custom_layout / propose_customized_variation returns {status:'pending'} to follow the outcome. Paginated: pass limit (default 20, max 100) and cursor (from the previous page's next_cursor; omit for the first page). Returns {items, next_cursor, total}; next_cursor is empty on the last page.
propose_customized_variation: Propose a customized COPY of a native section variation as a NEW competing allele in the GA display genome — the safe alternative to set_variation_customizations when you want your change TESTED against the original instead of overwriting it. The copy inherits the source layout's code and customizations, with your patch merged on top (group-aware, like set_variation_customizations). Behaviour follows the store's agent publish mode: 'auto' activates immediately (allele injected into the live population at GA-allocated traffic); 'gated' (default) queues it for one-click merchant approval — follow the outcome with list_agent_proposals / get_agent_proposal. Returns {status: 'live'|'pending', proposal_id?, experiment_variation_id, variation_id, allele, ...}. Read get_customization_schema first; do not invent keys.

Account, billing & status

Account status, usage, and store administration.

get_account_status: One read for the target store's account: subscription tier (slug + name) and whether billing is usage-based, AI-credit status for the current month (included/used/remaining, whether overage billing is enabled and its price), the agent publish mode (gated|auto — governs whether go-live actions execute or queue for merchant approval), the autonomous optimization mode (auto_optimize_mode: off|curate|improve) plus auto_improve_eligible (true only when mode=improve AND the shop is a beta shop, i.e. the auto-improve agent is actually active), the beta-shop flag (gates custom-code authoring tools), and the MCP rate-limit parameters. Blocks degrade independently (available=false + note) when a backing system is unreachable.
get_auto_improve_status: Run-status for the autonomous auto-improve agent on the target store: mode (off|curate|improve), eligible (true only when mode=improve AND the shop is a beta shop — i.e. the agent is actually active), the latest REAL run (last_run_at + examined/proposed/auto_approved/skipped/capped/metered), the latest dry-run timestamp, and pending_proposals (auto-improve proposals still awaiting merchant approval). last_auto_approved is the subset of proposals that were activated LIVE WITHOUT merchant approval because they were obviously-correct placeholder text fixes AND the store opted into auto-approval (0 for every store with the default flag off). Use it to see whether the agent is on and what it last did; follow individual proposals with list_agent_proposals(origin='auto_improve').
stores_current: Describe the authenticated MCP scope: whether it is a single store or an organization (sync group), the default store used when store_ref is omitted, and how many stores are reachable. Read-only.
stores_list: List the stores this credential can act on. Organization (sync-group) credentials span every store in the multistore sync; single-store credentials list only their own store. Read-only navigation: pick a store's integration_id, shop domain, or nickname and pass it as store_ref to other tools.

Addons & campaigns

Bundles, discounts, and addon lift tests.

bundle_campaigns_delete: Remove one offer campaign from a bundle's config by key. Persistence-only: if the campaign was deployed, deploy the bundle afterwards so its Shopify code discount is torn down (an active->absent campaign is reconciled on the next deploy).
bundle_campaigns_deploy: Deploy the bundle that owns a campaign so its offer override is provisioned on Shopify. This runs the full bundle convergence (Cart Transform, base bundle-gifts discount, picker mirror) and reconciles every active campaign's dedicated code discount, then returns the named campaign's resolved status, shopify_discount_gid, and discount link. Use bundles_deploy to converge the whole bundle without focusing on one campaign. This is a DESTRUCTIVE, live-storefront change and follows the store's agent publish mode: 'auto' deploys immediately (returns {status:'live'}); 'gated' (default) queues it for one-click merchant approval (returns {status:'pending', proposal_id}) — track it via list_agent_proposals / get_agent_proposal. On approval Eevy runs the exact same deploy.
bundle_campaigns_get: Get one offer campaign from a bundle by campaign key, returning the full campaign object (including any display passthrough fields) plus a deployed flag.
bundle_campaigns_list: List the offer campaigns connected to one bundle (config.campaigns). Each entry: key, name, status, code, priority, message, per-tier override keys, shopify_discount_gid, and whether it is currently deployed. Read learn_bundles for the campaign override contract.
bundle_campaigns_set: Create or update one offer campaign on a bundle (config.campaigns.<key>). Provided fields are merged over any existing campaign so partial edits are safe; deploy-managed fields (shopify_discount_gid) are preserved unless you explicitly clear them. This is persistence-only and validates with the lenient draft gate — call bundle_campaigns_deploy (or bundles_deploy) to provision the Shopify code discount.
bundles_create: Create a draft Bundle record for one target store. This is persistence-only: it does not create Shopify products/variants, Cart Transform, discounts, or picker mirrors. Read learn_bundles first; owning_product_gid/parent_variant_by_selection refer to Eevy-managed hidden offer variants that must exist before deploy.
bundles_delete: Delete a draft or archived bundle. Deployed bundles must be undeployed first.
bundles_deploy: Deploy one target store's Bundle to Shopify. This is the convergence action: validates parent variants, writes/updates Cart Transform, bundle-gifts automatic discount, Eevy-owned parent variant prices/images, hydrated owning-product data, and picker mirror. It requires existing Eevy-managed hidden parent product/variants; if they are missing, stop and request/provision them instead of creating ad-hoc merchant products. This is a DESTRUCTIVE, live-storefront change and follows the store's agent publish mode: 'auto' deploys immediately (returns {status:'live'}); 'gated' (default) queues it for one-click merchant approval (returns {status:'pending', proposal_id}) — track it via list_agent_proposals / get_agent_proposal. On approval Eevy runs the exact same deploy.
bundles_get: Get one bundle from one target store including its full config and owning_product_gid. The owning product is an Eevy-managed hidden commercial-offer product, not a normal physical component product.
bundles_list: Legacy alias for list_bundles. Paginated: pass limit (default 50, max 200) and cursor (from the previous page's next_cursor; omit for the first page). Returns {items, next_cursor, total}; next_cursor is empty on the last page.
bundles_rehydrate: Register product-update webhooks and refresh an already-deployed bundle from live Shopify data without rerunning full deploy. Rehydrates component and Eevy parent variant title/image/price data, then rewrites deployed mirrors when needed.
bundles_undeploy: Undeploy one target store's bundle: remove the Cart Transform + bundle-gifts discount and reset it to draft. Leaves the Eevy-managed parent product/variants and picker mirror in place.
bundles_update: Update one target store's Bundle draft/deployed record: name, owning_product_gid, and/or config. Save is mostly persistence-only; deploy/rehydrate perform Shopify convergence. Do not substitute normal component variants for Eevy-owned parent variants.
cancel_addon_lift_testbeta: Cancel the running lift test for a custom addon. Safe/reversible — not subject to agent_publish_mode gating. The addon reverts to draft status (or graduated if a previous winner was set). (beta)
create_custom_addonbeta: Create a DRAFT custom addon (name, display_name, placement, embed_tag, html/css/javascript + optional arms). If arms are omitted, two default arms are seeded: off-state '-' and on-state 'A', so the addon is immediately lift-testable. The addon remains DRAFT and inert until a lift test is started. (beta)
create_custom_addon_armbeta: Add a new lift-test arm to a custom addon. Arms carry only customization JSON (not code). Exactly one arm must be the off-state control — enforce this before starting a lift test. (beta)
delete_custom_addonbeta: Soft-delete a custom addon: sets status=draft and is_active=false. The addon is NOT destroyed — it can be inspected in the studio. Any running lift test must be cancelled before calling this. (beta)
delete_custom_addon_armbeta: Hard-delete a specific arm from a custom addon. Cannot delete the off-state arm while a lift test is running. (beta)
discounts_create: Create a new discount campaign (validated before persistence).
discounts_delete: Delete a discount campaign, removing its Shopify discount first when one exists.
discounts_deploy: Push the campaign to Shopify (create or update the automatic/code discount) and mark it active. This is a DESTRUCTIVE, live-storefront change and follows the store's agent publish mode: 'auto' pushes immediately (returns {status:'live'}); 'gated' (default) queues it for one-click merchant approval (returns {status:'pending', proposal_id}) — follow the outcome with list_agent_proposals / get_agent_proposal. On approval Eevy runs the exact same push.
discounts_get: Get a single discount campaign including nested discount lines.
discounts_list: List all discount campaigns for the target store.
discounts_stats: Read A/B performance for a discount campaign: per-arm net_rpv (primary headline metric), uplift vs control, p_value, cvr (a 0-1 fraction), aov, redemptions, visitors — plus a summary naming the leading arm (max net_rpv) and whether it is statistically significant (leader p_value < 0.05). Read-only; data is the daily rollup (may lag). Use it to steer discount decisions: which arm wins and whether the result is trustworthy yet. Defaults: window=all, product_handle=__all__ (campaign-wide).
discounts_update: Replace the mutable fields of an existing discount campaign (preserves id, Shopify GID, and push state).
get_addon_lift_testbeta: Get the current (or most recent) lift test for a custom addon. Returns the active running test if one exists, otherwise the latest completed/cancelled test. Returns {status:'none'} when no test has ever run. (beta)
get_custom_addonbeta: Get one custom addon: full HTML/CSS/JS, all arms (id, variant_letter, is_off_state, customizations), status, winning_variation_id, plus the latest lift test if any. (beta)
graduate_addonbeta: Graduate a custom addon by promoting the winning arm. Cannot graduate the off-state arm. Honors the store's agent_publish_mode: 'auto' graduates immediately; 'gated' queues for merchant approval. (beta)
learn_addons: Reference for custom addons: what an addon is (a presentational HTML/CSS/JS widget distributed via the shared app embed), that arms differ only by customization JSON with exactly one off-state arm, the lift-test lifecycle (start 50/50 -> inspect -> graduate winner or cancel), and that start/graduate honor the store's agent publish mode.
list_bundles: List bundles for one target store (id, name, status, tier keys, version, updated_at). Use stores_list first when your credential spans multiple stores. Paginated: pass limit (default 50, max 200) and cursor (from the previous page's next_cursor; omit for the first page). Returns {items, next_cursor, total}; next_cursor is empty on the last page.
list_custom_addonsbeta: List this store's custom addons. Returns {id, name, display_name, placement, embed_tag, status, is_active, arm_count}. (beta)
product_variants_get: Resolve a product's variants (gid, title, sku, selected options) for the given handle. Useful for filling in bundle/discount variant GIDs.
products_search: Search the target store's synced products (cached_products) by handle/title substring. Returns {handle, title} items sorted by handle. Paginated: pass limit (default 50, max 200) and cursor (from the previous page's next_cursor; omit for the first page). Returns {items, next_cursor, total}; next_cursor is empty on the last page.
start_addon_lift_testbeta: Start a 50/50 lift test for a custom addon. Both arms must be RENDERING variations (variant vs variant): pass control_variation_id explicitly — the off-state (hidden) arm is rejected because hidden arms emit no impressions, so the test could never measure them. Validates that the addon has exactly one off-state arm and at least one treatment arm. Honors the store's agent_publish_mode: 'auto' starts immediately; 'gated' queues a pending action for merchant approval. (beta)
update_custom_addonbeta: Update mutable fields (display_name, description, html, css, javascript) on a DRAFT custom addon. Omit any field to leave it unchanged. Placement, embed_tag and name are immutable. (beta)
update_custom_addon_armbeta: Update the customizations JSON on a specific arm of a custom addon. (beta)

Reference & learning

Docs, methods, and schema references for agents.

bundles_config_reference: Legacy alias for learn_bundles.
discounts_config_reference: Return the nested discount lines schema, effect params, target rules, and campaign field reference.
learn_bundles: Learn how to operate Eevy bundles: config schema, Eevy-owned hidden parent product/variant model, draft-vs-deploy validation, deploy artifacts, line-item property contract, and a generic example config. Read this before creating or deploying bundles.

Frequently Asked Questions

Free — no account needed

See exactly what's costing you conversions

Paste your product URL. Get a scored Shopify PDP audit in 30 seconds — then see how Eevy AI fixes every gap.

Scan my store →