Return what's actually firing into ingest as a structured signature, for diffing against the project's authored `event-schema.yaml`. Different shape from the YAML — this is observation, not declaration.
Response shape:
```
{
period: "30d",
events: [
{ name: "checkout", count: 42,
properties: {
plan: [{ type: "string", occurrences: 42 }],
count: [{ type: "number", occurrences: 39 },
{ type: "string", occurrences: 3 }] // ← drift!
}}
]
}
```
Each property value is an *array* of typed observations. One entry = the key consistently fired with one type. Two-plus entries = same key fired under multiple storage columns in the period, which is exactly the silent-type-drift signal you want to surface (one call site sending `count: 5`, another sending `count: "5"`).
Use it to compare declared vs reality:
- Events declared, missing here → dead instrumentation
- Events here, not declared → unauthored events firing
- Properties on a declared event missing from the schema → silent property drift
- `properties[key].length > 1` → type-column collision; one of the call sites is sending the wrong type
Examples:
- "what events are firing in production" → no params (defaults to 30d, excludes pageview/pageview_end)
- "did the spec drift this week" → period="7d"
- "include automatic pageview events too" → include_pageviews=true
Limitations: returns keys + types only, no property *values*. `occurrences` is row-level (each event firing counts), not unique visitors. Excludes `pageview` and `pageview_end` by default since the SDK extension owns their schema.
Pairs with: `events.list` for per-event volume context (this tool also returns `count`, but `events.list` supports filters and grouping); the local `event-schema.yaml` for declared-vs-observed diff.
Connector