Dalton

The star in the Dalton experiments table: favourites an experiment so it stays at the top of the list in Dalton, or removes the favourite. Only that view calls this, on the user's click; never call it yourself.

favourite_experiment

Where should a test run? Answers "all collection pages", "the product pages", "the homepage" with real traffic behind it. Returns, for the store's domain: - the rulesets already set up, each with how many URLs it covers and its reach; - ready-made rulesets Dalton detects from the site's URL structure ("All collection pages", "All product pages") that no existing ruleset covers yet; - the busiest paths (filtered by `query`), so you can see the URL shape and write a custom ruleset when none fits; - if you pass a `ruleset`, exactly what it matches. Prefer an existing ruleset; else a ready-made one (pass its `ruleset` straight to `add_ruleset`); only write rules by hand for the rare case neither fits. Reach counts sessions over the last 30 days, bots excluded.

find_rulesets

Profile of one account: plan, brand (name, website, industry, location, description) and its competitor brands.

get_customer

One A/B test in full: the ruleset it runs on, plan and verdict, per-variant sessions, conversions, CVR, uplift vs baseline, confidence and 90% range, the revenue per session and average order value comparison, plus each variant's changes (selector + html/css/js). Drafts show their changes with no figures yet. A deployed test names the variant now served to every visitor. To run the same test on another ruleset, use `copy_experiment`. Uplift and confidence come from Beta posteriors on the log CVR ratio and are printed only once every variant has ≥350 sessions and ≥50 conversions and the planned window (14/28/42 days) is complete. A winner needs the account's confidence bar (90% unless changed in the account settings) on conversion rate or on revenue per session, and no revenue per session settled below the baseline. Of the variants that clear it, the one with the best revenue per session leads; `verdict.decided_by` says which metric carried it. Older Smart traffic experiments open here too, whatever their status — a running or paused one reads exactly like a deployed one. Their figures are the modelled Bayesian estimates stored on each variant, with no planned window: the verdict fires once the run's own confidence stands up, or 28 days after launch. No revenue comparison for these.

get_experiment

The store's conversion funnel for the last `days` days: Visitors → Engaged → Add to cart → Purchase, with the step-to-step drop rate and the weakest step. This is what tells you *where* the store leaks. The add-to-cart stage is omitted when the account doesn't track it; stage labels use the account's own goal names.

get_funnel

What Dalton has learned about this account's visitors from its experiments: up to four insights, each a claim about what works ("Social proof lifts conversion on product pages"), a short explanation with what to try next, and a verdict — `proven` (two or more settled wins agree), `promising` (one win, or a positive trend), `no_effect` (this execution settled as not moving the needle) or `unclear` (results contradict). The same insights as the Learnings page in the Dalton app. Read this before proposing a new test, so ideas build on what already worked and don't repeat what didn't. These are conclusions across experiments, not results: for the figures behind them use `list_experiments` with `status="finished"`, or `get_experiment` on an id listed under an insight. A source shown without an id is an experiment these tools can't open; its name is all there is. Dalton writes the insights itself once enough experiments have a readable result, so a new account has none yet.

get_learnings

Everything about one page: all sessions vs entry sessions, conversion rate, engagement, click-through, scroll depth, bounce and exit rate — plus where visitors go next and how each onward branch converts. Use it to explain *why* a page from `get_page_scorecard` wins or leaks. `path` is the URL path exactly as Dalton stores it (e.g. `/products/blue-shirt`), without query string. Figures are over every visit of the page, not only landings (unlike `get_page_scorecard`'s default). Exit rate = exits ÷ page views. The next page is the page first viewed after this one; `(exit)` is a row of its own, so the shares sum to 100 over all visits.

get_page_detail

Which pages win and which leak. Winners = conversion rate ≥ median *and* bounce ≤ median, ranked by sessions; leaks = bounce above the cohort median, ranked by `excess_bounce` — the extra sessions lost versus a typical page. Lead with `sessions_lost`, never with a count of leaking pages. `group_by="pages"` scores individual paths; `"groups"` / `"markets"` roll paths up into the account's configured page groups or markets (fewer, more answerable buckets). Flags are relative to the returned cohort and shift when filters change.

get_page_scorecard

Store-wide totals for the last `days` days: human sessions, conversion rate, bounce rate, revenue (in the account's reporting currency) and revenue per session. The baseline to compare other numbers against. Bots are always excluded. Conversion goal and currency come from the account's settings.

get_site_totals

Sessions, share of traffic, and conversion rate per value of one dimension. Use `dimension="channel"` (direct, search, paid, paid_social, organic_social, email, referral, …) or `"platform"` (google, meta, tiktok, klaviyo, chatgpt, …) to see whether a conversion problem is a traffic-quality problem, and `"device_type"` for the mobile-vs-desktop gap — the most common CRO finding. Share is computed over the returned rows (top 12; top 6 for device), not over all store sessions. For `device_type` the `device_type` filter is ignored, tablet is counted as mobile, and unknown devices are dropped.

get_traffic_breakdown

The Launch button in the Dalton experiment view: puts a draft live with the variants the user ticked, as the editor's Launch does. Only that view calls this, after the user confirmed in its launch pop-up; never call it yourself.

launch_experiment

List an account's deployments — the changes Dalton permanently applies to its rulesets. When an experiment finishes with a winner, that variant is deployed: served to every visitor of the ruleset instead of a split. Check this before drafting a test on a ruleset: a serving deployment has already changed what visitors see there. Each row gives the ruleset, the experiment the winner came from, and a state: `serving` (live), `paused` (switched off, can be resumed in Dalton) or `concluded` (stopped for good; kept as history). Deployments are managed in the Dalton app, not from here. Every row carries the id of the experiment the winner came from, A/B test or Smart traffic alike — open it with `get_experiment` for the winning variant's changes and the result behind it. An id is missing only when the account no longer lists that experiment.

list_deployments

List an account's A/B tests, each with a verdict: `collecting`, `losing`, `thin`, `winner`, `baseline` (control won), `close` (promising) or `flat`, plus the leader's uplift and confidence once the planned window is complete and every variant has enough data. A test moves draft → running (or paused) → finished. Finished is either `concluded` (stopped, nothing shipped) or `deployed` (its winning variant is now served to every visitor of the page; "deployed (paused)" when that is switched off). A finished test's result is final, so its figures show however long it ran. `status="finished"` is the account's testing history — what was tried and what it did; `get_learnings` gives the conclusions Dalton drew across those tests. Mid-run figures are deliberately withheld (shown as —) except for `losing`, the one verdict allowed to fire early (from day 7). `get_experiment` gives one test's full per-variant scorecard. Older Smart traffic experiments (Dalton's earlier self-learning format) are listed too, at every status — running, paused, concluded or deployed; a running one is labelled `optimizing` and matches `status="running"`. Their figures are the modelled Bayesian estimates stored on each variant, with no planned window: a verdict fires once the run's own confidence stands up, or 28 days after launch. Only creating and copying one is off limits.

list_experiments

The rulesets set up in this account, with the `ruleset_id` that `query_content_map` and `create_experiment` take. Use `find_rulesets` to decide which ruleset (or new one) a test should run on.

list_rulesets

The Pause button in the Dalton experiment view: stops a running test so visitors see the original again, as pausing it in Dalton does. Only that view calls this, on the user's click; never call it yourself.

pause_experiment

A ruleset's page sections, selectors and markup as Dalton scanned them — the preferred source for selectors before `create_experiment`. Start with `view="sections"`, then zoom in with `view="section"` or `view="html"` (`detail="mid"` is usually enough to write a selector). Views: - `sections` (default): every section with id, selector, name, location, a short preview and asset summary. - `section`: one section in full at the given `detail`. - `html`: one section's HTML at the given `detail` — use it to write `target.css` and `payload.html` that match the live DOM. - `styles`: one section's computed styles for `viewport` (`desktop`|`mobile`). - `structure`: page-level skeleton, structure, template hints and profile. `detail`: `low` ~400 chars, `mid` ~8000, `high` uncompressed. A just-added ruleset may still be scanning (retry in a minute). If the result is missing, empty or wrong, tell the user. If you can fetch the page URL, you may take selectors from its live markup instead; say that you did.

query_content_map

What Dalton knows about the account's brand and its competitors, gathered by scanning their sites and ads. Read `controls` before drafting a variant so it matches the brand; use the rest to see how the brand and its competitors sell. Views: - `controls` (default): the brand's guidelines — colours, typography, spacing, buttons, cards, forms, imagery, voice, content restrictions and logo. "not set" means the brand has no approved value for that key yet. - `competitors`: the account's own brand and the competitor brands Dalton tracks, with each one's `id` and how many intel facts it has. - `intel`: current facts about those brands (messaging, trust and design patterns, campaigns, discounts, shipping and returns policies, page structures, …), grouped by brand. Lists the `kind` values that exist; filter with `kind` (exact match) and `brand_id`. - `explorations`: the raw observations behind the intel, newest first — ads, page screenshots (banners, sections, full pages) and offers. Filter with `brand_id` and `kind` (`ad` | `screenshot` | `offer`). - `exploration`: one observation in full (needs `exploration_id`), with the intel it supports. Images aren't included; names, descriptions, captured text and source URLs are. `intel` and `explorations` are paged: pass the `cursor` the output gives.

read_brand_intelligence

Fetch a page from the Dalton docs (docs.getdalton.com) as markdown. Appending `.md` to any docs URL returns the markdown source directly. Call with no `path` to get the docs index (`llms.txt`), which lists every available doc and its URL — start there to discover what's available, then call again with a specific path.

read_docs

Page metrics over time: one row per day, week or month of the last `days` days, for one page or for all pages, optionally split into the 5 biggest values of one dimension. Use it to see when a page's conversion, bounce, click-through or scroll depth changed, or which pages gained or lost traffic (`group_by="path"`). `sessions` counts page visits, one per page per session: without `path` a session that saw three pages counts three times, so filter by `path` or group by it. `conversion_rate` counts visits that converted after seeing the page, `entry_conversion_rate` only the visits that landed on it. Bounce is over landings, exit rate = exits ÷ pageviews, and click-through is the share of visits that went on to another page. Bots are always excluded. Weeks start on Monday, and the first and last week or month can be partial. For one page's totals and where its visitors go next use `get_page_detail`; for store-wide trends `read_session_time_series`.

read_page_time_series

Store-wide session metrics over time: one row per day, week or month of the last `days` days, optionally split into the 5 biggest values of one dimension. Use it for trends — is the conversion rate rising, when did revenue per session drop, how do mobile and desktop move week by week, which UTM source grew. A session counts in the bucket of its first hit, under its landing page's channel, device and platform. Bots are always excluded. Weeks start on Monday, and the first and last week or month can be partial. Conversion goal and currency come from the account's settings. For one total use `get_site_totals`, for one split without a time axis `get_traffic_breakdown`, and for a page's trend `read_page_time_series`.

read_session_time_series

Remove one variant from a draft A/B test, e.g. drop Variant C before launch — the same as deleting it in the Dalton editor. The baseline and a test's last variant can't be removed, and only unlaunched experiments can be changed. To change a variant instead, use `update_variant`.

remove_variant

Link the brand of an account that has none yet, from its website. Backoffice only. For accounts created without a website: does what account creation does with one — links (and enriches) the brand, starts the brand scan and the section seed, so brand intelligence and the CRO agent have a site to work on. Refused when the account already has a brand; `get_customer` shows it.

set_customer_website

Send the user's feedback about Dalton or this MCP to the Dalton team. The note is stored for the team to read; it changes nothing in the user's account. Call this only when the user asks to send feedback, or when you offered to pass something on and the user agreed. When the user asks for something Dalton can't do, tell them so; you may offer to send it as feedback, but don't send anything they didn't agree to. **Accounts on Dalton's older setup.** Dalton recently moved its experimentation platform to a new generation, and these tools only serve accounts that were migrated to it. If an account has no rulesets or no experiments here while the user is sure they have them, that's most likely why — say so, point them at the Dalton team, and offer to send a note about what they were trying to reach.

suggestion_box

Rename a draft experiment and/or change who sees it. Only unlaunched experiments can be changed; variants are changed with `update_variant`, added with `add_variant` and removed with `remove_variant`. The ruleset can't be changed: to run a test on a different ruleset, use `copy_experiment`.

update_experiment

Change a variant's operations (and, on a draft, its name) by sending only the change — use this to refine a test after `create_experiment` instead of creating a new one. The baseline can't be changed. To add another variant use `add_variant`; to drop one, `remove_variant`. Read the variant with `get_experiment` first: it lists the operations as `operations[0]`, `operations[1]`, … and gives the `version_id`. Each edit is one of: - `{"operation": 0, "field": "js", "find": "Explore Noon", "replace": "Meet Noon"}` — replace text in an operation's `html`, `css`, `js` or `selector`. `find` must occur exactly once in that field; quote enough around it to be unique. An empty `find` fills a field that is empty. - `{"add": op}` — append a new operation, shaped as in `create_experiment`. - `{"remove": 0}` — drop an operation. Operation numbers always refer to the list as `get_experiment` showed it: text edits apply in order, then removals, then additions. Take new selectors from `query_content_map`; the response checks them against the page as Dalton scanned it. The previous version stays in the editor's history. A running or paused experiment takes small code fixes too, as the editor's code view does, without a restart: text edits to `html`/`css`/`js` only, changing a few characters in total (a refusal says how many). Visitors get the change within minutes and the results mix before and after it, so fix bugs this way rather than test a new idea.

update_variant

Same as `get_experiment`, and also shows the test as a Dalton screen in the chat, in hosts that show Dalton views: a draft with its variants, a screenshot of the page and Launch, Preview and editor buttons; a launched test with its results and Pause, Deploy and developer instructions. Use it when the user wants to see, launch or act on the test. Those buttons are the user's clicks, never yours; each one reaches you as a note in the conversation. One A/B test in full: the ruleset it runs on, plan and verdict, per-variant sessions, conversions, CVR, uplift vs baseline, confidence and 90% range, the revenue per session and average order value comparison, plus each variant's changes (selector + html/css/js). Drafts show their changes with no figures yet. A deployed test names the variant now served to every visitor. To run the same test on another ruleset, use `copy_experiment`. Uplift and confidence come from Beta posteriors on the log CVR ratio and are printed only once every variant has ≥350 sessions and ≥50 conversions and the planned window (14/28/42 days) is complete. A winner needs the account's confidence bar (90% unless changed in the account settings) on conversion rate or on revenue per session, and no revenue per session settled below the baseline. Of the variants that clear it, the one with the best revenue per session leads; `verdict.decided_by` says which metric carried it. Older Smart traffic experiments open here too, whatever their status — a running or paused one reads exactly like a deployed one. Their figures are the modelled Bayesian estimates stored on each variant, with no planned window: the verdict fires once the run's own confidence stands up, or 28 days after launch. No revenue comparison for these.

visualize_get_experiment

Same as `get_funnel`, and also draws the result as a Dalton chart in the chat, in hosts that show Dalton views; you get the same markdown either way. Use it when the user wants to see the numbers, a trend or a comparison; call `get_funnel` for figures you only read to reason with. The store's conversion funnel for the last `days` days: Visitors → Engaged → Add to cart → Purchase, with the step-to-step drop rate and the weakest step. This is what tells you *where* the store leaks. The add-to-cart stage is omitted when the account doesn't track it; stage labels use the account's own goal names.

visualize_get_funnel

Same as `get_page_detail`, and also draws the result as a Dalton chart in the chat, in hosts that show Dalton views; you get the same markdown either way. Use it when the user wants to see the numbers, a trend or a comparison; call `get_page_detail` for figures you only read to reason with. Everything about one page: all sessions vs entry sessions, conversion rate, engagement, click-through, scroll depth, bounce and exit rate — plus where visitors go next and how each onward branch converts. Use it to explain *why* a page from `get_page_scorecard` wins or leaks. `path` is the URL path exactly as Dalton stores it (e.g. `/products/blue-shirt`), without query string. Figures are over every visit of the page, not only landings (unlike `get_page_scorecard`'s default). Exit rate = exits ÷ page views. The next page is the page first viewed after this one; `(exit)` is a row of its own, so the shares sum to 100 over all visits.

visualize_get_page_detail

Same as `get_page_scorecard`, and also draws the result as a Dalton chart in the chat, in hosts that show Dalton views; you get the same markdown either way. Use it when the user wants to see the numbers, a trend or a comparison; call `get_page_scorecard` for figures you only read to reason with. Which pages win and which leak. Winners = conversion rate ≥ median *and* bounce ≤ median, ranked by sessions; leaks = bounce above the cohort median, ranked by `excess_bounce` — the extra sessions lost versus a typical page. Lead with `sessions_lost`, never with a count of leaking pages. `group_by="pages"` scores individual paths; `"groups"` / `"markets"` roll paths up into the account's configured page groups or markets (fewer, more answerable buckets). Flags are relative to the returned cohort and shift when filters change.

visualize_get_page_scorecard

Same as `get_site_totals`, and also draws the result as a Dalton chart in the chat, in hosts that show Dalton views; you get the same markdown either way. Use it when the user wants to see the numbers, a trend or a comparison; call `get_site_totals` for figures you only read to reason with. Store-wide totals for the last `days` days: human sessions, conversion rate, bounce rate, revenue (in the account's reporting currency) and revenue per session. The baseline to compare other numbers against. Bots are always excluded. Conversion goal and currency come from the account's settings.

visualize_get_site_totals

Same as `get_traffic_breakdown`, and also draws the result as a Dalton chart in the chat, in hosts that show Dalton views; you get the same markdown either way. Use it when the user wants to see the numbers, a trend or a comparison; call `get_traffic_breakdown` for figures you only read to reason with. Sessions, share of traffic, and conversion rate per value of one dimension. Use `dimension="channel"` (direct, search, paid, paid_social, organic_social, email, referral, …) or `"platform"` (google, meta, tiktok, klaviyo, chatgpt, …) to see whether a conversion problem is a traffic-quality problem, and `"device_type"` for the mobile-vs-desktop gap — the most common CRO finding. Share is computed over the returned rows (top 12; top 6 for device), not over all store sessions. For `device_type` the `device_type` filter is ignored, tablet is counted as mobile, and unknown devices are dropped.

visualize_get_traffic_breakdown

Same as `list_experiments`, and also shows the list as Dalton's experiments table in the chat, in hosts that show Dalton views: sortable columns, and per row a star, a trash for drafts and an open link. Use it when the user wants to browse or manage their experiments. Starring and deleting are the user's clicks, never yours; each one reaches you as a note in the conversation. List an account's A/B tests, each with a verdict: `collecting`, `losing`, `thin`, `winner`, `baseline` (control won), `close` (promising) or `flat`, plus the leader's uplift and confidence once the planned window is complete and every variant has enough data. A test moves draft → running (or paused) → finished. Finished is either `concluded` (stopped, nothing shipped) or `deployed` (its winning variant is now served to every visitor of the page; "deployed (paused)" when that is switched off). A finished test's result is final, so its figures show however long it ran. `status="finished"` is the account's testing history — what was tried and what it did; `get_learnings` gives the conclusions Dalton drew across those tests. Mid-run figures are deliberately withheld (shown as —) except for `losing`, the one verdict allowed to fire early (from day 7). `get_experiment` gives one test's full per-variant scorecard. Older Smart traffic experiments (Dalton's earlier self-learning format) are listed too, at every status — running, paused, concluded or deployed; a running one is labelled `optimizing` and matches `status="running"`. Their figures are the modelled Bayesian estimates stored on each variant, with no planned window: a verdict fires once the run's own confidence stands up, or 28 days after launch. Only creating and copying one is off limits.

visualize_list_experiments

Same as `read_page_time_series`, and also draws the result as a Dalton chart in the chat, in hosts that show Dalton views; you get the same markdown either way. Use it when the user wants to see the numbers, a trend or a comparison; call `read_page_time_series` for figures you only read to reason with. Page metrics over time: one row per day, week or month of the last `days` days, for one page or for all pages, optionally split into the 5 biggest values of one dimension. Use it to see when a page's conversion, bounce, click-through or scroll depth changed, or which pages gained or lost traffic (`group_by="path"`). `sessions` counts page visits, one per page per session: without `path` a session that saw three pages counts three times, so filter by `path` or group by it. `conversion_rate` counts visits that converted after seeing the page, `entry_conversion_rate` only the visits that landed on it. Bounce is over landings, exit rate = exits ÷ pageviews, and click-through is the share of visits that went on to another page. Bots are always excluded. Weeks start on Monday, and the first and last week or month can be partial. For one page's totals and where its visitors go next use `get_page_detail`; for store-wide trends `read_session_time_series`.

visualize_read_page_time_series

Same as `read_session_time_series`, and also draws the result as a Dalton chart in the chat, in hosts that show Dalton views; you get the same markdown either way. Use it when the user wants to see the numbers, a trend or a comparison; call `read_session_time_series` for figures you only read to reason with. Store-wide session metrics over time: one row per day, week or month of the last `days` days, optionally split into the 5 biggest values of one dimension. Use it for trends — is the conversion rate rising, when did revenue per session drop, how do mobile and desktop move week by week, which UTM source grew. A session counts in the bucket of its first hit, under its landing page's channel, device and platform. Bots are always excluded. Weeks start on Monday, and the first and last week or month can be partial. Conversion goal and currency come from the account's settings. For one total use `get_site_totals`, for one split without a time axis `get_traffic_breakdown`, and for a page's trend `read_page_time_series`.

visualize_read_session_time_series

The signed-in user and the accounts they can access. Call this first: every account-scoped tool takes a `customer_id` from here. `get_customer` has the brand profile if you need it. Backoffice users can access every account, but only the accounts they are a member of are listed; pass `search` (part of an account name) to find any other.

whoami