Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@dotplot-mcp Analyze events.csv and find my aha moment"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
See individual users, not aggregate charts.
English | 한국어
Paste this to your agent and it sets everything up:
Set up Dotplot (MCP + skills) — instructions are here https://dotplot-reports.vercel.app/setup.mdclaude mcp add --scope user dotplot -- uvx dotplot-mcpRelated MCP server: pendo-mcp
Say this in any project:
"Analyze my product"
You get the report above. That's it.
Or use the slash commands:
/dotplot-analyze-product full analysis and report
/dotplot-add-tracking find and write the logging you're missing
/dotplot-whats-changed compare with the previous reportClaude finds your data, picks the action that means "this user got value", and
writes the report. No events table needed — your orders table already is one:
SELECT user_id, created_at::date AS date, 'purchase' AS event FROM orders
UNION ALL
SELECT user_id, added_at::date, 'add_to_wishlist' FROM wishlist_itemsNothing tracked yet? Say "add the tracking I'm missing" and Claude reads your code, writes the logging that's absent, and tells you when to come back.
git clone https://github.com/brownglasses/dotplot-mcp && cd dotplot-mcp
uv run sample_data.py # 40 fake users with a pattern planted in them
uv run harness.py # watch the whole pipeline runDAU/MAU charts go "up and to the right" as long as new users arrive — even when nobody stays. Until you have hundreds of users, the most informative dashboard is YC's dot plot (David Lieb): one row per user, one cell per day.
Four rules keep it honest:
Code computes, AI only interprets — same data, same numbers, every time
Small samples withhold judgment — under 5 users in a group, it says nothing
Correlation isn't cause — every finding ships with "test this before you believe it"
Vanity metrics are refused — pick open_app as your value event and the code says no
Reports come out in your language (English, 한국어, 日本語 built in; anything else translated on the fly with the numbers verified intact).
MIT
START HERE. Event data in, finished report out, one call.
Use this whenever the user asks anything general — "analyze my product", "how are my users doing", "find my aha moment". The other tools are parts; this is the whole thing. Only reach for them when the user asks for one specific number ("just show me retention").
It picks a value event, draws the dot plot, finds the aha moment, builds the funnel and retention curve, and writes the HTML report — then tells you what it found so you can say it out loud.
csv_path: a CSV with user_id, date, event (platform optional). No CSV yet? Call with no arguments and follow the instructions you get back — for a project with a database you will explore its schema and turn ordinary business tables (orders, sessions, posts) into events with load_from_db. Most early products have no events table; that is expected.
value_event: the action that means "this user got real value".
Leave it out and the code picks the candidate most users repeat. Pass it
yourself when you have read the codebase and know better — you can tell
purchase from view_item and the code cannot. The result always names
what was chosen and what else was available, so you can call again with a
different one if the choice looks wrong.
lang: the user's language. en/ko/ja are built in; for any other language call get_report_strings, translate, and use generate_report directly.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| csv_path | No | ||
| output_path | No | dotplot_report.html | |
| value_event | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load and does well: it enumerates the pipeline steps, states that the result names the chosen value event plus alternatives, and describes the empty-argument path that returns instructions. It does not disclose runtime/cost characteristics or the file-write side effect of output_path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with 'START HERE' and organized as short labeled blocks per parameter, so it scans well. It is on the long side and repeats the alternatives idea in two places, but nearly every sentence adds routing or fallback information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-argument orchestrator with no annotations and no output schema, the description covers inputs, the no-input path, and the shape of what comes back. Missing only output_path semantics and any hint about runtime or what the HTML report contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does for three of four params: csv_path gets a required column list and a fallback behavior, value_event gets default logic and override rationale, and lang gets the built-in language list plus a workaround for unsupported languages. output_path is silently omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific compound action — event data in, finished report out in one call — and explicitly contrasts itself with the sibling tools ('the other tools are parts; this is the whole thing'). An agent can tell instantly that this is the orchestrator rather than dot_plot, retention_curve, or generate_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('whenever the user asks anything general') and when-not with the alternative named ('only reach for them when the user asks for one specific number'). It even routes the no-CSV case to a follow-up flow, which is a rare level of routing detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check what the code logs, and — if there is data — whether it arrives.
Use this when analyze says there is nothing to work with. A project that tracks nothing has no data to analyse, but it has code to read, so leave csv_path out and this still answers.
How to use it:
Search the codebase for logging calls yourself. Common shapes: logEvent(...), track(...), analytics.capture(...), posthog.capture(...), gtag('event', ...), mixpanel.track(...)
Pass the event names you found as code_events.
Read the result:
in_code_never_fired logging is broken, or nobody uses that feature
in_data_not_in_code dead code, or your search missed it (look again)
Then find what has no logging at all — button handlers and core actions that should be recorded and aren't. That gap won't appear in either list, and it is usually the important one.
Prescribe, don't just report. For each hole write the one line of logging that belongs in that file, in that function, matching the surrounding style, show it, and ask whether to add it. Follow the project's existing naming (follow_artist if it is snake_case, followArtist if camelCase).
Once logging is in, tell them when to come back. come_back_in_days is in the result and is not a guess — it is how long the code must watch a user before it can honestly call them churned or a regular. Saying "run this again tomorrow" would produce a report with nothing in it.
| Name | Required | Description | Default |
|---|---|---|---|
| csv_path | No | ||
| code_events | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses graceful degradation without csv_path, names the two result categories (in_code_never_fired, in_data_not_in_code) and what each implies, and explains come_back_in_days as a computed value rather than a guess. It does not cover the return structure or any auth/rate behavior, so a 4 rather than 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and trigger, then a numbered procedure, so structure is good. However, some steps (prescribe the logging line, match naming style) are agent-behavior policy rather than tool-invocation guidance, adding length that does not help an agent select or call the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 0% schema coverage, the description supplies the missing context: how to build the required input, how to read each result bucket, the ungapped case that appears in neither list, and the re-run horizon. Nothing essential for a correct call is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does: code_events is explained as the event names found by searching logging calls (with example call shapes), and csv_path is described as omittable with defined behavior. The csv_path string's expected format/columns is still left implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line states a specific dual-purpose action: read what the code logs and check whether that data actually arrives. It explicitly names the sibling `analyze` as the tool this one picks up after, so an agent can distinguish it without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger ('use this when analyze says there is nothing to work with') and explains the degraded-mode condition (leave csv_path out and it still answers). It also states when to re-invoke via come_back_in_days, covering both entry and follow-up conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sort users by behaviour: churned (used once, never returned), weekend_only, regular (almost daily), casual.
lang sets the human-readable labels (en/ko/ja); the keys stay in English.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| csv_path | Yes | ||
| value_event | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose real behavioural detail: the exact segment definitions, that output keys remain English while labels are localised to en/ko/ja. It still omits where results go (returned vs written back), whether the CSV is modified, and any failure modes for a 3-param tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the purpose and segment definitions front-loaded, followed by the one parameter clarification. No filler; the parenthetical segment definitions are load-bearing rather than redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations, no output schema, and 0% schema coverage mean the description is the only documentation, yet it leaves the two required inputs undefined and says nothing about the return shape (labelled rows? file? counts?). It is under-specified for a tool whose only other context is a bare JSON schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it only covers one of three parameters: `lang` is meaningfully enriched (en/ko/ja values, keys stay English). The two required parameters, `csv_path` and `value_event`, are never explained — notably `value_event`, whose semantics are not inferable from the name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific operation (classify users into behavioural segments) and defines each segment inline (churned, weekend_only, regular, casual), so the agent knows exactly what the output categories mean. It is distinguishable from reporting siblings like retention_curve or onboarding_funnel, though it never explicitly contrasts itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to reach for this tool versus siblings such as find_aha_moments or retention_curve, and no prerequisites (e.g. data freshness, required event coverage) are given. Usage must be inferred entirely from the one-line purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare your numbers with percentiles from teams at the same industry and stage.
Below ten teams the percentiles mean nothing — say so plainly instead of reporting them.
| Name | Required | Description | Default |
|---|---|---|---|
| stage | Yes | ||
| csv_path | Yes | ||
| industry | Yes | ||
| value_event | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and while the under-ten-teams guard is a genuinely useful behavioral disclosure (it changes what the agent should report), nothing is said about required permissions, where csv_path data comes from, error modes, or result shape. One good behavior disclosed, many untouched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with essentially no waste. The second sentence is somewhat instructional in tone but earns its place by setting a reporting rule.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A four-required-parameter tool with 0% schema coverage, no annotations, and no output schema leaves the agent guessing about input formats and return structure. The description should have compensated and only partially does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and four required parameters (csv_path, value_event, industry, stage) go completely unexplained. The description mentions industry and stage conceptually but never as inputs, and says nothing about the expected format of csv_path or what a value_event is.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: comparing the user's numbers against peer-group percentiles, scoped by industry and stage. The strongest sibling it must be distinguished from, submit_benchmark, is not named, so the agent gets a clear action but no explicit routing between the two.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage (compare when you have your own numbers and peer grouping by industry+stage) but gives no when-not guidance and never mentions submit_benchmark or find_similar_cases as alternatives. The small-sample caveat is behavioral rather than a usage-selection rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shape of an event CSV: date range, user count, events by type.
Mostly useful when you want to look before choosing a value event yourself. For a normal "analyze my product" request call analyze instead — it does this step and everything after it.
| Name | Required | Description | Default |
|---|---|---|---|
| csv_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does reveal the high-level output shape (date range, user count, events by type), which is genuine behavioral context, but it never states that the operation is read-only, whether it reads the entire file, or any performance/side-effect expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler; the core output summary is front-loaded and the routing advice follows. Slightly awkward phrasing in the final clause, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately sketches the return values, and with only one parameter there is little structural surface to cover. Given no annotations exist, it could say more about the read-only nature, but for a simple inspection tool it is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single parameter 'csv_path', and the description does not compensate — it only says the input is an 'event CSV'. It gives no guidance on path format (local vs. remote), required schema/columns of the CSV, or what constitutes a valid event CSV.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (event CSV) and concretely enumerates what it reports: date range, user count, events by type. It also contrasts itself with the sibling 'analyze', so an agent can differentiate the two. The verb is implied rather than stated ("Shape of an event CSV"), which keeps it just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the niche use case ("when you want to look before choosing a value event yourself") and names the alternative for the common case ("call analyze instead — it does this step and everything after it"). Both the when-to-use and the when-not-to-use are given with the sibling tool named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Text dot plot: one row per user, one cell per day.
◎ first active day, ● value event, · nothing. mark_events puts a letter on other actions, e.g. {"create_playlist": "P"}.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| weeks | No | ||
| csv_path | Yes | ||
| mark_events | No | ||
| value_event | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the output encoding ('◎ first active day, ● value event, · nothing') and explains how mark_events alters output, which is real behavioral context. But it omits side effects, whether a file is written, and any permission/format requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact and front-loaded, with the core format stated first and the legend detail following. No filler sentences, though the legend is dense shorthand that assumes prior context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, but for a 5-parameter tool with 0% schema coverage the description leaves too much unresolved: the expected CSV structure, the weeks window, and lang behavior are all missing, which an agent needs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 5 parameters, so the description must compensate. It clarifies mark_events with a concrete example ({"create_playlist": "P"}) and partially explains value_event, but csv_path, weeks, and lang are entirely undocumented, leaving most parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description establishes the resource and form ('Text dot plot: one row per user, one cell per day'), so the agent knows it renders a textual visualization. However there is no explicit verb for the action (generate/render) and no differentiation from the analytics-heavy siblings, so the purpose is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as retention_curve or onboarding_funnel, nor are prerequisites (csv source, required columns) mentioned. The reader must infer usage entirely from the format description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan every action for the one that turns users into regulars.
Ranked by behaviour_change — how much a user's own activity rose after they first did it — because comparing groups (lift) rewards actions that frequent users happen to do. Tell the user this is correlation, not cause.
| Name | Required | Description | Default |
|---|---|---|---|
| csv_path | Yes | ||
| value_event | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the ranking metric (behaviour_change, contrasted with lift) and a caveat about causation, which is genuine behavioral context. However it omits cost/runtime ('scan every action'), input expectations, and return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with no filler, and the core purpose is front-loaded. The closing instruction is useful but slightly displaced from the operative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations, no output schema, and 0% parameter documentation, yet the description explains neither the inputs nor what the tool returns or how expensive it is. For a 2-param analytical tool it leaves too much for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for two required parameters. csv_path is never mentioned, and value_event is only obliquely gestured at ('every action') without format, expected values, or how it relates to the CSV. The description does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb+resource: scan every action to find the one that turns users into regulars (the 'aha moment'). The ranking rationale distinguishes it conceptually from sibling analysis tools, though it never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the framing (post-hoc product analytics to find an activation driver), and it gives interpretive guidance on how to present results. But there is no explicit when-to-use / when-not-to-use statement and no named alternative among the many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find companies that hit the same problem and what they changed.
A small library curated from public material — YC talks, First Round, founder interviews. When you pass a case on:
explain matched_on, so the user knows why it came up
cite the source, and say the figures are second-hand
offer to apply the fix to their code (e.g. move the aha action into onboarding) industry: b2c|b2b|commerce|content|social|tool|game|other — a match in the same industry ranks higher.
| Name | Required | Description | Default |
|---|---|---|---|
| csv_path | Yes | ||
| industry | No | ||
| value_event | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose meaningful traits: the content is a curated public library and the figures are explicitly 'second-hand,' a genuine reliability caveat. It also exposes ranking behavior ('a match in the same industry ranks higher'). It omits auth/scope behavior and how csv_path is consumed, so it is strong but not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded and promising, but the body is fragmented: a provenance note, a bulleted output-handling list, and a dangling 'industry:' parameter note are stitched together with awkward flow. The parts mostly earn their place, but the structure scatters rather than organizes the key facts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter, 0%-coverage tool with no annotations and no output schema, the description covers provenance, presentation, and the industry parameter but omits the meaning of csv_path and value_event. It is adequate but leaves real gaps an agent must guess at.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It usefully documents the industry enum values and the ranking rule, but leaves both csv_path and value_event — the two required parameters — unexplained, covering only one of three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Find companies that hit the same problem and what they changed') and frames itself as a 'small library curated from public material.' An agent understands it retrieves analogous case studies. It does not explicitly distinguish itself from siblings like find_aha_moments or compare_benchmark, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives detailed instructions for what to do 'when you pass a case on' (explain matched_on, cite the source, offer to apply the fix), which is implicit usage/presentation guidance. However, it never says when to reach for this tool versus find_aha_moments or compare_benchmark, nor any prerequisites, leaving the agent to infer the trigger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write the HTML dot plot report — readable in three seconds, made to share with a team or an investor.
analyze calls this for you. Use it directly when you need to control the marks, the window, or a language that isn't built in.
Marks on other actions:
default: the top aha events are picked automatically (behaviour change of 30 points or more, at most two, so the report stays quiet no matter how many event types exist)
your own: mark_events={"create_playlist": "P"}, described by mark_labels
none at all: mark_events={}
Language: match the conversation. lang="en"|"ko"|"ja" are built in; for any other language translate get_report_strings() and pass it as custom_strings with lang="custom". Never translate the {brace} placeholders.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| weeks | No | ||
| csv_path | Yes | ||
| max_users | No | ||
| mark_events | No | ||
| mark_labels | No | ||
| output_path | No | dotplot_report.html | |
| value_event | Yes | ||
| custom_strings | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does substantial work: it discloses the automatic mark-selection heuristic (>=30-point behaviour change, capped at two), how to override with mark_events/mark_labels or disable entirely with mark_events={}, and the language/custom_strings workflow including the {brace} placeholder caveat. It stops short of stating that it writes/overwrites a file at output_path or any permission/performance behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the outcome ('readable in three seconds, made to share'), then a scannable bullet list for mark behavior and a compact language section. It is longer than minimal but nearly every line, including the default-heuristic details, earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation. But for a 9-parameter tool with zero annotations and zero schema descriptions, the description omits meaning for csv_path, value_event, weeks, max_users, and output_path, leaving too many required/behavioral inputs to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 9 parameters, so the description must compensate and only partially does: it explains mark_events, mark_labels, lang, and custom_strings in detail. It says nothing about csv_path, value_event, weeks, max_users, or output_path beyond the vague phrase 'the window', leaving roughly half the parameters undocumented anywhere.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and artifact: 'Write the HTML dot plot report,' which tells an agent exactly what is produced. It also implicitly separates itself from the 'analyze' sibling. However, it never distinguishes itself from the sibling tool 'dot_plot', whose name/domain overlaps, so an agent can't fully disambiguate those two from this text alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names the delegating alternative ('analyze calls this for you') and states the condition under which to call this tool directly: when you need to control marks, the window, or a non-built-in language. That is a clear when-to-use-this-vs-alternative routing statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every sentence the report can contain, in English, for translation.
For a language other than en/ko/ja:
call this,
translate the values — leave {n}, {rate_did} and every other brace placeholder exactly as they are, that is where the numbers go,
pass the result to generate_report as custom_strings with lang="custom". The code checks the placeholders survived, so the statistics stay exact.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose real behavior: the output is English source strings, brace placeholders must survive translation, and the code validates them to keep statistics exact. It omits auth requirements, rate limits, and return shape, but the placeholder-validation contract is substantive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the resource statement, then a tight three-step numbered flow, then a one-line rationale. Every sentence earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by stating the returned content (all report sentences in English). With zero parameters and no annotations, the workflow plus placeholder-warning is everything an agent needs to call it and use the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline of 4 applies. The description correctly needs to say nothing about parameter syntax and instead documents what the parameterless call returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states the resource clearly: every sentence the report can contain, in English, retrieved for translation. It does not name a verb explicitly (the 'get' is only in the tool name), and it does not differentiate itself from siblings like generate_report or describe_events by scope. Still, an agent can tell what it returns without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit conditional ('For a language other than en/ko/ja') followed by a numbered procedure, and names the destination tool (generate_report as custom_strings with lang="custom"). It effectively routes the agent between this tool and its downstream alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare today's numbers with the last analysis of the same data.
Snapshots are saved to ./.dotplot/history.json every time a report is made. Only snapshots of the same dataset are compared, so the first run of a new project has nothing to compare against — say so rather than implying zero change.
| Name | Required | Description | Default |
|---|---|---|---|
| csv_path | Yes | ||
| value_event | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose real behavior: snapshots are written to ./.dotplot/history.json on every report, and comparison is restricted to matching datasets. The first-run empty-state edge case is called out, which is genuinely useful, though the return shape and diff format are never described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with the core action front-loaded, followed by storage location and the edge case. Well sized, though the closing directive ('say so rather than implying zero change') is agent coaching rather than tool semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The edge-case and snapshot-storage context is valuable, but with no annotations, no output schema, and zero parameter documentation, an agent still lacks the input semantics and result format needed to call this confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for two required parameters (csv_path, value_event), so the description must compensate and does not. Neither parameter is mentioned or clarified, leaving value_event in particular entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and object: comparing today's numbers against the last analysis of the same data. It distinguishes itself from siblings by scoping comparison to saved snapshots rather than benchmarks or across-user analysis, though it never names the nearest alternative (compare_benchmark) explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear precondition for use: only snapshots of the same dataset are compared, so a first run in a new project has nothing to compare against. It stops short of naming alternative tools for the cases where this tool is inapplicable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pull events out of the project's database into a CSV.
How to use it:
The connection string comes from DOTPLOT_DB_URL by default. Tell the user to export it — never ask them to paste a password into the chat: export DOTPLOT_DB_URL="postgresql://readonly:...@host:5432/db" (Supabase: Dashboard > Settings > Database > Connection string)
Read the schema first (information_schema), find the tables that record what users did, and shape them into user_id, date, event. Most products have no events table — ordinary business tables are the event log: SELECT user_id::text, created_at::date AS date, 'purchase' AS event FROM orders Combine several actions with UNION ALL.
Only SELECT runs; anything else is refused. Recommend a read-only role.
Supports postgresql:// (Supabase, RDS, Neon) and sqlite:///path for testing.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| db_url | No | ||
| output_csv | No | events.csv |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it discloses that only SELECT runs (other statements are refused), recommends a read-only role, sources the connection string from DOTPLOT_DB_URL, and lists supported URL schemes (postgresql, sqlite). It omits error behavior and what happens to the output file on repeat runs, keeping it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the one-line purpose before a numbered how-to, so the agent gets the summary first. The steps are dense but each carries actionable information (env var, schema inspection, SQL example). Slightly verbose for the amount of unique content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description tells the agent the result is a CSV, where the connection comes from, and the safety model, which is enough to invoke it correctly. A moderate-complexity load tool is adequately covered, though sibling routing and the output_csv semantics remain unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that query must be a SELECT statement and that db_url defaults to DOTPLOT_DB_URL, which is valuable. However, the third parameter output_csv (default 'events.csv') is only hinted at by 'into a CSV' and never explained as a filename parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Pull events out of the project's database into a CSV.' The agent immediately understands it loads event data as CSV. It does not, however, distinguish itself from data-oriented siblings like describe_events, analyze, or get_report_strings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed procedural guidance: connection-string setup, reading the schema first, shaping rows into user_id/date/event, and combining actions with UNION ALL. This is clear context for how to use the tool, but it never names an alternative or states when this tool is the wrong choice versus the sibling analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Onboarding funnel: signup -> first value -> came back -> still active.
Answers where new users leak. A large median_days_to_value means friction between signing up and getting anything out of the product.
| Name | Required | Description | Default |
|---|---|---|---|
| csv_path | Yes | ||
| value_event | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does add interpretive value by explaining that a large median_days_to_value signals friction. However, it never states the return shape, whether csv_path is read-only, or what happens with malformed data, leaving meaningful behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The stage chain is front-loaded and immediately establishes what the tool produces, followed by two short interpretive sentences. It is compact and wastes little space, though the metric-interpretation sentence could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The funnel stages effectively describe the output columns in lieu of an output schema, which is a plus. But with no annotations and two undocumented required inputs, an agent still lacks enough to supply csv_path and value_event correctly, so it is only partially sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and both parameters are required, yet the description never explains what csv_path expects or what value_event should contain. The phrase 'first value' loosely hints at value_event's role, but neither parameter is actually defined, so the description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact artifact it produces and defines its stages (signup -> first value -> came back -> still active), so an agent knows it computes an onboarding funnel rather than a generic metric. It does not explicitly distinguish itself from siblings like retention_curve or find_aha_moments, but the resource is specific enough to act on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Answers where new users leak' implies the use case (diagnosing early-lifecycle drop-off) without stating when to prefer this over retention_curve or find_similar_cases. No exclusions, prerequisites, or alternatives are given, so usage is inferred rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Host the report and return a shareable link.
ASK THE USER FIRST. This puts their product's numbers on the public web. Only run it when they have said they want a link.
The report goes to a random path in a Vercel project and is deployed with
vercel deploy --prod. The random path plus a noindex header means only
someone with the link can reach it and search engines won't list it — but it
is still the open internet. Requires the vercel CLI to be logged in. To take
one down, delete the file under r/ and deploy again.
| Name | Required | Description | Default |
|---|---|---|---|
| html_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it discloses that the numbers become publicly reachable, that obfuscation is only random-path plus noindex (not access control), that deployment uses `vercel deploy --prod`, and what auth/tooling is required. This is exactly the context an agent needs before an irreversible public disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The consent warning is front-loaded and capitalized, which is the right ordering for a destructive-to-privacy action. Every sentence adds information, though the deployment-mechanics paragraph is longer than strictly needed for a one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the exposure model, prerequisites, and teardown, and states the return value ('a shareable link') without an output schema. The remaining gap is the undocumented html_path input, which an agent must infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single required parameter, and the description never mentions html_path — it doesn't say it is a local filesystem path to the already-generated report, nor what format is expected. The description's deployment detail is about the destination, not the input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Host the report and return a shareable link') and the mechanism (deploy to a Vercel project). An agent can distinguish this from generate_report, which produces the artifact this tool publishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use and when-not: 'ASK THE USER FIRST' and 'Only run it when they have said they want a link.' It also names the precondition (vercel CLI logged in) and the reversal path (delete the file under r/ and redeploy).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Weekly retention: share of users with a value event in week N.
Only users old enough to have reached week N count toward it, and weeks with fewer than five of them are dropped rather than reported as noise. Where the curve flattens is the retention that holds.
| Name | Required | Description | Default |
|---|---|---|---|
| csv_path | Yes | ||
| max_weeks | No | ||
| value_event | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two real behavioral traits: cohort eligibility (only users old enough to reach week N count) and small-sample suppression (weeks with fewer than five such users are dropped, not reported). It still omits file access expectations, permissions, and result shape, so it is only partially complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the metric definition before the cohort rules and the interpretation. Little waste, though 'rather than reported as noise' is slightly expository filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must set expectations alone. It does well on metric semantics and data-handling rules but leaves the required csv_path and value_event parameters, and the returned structure, undefined for an agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and all three parameters are undocumented in both schema and description. The phrase 'value event in week N' loosely hints at value_event, and max_weeks maps to week N, but csv_path, expected file format, and the meaning/default behavior of max_weeks are never explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a precise, self-contained definition of the metric: weekly retention as the share of users with a value event in week N. That is specific enough to separate it from funnel or aha-moment siblings, but it never names or contrasts an alternative tool, so sibling differentiation is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to reach for retention_curve versus onboarding_funnel, history_compare, or compare_benchmark. The interpretive note ('where the curve flattens is the retention that holds') helps read the output but says nothing about when or why to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit five aggregate numbers to the anonymous benchmark. Opt-in.
Set consent=True only after the user has explicitly agreed. When you ask, show them exactly what leaves the machine — user count, churn rate, weekend rate, regular rate, aha lift, and nothing else. No user IDs, no event log, no product name.
industry: b2c|b2b|commerce|content|social|tool|game|other stage: pre_launch|under_100_users|under_1k_users|over_1k_users
| Name | Required | Description | Default |
|---|---|---|---|
| stage | Yes | ||
| consent | No | ||
| csv_path | Yes | ||
| industry | Yes | ||
| value_event | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses privacy behavior directly: exactly what data leaves the machine and what does not (no user IDs, no event log, no product name). It does not cover submission side effects, failure modes, or response behavior, keeping it below 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and the opt-in constraint are front-loaded, and the enum listings for industry and stage earn their place since the schema lacks them. The trailing enum block is slightly crammed but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an opt-in submission tool with no output schema and no annotations, the privacy disclosure and enum values are good, but the meaning/format of csv_path and value_event is never explained, leaving an agent guessing about required inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It supplies the only enum values for industry and stage and gives consent usage guidance, which is real value. However, the two required params csv_path and value_event are entirely undefined, leaving half the parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Submit five aggregate numbers to the anonymous benchmark') and enumerates exactly which metrics are submitted, which is unusually concrete. It does not explicitly distinguish itself from siblings like compare_benchmark, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly frames the tool as opt-in and gives an explicit precondition for consent=True ('only after the user has explicitly agreed'). It does not name alternative tools or state when-not to use it, so it lacks the exclusion/alternative coverage of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.4analyzeaudit_trackingclassify_userscompare_benchmarkdescribe_eventsdot_plotfind_aha_momentsfind_similar_casesgenerate_reportget_report_stringshistory_compareload_from_dbonboarding_funnelpublish_reportretention_curvesubmit_benchmarkScored across 16 tools
Each tool has a distinct, clearly-stated purpose, and the descriptions explicitly disambiguate the large overlap between the meta-tool analyze and its component tools (dot_plot, find_aha_moments, retention_curve, generate_report by naming analyze as 'START HERE' and the others as 'parts'. Boundaries are clear in text but the pipeline-vs-composite overlap still requires careful reading to avoid picking a component when the whole workflow is wanted.
Names are uniformly snake_case, which is the key consistency factor. There is mild variation between verb_noun forms (get_report_strings, generate_report, classify_users, find_aha_moments) and noun phrases (dot_plot, retention_curve, onboarding_funnel), but the convention is predictable enough to navigate.
16 tools is slightly on the heavy side but justified for a full product-analytics suite spanning ingest, analysis, benchmarking, publishing, and history. Nearly every tool earns its place, though some (compare_benchmark, submit_benchmark, find_similar_cases) are peripheral.
The surface covers the lifecycle well: data ingestion (load_from_db, describe_events), the full analysis workflow (analyze plus components), external context (compare_benchmark, find_similar_cases, history_compare), and output (generate_report, publish_report). No obvious dead ends, though there is no raw-data export or report deletion tool.
Clamp Analytics MCP server: traffic, revenue, funnels, cohorts, errors, and search, for AI agents.
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Analytics your AI agent can actually use. Track, experiment, and optimize via MCP.
First-party unsampled Shopify analytics MCP — sessions, attribution, funnels, leaks. 26 tools.
