ChatGPT Plugin

GemPages by GemCommerce

Build Shopify landing pages

Brand: Unknown

Category: Pending
Primary Subcategory: Pending

Integration details

Description

GemPages by GemCommerce connects ChatGPT to the GemPages app on your Shopify store, so you can research, build, and publish landing pages from a conversation. What you can do: - Research product and market content for a landing page - Turn marketing content into a complete landing page - Convert HTML or an image into an editable GemPages page - List, inspect, and update your GemPages pages and sections - Publish or unpublish pages on your Shopify storefront Requirements: a Shopify store with the GemPages app installed. All actions follow the limits of your GemPages plan. GemPages only accesses the Shopify stores you connect with a connection code from GemPages Preferences.

Integration type: Plugin
Verification status: Not applicable
Platform: ChatGPT
Category: Pending
Primary Subcategory: Pending
Secondary Subcategories: None listed
Brand: Unknown
Access: Account required
First tracked: 2026-10-29
Tool count: 44
Market: US

Agent DiscoverabilityChatGPT Plugin Discovery Score

ChatGPT organic discovery is live

Your score is coming

ChatGPT now suggests Plugins on its own when they match a user's request.Your Plugin Discovery Score measures how often yours appears, and it will show here as soon as it’s ready.

ChatGPT recommends Airtable when a user asks it to update a CRM. — ChatGPT surfaces Airtable because it matches the user's request.

Primary Subcategory

Competitive lineup

No Primary Subcategory assigned yetOnce GemPages by GemCommerce has a Primary Subcategory, the Plugins and Connectors it competes with will appear here with their scores.

Tools

44 tools agents can invoke

Adds another Shopify store to this connector by redeeming a one-time connect code (OTP) in the form `GC-xxxxxx`, so its GemPages resources become reachable here. Use when the user wants to work on an additional store that isn't connected in this session yet: the merchant generates a connect code (`GC-xxxxxx`) in that store's GemPages admin, then gives it to you. Pass it as `otp` — this grants the connector access to the store and app the code was minted for. Does NOT require a shopId: the OTP encodes the target shop and app. Returns the connected `shopID`, `consentState`, and `appType`; reuse that `shopID` as the `shopId` on subsequent tool calls for that store. A stale, already-redeemed, or expired OTP makes this call FAIL (an error is thrown) — it never returns successfully for a bad code. So on a successful response, the sentence you show the user for THIS connection must be exactly the `message` field's text, verbatim, with no added or reworded commentary — no comparison to a shopId seen earlier in the conversation, no comment about reconnects vs new connections ('same store as before' and similar phrasing is banned, not just discouraged). This does not restrict anything else: still call get_shop (or any other tool) afterward exactly as you normally would to fetch shop details or continue the workflow, and you may add your own text around/after the verbatim message for that follow-up — only the connection-confirmation sentence itself must not be reworded.
add_shop
[content-research review step] The gate that decides whether review collection is complete — call it after each collection round and follow its verdict. Submit the reviews you actually collected; the server counts, deduplicates and validates them and returns the real total. You do not decide when there are enough reviews and you must not report a count of your own: this tool is the only authority. It rejects entries with empty or fragmentary body text, entries with no URL, and duplicates (within the batch and across rounds), so a corpus that looks big can still come back short. When ok=false, collect from the sources listed in nextSources and call again with ONLY the new reviews plus the returned corpusToken — never resend reviews already counted. Repeat until ok=true; do NOT start analysis while ok=false. Target: 500 unique reviews across marketplace + social collection combined (one shared pool), cap 1000, and at most 3 rounds — after that a genuinely thin corpus is accepted and the shortfall must be reported to the merchant honestly. Stateless: no shopId, nothing stored server-side.
gempages_verify_reviews
Build a complete GemPages Section IN ONE CALL and save it straight onto the draft theme page (pageSectionCreate) — the section on GemPages is the working copy, so the doc never round-trips through your context. [convert-html step: build+save] HARD ARTIFACT GATE: `artifactAudit` is required. Populate it only after writing non-empty dom-tree.log and layer-tree.log for this section and completing the layer-tree self-check. Missing, inconsistent, or unfinished audit data is rejected before any pageSectionCreate mutation. Compose the section from: `skeleton` OR `json` (a full Section object), then `operations` applied on top, in order. Layout mechanism (editor-native): Section and Row are BOTH column containers — `settings.layout.<device>.cols` declares the split and the node has exactly one direct Col child per cols entry; Col appears ONLY inside Section/Row; a nested split = a Row placed inside a Col via ops. `skeleton` generates the Section splitting DIRECTLY into one content Col per `cols` entry (no Row layer). Each op: ADD/UPSERT {parentUid, node, position?} (`node` = one {uid, tag, ...} or an array of siblings; an existing uid is REPLACED in place — include `childrens` or the op is rejected) or REMOVE {action: "remove", uid}. With `skeleton`, parentUid may use symbolic refs: "$col0"/"$col1"/… (the skeleton's content Col per `cols` entry) and "$section". Nodes may be partial — element-template defaults auto-fill. The section is structurally validated BEFORE saving: on structural errors NOTHING is created and the errors are returned (fix the ops and re-call). Advisory per-element schema warnings are returned in the ack. Returns {message, pageSectionId, sectionUid, tree} (plus the full component when returnDoc:true) — record pageSectionId, then order it onto the page with gempages_update_page (sectionPosition). Refine afterwards with gempages_convert_template_edit_section.
gempages_convert_template_build_section
Edit a page section ALREADY SAVED on GemPages, server-side — the component never transits your context: the server fetches it, applies your ops/patches, validates, and writes it back (pageSectionUpdate). [convert-html step: refine] `operations` = node ops applied in order, atomic: ADD/UPSERT {parentUid, node, position?} (`node` = one {uid, tag, ...} or an array of siblings, partial fields auto-fill; an existing uid is REPLACED in place — include `childrens` or the op is rejected) / REMOVE {action: "remove", uid}. `patches` = [{uid, path, value}] dot-path edits ("$delete" removes the key), applied after the ops. With NEITHER operations NOR patches this is a read-only INSPECT: returns the stored section's compact uid tree (set returnDoc:true to also get the full component — rarely needed). Returns {message, tree} + validation report. Structural problems are reported but the update still applies (the section is a draft — fix with a follow-up call); an invalid op (unknown uid/parentUid, children-dropping replace) aborts with NO update.
gempages_convert_template_edit_section
Look up the GemPages generation library by `kind` — one entry point for element templates, section templates, layout patterns, modification strategies, and icons. Read-only reference (no live shop data, no shopId). kind="element": name=<tag> → the element's default JSON template (use the exact `tag`, e.g. "Text", "Button" — NOT the label). Omit name → list available element tags. Do NOT pass "Col" — use kind="pattern". kind="section": name=<template name, e.g. "hero-banner-simple"> → full SECTION TEMPLATE JSON (a generation reference, not a live shop section). Omit name → list section templates with the elements they contain. kind="pattern": name="section-single-col" | "section-two-col" → layout skeleton (Section/Row/Col, no content). Omit name → list patterns. kind="strategy": name=<strategy name, e.g. "button-horizontal-align"> → full step-by-step modification guide. Omit name → list strategies. kind="icon": name=<exact icon name, e.g. "star-filled"> → ready-to-use iconSvg value; OR query=<keyword> (+ optional weight: bold/light/regular/filled) → matching icon NAMES. Provide query or name (icons are not listed in bulk).
gempages_convert_template_get_library
Read a GemPages knowledge/reference document by key. FIRST tool family for any HTML→GemPages generation task — consolidates the static reference docs into one entry point. Returns reference text, not live shop data; takes no shopId. REQUIRED ORDER: start with doc="guidelines", then doc="generation-rules". When cloning HTML, also load doc="element-taxonomy" once per page. The rest are reference lookups. Keys for `doc`: - "guidelines": master rules. Call FIRST. - "generation-rules": core generation rules (element anatomy, layout hierarchy, property placement). Call SECOND. - "element-taxonomy": HTML→GemPages container & nesting taxonomy (free/managed/leaf, flowTag, notAppendTags, default children trees) + HTML→element mapping. For cloning; once per page. - "cloning-context": the walker's CSS→GemPages field-mapping rules (border→advanced.border, padding→spacing-setting, gap→verticalGutter, fit vs fill, Section-margin traps, …). Same content otherwise attached only to the FIRST gempages_convert_template_get_html_section call — fetch this when cloning HTML. Not a hint to delegate: the convert run is ONE agent and sub-agents are off by default (see the skill's Roles section). In the rare user-requested delegation, the worker MUST fetch this itself — it has its own context and does not inherit that first-section attachment, which is exactly why delegating is expensive. - "no-scaffold-derive-values": HTML→GemPages cloning rule — trace every value to source or template; never copy values from sibling pages/builders. - "per-node-derive-verify": repeated structures (cards/rows/grid items) — diff layout vars across ALL instances before building; verify with style parity, not just content coverage. - "validation-checklist": rules the validator enforces. Reference only. - "nesting-rules": valid parent→child relationships for all element types. - "settings-dictionary": what each JSON property does. - "style-tokens": available design tokens (colors, typography, spacing, border radius). - "elements-list": catalog of all element tags grouped by category.
gempages_convert_template_get_knowledge
Returns the detailed native GemPages layer tree for a SINGLE section of a page, plus a [diagnostics] footer. Stateless: pass the raw `html` of one section (the convert-html pipeline builds one file per section, so pass that file's html with index 0) plus its 0-based `index`. Set includeCloningContext=true on the FIRST section you load (once per page) to also get the clone-mode styling/mapping rules.
gempages_convert_template_get_html_section
Returns the RAW HTML of an 'uncertain' cluster that the layer tree flagged (a node with data.uncertain=true + data.clusterId). Use ONLY when a cluster's element type is ambiguous — the detectors couldn't classify it (e.g. a Marquee/Carousel built with non-semantic / Tailwind-CDN classes). Returns just that one cluster's HTML (bounded context) so you can classify it yourself and build the right GemPages element. Stateless: pass the same `html` you gave gempages_convert_template_get_html_section plus the clusterId from the layer tree. Do NOT use it to read whole sections — that's gempages_convert_template_get_html_section.
gempages_convert_template_get_html_cluster
Inspect a GemPages SectionData doc. Omit `uid` → a compact uid tree (one line per node: tag, uid, label + key info like cols/text/color/bg/src) to find the uid to target with gempages_convert_template_edit_section (operations/patches) or gempages_convert_template_patch_node. Provide `uid` → just that node's uid/tag/label/settings/styles/advanced (with a childrenSummary, not the full subtree) to inspect its properties before patching. Read-only, stateless: pass the doc you are building (a single Section object {...} or an array [{...}]).
gempages_convert_template_inspect
Apply targeted edits to a SectionData doc: an array of {uid, path, value} patches, where `path` is a dot-path within the node (e.g. "styles.typo.attrs.color") and `value` is the new value (use "$delete" to remove the key). Stateless: pass the current `doc`; returns {message, doc}.
gempages_convert_template_patch_node
The single validation gate for GemPages SectionData JSON: runs the structural checks (BLOCKING) PLUS per-element JSON-schema checks against knowledge-base/library/element-schemas (ADVISORY warnings only — never block). Use this as the gate before pushing/exporting a page (it re-runs the same structural checks gempages_convert_template_build_section applies before saving, so there is no separate structural-only tool to call). Structural errors must be fixed; schema warnings are advisory (the schemas are auto-generated and may over-report). Pass a single Section object {...} or an array of sections [{...}]. Stateless: pass the JSON directly.
gempages_convert_template_validate_schema
Deletes multiple GemPages page sections from a theme page in one call.
gempages_bulk_delete_section
[gen-page steps 03-04] Continue the page fill start_page_fill opened, and produce the finished page. Call it REPEATEDLY — once per paused step, TWICE in a normal gen run: profile (03) → swap (04). Each call takes the TOKEN from the step it is answering plus YOUR answer to that step's prompt, and returns either the next paused step or, after swap, the assembled landing-page.html + 06-replacements.json. Along the way it fetches the winning template, extracts and classifies its text slots, applies your replacements onto the template's own DOM and recolors to the brand palette. Do NOT pass the customer's article back on any step: the prompts point at the run's 00-input.md, which you read yourself. It neither classifies content nor ranks templates: those are process_build_input and rank_page_templates, and neither issues a TOKEN.
continue_page_fill
[gen-page step 00 — call this BEFORE gen_page] Returns a short-lived `uploadUrl` for sending the customer's raw content to the server as FILES, so the article never has to be typed into a tool argument. Write each piece of content to its own local .md file (or use the .txt/.md the user uploaded, unread), then `curl -sS -X POST "<uploadUrl>" -H 'Content-Type: text/plain' --data-binary @<file>` once per piece — each returns a `sourceId` to pass as `contents[].sourceId` to gen_page. This is the PREFERRED way to start a gen run: passing the article inline instead costs roughly four minutes per piece in generated tokens. One ticket covers the whole batch — pass `count`. It already carries its own credential; do not add an Authorization header.
create_content_upload_url
Creates a new GemPages theme page (a page built with GemPages for the merchant's Shopify storefront) and binds it to sections. Creates every page type the merchant names in their own words — a Headless page is `type: "STATIC"`, a landing page is `GP_STATIC`. Pass themeSectionIDs and sectionPosition (same array) to attach sections in render order.
gempages_create_page
Creates a new page section on a GemPages theme page.
gempages_create_section
[gen-page step 00] Generate landing page(s) from ONE OR MANY pieces of raw marketing CONTENT — a brief, advertorial, product description, offer copy, or rough notes (text, NOT pasted HTML). This is the PREFERRED tool and the ENTRY POINT for any "build / create / generate a landing page" (or sales page / product page) request given product or offer text — start here, not at any later step, and ALWAYS when the user supplies more than one piece. Do NOT use the convert-html-to-gempages skill for this — that pipeline is only for cloning an EXISTING page the user hands over — pasted HTML, a URL, or a screenshot of it. GET THE CONTENT IN AS FILES: write each piece to its own local file, call create_content_upload_url and `curl` each one up, then pass the returned ids as `contents[].sourceId` — typing the article into `contents[].content` instead costs about four minutes per piece. It opens the batch (store → batch folder → batch-log.json listing EVERY content as pending, one <NN>-<content-slug> page folder each, EVERY folder created up front with its 00-input.md already written), then drives the contents through the normal per-content flow ONE AT A TIME, handing you the process_build_input (step 01) call for each in turn. Pass every piece of content up front in `contents`; the returned `batchToken` carries only the remaining items' FOLDER NAMES (not their text — that's already on disk), so call gen_page again with that token to advance to the next one, reading its content back from its own 00-input.md. Each content then runs process_build_input → save_content_profile → rank_page_templates → save_template_scores → get_template_selection_files → start_page_fill → continue_page_fill, each tool naming the next in its response. This tool does not classify, rank or fill: it owns the folders and the queue only.
gen_page
Retrieves a GemPages theme page by ID, including its sections summary.
gempages_get_page
Returns the shareable links for a GemPages theme page: `editorUrl` (opens it in the GemPages visual editor) and `previewUrl` (renders the page's current draft — it addresses the page by id, so it works at ANY status, published or not). For every page type except Headless (`STATIC`), `previewUrl` goes through the storefront app proxy; a Headless page instead previews on the store's own primary domain (e.g. a Vercel deployment), since it isn't rendered through the Shopify theme at all. `previewUrl` is a url string when previewable; when the page has no sections yet — or, for a Headless page, when its handle or the store's primary domain can't be resolved — it is instead `{error}`, since the preview would be blank or wrong: relay that error and offer `editorUrl` in its place. Also turns on the GemPages Theme Helper app embed so the preview renders with GemPages' CSS/JS — see `themeHelper` in the result and relay its `note` if present. Use whenever the user asks for the edit/preview/open link of a page, or to hand back links after creating or publishing one.
gempages_get_page_links
Retrieves a Shopify product (from the merchant's store, synced into GemCommerce) by ID or handle, including its options.
gempages_get_product
Retrieves a GemPages page section by ID, including its component source.
gempages_get_section
Fetches the full instructions for a named skill. Call this before executing a multi-step workflow to get the exact steps and tool sequence. Pass shopId so plan-gated skills can be verified — see the Plan gating section of the server instructions for which skills that covers; a gated skill is refused without it.
gempages_get_skill
[gen-page artifacts 04-05] Render this run's winning template exactly as fetched (04-template.html: pre-swap, pre-recolor, assembled as one standalone page — except font, which is always forced to Inter, tokens AND inlined @font-face, to avoid a cross-section token-merge artifact, see the file header) and its editable text slots (05-slots.json: extracted server-side and classified ai_writable vs requires_real_data — never extract slots yourself). Call it once the winner id is known — Rank #1, a top-10 id the user picked, or a template the user pinned outright. Save both files into the run's page folder under exactly those names and reply with file:// links. It is the LAST selection step: its response names the start_page_fill call that generates the page. This tool does NOT fill or assemble anything itself. For 02-content-profile.json (right after Step 1, before scoring) use save_content_profile; for 03-scores.json (from the Step-5 ranking JSON) use save_template_scores — neither needs the GraphQL fetch this tool makes.
get_template_selection_files
Lists GemPages theme pages (pages built with GemPages for the merchant's Shopify storefront) with optional filters by theme, type, status, name, or handle.
gempages_list_pages
Lists Shopify products from the merchant's store (synced into GemCommerce). Supports optional filters by title, vendor, status, handle, or baseID (the Shopify product ID, e.g. from an admin URL). If the user gives a plain numeric Shopify product ID (e.g. 8676662837419) or a Shopify admin product link (e.g. https://admin.shopify.com/store/<handle>/products/8676662837419), convert it to gid://shopify/Product/<id> and pass that as baseID.
gempages_list_products
Lists page sections of a GemPages theme page (per-page instances of theme sections).
gempages_list_section
Lists all available skills (step-by-step workflows). Call this when you are unsure which workflow to follow for a task.
gempages_list_skills
[gen-page step 00b] Capture or reuse a store's BRAND STYLE (brand colors + typography) — the brand-style.md document kept at the STORE level and reused by every batch. Call it ONCE per store at the START of a run or batch, right where the content input is taken and BEFORE any template is fetched. FIRST look for brand-style.md in the store folder: found → pass its text as `existingDocument` and this tool validates it and tells you to reuse it WITHOUT asking the user anything; not found → call with just `storeHandle` to get the exact question to ask. When the user answers, call again with what they gave: `raw` for a CSS/design-token file or a page from their site (this tool extracts the colors — do not extract them yourself), or `primary`/`secondary` hex for a value they typed, read out of a PDF/image, or picked from options you offered. If they skip, call with `decline: true` so they are never asked again. EVERY branch that asks the user something is a BARRIER — end your turn on the question and continue only once they answer; the brand must be resolved before a template is fetched. PICKING AN OPTION IS NOT THE ANSWER: three of the four take two moves (pick, then supply the hex / the file / their palette choice), so a pick puts you back in the wait — only Skip is complete at pick time. A dismissal IS an answer (proceed on the template's own palette and say so); an unanswered question is not one. Never invent brand colors and never skip on the user's behalf. Font families are checked against Google Fonts and the system stack before anything is saved (AC-4.7) — one that cannot be delivered comes back as a question to put to the user, not as a file.
process_brand_style
[gen-page step 01] Process the raw CONTENT input for a landing-page gen run: renders this run's 00-input.md, then classifies the content into ONE GemPages template archetype (ADVERTORIAL | LISTICLE | COMPARISON — never CLICKTHROUGH) with a confidence score and writes 01-classification.json. Call this FIRST, before rank_page_templates — it consumes the templateType this returns and must not re-classify. INPUT: pass the content as TEXT, ONE piece per call, the same way whatever its source — pasted chat text, the FULL text of an uploaded .txt/.md file (read it and pass it through like chat text; never a summary), or one Product Research output. Call it with just `content` to get the classification brief (the classify-template-type skill), then call it again with `classification` (the JSON verdict) and the `inputMetaToken` it returned — do NOT resend `content` on that call or any later one. If confidence is below the threshold the tool tells you to ask the USER to pick an archetype (or a Custom one) — send their answer back as `userTemplateType`. An unsupported custom type does NOT generate anything yet: the tool returns a disclaimer and asks you to get the user's explicit confirmation first — call again with the same `userTemplateType` plus `confirmed: true` only once they confirm. Confirmed, it switches the run to an AI-only page with the disclaimer and skips the GemPages template pipeline, ranking and selection. A confident AI classification (Case A) proceeds directly, with no confirmation asked.
process_build_input
Publishes a GemPages theme page live to the merchant's Shopify storefront and waits for the async backend job to reach a terminal status. [HTML→GemPages pipeline · push] Only call after explicit user confirmation. Awaits a websocket pagePublish event (Status=SUCCESS/ERROR); falls back to polling themePage.status if the websocket disconnects. Total wait is capped (default 30s, env: GC_PUBLISH_TIMEOUT_MS). Also turns on the GemPages Theme Helper app embed first so the live page renders with GemPages' CSS/JS — see `themeHelper` in the result and relay its `note` if present. Returns a structured outcome — only treat publishing as successful when ok===true and status==="PUBLISHED".
gempages_publish_page
[gen-page step 02] Fetch the LIVE GemPages template library slice for one archetype and return it together with the template-ranking rubric, so YOU (the host model) can score every template against the customer's content and present the TOP 10. The rubric served is ARCHETYPE-SPECIFIC (its own structural fingerprint block vocabulary) when templateType is ADVERTORIAL, LISTICLE or COMPARISON — pass it whenever you have it, from process_build_input's classification. Omitted, or CLICKTHROUGH, or ranking multiple archetypes at once falls back to the generic rubric. This is the only upstream read in the ranking step; it holds no state, issues no token and saves nothing. Call it AFTER 02-content-profile.json exists (save_content_profile) — the profile is the INPUT to the scoring rubric. Filter with pageType/templateType, and pass excludeTemplateIds on a gen_page batch so two pages never land on the same template. Afterwards: save_template_scores turns your Step-5 ranking JSON into 03-scores.json (never hand-write a report), and — only if the user wants the page actually built — get_template_selection_files then start_page_fill with the winner's id. Stopping right after the scores is a perfectly valid run: use exactly this tool for a template-fit report with no page behind it.
rank_page_templates
[gen-page artifact 02] Turn a piece of raw marketing CONTENT into its ContentProfile JSON and render 02-content-profile.json for you to save. TWO PHASES: call it with `content` to get the conversion brief (the template-ranking rubric, scoped to its Step 1 — the profile schema and field guidance), then call it again with `contentProfile` (the JSON you produced) to get the artifact. Fetches nothing either way. This is the tool for a profile with NO ranking behind it. On a normal gen run DO NOT call it: rank_page_templates serves the same rubric, you work its Steps 1-5 in ONE turn, and save_template_scores({ranking}) renders 02 out of the content_profile embedded in that Step-5 JSON — calling this tool as well means emitting the profile twice and pausing the run between two halves of one rubric. If you are already holding the ranking rubric, skip phase 1 and pass `contentProfile` directly.
save_content_profile
[gen-page artifacts 02–03] Render 03-scores.json (every candidate template's score) from the template-ranking skill's Step-5 output JSON, plus 02-content-profile.json again (the embedded content_profile — idempotent with save_content_profile's early save). 03 IS the ranking's record: do not also hand-write a report of the same numbers. Fetches nothing: pass this the moment Step 5 is done, whether or not a template will actually be built (a report-only rank_page_templates run stops here). For the winning template itself, use get_template_selection_files({recommendedTemplateId}) — a different tool, since that one needs a GraphQL fetch this one does not.
save_template_scores
[gen-page step 03] Fill an ALREADY-CHOSEN template with the customer's content and assemble the finished landing page. This is NOT the entry point for a "build me a landing page" request — that is gen_page, which opens the run and walks the selection steps first. Call this only once the winning template is known: the ranking (rank_page_templates → save_template_scores → get_template_selection_files) runs BEFORE it and its winner is passed here as recommendedTemplateId, which is REQUIRED — this tool ranks nothing and will not pick a template for you. It fetches nothing either: it returns a TOKEN plus the step-03 prompt, and you answer each paused step with continue_page_fill using that TOKEN. The gen run then runs profile → swap straight through — no pause asking whether to fill in the content — and ends with 06-replacements.json + landing-page.html. MANDATORY before answering ANY paused step: call gempages_get_skill(name:"gen-page") and obey it exactly — it OVERRIDES your own judgment. If the user states a PRIMARY brand color, pass brandColor and the tool derives a palette and recolors the template accents automatically.
start_page_fill
Unpublishes one or more GemPages theme pages by ID, removing them from the live Shopify storefront.
gempages_unpublish_page
Updates a GemPages theme page's properties.
gempages_update_page
Updates an existing GemPages page section's properties.
gempages_update_section
Uploads an image to the merchant's Shopify CDN via the GemCommerce upload API and returns a CDN-hosted file record. Use for images that need to be embedded in GemPages content (page HTML/Liquid) or anywhere else in the merchant's Shopify store. Accepts one of: - `url`: public HTTP/HTTPS URL — the server fetches and re-uploads it. - `filePath`: absolute path to a local file readable by the MCP server process (e.g. /Users/me/img.png or file:///...). Use when the source HTML references a local image. Only works when the MCP server runs on the same machine as the file. - `base64` + `mimeType` + `fileName`: raw base64-encoded image (no data URI prefix). Use when the server cannot read the file directly (remote MCP server) — read and base64-encode on the client first. Returns the upload API response including the CDN `filePath` to embed in page HTML/Liquid content.
gempages_upload_image
Checks whether a URL handle is available and valid before creating a GemPages theme page. [HTML→GemPages pipeline · push] Must be called first — do not create anything if `themePageValidateHandle.isValid` is false.
gempages_validate_page_handle
Gets the GemCommerce shop profile for the store the user wants to work on: shopId, shopifyDomain, published GemPages themeID, and consentState. For a new shop-linked request containing a Shopify Admin URL (admin.shopify.com/store/<store-handle>/...), derive <store-handle>.myshopify.com from the path and call get_shop immediately with domain. Do not fetch the URL or call gempages_list_connected_shops, who_am_i, skill discovery/fetch, or ask first. Call after the user provides a Shopify domain/shopId, chooses one from gempages_list_connected_shops, wants to switch stores, or before pushing a page. After add_shop(otp), call this only if the flow specifically needs shopifyDomain/themeID — add_shop already returns shopId + consentState. If the store is not connected (GemPages not installed there), returns a Shopify app install link instead of shop fields — ask the user for another Shopify domain or GemCommerce shopId, or to install/reinstall GemPages; do not call gempages_list_connected_shops for this request.
get_shop
Lists the GemPages shops already connected to this MCP, so the AI can select the target shop for a new shop-linked request. Before calling, parse any user-provided Shopify product URL. For https://admin.shopify.com/store/<handle>/products/..., derive <handle>.myshopify.com; for https://<store>.myshopify.com/products/..., use the URL hostname. If the user provides a Shopify domain or either URL yields one, never call this tool; call get_shop({domain: "<shopify-domain>"}) instead. Call immediately as an internal preflight only when the current user message has no GemCommerce connect code, explicit Shopify domain, or GemCommerce shopId. It takes no arguments and no shopId header. Returns shops[]; each entry has shopId and may include shopDomain/displayName. Handle the result: if autoDetectionFailed is true, ask the user to reconnect or refresh GemCommerce MCP auth, then retry; if one shop is returned, call get_shop with its shopId; if multiple shops are returned, ask the user to choose only from those shops, showing shopDomain/displayName when available, otherwise shopId; if none are returned, ask for a Shopify domain, GemCommerce shopId, or connect code.
gempages_list_connected_shops
Records the user's Yes/No answer to the data-collection consent question ("Would you be willing to let us collect data from your GemPages MCP sessions to improve the product?") for one store. Call ONLY right after the user explicitly answers Yes or No to that question; never call it for skip/defer/unclear answers, speculatively, or on the user's behalf. Pass shopId and allowed (true = user said Yes, false = user said No). Persists per (user, shopId) in userMeta key mcp_{shopId}. Returns { shopId, consentState } — mirror consentState into activeShop/current_active_shop.json. A refused answer does not block the requested flow; it only means the later open/review feedback step must skip save/rate collection.
gempages_set_consent
Saves output feedback for CONTENT_RESEARCH, HTML_GENERATION, or TEMPLATE_CONVERSION, in one call. Pass flowKey, rating, contentLength (the ZIP's exact byte size), optional comment, and that flow's flowData — productResearch for CONTENT_RESEARCH, htmlGeneration for HTML_GENERATION. One call submits the rating AND returns uploadURL + outputId when the flow supports capture. If uploadURL comes back, PUT the ZIP to it with Content-Type: application/zip and exactly the Content-Length declared here; the URL is signed for both, so a re-created ZIP is rejected. The PUT completes the capture — there is no follow-up call. Never Base64-encode or pass ZIP bytes to this tool.
gempages_save_and_rate_flow_output
Retrieves the current authenticated GemCommerce user. Does not require shopId (scoped to the authenticated user).
who_am_i

FAQs