First-party app
Amplitude

Amplitude

Send events to Amplitude and query its analytics — segmentation, funnels, retention, cohorts, user activity and chart results.

stable Analytics & BIMarketing

About

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.

App id
io.w6w.amplitude
Version
0.1.1
Author
w6w
Licence
MIT
Categories
Analytics & BI · Marketing

Overview

Amplitude 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.

Build with Amplitude

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.

Add an annotation

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.

List annotations

annotation-list

The vertical lines on every chart — releases, campaigns, incidents. They are project-wide, so one added for a single question appears everywhere.

Run a saved chart

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.

List cohorts

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.

Batch-load events

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.

List event types

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.

Query event segmentation

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.

Track events

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.

Query a funnel

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.

Set group properties

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.

Query retention

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.

Get a user's activity

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.

Delete users (GDPR)

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.

Set user properties

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.

Search for a user

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>"
      }
    }
  ]
}

Here are some of the things you can do

  • Add an annotation

    perform
    annotation-create
  • List annotations

    read
    annotation-list
  • Run a saved chart

    search
    chart-query
  • List cohorts

    read
    cohort-list
  • Batch-load events

    perform
    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.

Install
npm install @w6w/sdk
yarn add @w6w/sdk
pnpm add @w6w/sdk
deno add npm:@w6w/sdk
Code
import { 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);
Install the CLI
npm install -g @w6w/cli
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.

What the agent gets

Credentials it can't read

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.

A tool surface scoped to the caller

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.

A durable workflow in one call

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.

Health-aware discovery

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).

Request MCP access

Health checks

Amplitude declares its own checks, so its health is a property of the app rather than something the host guesses at.

service

Amplitude service status

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.

quota

Request headroom