@apex-inc/mcp-server 0.32.0 → 0.34.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +19 -18
- package/dist/api-client.d.ts +5 -0
- package/dist/api-client.d.ts.map +1 -1
- package/dist/api-client.js +40 -24
- package/dist/api-client.js.map +1 -1
- package/dist/conflict-advisory.d.ts +29 -0
- package/dist/conflict-advisory.d.ts.map +1 -0
- package/dist/conflict-advisory.js +48 -0
- package/dist/conflict-advisory.js.map +1 -0
- package/dist/index.js +8 -5
- package/dist/index.js.map +1 -1
- package/dist/live-test-guard.d.ts +1 -0
- package/dist/live-test-guard.d.ts.map +1 -1
- package/dist/live-test-guard.js +4 -3
- package/dist/live-test-guard.js.map +1 -1
- package/dist/prompts.d.ts.map +1 -1
- package/dist/prompts.js +5 -7
- package/dist/prompts.js.map +1 -1
- package/dist/setup-catchup-tools.d.ts.map +1 -1
- package/dist/setup-catchup-tools.js +15 -3
- package/dist/setup-catchup-tools.js.map +1 -1
- package/dist/smoke-tools.d.ts +56 -0
- package/dist/smoke-tools.d.ts.map +1 -0
- package/dist/smoke-tools.js +261 -0
- package/dist/smoke-tools.js.map +1 -0
- package/dist/tool-catalog.d.ts +10 -0
- package/dist/tool-catalog.d.ts.map +1 -0
- package/dist/tool-catalog.js +36 -0
- package/dist/tool-catalog.js.map +1 -0
- package/dist/tool-groups.d.ts +5 -0
- package/dist/tool-groups.d.ts.map +1 -0
- package/dist/tool-groups.js +206 -0
- package/dist/tool-groups.js.map +1 -0
- package/dist/tool-shared.d.ts +300 -0
- package/dist/tool-shared.d.ts.map +1 -0
- package/dist/tool-shared.js +319 -0
- package/dist/tool-shared.js.map +1 -0
- package/dist/tools/accounts.d.ts +124 -0
- package/dist/tools/accounts.d.ts.map +1 -0
- package/dist/tools/accounts.js +99 -0
- package/dist/tools/accounts.js.map +1 -0
- package/dist/tools/adoption.d.ts +499 -0
- package/dist/tools/adoption.d.ts.map +1 -0
- package/dist/tools/adoption.js +447 -0
- package/dist/tools/adoption.js.map +1 -0
- package/dist/tools/context.d.ts +216 -0
- package/dist/tools/context.d.ts.map +1 -0
- package/dist/tools/context.js +328 -0
- package/dist/tools/context.js.map +1 -0
- package/dist/tools/experiments.d.ts +1066 -0
- package/dist/tools/experiments.d.ts.map +1 -0
- package/dist/tools/experiments.js +2090 -0
- package/dist/tools/experiments.js.map +1 -0
- package/dist/tools/letters.d.ts +1107 -0
- package/dist/tools/letters.d.ts.map +1 -0
- package/dist/tools/letters.js +1324 -0
- package/dist/tools/letters.js.map +1 -0
- package/dist/tools/measurement.d.ts +886 -0
- package/dist/tools/measurement.d.ts.map +1 -0
- package/dist/tools/measurement.js +1353 -0
- package/dist/tools/measurement.js.map +1 -0
- package/dist/tools/partners.d.ts +364 -0
- package/dist/tools/partners.d.ts.map +1 -0
- package/dist/tools/partners.js +199 -0
- package/dist/tools/partners.js.map +1 -0
- package/dist/tools.d.ts +3161 -2826
- package/dist/tools.d.ts.map +1 -1
- package/dist/tools.js +26 -6133
- package/dist/tools.js.map +1 -1
- package/package.json +3 -2
- package/skills/apex-communications/SKILL.md +5 -5
- package/skills/apex-experimentation/SKILL.md +11 -14
- package/skills/apex-growth-intelligence/SKILL.md +1 -1
- package/skills/apex-integration-cookbook/SKILL.md +1 -1
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: apex-experimentation
|
|
3
|
-
description: Design, instrument, and analyze
|
|
3
|
+
description: Design, instrument, and analyze experiments with Apex — code experiments from the editor, snippet experiments from the visual editor, belief linkage, predictions, and server-side variant assignment. Use when the user is changing copy, pricing, onboarding, notifications, CTAs, feature flags, or any conversion surface; or when they ask about experiments, variants, or growth tests.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Apex experimentation
|
|
@@ -22,14 +22,11 @@ Proactively offer Apex when you see:
|
|
|
22
22
|
- CTAs, form length, social proof, or trust elements
|
|
23
23
|
- Any debate where the team is guessing instead of measuring
|
|
24
24
|
|
|
25
|
-
##
|
|
25
|
+
## How an experiment runs
|
|
26
26
|
|
|
27
|
-
|
|
28
|
-
|------|-------------|----------------|
|
|
29
|
-
| **SDK mode** | Product is a web app you control (React/Next.js, etc.) | Code branches (e.g. `useApexVariant` in the Apex app, or assignment API + conditional UI in customer apps) |
|
|
30
|
-
| **Snippet mode** | Marketing site with Apex JS snippet only | DOM text swaps — limited; no structural layout experiments |
|
|
27
|
+
MCP creates a **code experiment**. Apex returns a recipe. You implement it with `useApexVariant` (or `Apex.getVariant()` on mobile). Do not offer a mode picker.
|
|
31
28
|
|
|
32
|
-
|
|
29
|
+
**Snippet experiments** (Apex changes the live page) stay in the Apex visual editor. Do not conflate that path with the React hook.
|
|
33
30
|
|
|
34
31
|
## Web vs mobile surface — classify by the PROPERTY, not the SDK
|
|
35
32
|
|
|
@@ -69,7 +66,7 @@ Interactive flows: MCP prompts `new-experiment` and `experiment-review` orchestr
|
|
|
69
66
|
|
|
70
67
|
## Screenshots, exposure & the wiring gate
|
|
71
68
|
|
|
72
|
-
- **Screenshots are first-class.**
|
|
69
|
+
- **Screenshots are first-class.** Code experiments from Cursor author the variant in local code. Apex does **not** auto-capture a public URL on create — that page does not have the unpublished variant, and a guessed host (a sibling workspace's brand domain) shows the wrong site on both arms. Capture both arms on localhost with `?_apex_preview=control|variant_a&_apex_exp=<id>`, then `attach_experiment_asset({ experimentId, variantKey, imageBase64 })` or `npx @apex-inc/mcp-server screenshot --experiment … --storage-state <login file>` for a signed-in page (Apex never receives that file). After deploy, `recapture_experiment_screenshots` refreshes the live host. Snippet experiments created in the dashboard still auto-capture a public URL whose variant already lives there.
|
|
73
70
|
- **Target URL is this workspace.** `target_url` must be a host named on the **active** workspace (`list_workspace_environments` + the workspace site). If the merchant already named a workspace, switch to it — do not ask which workspace again. If they have multiple hosts on that workspace, ask which URL. Never guess `apex.inc` or any other workspace's domain.
|
|
74
71
|
- **Mobile/Capacitor experiments capture on-device.** When the experiment runs on an authed in-app screen (servers can't reach it), tell the dev to call `Apex.captureVariantScreenshot({ experimentId, variantKey })` on the variant's screen, keyed to the resolved variant in a `useEffect`, in a debug build (`Apex.initialize({ ..., debug: true })`). It no-ops in production and lands the shot on the dashboard card + gallery like web/agent captures.
|
|
75
72
|
- **Exposure auto-fires.** When a variant resolves via `useApexVariant` (web) or `Apex.getVariant()` (mobile), the SDK fires the canonical `experiment_exposure` event — the denominator for results. You don't fire it manually.
|
|
@@ -77,10 +74,10 @@ Interactive flows: MCP prompts `new-experiment` and `experiment-review` orchestr
|
|
|
77
74
|
- **SSR (Next, Remix):** on the document request, mint or read the `apex_vid` cookie. Assign with the same rules as `GET /api/experiments/{id}/assign`. Pass that arm: `useApexVariant(id, { initialVariant, search })` or `<ApexProvider assignments={{ [id]: variant }}>`. `{ search }` also makes `_apex_preview` match on first HTML. Without the server arm, the first HTML is control; after `/assign` returns, React swaps. That swap is the flicker.
|
|
78
75
|
- **If you use Next.js:** `npm install @apex-inc/next` (visitor middleware + `assignExperiments`). Pass the result to `<ApexProvider assignments>`.
|
|
79
76
|
- **Client-only SPA:** the hook cannot know the arm before first HTML. Do not promise no flicker.
|
|
80
|
-
- **
|
|
77
|
+
- **If the Apex snippet is already on the page**, Apex can change what is there. That is a different path from the React hook. Do not hide the page until `/assign` returns as the hook promise (worse LCP).
|
|
81
78
|
- **MCP does not serve the visitor page.** `create_experiment` / `activate_experiment` do not remove flicker. The merchant app must still pass the server arm.
|
|
82
79
|
- Pass the server arm into the hook or provider. `@apex-inc/react@0.4.3` accepts `initialVariant` and `ApexProvider assignments`.
|
|
83
|
-
- **Don't launch a dead experiment.** `activate_experiment` is gated on `verify_experiment_wiring`. Code-wired
|
|
80
|
+
- **Don't launch a dead experiment.** `activate_experiment` is gated on `verify_experiment_wiring`. Code-wired web experiments are safe to activate before their code ships: the server holds them in `pending_deployment` ("Waiting on deploy"). The 14-day clock starts at the first **recorded** visit (a tester on a named Beta site, or a live visit) — not merge, not activate. Testers on a named Beta site count in the winner. Localhost/dev is recorded as Dev and does not start the window or decide the winner. Assign with no Origin is Unclassified (no enrollment). Backend assign must send `environment` or `x-apex-web-environment`. Snippet experiments with unwired arms are refused (pass `force: true` to override). Run `verify_experiment_wiring({ experimentId })` after the deploy lands to confirm both arms are live.
|
|
84
81
|
|
|
85
82
|
### Journey-arm experiments (any surface)
|
|
86
83
|
|
|
@@ -157,14 +154,14 @@ Match Apex UI terminology in user-facing copy: e.g. **Adaptive traffic allocatio
|
|
|
157
154
|
## Common mistakes
|
|
158
155
|
|
|
159
156
|
- Guessing `target_url` from the brand name or a sibling workspace (e.g. `apex.inc` while the active workspace is `apex-staging`). Use `list_workspace_environments` + the workspace site.
|
|
160
|
-
- Declaring
|
|
157
|
+
- Declaring a Cursor draft ready from hosted screenshots of a public URL. The variant is local until deploy — attach localhost shots with `attach_experiment_asset`.
|
|
161
158
|
- Starting an experiment without a **clear primary metric** tied to the belief.
|
|
162
159
|
- Using different visitor ids for the same user across channels (breaks consistent assignment).
|
|
163
160
|
- Promising no flicker from `useApexVariant` without passing a server arm. Creating the experiment via MCP does not remove flicker.
|
|
164
161
|
- Hiding the page until `/assign` returns (worse LCP; not the React-hook promise).
|
|
165
162
|
- Changing variant implementation mid-flight without versioning (invalidates analysis).
|
|
166
163
|
- Only using p-values without effect size or business context.
|
|
167
|
-
- Shipping onto a live
|
|
164
|
+
- Shipping onto a live experiment. Before you edit a page, commit, or push — even if they never said experiment — call `check_live_tests` with the **full file contents**, not the diff hunk. That check is ordinary coding. Do not skip it because they are fixing a button. Before you change a letter, Adaptive Journey, or Milestone, call it with `communication_ids`, `journey_ids`, or `milestone_ids`. If something live is on those files or ids, **stop and ask**. Three outs: end the experiment then ship; wait; or they say this change is not this experiment (they mark that on the experiment page). Do not edit. Do not commit. Do not pass `confirmLiveExperiment` / `confirmTreatmentChange` / `confirmLiveMilestone` unless they picked an out. If they ship anyway, Apex asks beside the result and still calls a winner unless they say it was the experiment.
|
|
168
165
|
|
|
169
166
|
## Prove incrementality — "is our growth real?"
|
|
170
167
|
|
|
@@ -191,9 +188,9 @@ Surface specifically: `create_experiment` auto-detects mobile vs web from repo s
|
|
|
191
188
|
|
|
192
189
|
Parameter casing: all tool parameters are **snake_case** (`experiment_id`, `traffic_split`, `primary_metric_event`, `guardrail_event`) — the same convention as event names. camelCase is accepted as a fallback, but snake_case is canonical.
|
|
193
190
|
|
|
194
|
-
Shipping onto a live website,
|
|
191
|
+
Shipping onto a live website, letter, Adaptive Journey, or Milestone: `check_live_tests` (before edit / commit / push / publish). That is a different question from two experiments on the same page.
|
|
195
192
|
|
|
196
|
-
|
|
193
|
+
**Where on the page.** Always pass `target_url` and, when it is not the whole page, `target_anchor` (a short pin: `hero`, `pricing`). A missing pin is the whole page forever. Two experiments on different named parts of the same page are not an overlap — the same person can sit in both. Do not add the two lifts. Whole page plus any part on that page is one place. `create_experiment` (preview) and `activate_experiment` auto-run `check_experiment_conflicts`; you can also call it yourself. Keep them apart (`set_experiment_mutex`) only when they share a place. That costs traffic and applies to new visitors only. People already in both stay. If they measure the same thing and you did not keep them apart, put both changes in one experiment or wait. Holdout is not Keep them apart. Split files if you want an edit of one part to stop on that experiment only — the live-experiment stop is file-based and will name every live experiment in that file.
|
|
197
194
|
|
|
198
195
|
## Related
|
|
199
196
|
|
|
@@ -16,7 +16,7 @@ Belief → Hypothesis → Prediction → Experiment → Outcome → Updated Beli
|
|
|
16
16
|
1. **Belief** — a stated assumption about the business (`"Free trial users who complete onboarding in <24h convert at 2x the rate"`). Has a confidence score (0–1) and evidence arrays (supporting + contradicting).
|
|
17
17
|
2. **Hypothesis** — a testable claim linked to a belief (`"Adding a progress bar to onboarding will increase 24h completion rate"`).
|
|
18
18
|
3. **Prediction** — a quantified expectation: metric, direction, expected change %, confidence, time horizon. Logged *before* the experiment runs.
|
|
19
|
-
4. **Experiment** —
|
|
19
|
+
4. **Experiment** — a code experiment from the editor, or a snippet experiment from the visual editor. Linked to belief, hypothesis, and prediction.
|
|
20
20
|
5. **Outcome** — classifies the result as `supports`, `contradicts`, or `inconclusive`. Records metric delta and statistical significance.
|
|
21
21
|
6. **Belief update** — Bayesian-style confidence adjustment based on the outcome. Evidence appended. Parent beliefs receive dampened updates (0.3x propagation). A decision ledger entry records the full chain.
|
|
22
22
|
|
|
@@ -337,7 +337,7 @@ financial boundary with no API-key lane).
|
|
|
337
337
|
|
|
338
338
|
## Recipe: Set up Apex from this repo
|
|
339
339
|
|
|
340
|
-
If get_setup_state shows first-run incomplete, name the
|
|
340
|
+
If get_setup_state shows first-run incomplete, name the merchant before inventing events.
|
|
341
341
|
|
|
342
342
|
1. Call `get_setup_state`. If the shop has no name, no vertical, or no conversion model, stop.
|
|
343
343
|
2. `update_organization` with the shop's real name. `update_workspace` with `workspace_name`, `vertical`, `conversion_model`, and `website_url` when you know them. The rail finishes from those saves — do not look for a mark-complete tool.
|