Analytics for MCP servers — every tool call an agent makes lands as a normal PostHog event, so you get per-tool failure and latency, the agent's own account of what it was after, and the tools it went looking for and didn't find. Beta, behind a feature preview.
The @posthog/mcp SDK instruments your own server, and PostHog's hosted MCP server sends the same events, which is what most projects end up looking at first. Each invocation arrives as one $mcp_tool_call event carrying tool name, client, latency, error and session. The initialize handshake, tools/list, resource reads and prompt fetches come with it and give you the breakdown by client.
Two of the signals are ones your server logs can't produce on their own. The agent says what it was trying to do, and PostHog clusters those statements into themes across sessions. When the right tool doesn't exist, the agent reports the gap through a virtual get_more_tools tool, so what to build next comes back as counted data rather than a guess.
Because all of it is ordinary events on the events table, product analytics, SQL and session replay work over it with no second pipeline. The same stream feeds Self-driving, where a scout weighs failing, retried and slow tools by volume and reach and files one report per owning team. A coding agent opens a pull request only for servers you own; reports about PostHog's hosted server go to a human with no repository attached.
It's beta as of August 2026. The in-app views sit behind a feature preview, and @posthog/mcp is still a 0.x release, so pin a version and expect event names and properties to move.