Amplitude Automation via Rube MCP

Automate Amplitude product analytics through Composio's Amplitude toolkit via Rube MCP.

Prerequisites

• Rube MCP must be connected (RUBE_SEARCH_TOOLS available)
• Active Amplitude connection via RUBE_MANAGE_CONNECTIONS with toolkit amplitude
• Always call RUBE_SEARCH_TOOLS first to get current tool schemas

Setup

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.

• Verify Rube MCP is available by confirming RUBE_SEARCH_TOOLS responds
• Call RUBE_MANAGE_CONNECTIONS with toolkit amplitude
• If connection is not ACTIVE, follow the returned auth link to complete Amplitude authentication
• Confirm connection status shows ACTIVE before running any workflows

Core Workflows

1. Send Events

When to use: User wants to track events or send event data to Amplitude

Tool sequence:

• AMPLITUDE_SEND_EVENTS - Send one or more events to Amplitude [Required]

• events: Array of event objects, each containing:
• event_type: Name of the event (e.g., 'page_view', 'purchase')
• user_id: Unique user identifier (required if no device_id)
• device_id: Device identifier (required if no user_id)
• event_properties: Object with custom event properties
• user_properties: Object with user properties to set
• time: Event timestamp in milliseconds since epoch

• At least one of user_id or device_id is required per event
• event_type is required for every event; cannot be empty
• time must be in milliseconds (13-digit epoch), not seconds
• Batch limit applies; check schema for maximum events per request
• Events are processed asynchronously; successful API response does not mean data is immediately queryable

2. Get User Activity

When to use: User wants to view event history for a specific user

Tool sequence:

• AMPLITUDE_FIND_USER - Find user by ID or property [Prerequisite]
• AMPLITUDE_GET_USER_ACTIVITY - Retrieve user's event stream [Required]

• user: Amplitude internal user ID (from FIND_USER)
• offset: Pagination offset for event list
• limit: Maximum number of events to return

• user parameter requires Amplitude's internal user ID, NOT your application's user_id
• Must call FIND_USER first to resolve your user_id to Amplitude's internal ID
• Activity is returned in reverse chronological order by default
• Large activity histories require pagination via offset

3. Find and Identify Users

When to use: User wants to look up users or set user properties

Tool sequence:

• AMPLITUDE_FIND_USER - Search for a user by various identifiers [Required]
• AMPLITUDE_IDENTIFY - Set or update user properties [Optional]

• For FIND_USER:
• user: Search term (user_id, email, or Amplitude ID)
• For IDENTIFY:
• user_id: Your application's user identifier
• device_id: Device identifier (alternative to user_id)
• user_properties: Object with $set, $unset, $add, $append operations

• FIND_USER searches across user_id, device_id, and Amplitude ID
• IDENTIFY uses special property operations ($set, $unset, $add, $append)
• $set overwrites existing values; $setOnce only sets if not already set
• At least one of user_id or device_id is required for IDENTIFY
• User property changes are eventually consistent; not immediate

4. Manage Cohorts

When to use: User wants to list cohorts, view cohort details, or update cohort membership

Tool sequence:

• AMPLITUDE_LIST_COHORTS - List all saved cohorts [Required]
• AMPLITUDE_GET_COHORT - Get detailed cohort information [Optional]
• AMPLITUDE_UPDATE_COHORT_MEMBERSHIP - Add/remove users from a cohort [Optional]
• AMPLITUDE_CHECK_COHORT_STATUS - Check async cohort operation status [Optional]

• For LIST_COHORTS: No required parameters
• For GET_COHORT: cohort_id (from list results)
• For UPDATE_COHORT_MEMBERSHIP:
• cohort_id: Target cohort ID
• memberships: Object with add and/or remove arrays of user IDs
• For CHECK_COHORT_STATUS: request_id from update response

• Cohort IDs are required for all cohort-specific operations
• UPDATE_COHORT_MEMBERSHIP is asynchronous; use CHECK_COHORT_STATUS to verify
• request_id from the update response is needed for status checking
• Maximum membership changes per request may be limited; chunk large updates
• Only behavioral cohorts support API membership updates

5. Browse Event Categories

When to use: User wants to discover available event types and categories in Amplitude

Tool sequence:

• AMPLITUDE_GET_EVENT_CATEGORIES - List all event categories [Required]

• No required parameters; returns all configured event categories

• Categories are configured in Amplitude UI; API provides read access
• Event names within categories are case-sensitive
• Use these categories to validate event_type values before sending events

Common Patterns

ID Resolution

Application user_id -> Amplitude internal ID:

1. Call AMPLITUDE_FIND_USER with user=your_user_id
2. Extract Amplitude's internal user ID from response
3. Use internal ID for GET_USER_ACTIVITY

Cohort name -> Cohort ID:

1. Call AMPLITUDE_LIST_COHORTS
2. Find cohort by name in results
3. Extract id for cohort operations

User Property Operations

Amplitude IDENTIFY supports these property operations:

• $set: Set property value (overwrites existing)
• $setOnce: Set only if property not already set
• $add: Increment numeric property
• $append: Append to list property
• $unset: Remove property entirely

{
  "user_properties": {
    "$set": {"plan": "premium", "company": "Acme"},
    "$add": {"login_count": 1}
  }
}

Async Operation Pattern

For cohort membership updates:

1. Call AMPLITUDE_UPDATE_COHORT_MEMBERSHIP -> get request_id
2. Call AMPLITUDE_CHECK_COHORT_STATUS with request_id
3. Repeat step 2 until status is 'complete' or 'error'

Known Pitfalls

User IDs:

• Amplitude has its own internal user IDs separate from your application's
• FIND_USER resolves your IDs to Amplitude's internal IDs
• GET_USER_ACTIVITY requires Amplitude's internal ID, not your user_id

• Must be in milliseconds since epoch (13 digits)
• Seconds (10 digits) will be interpreted as very old dates
• Omitting timestamp uses server receive time

• Event ingestion has throughput limits per project
• Batch events where possible to reduce API calls
• Cohort membership updates have async processing limits

• Response data may be nested under data key
• User activity returns events in reverse chronological order
• Cohort lists may include archived cohorts; check status field
• Parse defensively with fallbacks for optional fields

Quick Reference