Sagen Sie Ihrem Agenten, er soll den Test durchführen

Set up Mida A/B testing in this project. Work through these in order, and stop to ask me whenever something is ambiguous.

1. Check I have a Mida account. If I do not, send me to https://app.mida.so/sign-up and wait for me to finish — creating the account is my job, not yours.

2. Connect the Mida MCP server so you can read and write my experiments directly. The endpoint is https://mcp.mida.so/mcp over streamable HTTP with browser authorization. In Claude Code: claude mcp add --transport http mida https://mcp.mida.so/mcp
   Once connected, call select_project before any other Mida tool, or every call returns 404. list_projects returns a project_key for each of my projects — that value IS the key the tag needs in step 3, so read it from there rather than asking me to copy it out of the dashboard.

3. Work out where this site actually lives before you change anything: a codebase you can edit, or a hosted platform I log into. Check the repo if there is one, and check the live page. Tell me what you found.

4. Get the tag from Mida rather than assembling it. Call the get_install_snippet MCP tool — it returns the finished tag with the region-correct host and my real project key already substituted, and you paste that exactly. This is the shape, not the value:
   <script type="text/javascript" async src="https://CDN_HOST/js/optimize.js?key=PROJECT_KEY"></script>
   CDN_HOST is cdn-eu.mida.so for an EU account and cdn.mida.so otherwise. The tag reads its API region from the host it was loaded from, so a hand-assembled tag with the wrong host installs cleanly and then silently finds no experiments. If that tool is not available, take the whole snippet from the install page in my dashboard, or ask me which region I am on.

5. Install it the way that suits where the site lives, and tell me which path you took and why:
   - A codebase: put the tag in <head>, as high as possible, and do not defer it — variants have to apply before first paint or the page will flicker. On server-rendered pages where you want zero flicker, use a server-side SDK instead — mida-node, mida-nextjs, mida-php, or mida-python. Docs: https://docs.mida.so/docs/server-side/sdks
   - A hosted platform that has its own MCP server: connect it and install through it, so I never have to paste code. Prefer the platform's remote MCP endpoint with browser authorization over a local setup with an API token — some platforms only allow their custom code endpoints for apps authorized that way, so a token setup can fail on the exact call you need. Register the tag as site-wide custom code in the head, apply it to the site, then publish if that platform needs a publish for custom code to go live. Ask me first if the site is live.
   - A hosted platform with no MCP server: do not try to click your way through the admin UI. Tell me exactly where the tag goes on that platform, give me the tag, and wait for me.

6. Verify it before you call this done. Load a page and confirm the script fetches, the project key is correct, and a pageview reaches Mida. If a tag manager, a consent gate, or a script optimizer such as WP Meteor is rewriting or deferring the tag, say so plainly — any of those will silently stop it working.

7. Do not create a test yet. Report what you installed, then ask me what I want to test first. When I tell you, build it from selectors you have read in my actual markup — never guess at something like "h1".

I want to move this project off its current A/B testing tool and onto Mida. Plan it first — do not change any code yet.

1. Find what is running now. Search the codebase and the rendered <head> for VWO, Optimizely, Convert, AB Tasty, Kameleoon, Google Optimize leftovers, GrowthBook, Statsig, Split, and any homegrown flag code. Check the tag manager container too — a lot of tests live in GTM rather than in the repo. List every file, snippet, and container tag you find.

2. Inventory the experiments, not just the tool. For each live test, tell me: which pages it targets, what it changes, what counts as a conversion, the traffic split, and any audience or targeting rules. Read the variant code — rebuilding that is where the real work is.

3. Map each test to a Mida equivalent, and be explicit about what does NOT map cleanly. I would rather see the gaps than have them papered over.

4. Give me a file-by-file plan: what gets removed, what gets added, the Mida equivalent of each test, and the order to do it in so I am never running two testing tools on the same page at once.

Then stop and wait for my go-ahead.

Once I approve:
- Connect the Mida MCP server so you can build the tests directly. The endpoint is https://mcp.mida.so/mcp over streamable HTTP with browser authorization. In Claude Code: claude mcp add --transport http mida https://mcp.mida.so/mcp
- Call select_project before any other Mida tool, or every call returns 404.
- Rebuild each test using selectors you have actually read from my markup. Never guess a selector.
- Leave the old tool's script in place but disabled until I confirm Mida is reporting data, then remove it.

Reference:
- Client-side tag, in <head> and not deferred: <script type="text/javascript" async src="https://CDN_HOST/js/optimize.js?key=PROJECT_KEY"></script>
- CDN_HOST is cdn-eu.mida.so if my account is on the EU region and cdn.mida.so otherwise. The tag derives its API region from that host, so the wrong one silently sends settings requests to the wrong region and no experiment ever loads.
- Do not assemble the tag by hand: once MCP is connected, the get_install_snippet tool returns the finished tag with the correct host and key. If that tool is not available, copy the snippet from the install page in my dashboard, or ask me.
- Server-side SDKs (Node, Next.js, PHP, Python): https://docs.mida.so/docs/server-side/sdks
- No account yet? Sign up at https://app.mida.so/sign-up

Build my first A/B test in Mida, on a page you have actually read.

1. Connect the Mida MCP server if it is not connected: claude mcp add --transport http mida https://mcp.mida.so/mcp
   Then call select_project before any other Mida tool, or every call returns 404.

2. Check the tag is live before you design anything. If Mida is not receiving data yet, stop and install it first — a test on a page with no tag reports nothing and looks like a flat result.

3. Ask me which page matters, then read that page's real markup. Get the selectors from the DOM you fetched, never from a guess. A blind selector like h1 is the single most common way an agent's test silently does nothing.

4. Tell me what you want to change and why before you build it. One change per variant. I want to know which change won, and a variant that moves the headline, the button colour and the layout at once cannot tell me that.

5. Call get_my_testing_history and get_testing_benchmarks first. If I have run this test before, say so instead of proposing it again. If the benchmark for this pattern is weak, say that too.

6. Build it as a draft with create_experiment. Do not start it. Give me a preview URL with generate_preview_url so I can see both arms myself.

7. Tell me how long it will need before it can say anything, based on my traffic and current conversion rate. If that is longer than I will wait, say so now rather than after three weeks of no answer.

Tell me what my Mida tests actually say, and be blunt about the ones that say nothing.

1. Connect the Mida MCP server if needed: claude mcp add --transport http mida https://mcp.mida.so/mcp
   Call select_project first, or every call returns 404.

2. List my running and recently finished experiments, then pull the result for each one.

3. For every test, tell me three things: what changed, what the number is, and whether it is worth acting on yet. Use the statistics Mida returns rather than recomputing significance yourself.

4. Say "not enough data yet" out loud when that is the answer. Do not dress up a coin flip as a winner, and do not call a loser a learning.

5. Flag anything that looks broken rather than merely losing: an arm with no traffic, a goal with no conversions on any arm, a split that is nowhere near what was configured. Those are install or targeting bugs, not results.

6. Then give me the shortlist: which tests to conclude now, which to leave running, and which to kill. One line of reasoning each.