posthog-toolkit-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| POSTHOG_HOST | Yes | Required. The PostHog instance URL, e.g. https://us.posthog.com, https://eu.posthog.com, or a self-hosted URL. | |
| POSTHOG_API_KEY | Yes | Required. A personal API key (phx_...). A project token (phc_...) is rejected at startup. | |
| POSTHOG_PROJECT_ID | No | Default project for the tools and for {project_id} in paths. | |
| POSTHOG_TIMEOUT_MS | No | Request timeout in milliseconds. Default 120000. | 120000 |
| POSTHOG_ALLOW_WRITE | No | Set to 1, true or yes to register posthog_api_request. Off by default. | false |
| POSTHOG_MAX_RESPONSE_CHARS | No | Cap on a tool response. Default 100000. | 100000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| posthog_queryA | Runs a HogQL (ClickHouse SQL dialect) query: tables events, persons, sessions, groups, raw_session_replay_events. Example: SELECT event, count() FROM events WHERE timestamp > now() - INTERVAL 7 DAY GROUP BY event ORDER BY 2 DESC LIMIT 20. |
| posthog_event_definitionsA | Event names seen in a project, with when each was last seen. Use it instead of guessing event names in HogQL. |
| posthog_property_definitionsA | Event or person property names in a project, with their types. Use it instead of guessing property names in HogQL. |
| posthog_replaysA | Session recordings of one distinct_id in a time window, newest first, with links to watch them. Recordings older than the instance retention are gone. Naive timestamps are read in the project timezone. |
| posthog_projectsA | Projects of the organization with their ids. Works with API keys scoped to specific projects. |
| posthog_api_getA | GET any PostHog REST endpoint for what HogQL does not cover: feature flags, insights, dashboards, experiments, cohorts. {project_id} in the path is replaced with the default project, e.g. /api/projects/{project_id}/feature_flags/ |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool targets a distinct area—definitions, projects, HogQL querying, replays, and generic REST access—so an agent can usually choose correctly. The only mild overlap is between posthog_query and posthog_api_get, but the HogQL vs REST distinction is clearly drawn.
All tools share a posthog_ prefix and snake_case, but the pattern is mixed: event_definitions, projects, property_definitions, and replays are resource nouns, while posthog_query is an operation and posthog_api_get introduces a verb suffix. It is readable but not a consistent verb_noun scheme.
Six tools cover the core PostHog introspection and querying use cases without padding. The generic posthog_api_get tool avoids the need for many narrowly-scoped REST endpoint tools.
Event/property definitions, project selection, HogQL querying, session replays, and a generic REST GET cover the main read and analysis workflows. Write/update operations are not exposed through the REST wrapper, but that appears intentionally out of scope for this query-oriented toolkit.