@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.
Files changed (74) hide show
  1. package/README.md +19 -18
  2. package/dist/api-client.d.ts +5 -0
  3. package/dist/api-client.d.ts.map +1 -1
  4. package/dist/api-client.js +40 -24
  5. package/dist/api-client.js.map +1 -1
  6. package/dist/conflict-advisory.d.ts +29 -0
  7. package/dist/conflict-advisory.d.ts.map +1 -0
  8. package/dist/conflict-advisory.js +48 -0
  9. package/dist/conflict-advisory.js.map +1 -0
  10. package/dist/index.js +8 -5
  11. package/dist/index.js.map +1 -1
  12. package/dist/live-test-guard.d.ts +1 -0
  13. package/dist/live-test-guard.d.ts.map +1 -1
  14. package/dist/live-test-guard.js +4 -3
  15. package/dist/live-test-guard.js.map +1 -1
  16. package/dist/prompts.d.ts.map +1 -1
  17. package/dist/prompts.js +5 -7
  18. package/dist/prompts.js.map +1 -1
  19. package/dist/setup-catchup-tools.d.ts.map +1 -1
  20. package/dist/setup-catchup-tools.js +15 -3
  21. package/dist/setup-catchup-tools.js.map +1 -1
  22. package/dist/smoke-tools.d.ts +56 -0
  23. package/dist/smoke-tools.d.ts.map +1 -0
  24. package/dist/smoke-tools.js +261 -0
  25. package/dist/smoke-tools.js.map +1 -0
  26. package/dist/tool-catalog.d.ts +10 -0
  27. package/dist/tool-catalog.d.ts.map +1 -0
  28. package/dist/tool-catalog.js +36 -0
  29. package/dist/tool-catalog.js.map +1 -0
  30. package/dist/tool-groups.d.ts +5 -0
  31. package/dist/tool-groups.d.ts.map +1 -0
  32. package/dist/tool-groups.js +206 -0
  33. package/dist/tool-groups.js.map +1 -0
  34. package/dist/tool-shared.d.ts +300 -0
  35. package/dist/tool-shared.d.ts.map +1 -0
  36. package/dist/tool-shared.js +319 -0
  37. package/dist/tool-shared.js.map +1 -0
  38. package/dist/tools/accounts.d.ts +124 -0
  39. package/dist/tools/accounts.d.ts.map +1 -0
  40. package/dist/tools/accounts.js +99 -0
  41. package/dist/tools/accounts.js.map +1 -0
  42. package/dist/tools/adoption.d.ts +499 -0
  43. package/dist/tools/adoption.d.ts.map +1 -0
  44. package/dist/tools/adoption.js +447 -0
  45. package/dist/tools/adoption.js.map +1 -0
  46. package/dist/tools/context.d.ts +216 -0
  47. package/dist/tools/context.d.ts.map +1 -0
  48. package/dist/tools/context.js +328 -0
  49. package/dist/tools/context.js.map +1 -0
  50. package/dist/tools/experiments.d.ts +1066 -0
  51. package/dist/tools/experiments.d.ts.map +1 -0
  52. package/dist/tools/experiments.js +2090 -0
  53. package/dist/tools/experiments.js.map +1 -0
  54. package/dist/tools/letters.d.ts +1107 -0
  55. package/dist/tools/letters.d.ts.map +1 -0
  56. package/dist/tools/letters.js +1324 -0
  57. package/dist/tools/letters.js.map +1 -0
  58. package/dist/tools/measurement.d.ts +886 -0
  59. package/dist/tools/measurement.d.ts.map +1 -0
  60. package/dist/tools/measurement.js +1353 -0
  61. package/dist/tools/measurement.js.map +1 -0
  62. package/dist/tools/partners.d.ts +364 -0
  63. package/dist/tools/partners.d.ts.map +1 -0
  64. package/dist/tools/partners.js +199 -0
  65. package/dist/tools/partners.js.map +1 -0
  66. package/dist/tools.d.ts +3161 -2826
  67. package/dist/tools.d.ts.map +1 -1
  68. package/dist/tools.js +26 -6133
  69. package/dist/tools.js.map +1 -1
  70. package/package.json +3 -2
  71. package/skills/apex-communications/SKILL.md +5 -5
  72. package/skills/apex-experimentation/SKILL.md +11 -14
  73. package/skills/apex-growth-intelligence/SKILL.md +1 -1
  74. 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 A/B experiments with Apex — SDK and snippet modes, 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.
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
- ## Two execution modes
25
+ ## How an experiment runs
26
26
 
27
- | Mode | When to use | Implementation |
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
- Prefer **SDK mode** when the user is in an app codebase. Prefer **snippet mode** only when they explicitly use the marketing snippet and cannot deploy code.
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.** SDK / Cursor experiments 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/DOM experiments created in the dashboard still auto-capture a public URL whose variant already lives there.
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
- - **Snippet mode** (Apex mutates the DOM) is a different path. Do not conflate. Do not hide the page until `/assign` returns as the React-hook promise (worse LCP).
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 (SDK-hook) 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`. Non-SDK 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.
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 an SDK / Cursor draft ready from hosted screenshots of a public URL. The variant is local until deploy — attach localhost shots with `attach_experiment_asset`.
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 test. 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 test then ship; wait; or they say this change is not the thing under test (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 test.
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, app test, letter, Adaptive Journey, or Milestone: `check_live_tests` (before edit / commit / push / publish). That is a different question from two tests on the same page.
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
- Avoiding interaction effects: two experiments on the **same surface/component** contaminate each other. `create_experiment` (preview) and `activate_experiment` auto-run a conflict check and surface an advisory; you can also call `check_experiment_conflicts` yourself. Resolve it by either (a) **mutual exclusion** — `set_experiment_mutex` so no visitor is in both (run concurrently, the scientifically clean default), or (b) **sequencing** — launch the second only after the first concludes. If two experiments share a surface AND the same primary metric, they're usually arms of ONE experiment — add a variant instead of creating a second. Pass `target_component` (e.g. "ProductCard") on create so the guard can detect overlap precisely, especially for mobile/SDK experiments.
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** — runs in snippet or SDK mode. Linked to belief, hypothesis, and prediction.
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 shop before inventing events.
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.