Discovery

Two things evolve under you: the team’s product mix (they adopt new products, turn others off) and PostHog’s own offering (new products ship with new MCP tools). The reliable substrate through both is the MCP tool surface — it tracks what’s possible to look at and grows over time. Lean on it: a tool family that wasn’t there last time is a strong hint of a product worth folding into the map.

One cheap pass, then a durable map you keep current

Discovery is amortized, not repeated every run:

• No pattern:general:coverage-map yet (early runs): spend this run building it. Run the breadth pass below, then write the map.
• Map exists and is recent: skip discovery. Read it, pick a live surface, and investigate — rotating across surfaces over successive runs.
• Map is stale (~weekly, or the project clearly changed): re-sense-check it. Re-run the breadth pass, skim the MCP tools for capabilities new since last time, and update the parts that drifted. Don’t assume last week’s map is still complete — products appear on both sides.

Stay bounded — discovery is orientation, not investigation. A handful of cheap reads is enough; you have future runs to go deep.

Breadth pass: event taxonomy + tool surface

Two cheap reads do most of the work.

1. The event taxonomy. read-data-schema (events) returns the event names this team captures — and the names alone reveal which products are live:

2. The MCP tool surface. Skim the available tools (the MCP’s own search / tools discovery). New query-* or product tool families that weren’t there before are how you notice PostHog shipped a product you don’t yet have a lens for — pick it up and probe whether this team uses it.

Pair both with the profile’s configured-entity sections (dashboards, flags, experiments, surveys, pipelines, warehouse sources, cohorts): together they tell you what’s “configured,” what’s “emitting,” and what’s “now possible to query.”

Confirm the surfaces the taxonomy can’t show

A few products don’t announce themselves cleanly in the event list — probe them directly when the breadth pass hints they might be present, one cheap read each:

• Error tracking — query-error-tracking-issues-list (issue count + recent activity; $exception volume alone doesn’t tell you issue state).
• Session replay — query-session-recordings-list (are sessions recording, and how recently?).
• Logs — query-logs (any volume, by service / severity).
• Tracing / APM — query-apm-spans (OTel spans present?).
• LLM analytics — query-llm-traces-list (live traces, not just $ai_* counts).
• Revenue — revenue events in the taxonomy, or warehouse Stripe sources in the profile.
• Data warehouse — the profile’s external_data_sources; deeper structure via execute-sql over system.information_schema.*.

When you hit a surface no tool seems to cover, that’s worth a mcp-gap: scratchpad note (see conventions.md) — a capability the fleet may want later.

Write the coverage map

Persist what you found as a single durable entry, overwriting it in place (pattern:general:coverage-map). Make it future-run actionable: each live product with a rough volume / last-seen and a one-line “what’s worth watching here,” an explicit list of products that are absent so future runs don’t re-probe them, and the date you last sense-checked it. Example shape:

Future runs read this first, skip the absent products, and rotate attention across the live ones — that’s what turns a once-a-day generalist into something that covers the whole project over a week instead of re-checking one corner, and keeps up as both the team and PostHog change.