MCP analytics: dashboards and insights over the existing mcp_tool_call PostHog event

[JSONbored]

Part of epic #8286. Gap found during a coverage audit against the maintainer's requested list (2026-07-25): every other analytics surface (web, AI observability, error tracking) has a dedicated sub-issue, but MCP tool-call analytics -- despite already emitting real PostHog events -- has no sub-issue covering dashboards/insights over that data.

Current state

src/mcp/telemetry.ts (#6235, landed before this epic) already emits a real mcp_tool_call event on every tools/call dispatch through the remote MCP (src/mcp/server.ts's recordMcpToolTelemetry chokepoint) -- tool name, caller type (remote/local), success, coarse duration. Opt-in (POSTHOG_API_KEY), never throws, anonymous fixed distinct_id (no per-actor identity by design, #6228). The local/CLI-side counterpart (packages/loopover-mcp/lib/telemetry.js) has separate wiring status per #6236/#6238 -- confirm its current state before assuming both sides already emit.

This capture path is NOT itself in scope here -- it already exists and already works. What's missing is turning the resulting event stream into something a maintainer actually looks at: no PostHog insight, dashboard panel, or alert currently consumes mcp_tool_call.

Requirements

• Confirm current emission state on both the remote (src/mcp/server.ts) and local (@loopover/mcp CLI) paths -- don't assume feat(mcp): add a typed PostHog wrapper module for packages/loopover-mcp (local, opt-in) #6236/feat(mcp): instrument the local MCP tool-dispatch chokepoint with PostHog events (opt-in) #6238 fully landed.
• Design and build PostHog insights/dashboard panel(s) over mcp_tool_call: adoption over time (unique tool names, call volume), success/failure rate per tool, coarse latency distribution, remote-vs-local split.
• Decide whether this belongs on its own dashboard or as a section of Insights, dashboards, and alert routing — the core PostHog buildout (gates the Sentry sunset) #8294's core PostHog buildout (that issue owns the general insights/dashboards/alert-routing work) -- coordinate scope with Insights, dashboards, and alert routing — the core PostHog buildout (gates the Sentry sunset) #8294 rather than duplicating dashboard-creation effort.
• No new capture fields beyond the existing Spec: usage-telemetry instrumentation strategy for MCP (PostHog) #6228 allowlist (tool, callerType, ok, durationMs) -- this issue is about consuming what's already emitted, not expanding what's captured.

Deliverables

• Verified current emission state on both remote and local MCP paths, documented here
• PostHog dashboard/insight(s) over mcp_tool_call covering adoption, success rate, latency
• Scope coordinated with Insights, dashboards, and alert routing — the core PostHog buildout (gates the Sentry sunset) #8294 (no duplicate dashboard-building work)

Links & Resources

• feat(mcp): add a typed PostHog wrapper module for src/mcp/server.ts (remote) #6235, Spec: usage-telemetry instrumentation strategy for MCP (PostHog) #6228 (the existing capture path and its allowlist decision)
• feat(mcp): add a typed PostHog wrapper module for packages/loopover-mcp (local, opt-in) #6236, feat(mcp): instrument the local MCP tool-dispatch chokepoint with PostHog events (opt-in) #6238 (local/CLI-side wiring status)
• src/mcp/telemetry.ts, src/mcp/server.ts
• Insights, dashboards, and alert routing — the core PostHog buildout (gates the Sentry sunset) #8294 (the epic's general insights/dashboards/alert-routing issue)

Boundaries

Dashboard/insight construction over already-emitted data only -- no new capture fields, no changes to src/mcp/telemetry.ts's allowlist.

maintainer-only.

[linear-code]

JSO-5963