Skip to main content
Glama

Posthog Connector

posthog_connector
Read-onlyIdempotent

PostHog product analytics: account/project info, raw events, person records, event definitions, HogQL queries, and funnel conversion analysis. Read-only via Personal API key (Path A). When the user asks for a visual, trend, comparison, or recap, call chart_render with the numeric values returned by this connector. If the connector result includes a verified chart_provenance token, the same authenticated user may pass it as provenance_token within 15 minutes, on any replica, and map every value to its exact source_path so chart_render preserves verified provenance. Without a valid connector receipt, chart_render labels values as unverified_model_data. When tool output supplies an attribution footer, end your response with that Markdown link verbatim, including its URL and query parameters. Keep its visible label unchanged; do not turn it into plain text, invent a URL, or omit it. Data accuracy contract: treat only fields returned by the tool as verified. Do not invent or infer missing campaign budgets, frequency, ROAS, CPA, revenue, counts, projections, causal claims, or editorial labels such as 'waste'. Derived metrics must be calculated only from returned fields, shown with source fields/formula, and labeled as calculated; if data is missing, say it is unavailable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesget_account_info: Get PostHog account and project metadata for the connected user. Returns the user email, organization name, project ID, | list_events: List recent raw events captured by PostHog for the project. Returns event ID, event name, distinct ID, timestamp, the fu | list_persons: List person records for the PostHog project. A person is PostHog's unified user record, aggregating events from one or m | get_event_definitions: List event-name definitions for the project — the event catalog that tells you what event names can actually be queried | run_query: Execute a HogQL query against PostHog events and persons. HogQL is PostHog's SQL-like query language — use it for compou | get_funnel: Compute a funnel over an ordered list of event steps. Returns the per-step user count, the conversion rate from the firs
paramsNoAction-specific parameters. get_account_info: none | list_events: {project_id?: integer, event?: string, after?: string, before?: string, limit?: integer} | list_persons: {project_id?: integer, search?: string, limit?: integer} | get_event_definitions: {project_id?: integer, search?: string, limit?: integer} | run_query: {query: string, project_id?: integer, limit?: integer} | get_funnel: {steps: array, project_id?: integer, date_from?: string, date_to?: string}

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Added
  4. Removed
  5. Added

TDQS

A3.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnly/idempotent/destructive, but the description adds substantial context beyond them: authentication via Personal API key, the 15-minute provenance_token validity window and replica-agnostic reuse, the requirement to echo the attribution footer verbatim, and a data-accuracy contract governing derived metrics. These are real behavioral and output-handling traits an agent could not get from the annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentence front-loads purpose well, but the bulk of the text is devoted to chart_render routing, provenance tokens, footer formatting, and a generic accuracy policy rather than this tool's own behavior. It is long and mixes cross-tool concerns into the connector definition, diluting the signal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does supply enough context to call it correctly: access mode, the six actions with their return shapes (via the enum docs), provenance semantics, and output-format obligations. What is missing is any statement of limits, pagination, or error behavior for the raw list/query actions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the action enum plus params object already document each operation and its action-specific fields. The description restates the data domains but adds no syntax, format, or default-value detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific product (PostHog) and enumerates the concrete data domains it exposes — account/project info, raw events, person records, event definitions, HogQL queries, and funnel conversion — so an agent can tell what it does. It does not differentiate itself from the sibling posthog_dashboard, so the sibling boundary is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the access mode ('Read-only via Personal API key (Path A)') and gives a clear hand-off rule for chart_render when a visual/trend/comparison is requested. However, it never says when to use this connector versus posthog_dashboard or the other *_connector siblings, so selection guidance is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources