Send events to Amplitude and query its analytics — segmentation, funnels, retention, cohorts, user activity and chart results.
Amplitude ships in the w6w first-party pack. It declares 15 actions, 2 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.amplitudeAmplitude is a product analytics platform, and this app covers both halves of it: sending events and identifying users and groups, and querying the analytics built on top of them — segmentation, funnel conversion, retention curves, cohorts, and a user’s own recent activity. It is the app to reach for when a workflow needs to record what happened in a product, or answer a question about it, without hand-rolling calls to Amplitude’s separate ingest and query APIs.
Beyond the basics, it handles the details that make Amplitude’s API easy to get subtly wrong: duplicate event delivery is deduplicated automatically rather than double-counted, a batch send reports exactly which events were rejected so only those need resending, and release annotations can be marked on every chart in a project. Cohort and event-taxonomy reads make it possible to pull the same segments and definitions the Amplitude dashboard uses. GDPR-style user erasure is also supported, for workflows that need to remove a person’s data on request.
Three routes to the same 15 actions. The Workflow tab is generated from Amplitude's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
annotation-create Mark a date on every chart — the release marker. There is NO uniqueness: posting twice leaves two identical lines, and removing them is a manual job.
annotation-list The vertical lines on every chart — releases, campaigns, incidents. They are project-wide, so one added for a single question appears everywhere.
chart-query Run a chart somebody already built, instead of reconstructing its query. It uses the chart's own saved date range, which cannot be overridden here.
cohort-list Behavioural cohorts — saved sets of users defined by what they did. `size` is as of the last recomputation, and a cohort that stopped recomputing keeps reporting it.
event-batch Bulk-load events through the higher-throughput queue. Same payload as `event-track`, far more generous throttling, and a longer delay before the data is queryable.
event-list The project's event taxonomy as it actually is. Hidden and deleted events are still listed — which is the only way to notice that a chart's event was tidied away.
event-segmentation The query behind most Amplitude charts. The response is PARALLEL ARRAYS — series of numbers lined up against a separate list of dates, with no labels inside them.
event-track Send events. Ids under 5 characters are SILENTLY REMOVED by Amplitude, and a retry double-counts unless insert_id is stable — both are handled here.
funnel-query Conversion through a sequence. The conversion WINDOW changes the answer more than anything else and defaults to 7 days; the step counts are cumulative, so drop-off is computed here.
group-identify Set properties on an account or workspace rather than a person. Group analytics is a paid feature and this accepts the request regardless — the properties just never appear.
retention-query Do people come back. The retention MODE — N-day, rolling or brackets — changes the same data into three very different curves, so a number without its mode means nothing.
user-activity One user's recent events — the support question, not an analytics one. It takes the AMPLITUDE ID, and a user id returns nothing rather than erroring.
user-delete Erase every event and property for named users, permanently. Asynchronous — it takes up to 30 days, so the user remaining queryable afterwards is expected.
user-identify Set properties on a user without sending an event. Use `$setOnce` for anything that should keep its first value — a plain object is `$set` and rewrites it every time.
user-search Find a user by id, device or Amplitude id. One person can be SEVERAL Amplitude ids if they used more than one device before signing in — taking the first loses the rest.
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying Amplitude's real ids.
{
"manifestVersion": "2",
"name": "amplitude-example",
"steps": [
{
"id": "annotation-create",
"uses": {
"app": "io.w6w.amplitude",
"action": "annotation-create",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"date": "<date>",
"label": "<label>"
}
}
]
}annotation-create annotation-list chart-query cohort-list event-batch +10 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for Amplitude, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to Amplitude. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "annotation-create",
payload: {
date: "<value>",
label: "<value>",
// chartId: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action annotation-create --payload '{"date":"<value>","label":"<value>"}' Give an AI agent Amplitude — without giving it Amplitude's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.amplitude#annotation-create",
"input": {
"date": "<date>",
"label": "<label>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's Amplitude connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
Amplitude's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. Amplitude itself is MIT, and the runtime that executes it is source-available (FSL).
Amplitude declares its own checks, so its health is a property of the app rather than something the host guesses at.
Amplitude's status page, which separates INGEST (Data Reception) from QUERY (Web Reporting). They fail independently, and which half is affected decides whether a workflow cares.