$npx -y skills add SamarthaKV29/antigravity-god-mode --skill amplitude-automationAutomate Amplitude tasks via Rube MCP (Composio): events, user activity, cohorts, user identification. Always search tools first for current schemas.
| 1 | # Amplitude Automation via Rube MCP |
| 2 | |
| 3 | Automate Amplitude product analytics through Composio's Amplitude toolkit via Rube MCP. |
| 4 | |
| 5 | ## Prerequisites |
| 6 | |
| 7 | - Rube MCP must be connected (RUBE_SEARCH_TOOLS available) |
| 8 | - Active Amplitude connection via `RUBE_MANAGE_CONNECTIONS` with toolkit `amplitude` |
| 9 | - Always call `RUBE_SEARCH_TOOLS` first to get current tool schemas |
| 10 | |
| 11 | ## Setup |
| 12 | |
| 13 | **Get Rube MCP**: Add `https://rube.app/mcp` as an MCP server in your client configuration. No API keys needed — just add the endpoint and it works. |
| 14 | |
| 15 | |
| 16 | 1. Verify Rube MCP is available by confirming `RUBE_SEARCH_TOOLS` responds |
| 17 | 2. Call `RUBE_MANAGE_CONNECTIONS` with toolkit `amplitude` |
| 18 | 3. If connection is not ACTIVE, follow the returned auth link to complete Amplitude authentication |
| 19 | 4. Confirm connection status shows ACTIVE before running any workflows |
| 20 | |
| 21 | ## Core Workflows |
| 22 | |
| 23 | ### 1. Send Events |
| 24 | |
| 25 | **When to use**: User wants to track events or send event data to Amplitude |
| 26 | |
| 27 | **Tool sequence**: |
| 28 | 1. `AMPLITUDE_SEND_EVENTS` - Send one or more events to Amplitude [Required] |
| 29 | |
| 30 | **Key parameters**: |
| 31 | - `events`: Array of event objects, each containing: |
| 32 | - `event_type`: Name of the event (e.g., 'page_view', 'purchase') |
| 33 | - `user_id`: Unique user identifier (required if no `device_id`) |
| 34 | - `device_id`: Device identifier (required if no `user_id`) |
| 35 | - `event_properties`: Object with custom event properties |
| 36 | - `user_properties`: Object with user properties to set |
| 37 | - `time`: Event timestamp in milliseconds since epoch |
| 38 | |
| 39 | **Pitfalls**: |
| 40 | - At least one of `user_id` or `device_id` is required per event |
| 41 | - `event_type` is required for every event; cannot be empty |
| 42 | - `time` must be in milliseconds (13-digit epoch), not seconds |
| 43 | - Batch limit applies; check schema for maximum events per request |
| 44 | - Events are processed asynchronously; successful API response does not mean data is immediately queryable |
| 45 | |
| 46 | ### 2. Get User Activity |
| 47 | |
| 48 | **When to use**: User wants to view event history for a specific user |
| 49 | |
| 50 | **Tool sequence**: |
| 51 | 1. `AMPLITUDE_FIND_USER` - Find user by ID or property [Prerequisite] |
| 52 | 2. `AMPLITUDE_GET_USER_ACTIVITY` - Retrieve user's event stream [Required] |
| 53 | |
| 54 | **Key parameters**: |
| 55 | - `user`: Amplitude internal user ID (from FIND_USER) |
| 56 | - `offset`: Pagination offset for event list |
| 57 | - `limit`: Maximum number of events to return |
| 58 | |
| 59 | **Pitfalls**: |
| 60 | - `user` parameter requires Amplitude's internal user ID, NOT your application's user_id |
| 61 | - Must call FIND_USER first to resolve your user_id to Amplitude's internal ID |
| 62 | - Activity is returned in reverse chronological order by default |
| 63 | - Large activity histories require pagination via `offset` |
| 64 | |
| 65 | ### 3. Find and Identify Users |
| 66 | |
| 67 | **When to use**: User wants to look up users or set user properties |
| 68 | |
| 69 | **Tool sequence**: |
| 70 | 1. `AMPLITUDE_FIND_USER` - Search for a user by various identifiers [Required] |
| 71 | 2. `AMPLITUDE_IDENTIFY` - Set or update user properties [Optional] |
| 72 | |
| 73 | **Key parameters**: |
| 74 | - For FIND_USER: |
| 75 | - `user`: Search term (user_id, email, or Amplitude ID) |
| 76 | - For IDENTIFY: |
| 77 | - `user_id`: Your application's user identifier |
| 78 | - `device_id`: Device identifier (alternative to user_id) |
| 79 | - `user_properties`: Object with `$set`, `$unset`, `$add`, `$append` operations |
| 80 | |
| 81 | **Pitfalls**: |
| 82 | - FIND_USER searches across user_id, device_id, and Amplitude ID |
| 83 | - IDENTIFY uses special property operations (`$set`, `$unset`, `$add`, `$append`) |
| 84 | - `$set` overwrites existing values; `$setOnce` only sets if not already set |
| 85 | - At least one of `user_id` or `device_id` is required for IDENTIFY |
| 86 | - User property changes are eventually consistent; not immediate |
| 87 | |
| 88 | ### 4. Manage Cohorts |
| 89 | |
| 90 | **When to use**: User wants to list cohorts, view cohort details, or update cohort membership |
| 91 | |
| 92 | **Tool sequence**: |
| 93 | 1. `AMPLITUDE_LIST_COHORTS` - List all saved cohorts [Required] |
| 94 | 2. `AMPLITUDE_GET_COHORT` - Get detailed cohort information [Optional] |
| 95 | 3. `AMPLITUDE_UPDATE_COHORT_MEMBERSHIP` - Add/remove users from a cohort [Optional] |
| 96 | 4. `AMPLITUDE_CHECK_COHORT_STATUS` - Check async cohort operation status [Optional] |
| 97 | |
| 98 | **Key parameters**: |
| 99 | - For LIST_COHORTS: No required parameters |
| 100 | - For GET_COHORT: `cohort_id` (from list results) |
| 101 | - For UPDATE_COHORT_MEMBERSHIP: |
| 102 | - `cohort_id`: Target cohort ID |
| 103 | - `memberships`: Object with `add` and/or `remove` arrays of user IDs |
| 104 | - For CHECK_COHORT_STATUS: `request_id` from update response |
| 105 | |
| 106 | **Pitfalls**: |
| 107 | - Cohort IDs are required for all cohort-specific operations |
| 108 | - UPDATE_COHORT_MEMBERSHIP is asynchronous; use CHECK_COHORT_STATUS to verify |
| 109 | - `request_id` from the update response is needed for status checking |
| 110 | - Maximum membership changes per request may be limited; chunk large updates |
| 111 | - Only behavioral cohorts support API membership updates |
| 112 | |
| 113 | ### 5. Browse Event Categories |
| 114 | |
| 115 | **When to use**: User wants to discover available event types and categories in Amplitude |
| 116 | |
| 117 | **To |