PostHog Automation via Rube MCP

Automate PostHog product analytics and feature flag management through Composio's PostHog toolkit via Rube MCP.

Toolkit docs

:

composio.dev/toolkits/posthog

Prerequisites

Rube MCP must be connected (RUBE_SEARCH_TOOLS available)

Active PostHog connection via

RUBE_MANAGE_CONNECTIONS

with toolkit

posthog

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

posthog

If connection is not ACTIVE, follow the returned auth link to complete PostHog authentication

Confirm connection status shows ACTIVE before running any workflows

Core Workflows

1. Capture Events

When to use

User wants to send event data to PostHog for analytics tracking

Tool sequence

:

POSTHOG_CAPTURE_EVENT

- Send one or more events to PostHog [Required]

Key parameters

:

event

Event name (e.g., '$pageview', 'user_signed_up', 'purchase_completed')

distinct_id

Unique user identifier (required)

properties

Object with event-specific properties

timestamp

ISO 8601 timestamp (optional; defaults to server time)

Pitfalls

:

distinct_id

is required for every event; identifies the user/device

PostHog system events use

$

prefix (e.g., '$pageview', '$identify')

Custom events should NOT use the

$

prefix

Properties are freeform; maintain consistent schemas across events

Events are processed asynchronously; ingestion delay is typically seconds

2. List and Filter Events

When to use

User wants to browse or search through captured events

Tool sequence

:

POSTHOG_LIST_AND_FILTER_PROJECT_EVENTS

- Query events with filters [Required]

Key parameters

:

project_id

PostHog project ID (required)

event

Filter by event name

person_id

Filter by person ID

after

Events after this ISO 8601 timestamp

before

Events before this ISO 8601 timestamp

limit

Maximum events to return

offset

Pagination offset

Pitfalls

:

project_id

is required; resolve via LIST_PROJECTS first

Date filters use ISO 8601 format (e.g., '2024-01-15T00:00:00Z')

Large event volumes require pagination; use

offset

and

limit

Results are returned in reverse chronological order by default

Event properties are nested; parse carefully

3. Manage Feature Flags

When to use

User wants to create, view, or manage feature flags

Tool sequence

:

POSTHOG_LIST_AND_MANAGE_PROJECT_FEATURE_FLAGS

- List existing feature flags [Required]

POSTHOG_RETRIEVE_FEATURE_FLAG_DETAILS

- Get detailed flag configuration [Optional]

POSTHOG_CREATE_FEATURE_FLAGS_FOR_PROJECT

- Create a new feature flag [Optional]

Key parameters

:

For listing:

project_id

(required)

For details:

project_id

,

id

(feature flag ID)

For creation:

project_id

Target project

key

Flag key (e.g., 'new-dashboard-beta')

name

Human-readable name

filters

Targeting rules and rollout percentage

active

Whether the flag is enabled

Pitfalls

:

Feature flag

key

must be unique within a project

Flag keys should use kebab-case (e.g., 'my-feature-flag')

filters

define targeting groups with properties and rollout percentages

Creating a flag with

active: true

immediately enables it for matching users

Flag changes take effect within seconds due to PostHog's polling mechanism

4. Manage Projects

When to use

User wants to list or inspect PostHog projects and organizations

Tool sequence

:

POSTHOG_LIST_PROJECTS_IN_ORGANIZATION_WITH_PAGINATION

- List all projects [Required]

Key parameters

:

organization_id

Organization identifier (may be optional depending on auth)

limit

Number of results per page

offset

Pagination offset

Pitfalls

:

Project IDs are numeric; used as parameters in most other endpoints

Organization ID may be required; check your PostHog setup

Pagination is offset-based; iterate until results are empty

Project settings include API keys and configuration details

5. User Profile and Authentication

When to use

User wants to check current user details or verify API access Tool sequence : POSTHOG_WHOAMI - Get current API user information [Optional] POSTHOG_RETRIEVE_CURRENT_USER_PROFILE - Get detailed user profile [Optional] Key parameters : No required parameters for either call Returns current authenticated user's details, permissions, and organization info Pitfalls : WHOAMI is a lightweight check; use for verifying API connectivity User profile includes organization membership and permissions These endpoints confirm the API key's access level and scope Common Patterns ID Resolution Organization -> Project ID : 1. Call POSTHOG_LIST_PROJECTS_IN_ORGANIZATION_WITH_PAGINATION 2. Find project by name in results 3. Extract id (numeric) for use in other endpoints Feature flag name -> Flag ID : 1. Call POSTHOG_LIST_AND_MANAGE_PROJECT_FEATURE_FLAGS with project_id 2. Find flag by key or name 3. Extract id for detailed operations Feature Flag Targeting Feature flags support sophisticated targeting: { "filters" : { "groups" : [ { "properties" : [ { "key" : "email" , "value" : "@company.com" , "operator" : "icontains" } ] , "rollout_percentage" : 100 } , { "properties" : [ ] , "rollout_percentage" : 10 } ] } } Groups are evaluated in order; first matching group determines the rollout Properties filter users by their traits Rollout percentage determines what fraction of matching users see the flag Pagination Events: Use offset and limit (offset-based) Feature flags: Use offset and limit (offset-based) Projects: Use offset and limit (offset-based) Continue until results array is empty or smaller than limit Known Pitfalls Project IDs : Required for most API endpoints Always resolve project names to numeric IDs first Multiple projects can exist in one organization Event Naming : System events use $ prefix ($pageview, $identify, $autocapture) Custom events should NOT use $ prefix Event names are case-sensitive; maintain consistency Feature Flags : Flag keys must be unique within a project Use kebab-case for flag keys Changes propagate within seconds Deleting a flag is permanent; consider disabling instead Rate Limits : Event ingestion has throughput limits Batch events where possible for efficiency API endpoints have per-minute rate limits Response Parsing : Response data may be nested under data or results key Paginated responses include count , next , previous fields Event properties are nested objects; access carefully Parse defensively with fallbacks for optional fields Quick Reference Task Tool Slug Key Params Capture event POSTHOG_CAPTURE_EVENT event, distinct_id, properties List events POSTHOG_LIST_AND_FILTER_PROJECT_EVENTS project_id, event, after, before List feature flags POSTHOG_LIST_AND_MANAGE_PROJECT_FEATURE_FLAGS project_id Get flag details POSTHOG_RETRIEVE_FEATURE_FLAG_DETAILS project_id, id Create flag POSTHOG_CREATE_FEATURE_FLAGS_FOR_PROJECT project_id, key, filters List projects POSTHOG_LIST_PROJECTS_IN_ORGANIZATION_WITH_PAGINATION organization_id Who am I POSTHOG_WHOAMI (none) User profile POSTHOG_RETRIEVE_CURRENT_USER_PROFILE (none) Powered by Composio