MCP Analytics
Contents
MCP Analytics shows how AI agents use your MCP tools. It records tool calls, agent intent, reported models, failures, and requests for missing capabilities. It supports PostHog's hosted MCP server and servers that use the MCP Analytics SDKs.
Each tool invocation creates a $mcp_tool_call event in your standard events table. Use these events in MCP Analytics, Product Analytics, or SQL. Self-driving uses them to find problems and create reports. It can open a pull request for a server you own.
The in-app MCP Analytics views are in beta. The @posthog/mcp SDK is published as a 0.x release, so event names, properties, and tracing behavior may change before 1.0. Pin a version and don't depend on it for production reporting yet.
Where you can use it
You explore MCP usage in the PostHog web app. The other surfaces let you query the same data, act on it, and pull it into your own tools.
PostHog WebBeta
Dashboards, session replay for agents, per-tool quality, and intent clustering.
Explore MCP usage →PostHog MCP
Query sessions, tool stats, failures, and intent clusters from any MCP client.
Query over PostHog MCP →PostHog DesktopBeta
Read Self-driving reports about failing tools, and merge the fixes for servers you own.
Fix tools in PostHog Desktop →Where its data comes from
MCP Analytics runs on the events your MCP server sends to PostHog. The SDK emits them automatically, and PostHog's hosted MCP server is instrumented the same way.
Tool calls
The canonical $mcp_tool_call event: tool name, client, latency, errors, and session.
Lifecycle and discovery
Legacy initialize handshakes, tools/list, and per-request protocol versions power client and spec adoption breakdowns.
Agent intent
What the agent said it was trying to do, clustered into themes across sessions.
Capture intent →Missing capabilities
Gaps agents report through the get_more_tools virtual tool when the right tool doesn't exist.
How MCP Analytics works with Self-driving
Self-driving uses your tool calls to find tools that need attention. A scout checks for high failure rates, repeated calls, slow responses, and large responses. It considers call volume and reach, then creates reports grouped by the team that owns the tools.
For your own server, the report includes a fix loop metric: the value that the proposed fix should improve. A coding agent then opens a pull request. For PostHog's hosted server, the report goes to a human without an attached repository. This path does not open a pull request.
Select Create fix task in the tool quality view to start a fix in a repository you choose. See PostHog Desktop for the report and fix process.