Convert MCP Server — Prompt Templates

Ready-to-use prompt templates for the Convert MCP server, organized by workflow. Derived from real-world usage by Hype Digital (strategy & analysis) and Optiphoenix (developer workflows).

How to Use These Templates

  • Prerequisites: Convert MCP server installed and configured in your AI client (Claude Desktop, Cursor, etc.). See setup guide.
  • Replace placeholders: in [brackets] with your actual values.
  • Access level required: is noted for each template: reporting, readOnly, or all.
  • Templates are grouped by persona: Strategist/Analyst, Developer, and Cross-functional.

Part 1: Strategist & Analyst Templates

These templates support the "learning system" workflow described by Hype Digital — shifting from isolated test reporting to compounding strategic insight.

Reporting

Template 1.1 — Experiment Portfolio Summary

When to use:

Monthly or quarterly reviews. Getting a high-level picture of what's been running, what's concluded, and what the outcomes were.

Summarize all experiments in project [PROJECT_ID] from the last [TIME_PERIOD, e.g., "90 days" or "Q1 2026"].

For each experiment, show:
- Name
- Status (active, paused, completed)
- Type (A/B, MVT, Split URL)
- Duration (start → end or start → today)
- Primary goal and whether it reached statistical significance
- Winning variation (if applicable) and observed lift
- What action was taken as a result of the experiment being run

Then provide a brief overall summary: how many tests ran, how many reached significance, and what the overall win rate was.
Reporting

Template 1.2 — Cross-Experiment Pattern Detection

When to use:

After a batch of tests has concluded. Looking for recurring themes in what works and what doesn't.

Pull all completed (statistically significant) experiments in project [PROJECT_ID] from the last [TIME_PERIOD].

Group them by:
1. Page or funnel stage tested (e.g., homepage, product page, pricing page, checkout)
2. Type of change (copy, layout, CTA, social proof, pricing, navigation)
3. Outcome (significant win, significant loss, inconclusive)

Then identify:
- Are there patterns in what types of changes tend to win on specific pages?
- Are there patterns in what consistently fails?
- Which page or funnel stage has the highest density of inconclusive results (possible signal of insufficient traffic or weak hypotheses)?

Present findings as a pattern analysis, not just a data table.

Don't fill in gaps with guesses. Only rely on actual experiment results.
Reporting

Template 1.3 — Failed Test Analysis

When to use:

Extracting learning from tests that didn't win. This is where most CRO programs leave value on the table.

Show me all experiments in project [PROJECT_ID] from the last [TIME_PERIOD] that either:
- Lost (statistically significant negative result), or
- Were inconclusive (did not reach significance)

For each, show the experiment name, what was being tested, the primary goal, the observed effect (even if not significant), and how long the test ran.

Then analyze:
- Were any inconclusive tests underpowered (ran for too short a time or had too little traffic)?
- Do the losing tests share common themes (e.g., all involved removing content, all targeted mobile, all changed pricing)?
- Are there tests that showed a small positive directional trend but didn't reach significance — candidates for re-testing with more traffic or a refined hypothesis?
- Review segments available. Did any tests reverse in trend (results) for specific segments?
Reporting

Template 1.4 — Audience Segment Performance Comparison

When to use:

Understanding whether test results vary by audience segment. Critical for determining if a "winner" is actually universal or segment-specific.

For experiment [EXPERIMENT_NAME_OR_ID] in project [PROJECT_ID]:

Break down results by the available audience segments. Show conversion rate, lift vs. control, and significance status for each segment.

Specifically, I want to know:
- Did mobile and desktop audiences respond differently?
- Were there segments where the variation won but others where it lost or was flat?
- Is the overall result being driven by one dominant segment, or is it consistent across segments?

If post-segmentation data is limited, tell me what's available and what isn't.
Reporting

Template 1.5 — Hypothesis Quality Audit

When to use:

Periodic review to assess whether your team is generating good hypotheses, based on actual test outcomes.

Pull all experiments from project [PROJECT_ID] over the last [TIME_PERIOD, e.g., "6 months"].

For each experiment, show:
- The experiment name and description (which typically contains the hypothesis)
- The primary goal
- The outcome (win/loss/inconclusive)
- The observed lift

Then assess:
- What percentage of experiments had clear, specific hypotheses in their descriptions vs. vague ones (e.g., "test new homepage" vs. "adding urgency messaging above the fold will increase add-to-cart rate by 5% for mobile users")?
- Is there a correlation between hypothesis specificity and test success rate?
- Which hypotheses led to the largest lifts — what do they have in common?
Reporting

Template 1.6 — Pre/Post Comparison (Before and After a Major Change)

When to use:

When a site redesign, replatform, or major feature launch has occurred and you want to compare experiment performance on either side of that event.

I need to compare experiment performance before and after [EVENT, e.g., "our site redesign on March 15, 2026"].

For project [PROJECT_ID]:
- Pull all completed experiments from [DATE_BEFORE_START] to [DATE_BEFORE_END] (the "before" period).
- Pull all completed experiments from [DATE_AFTER_START] to [DATE_AFTER_END] (the "after" period).

Compare:
- Win rate (% of tests reaching statistical significance with positive lift)
- Average observed lift in winning tests
- Average test duration to reach significance
- Types of tests being run (did the testing strategy shift after the change?)

Highlight any notable differences and flag if sample sizes make comparison unreliable.
Reporting

Template 1.7 — Active Experiment Health Check

When to use:

Weekly check-in to ensure running experiments are healthy and on track.

Show me all currently active experiments in project [PROJECT_ID].

For each, show:
- Name, start date, days running
- Traffic allocation (and whether it looks balanced — flag any potential sample ratio mismatch)
- Conversion rate per variation so far
- Whether the test is trending toward significance or appears flat
- Any experiments that have been running for more than [THRESHOLD, e.g., "30 days"] without reaching significance

Flag any experiments I should consider pausing or extending, and explain why.

Part 2: Developer Workflow Templates

These templates support the Optiphoenix workflow — building, configuring, and deploying experiments via the MCP server from within an IDE.

All

Template 2.1 — Create an A/B Experiment

When to use:

Pushing a fully coded experiment into Convert after development is complete.

Create a new A/B test in account [ACCOUNT_ID], project [PROJECT_ID] with the following configuration:

- Name: [EXPERIMENT_NAME]
- Description: [HYPOTHESIS_OR_BRIEF]
- URL: [TARGET_PAGE_URL]
- Status: draft
- Traffic distribution: [PERCENTAGE, e.g., "100"]

Variations:
1. Control
   - Name: "Control"
   - Is baseline: true
   - Traffic distribution: [e.g., "50"]
   - Code: (no changes)

2. Variation 1
   - Name: "[VARIATION_NAME]"
   - Is baseline: false
   - Traffic distribution: [e.g., "50"]
   - JS: [PASTE_OR_REFERENCE_JS_CODE]
   - CSS: [PASTE_OR_REFERENCE_CSS_CODE]

Goals: [LIST_GOAL_IDS, e.g., "1002467, 1002468"]
Primary goal: [PRIMARY_GOAL_ID]
Audiences: [LIST_AUDIENCE_IDS]
Locations: [LIST_LOCATION_IDS]
Reporting

Template 2.2 — List Available Goals and Audiences

When to use:

Before setting up a new experiment — checking what goals and audiences already exist in the project so you can reference them by ID.

For project [PROJECT_ID] in account [ACCOUNT_ID]:

1. List all available goals. Show each goal's ID, name, and type.
2. List all available audiences. Show each audience's ID, name, and targeting conditions.
3. List all available locations. Show each location's ID, name, and URL pattern.

I need these IDs to configure a new experiment.
All

Template 2.3 — Update an Existing Experiment

When to use:

Modifying a draft or paused experiment — e.g., adjusting traffic split, swapping variation code, or changing goals.

Update experiment [EXPERIMENT_ID] in project [PROJECT_ID]:

Changes to make:
- [DESCRIBE CHANGES, e.g., "Change traffic split to 70/30 (control/variation)"]
- [e.g., "Replace the variation JS with the following code: [PASTE_CODE]"]
- [e.g., "Add goal ID [GOAL_ID] as a secondary goal"]
- [e.g., "Change status from draft to active"]

Confirm the changes before applying.
Reporting

Template 2.4 — Bulk Experiment Status Check (for QA)

When to use:

During QA, verifying that experiments are configured correctly before going live.

For project [PROJECT_ID], show me all experiments currently in "draft" status.

For each, show:
- Experiment name and ID
- Number of variations and their names
- Traffic split across variations
- Goals attached (list names and IDs)
- Audiences attached
- Locations (URL targeting)
- Whether global JS or global CSS is set

Flag any experiments that are missing:
- Goals
- Audiences
- Locations
- Or have only one variation (no control or no challenger)
Read Only

Template 2.5 — Retrieve Experiment Code for Review

When to use:

Pulling back the JS/CSS that was pushed to Convert, for code review or to sync back to the local repo.

For experiment [EXPERIMENT_ID] in project [PROJECT_ID]:

Show me the full configuration including:
- All variation names, IDs, and their JS and CSS code
- Global JS and global CSS (if any)
- Targeting conditions (audiences and locations)
- Goals and primary goal

I want to verify this matches what's in our local codebase.
All

Template 2.6 — Pause Underperforming Experiments

When to use:

Routine maintenance — stopping experiments that have run too long without results or are showing harmful trends.

In project [PROJECT_ID], find all active experiments that meet ANY of these criteria:

1. Running for more than [DAYS, e.g., "45"] days without reaching statistical significance
2. Showing a statistically significant negative lift on the primary goal
3. Have a sample ratio mismatch (traffic split is off by more than 2% from the configured allocation)

For each matching experiment, show me the name, days running, current results, and the issue detected.

Then ask me to confirm before pausing any of them.

Part 3: Cross-Functional Templates

Useful for anyone — strategists, developers, and managers alike.

Reporting

Template 3.1 — Search the Convert Knowledge Base

When to use:

Anytime you have a "how do I..." question about Convert. The MCP server's built-in knowledge base (5,279+ indexed documentation chunks) can answer without leaving the conversation.

Search the Convert knowledge base for: [YOUR QUESTION]

Examples:
- "How do I set up revenue tracking for a Shopify store?"
- "What's the difference between sequential testing and fixed-horizon in Convert?"
- "How do I configure cross-domain tracking?"
- "What are the body schema requirements for creating an experiment via the API?"
Reporting

Template 3.2 — Experiment Velocity Report

When to use:

Reporting to leadership on the team's experimentation pace and productivity.

For project [PROJECT_ID], generate an experimentation velocity report for [TIME_PERIOD]:

Include:
- Total experiments created
- Total experiments that went live
- Total experiments completed
- Average time from creation to launch
- Average time from launch to conclusion (significance or manual stop)
- Experiments currently in draft (backlog size)
- Experiments currently active

Compare to the previous [TIME_PERIOD] if data is available. Are we testing more or less? Faster or slower?
Read Only

Template 3.3 — Full Project Audit

When to use:

Onboarding onto a new account or project. Getting a complete picture of what exists.

Give me a full audit of project [PROJECT_ID] in account [ACCOUNT_ID]:

1. Project settings: name, domain(s), active integrations
2. Experiments: total count by status (draft, active, paused, completed, archived). List the 5 most recently active.
3. Goals: total count, list all with names and types
4. Audiences: total count, list all with names and brief targeting descriptions
5. Locations: total count, list all with URL patterns
6. Any feature flags configured

I'm getting oriented on this project — give me the lay of the land.
Reporting

Template 3.4 — Competitor Benchmarking Prep

When to use:

Before competitive analysis. Pulling your own experiment data to compare against industry benchmarks.

For project [PROJECT_ID] over the last [TIME_PERIOD]:

Give me the following metrics:
- Total experiments completed
- Win rate (% of tests with statistically significant positive lift)
- Average lift in winning experiments
- Average test duration (days)
- Most-tested page or funnel stage
- Most common experiment type (A/B vs. MVT vs. Split URL)

I'll use these as internal benchmarks to compare against industry data.

Appendix: Cursor Rules File for Developer Workflows

If you're using Cursor, paste this into a .cursorrules file at your workspace root to standardize how the AI builds Convert experiments. Adapted from the Optiphoenix workflow.

## A/B Test Automation: General Workflow and Standards

### Inputs the AI must collect from the user
- **Experiment name**: UPPERCASE with underscores (e.g., `MT_01`, `UL_65`)
- **Test brief**: What needs to be changed and why
- **Control HTML**: Pasted markup or a URL to fetch and parse
- **Key selectors (optional)**: Prefer these if provided; otherwise derive from control HTML

### Output directory structure
EXPERIMENT_NAME/
├── src/
│   ├── config.js        # Selectors, html, text, styles
│   ├── utils/           # Shared utilities (optional)
│   └── v1/
│       ├── v1.js        # Main experiment logic
│       └── v1.css       # Styles
└── dist/                # Compiled output (optional)

### Coding standards
- **Naming:** Experiments: UPPER_CASE. CSS classes: lowercase with experiment prefix. Functions/variables: camelCase.
- **JavaScript:** Use const/let (never var). Arrow functions where suitable. querySelector/querySelectorAll for DOM. insertAdjacentHTML or insertAdjacentElement (never innerHTML or createElement).
- **Styles:** Class-based (no inline). Media queries for responsiveness. Body class scoped to experiment name.

### Automation flow
1. Collect inputs (experiment name, brief, control HTML, selectors)
2. Parse control HTML → identify targets → derive selectors if missing
3. Create folder structure and boilerplate files
4. Implement variation logic in src/v1/v1.js
5. Add styles in src/v1/v1.css
6. Build into dist/ (optional)
7. Summarize changes and next steps for QA

### Convert MCP deployment
After code review and QA, use the Convert MCP to:
1. List available goals, audiences, and locations for the target project
2. Create the experiment with the approved JS/CSS as variation code
3. Verify the configuration matches the local codebase
Notes
  • All templates assume the Convert MCP server is running and authenticated. See setup guide.

  • Templates marked all require write access. Start with reporting and escalate only when needed.

  • For best results, use models with strong agentic capabilities (Claude Sonnet 4.5+, GPT-5+) with extended thinking enabled.

  • These templates are starting points. Customize the placeholders, combine templates, and iterate based on your team's workflow.

Start your 15-day free trial now.
  • No credit card needed
  • Access to premium features
You can always change your preferences later.
You're Almost Done.
What Job(s) Do You Do at Work? * (Choose Up to 2 Options):
Convert is committed to protecting your privacy.

Important. Please Read.

  • Check your inbox for the password to Convert’s trial account.
  • Log in using the link provided in that email.
  • To ensure you receive your 30-day trial from our ambassador, please use the same browser to claim your account.

This sign up flow is built for maximum security. You’re worth it!