Lupper

Check a flow without saving it. Returns problems and what would block it from starting. Saves nothing. Needs write access because it is sent as a POST.

List the company's brand kits (separate brands or profiles, each with its own logo, colors and fonts). The default kit is marked. Use a brand_key from this list with lupper_branding and lupper_email_drafts_create. Read-only.

The company's brand identity: primary/secondary/accent colors, color palette, fonts, tone of voice, brand context (what the company sells or does), and logo. Call this before writing or designing an email so copy matches the tone and the design matches the brand. Pass brand_key for a specific brand kit when the company has several (see lupper_brand_kits). Read-only.

Runs every check a send would run (verified sending domain, spam score, footer and legal info, billing, quota, audience, content, compliance) for one email or SMS campaign draft, and tells you what blocks it. Sends nothing and changes nothing.

Campaigns synced from connected tools (such as Rule) and paid ads, with reporting fields. For email that Lupper sent, use lupper_email_campaigns. Without id: list them; from and to keep campaigns sent in that range. With id: one campaign (view "details", default) or the purchases and revenue attributed to it (view "conversions": conversions, revenue, average order value, conversion rate, currency, a short sample of orders without customer details). Read-only.

Companies this connection may use. Pass one of these ids as company on other tools when more than one is listed.

Use this before you create or change an email, template, product block or automation flow: call it with topic "guide" first and follow it (allowed blocks, workflow, rules, defaults). Other topics: design (look and copy), email_html (Outlook, dark mode, HTML), product_feeds (personal products and the product loop), merge_tags (valid variables), flows (flow steps, timings, defaults), onsite (popups, flyouts, bars and embedded forms: read before lupper_onsite_drafts_create). Use it also before you build or change a segment, add or import profiles, change consent, choose transactional or marketing, or explain campaign and flow results: call it with topic "audiences" first and follow it. Its topics: segments (rules, operators, fields, recipes), consent (consent states, upsert and CSV import, SMS, GDPR requests, why someone did not get an email), reporting (units, opens vs Apple privacy-proxy opens, attribution, deliverability, flow funnels). Without a topic it tells where the Lupper public API is documented and what this MCP connection can do. Read covers campaigns, reporting (account email/SMS, automation analytics, conversions), segments, profiles (timeline, orders, consent, GDPR export), templates, onsite, SMS drafts/analytics, and send-request status. Write (OAuth lupper:write, or lupper:write:<area> for one area only: profiles, segments, email, sms, automations, events, suppressions; or an API key) can update profiles/events/suppressions, save email or SMS drafts, create/update segments and members, and create a send approval request. An API key is required to delete profiles, import CSV, start automations, manage webhooks, and read audit logs (admin); those tools are only listed on API-key connections. No tool sends email or SMS directly: use lupper_campaign_preflight then lupper_request_send; a human must approve in the Lupper UI.

Results of email that Lupper sent (campaigns and automation emails). Without id: list them with sent, opened and clicked counts, newest first; from and to keep campaigns sent in that range; drafts are left out (use lupper_email_drafts). With id, view picks the report: "report" (default: delivered, unique and total opens and clicks, bounces, complaints, unsubscribes, clicked links; rates are fractions 0 to 1 on delivered), "stats" (condensed: audience, deliverability, top links, A/B results, inbox providers), "links" (clicks per link), "recipients" (who received it and what they did; contains email addresses, which is personal data; filter with status, url or q, paged with page and page_size), "conversions" (purchases and revenue attributed to it, no customer details), "send_history" (day by day results for a campaign that sends repeatedly, from and to as range, max 60 days). Read-only.

Copy an existing email so it can be changed without touching the original. Pass a draft or a template id and choose what to make: a new draft (default) or a new template. Content, subject, preheader, brand kit, A/B variant and translations are copied; nothing is sent, and a copy of a sent email starts as an ordinary draft. Use it to reuse last month's email, to turn a good draft into a template, or to start from a built-in template. Then change the copy with lupper_email_drafts_update or lupper_email_templates_update.

Email drafts. Without id: list the drafts (id, name, subject, audience, last change); sent emails are not listed here, use lupper_email_campaigns. With id: read one email as it is built: subject, preheader, and an outline of every section and block. An id also works for an email that was already sent (ids from lupper_email_campaigns), so use it to study how the company's earlier emails are structured before writing a new one in the same style. Use "outline" to see how the email is built (sections, columns, blocks, text, links, images). Pass include_document: true only if you need the raw editor JSON. Read-only. Does not create or send.

Save a new email draft in the visual editor as sections of blocks. Needs write access. Does not send. A person reviews it in the editor, where every block can be edited. To match the company's style, read an earlier email with lupper_email_drafts (ids from lupper_email_campaigns) or a template with lupper_email_templates. Call lupper_branding first to get the brand tone of voice, colors and logo; the draft is styled with the brand colors automatically (pass brand_key to use one of lupper_brand_kits). Make the logo the first section: a centred image block with src = logo_url and the company name as alt (review warns with brand_logo_missing when it is absent). Build a full campaign, not a stub: logo, hero image, headline with a short intro, products, one proof or story section from real facts, a button and a closing line. Look at the company's recent sent emails first (lupper_email_campaigns, lupper_email_preview) and match their structure and tone. Fitting emojis are fine in subject, preheader and headline when the brand voice is warm. Build a designed email, not a block of text. Put prices and products in product cards, never in paragraph text. Typical order: hero image, h1 heading, one short intro paragraph, a "products" section, button, divider, then a closing text. Sections are "layout" (1 to 4 columns of blocks) or "products" (product cards from the catalog: call lupper_products first and pass platform_product_id values; names, prices, images and links are filled in from the catalog). A "products" section can be dynamic: pass dynamic_feed (strategy, categories, brands, in_stock_only, time_window_days for best sellers, exclude_purchased, exclude_purchased_days) and each recipient gets their own products when the email is sent or previewed; platform_product_ids are then the fallback. For a design you already have as code, use a section of kind "html" with your own HTML (a full document or just the body, up to about 150 KB). It stays an editable HTML block in the visual editor, merge tags work, and a product loop works inside it: {{#each products strategy="best_sellers" limit="4" categories="Shoes" brands="Nike" window_days="30" exclude_purchased_days="60"}}...{{product.name}} {{product.price}} {{product.url}} {{product.image_url}}...{{/each}}. HTML drafts can never be activated or sent from here; sending still needs lupper_campaign_preflight and lupper_request_send, which a person approves. Only these blocks exist: text, image, button, divider, spacer, social, video, navbar, html, rss, calendar-button, article-card, podcast-episode, coupon. Use html only when nothing else fits. Use real https URLs. Do not invent images, prices or links. Every image must be hosted by Lupper: copy a web address, or an image the user attached or that was made in this chat, into the company library first with lupper_images_upload (pass `image` for a chat file, `url` for a web address) and use the returned url. Set the colors behind the email with `theme` (background_color is the outer page, content_background_color is the email column); a single section can override with its own background_color. Reuse the company's saved sections (footer, banners) via lupper_email_saved_blocks. Check "review" in the result and fix problems with lupper_email_drafts_update. The reply shows the saved email to the user. To see it yourself, call lupper_email_preview in the next step (never in parallel): it returns a picture of the rendered email. Use lupper_email_test_send if they want it in their own inbox.

Change an email draft that has not been sent. Needs write access. Read it first with lupper_email_drafts. Pass only what changes. To change part of the body use `edits`: each edit points at a block or section id from lupper_email_drafts (replace_block, patch_html, insert_block_after, delete_block, insert_section_after, delete_section, move_section). To change a few lines inside an html block use patch_html (exact find and replace; read the code first with lupper_email_drafts and html_block_id) instead of sending the whole block again. Everything not mentioned stays as it is, so prefer `edits` over `sections`. `sections` replaces the whole body, and `edits` can delete blocks or sections, so this overwrites saved content. Same block rules as lupper_email_drafts_create. Does not send. The reply shows the saved email to the user. To see it yourself, call lupper_email_preview in the next step (never in parallel with this): it returns a picture of the rendered email.

Show an email as it will look in an inbox, and LOOK at it. The reply includes two pictures of the rendered email (images you can see): first desktop, then phone, in the order of `screenshots`. Use them to check the result on both: alignment, spacing, a product loop that did not fill, missing or broken images, text on top of images, dark mode. Call it in the step after every create or update, before you hand over, and fix what you see with lupper_email_drafts_update. Long emails are read in parts: when a screenshots entry has has_more true, call again with that view and offset_px = its next_offset_px. Set dark_mode true for dark mode, or view "desktop" / "mobile" for one picture. Merge tags render with example data, so prices and names are samples. In ChatGPT and other apps that support it, the rendered email also appears inline for the user with a desktop and mobile view; everywhere else tell the user to open preview_url (works without logging in for one hour). Works for a draft, a sent email, or a template. Also checks the final HTML: size (Gmail cuts mail above about 102 KB), images without alt text, empty links and merge tags that were not filled. Do not call this in parallel with a save: that shows the email from before the save. Set screenshot false to skip the picture and get only the checks. Read-only.

List the company's saved email blocks and sections: the building pieces people saved in the editor, such as a footer, a free-shipping banner or a product row. Each has an id, a kind (section or block), a short outline of what it contains and a sync mode: "universal" content stays linked, so when it is changed in the app every email using it follows; "snippet" is a plain copy. Reuse them with lupper_email_drafts_update or lupper_email_templates_update using the edit { op: "insert_saved", saved_id, after_id }, so emails stay on-brand and consistent. Read-only.

Save a section or a block of an existing email to the company's library so it can be reused. Read the email first (lupper_email_drafts or lupper_email_templates) and pass the id of the section or block to save. Choose sync "universal" for content that must stay identical everywhere and be updated in one place (footer, legal text, shipping banner), or "snippet" (default) for a starting point that each email may change. The original email is not changed. Publishing later changes to universal content is done in the Lupper editor. Needs write access.

Email templates. Without id: list templates so a draft can start from one (id, name, subject). With id: read one template as it is built, so a new draft can follow the company's own template design. Use "outline" to see how the email is built (sections, columns, blocks, text, links, images). Pass include_document: true only if you need the raw editor JSON. Read-only. Does not send.

Save a new email template in the visual editor. Needs write access. Same sections and blocks as lupper_email_drafts_create (hero image, h1, short intro, products section, button, divider, closing text). A template is only a design to start drafts from; it never sends anything. In a template, keep text generic and use merge tags such as {{profile.first_name}} instead of a real recipient. Read an existing template or email first (lupper_email_templates, lupper_email_drafts) to match the company's style, and call lupper_branding for colors and tone. Check "review" in the result. The reply shows the saved template. Do not call lupper_email_preview in parallel with this.

Change one of the company's own email templates. Needs write access. Built-in templates cannot be changed; create a new one instead. Read it first with lupper_email_templates. Pass only what changes. To change part of the body use `edits` (replace_block, patch_html, insert_block_after, delete_block, insert_section_after, delete_section, move_section) with block and section ids from the outline; to change a few lines inside an html block use patch_html (exact find and replace, read the code with html_block_id first) instead of sending the whole block again; everything not mentioned stays as it is. `sections` replaces the whole body. Same sections and blocks as lupper_email_drafts_create (hero image, h1, short intro, products section, button, divider, closing text). A template is only a design to start drafts from; it never sends anything. In a template, keep text generic and use merge tags such as {{profile.first_name}} instead of a real recipient. The reply shows the saved template. Do not call lupper_email_preview in parallel with this.

Send one test of a saved email to the person who is connected, so they can see it in their own inbox. Works for a draft and for a template. Over OAuth the test always goes to the login email of the person who approved this connection; with an API key pass `email`. Merge tags are filled with example data and coupons with a fake code. It counts against the same test-send rate limits as the editor's test button. It reads what is saved, so save changes first. It does not send to any audience.

Read the translations of an email. Without `locale` it lists the languages that exist and how complete each one is. With `locale` (for example "en", "no", "de") it returns every translatable field of the email, in order: subject, preheader, text, button and image alt text, plus links and images, each with the source text, the current translation and a status (missing, stale because the source changed, or current). Translate the fields with status missing or stale and save them with lupper_email_translations_set. Text fields marked html keep their tags; only the words are translated. Read-only.

Save the translation of an email into one language. Read the fields first with lupper_email_translations_get (with locale), translate each source value, then pass them here as { ref, value } using the ref from that result. Pass only the fields you translated; other fields and other languages are kept. Keep html tags, links and merge tags such as {{profile.first_name}} exactly as in the source and translate only the words. Fields of kind url or image may be replaced with another https address for that language. Overwrites earlier translations of the same field. Needs write access. Recipients get the language that matches their profile; the layout is shared, so to change layout edit the email itself.

Record one event. Needs write access. Does not delete events.

List recent events. Does not create events.

Put an image in the company's image library and get back a Lupper-hosted URL. Do this before using an image in an email: a stored image stays online and is resized and optimised for email, while a link to someone else's site can break, get blocked or change. Two sources: `image` is a file from this chat (an image the user attached, or one you generated or edited here), `url` is a public https address of an image file. Pass exactly one. Only JPG, PNG, GIF and WebP are accepted (max about 15 MB; GIFs 3 MB). Pass the returned url as the src of an image block or as image_url of a hero. Needs write access.

List onsite campaigns (popups, flyouts, top bars and embedded forms): name, format, goal, status, views, clicks and sign-ups. Use lupper_onsite_get to see one, and lupper_onsite_stats for views over time. Does not change anything.

Create an onsite campaign as a draft: a popup, a flyout (small card in a corner), a top bar, or an embedded form placed inside a page. Returns a preview card and any problems the review found. This only saves a draft. It is never shown to visitors until a person opens it in the Lupper app, looks it over and sets it live there. You cannot publish it. A campaign is built from steps of blocks: heading, text, image, email_input, phone_input, field_input (first_name, last_name, company, city, birthdate, custom.<key> and so on), consent, sms_consent, choices, button, coupon, countdown, products, spacer, divider. All copy is plain text, never HTML. Colors are 6 digit hex. Links are https or a path starting with /. Call lupper_branding first and use the brand colors and tone of voice; image urls must come from lupper_images_upload; products come from lupper_products; coupon codes must be ones the company has really set up.

Change a draft or paused onsite campaign. Send only what changes: steps replaces all the content, style and targeting change just the fields you give. A live campaign cannot be changed from here. This only saves a draft. It is never shown to visitors until a person opens it in the Lupper app, looks it over and sets it live there. You cannot publish it. A campaign is built from steps of blocks: heading, text, image, email_input, phone_input, field_input (first_name, last_name, company, city, birthdate, custom.<key> and so on), consent, sms_consent, choices, button, coupon, countdown, products, spacer, divider. All copy is plain text, never HTML. Colors are 6 digit hex. Links are https or a path starting with /. Call lupper_branding first and use the brand colors and tone of voice; image urls must come from lupper_images_upload; products come from lupper_products; coupon codes must be ones the company has really set up.

Show one onsite campaign as a preview card: how it looks (desktop and mobile), its steps, when it shows, who sees it, and any problems the review finds. Does not change anything.

Daily onsite views and conversions. from and to are dates such as 2026-03-01. Omit them for the last 30 days. Does not change anything.

List orders for the company. Cap is 50.

List catalog products. Each has a platform_product_id. In ChatGPT the reply shows a picker of up to 8 products (image, name, price). When the user has not named the products, stop after this call and let them tick the picker. The next message lists the chosen platform_product_ids. Pass those ids to a "products" section. Use q so the right products are among the 8 shown.

Read customer profiles. Without id: list profiles (search with q, email or phone; page with limit and offset). Returns personal data. With id: one profile, including its consent. Add include to also read parts of that profile in the same call: "timeline" (recent events, site visits and email activity, newest first, with type, time, source and a few properties), "orders" (newest first, with status, total and line items; open carts included), "segments" (which segments and static lists it is in, with type and when it joined), "automations" (automation runs: which automation, what step, outcome), "export" (everything held about the person for a data access request: full profile, events, site visits, orders, customer records, identity links and list memberships; every export is written to the audit log; share it only with the person it is about). Only ask for what you need. limit caps the rows of timeline, orders and automations (default 25, max 100); per_section caps each long section of export (default 25, max 100). Read-only. Does not change anything. To add or remove someone from a static list use lupper_segments_members_add or lupper_segments_members_remove; to switch consent use lupper_profiles_consent.

Switch email or SMS marketing consent on or off for one existing profile. The change is recorded on the profile's timeline with this connection as the source. Switching consent OFF is always allowed and needs no confirmation. Switching it ON is only for a person who has actually agreed: set consent_basis_confirmed to true to say so. Someone who unsubscribed, opted out, or whose address bounced cannot be switched back on. To block an address from every send, use lupper_suppressions_create instead. Needs write access. It does not delete the profile.

Create a profile. Needs write access. Does not delete.

Update one profile by id. Replaces the fields you send. Needs write access.

Create a profile, or update it when one with the same email already exists. Send only the fields you want to set. Custom attributes are merged into the profile's custom_fields. It can also put the profile on existing static lists (segment_keys). Needs write access. Only set consent_marketing or consent_sms to true when the person has actually agreed, for example by signing up, and then also set consent_basis_confirmed to true. A person who unsubscribed or whose address bounced cannot be switched back on this way. It does not delete anything and does not send email.

Asks for a campaign draft to be sent. This only creates a pending request. Nothing is sent until a person approves it in the Lupper app, and an agent cannot approve. Runs the preflight first and creates nothing if anything blocks the send. Returns a link for the person to open.

Read segments and static lists. Without key: list them with name, status and size. With key, view picks what to read: "details" (default: the segment and its rule), "members" (the profiles in it: id, email and name, which is personal data; one page at a time with limit and offset, or search by email, name, phone or id), "history" (recent changes to who is in it, newest first, at most 50 per call, with time, profile id and email, plus the latest sync runs; use page to go further back), "compute_status" (whether a dynamic segment is being recalculated right now, when it last finished and whether the last run failed; use it after lupper_segments_create or lupper_segments_update said the calculation was still running). Read-only. Does not change membership or start a calculation.

Create a segment. A dynamic segment is filled by a rule and kept up to date automatically. A static list starts empty and is filled with lupper_segments_members_add. Needs write access. The rule is checked against this company's real fields, so call lupper_segments_fields and lupper_segments_preview_count first. It does not send to or sync with any ad platform, and it does not add profiles to a dynamic segment by hand.

What segment rules can use in this company. Without field: list the fields grouped by category, with the type and allowed operators of each. The category "order_data" holds this company's own order and order-line attributes (order_meta.* and line_item.*, such as resort, supplier, or cruise line); list fields (string type) accept the operators in_any and not_in_any with an array of values. With field and category: list the distinct values that field has, to pick real values for a rule, for example country codes, order statuses, product names, or any order_data field such as a resort or cabin, or tracked-event filter values (field country, region, city, page_url, source, utm_source, utm_medium or utm_campaign with the matching category event_dimension, behavior or event). Fields named tracking_event.<event_type> are "has done event" conditions, and custom_fields.<key> are the company's own profile attributes. For purchased products and order_data fields the values come from real purchased orders and the count is the number of orders; for other fields it is the number of profiles. Order data is paged: pass limit and offset, and check meta.has_more. Pass include_facets to also get other order-line attributes you can narrow the list by (facet_key plus facet_value, for example product_type = Accommodation). Call this before you build or change a rule with lupper_segments_preview_count, lupper_segments_create, or lupper_segments_update. Read-only. It does not read any profile data.