/exploring-mcp-tool-usage
Starting point for exploring how a PostHog MCP server's tools are used — routes a broad question to the typed tool that answers it. Use when the user asks "how is my MCP doing?", "what should I look at?", "explore my tool calls", "who uses my MCP tools?", "what are agents doing
$ npx -y skills add posthog/posthog --skill exploring-mcp-tool-usage --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/exploring-mcp-tool-usage
Context preview
The summary Claude sees to decide when to auto-load this skill.
Starting point for exploring how a PostHog MCP server's tools are used — routes a broad question to the typed tool that answers it. Use when the user asks "how is my MCP doing?", "what should I look at?", "explore my tool calls", "who uses my MCP tools?", "what are agents doing
SKILL.md
exploring-mcp-tool-usage.SKILL.mdname: exploring-mcp-tool-usage
description: >
Starting point for exploring how a PostHog MCP server's tools are used —
routes a broad question to the typed tool that answers it. Use when the user
asks "how is my MCP doing?", "what should I look at?", "explore my tool
calls", "who uses my MCP tools?", "what are agents doing with the MCP?", or
pastes an MCP analytics URL without a specific question. Offers a menu of
questions, each backed by a query tool, then hands off to the focused skill.
Exploring MCP tool usage
Any MCP server instrumented with the `@posthog/mcp` SDK emits a `$mcp_tool_call` event every time an agent invokes a tool. This skill is the **front door** for a user who knows they want to look at their MCP tool usage but hasn't picked a specific question. Offer the menu below, then route to the tool — or the focused skill — that answers what they choose.
Every per-tool tool here is gated behind the `mcp-analytics` flag, takes a `toolName` (the effective tool name — resolved server-side, so pass the name the agent actually invokes — **except `posthog:query-mcp-tool-failures`**, which matches `$exception` events and so takes the raw registered `$mcp_tool_name`) plus a `dateRange`, and runs the same query runner the tool-detail UI uses. So results match the UI, and you never hand-write the HogQL.
Suggested questions
Lead with these when the user is unsure what to ask:
| Ask the user… | Answered by | | ------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | "Which tools fail most, or are slowest?" | `exploring-mcp-tool-quality` (ranks all tools), then `posthog:query-mcp-tool-stats` to drill in | | "How is tool X doing overall?" | `posthog:query-mcp-tool-stats` — calls, errors, p50/p95, users, sessions, intents | | "How has tool X trended?" | `posthog:query-mcp-tool-daily-stats` — day-by-day series | | "Why is tool X failing?" | `posthog:query-mcp-tool-failures` — top error messages, by harness (raw tool name) | | "Who uses tool X the most?" | `posthog:query-mcp-tool-top-users` — top callers (incl. person email/name) | | "What gets called right before/after tool X?" | `posthog:query-mcp-tool-neighbors` (`neighborDirection: before`/`after`) | | "What are agents trying to do with tool X?" | `posthog:query-mcp-tool-sample-intents` — recent agent intents | | "What description is tool X registered with?" | `posthog:query-mcp-tool-descriptions` — distinct descriptions seen | | "Which harnesses use my MCP, how reliably?" | `posthog:query-mcp-harness-breakdown` — calls/errors/sessions per client | | "What are agents trying to do, across all tools?" | `exploring-mcp-intent-clusters` — semantic goal clusters | | "Who is connecting, and how active are they?" | `posthog:mcp-analytics-sessions-list` — one row per session, with client and person | | "What did this one session do?" | `exploring-mcp-sessions` — a single agent run's tool sequence |
Finding the tool name
The per-tool tools need a `toolName`. If the user named a tool, pass it. If they asked a broad "which tool…" question, start with `exploring-mcp-tool-quality` to rank the tools, pick the one that stands out, then drill in with the per-tool tools above. The name to pass is the **effective** tool name (the inner tool for single-exec wrapper calls) — the same string the tool-quality ranking returns. The one exception is `posthog:query-mcp-tool-failures`, which matches `$exception` events by the raw registered `$mcp_tool_name`, not the effective inner tool.
How to use a per-tool tool
Call it with the tool name and a window, e.g. for the headline numbers of a tool:
posthog:query-mcp-tool-stats { "toolName": "<tool>", "dateRange": { "date_from": "-7d" } }Then offer a natural follow-up from the menu — e.g. after `posthog:query-mcp-tool-stats` shows a high error rate, reach for `posthog:query-mcp-tool-failures`; after it shows broad reach, reach for `posthog:query-mcp-tool-top-users` or `posthog:query-mcp-tool-neighbors`.
When to drop to SQL
**Covered by a typed tool — don't hand-write SQL for these:**
| Question | Tool | | ---------------------------------- | ------------------------------------------- | | One tool's headline numbers | `posthog:query-mcp-tool-stats` | | One tool's day-by-day trend | `posthog:query-mcp-tool-daily-stats` | | One tool's top errors | `posthog:query-mcp-tool-failures` | | One tool's top callers | `posthog:query-mcp-tool-top-users` | | Tools called before/after one tool | `posthog:query-mcp-tool-neighbors` | | One tool's recent agent intents | `posthog:query-mcp-tool-sample-intents` | | One tool's registered descriptions | `posthog:query-mcp-tool-descriptions` | | Usage split by client harness | `posthog:query-mcp-harness-breakdown` | | List sessions | `posthog:mcp-analytics-sessions-list` | | One session's tool calls | `posthog:mcp-analytics-sessions-tool-calls` |
**Not covered — use `posthog:execute-sql`:**
- Cross-tool rankings (the tool-quality matrix — "which tool errors most?")
- Errored-session filtering (the session list has no error filter or error count)
- Effective tool names inside a session (`posthog:
Read more
name: exploring-mcp-tool-usage description: > Starting point for exploring how a PostHog MCP server's tools are used — routes a broad question to the typed tool that answers it. Use when the user asks "how is my MCP doing?", "what should I look at?", "explore my tool calls", "who uses my MCP tools?", "what are agents doing with the MCP?", or pastes an MCP analytics URL without a specific question. Offers a menu of questions, each backed by a query tool, then hands off to the focused skill.
Exploring MCP tool usage
Any MCP server instrumented with the `@posthog/mcp` SDK emits a `$mcp_tool_call` event every time an agent invokes a tool. This skill is the **front door** for a user who knows they want to look at their MCP tool usage but hasn't picked a specific question. Offer the menu below, then route to the tool — or the focused skill — that answers what they choose.
Every per-tool tool here is gated behind the `mcp-analytics` flag, takes a `toolName` (the effective tool name — resolved server-side, so pass the name the agent actually invokes — **except `posthog:query-mcp-tool-failures`**, which matches `$exception` events and so takes the raw registered `$mcp_tool_name`) plus a `dateRange`, and runs the same query runner the tool-detail UI uses. So results match the UI, and you never hand-write the HogQL.
Suggested questions
Lead with these when the user is unsure what to ask:
| Ask the user… | Answered by | | ------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | "Which tools fail most, or are slowest?" | `exploring-mcp-tool-quality` (ranks all tools), then `posthog:query-mcp-tool-stats` to drill in | | "How is tool X doing overall?" | `posthog:query-mcp-tool-stats` — calls, errors, p50/p95, users, sessions, intents | | "How has tool X trended?" | `posthog:query-mcp-tool-daily-stats` — day-by-day series | | "Why is tool X failing?" | `posthog:query-mcp-tool-failures` — top error messages, by harness (raw tool name) | | "Who uses tool X the most?" | `posthog:query-mcp-tool-top-users` — top callers (incl. person email/name) | | "What gets called right before/after tool X?" | `posthog:query-mcp-tool-neighbors` (`neighborDirection: before`/`after`) | | "What are agents trying to do with tool X?" | `posthog:query-mcp-tool-sample-intents` — recent agent intents | | "What description is tool X registered with?" | `posthog:query-mcp-tool-descriptions` — distinct descriptions seen | | "Which harnesses use my MCP, how reliably?" | `posthog:query-mcp-harness-breakdown` — calls/errors/sessions per client | | "What are agents trying to do, across all tools?" | `exploring-mcp-intent-clusters` — semantic goal clusters | | "Who is connecting, and how active are they?" | `posthog:mcp-analytics-sessions-list` — one row per session, with client and person | | "What did this one session do?" | `exploring-mcp-sessions` — a single agent run's tool sequence |
Finding the tool name
The per-tool tools need a `toolName`. If the user named a tool, pass it. If they asked a broad "which tool…" question, start with `exploring-mcp-tool-quality` to rank the tools, pick the one that stands out, then drill in with the per-tool tools above. The name to pass is the **effective** tool name (the inner tool for single-exec wrapper calls) — the same string the tool-quality ranking returns. The one exception is `posthog:query-mcp-tool-failures`, which matches `$exception` events by the raw registered `$mcp_tool_name`, not the effective inner tool.
How to use a per-tool tool
Call it with the tool name and a window, e.g. for the headline numbers of a tool:
posthog:query-mcp-tool-stats { "toolName": "<tool>", "dateRange": { "date_from": "-7d" } }Then offer a natural follow-up from the menu — e.g. after `posthog:query-mcp-tool-stats` shows a high error rate, reach for `posthog:query-mcp-tool-failures`; after it shows broad reach, reach for `posthog:query-mcp-tool-top-users` or `posthog:query-mcp-tool-neighbors`.
When to drop to SQL
**Covered by a typed tool — don't hand-write SQL for these:**
| Question | Tool | | ---------------------------------- | ------------------------------------------- | | One tool's headline numbers | `posthog:query-mcp-tool-stats` | | One tool's day-by-day trend | `posthog:query-mcp-tool-daily-stats` | | One tool's top errors | `posthog:query-mcp-tool-failures` | | One tool's top callers | `posthog:query-mcp-tool-top-users` | | Tools called before/after one tool | `posthog:query-mcp-tool-neighbors` | | One tool's recent agent intents | `posthog:query-mcp-tool-sample-intents` | | One tool's registered descriptions | `posthog:query-mcp-tool-descriptions` | | Usage split by client harness | `posthog:query-mcp-harness-breakdown` | | List sessions | `posthog:mcp-analytics-sessions-list` | | One session's tool calls | `posthog:mcp-analytics-sessions-tool-calls` |
**Not covered — use `posthog:execute-sql`:**
- Cross-tool rankings (the tool-quality matrix — "which tool errors most?")
- Errored-session filtering (the session list has no error filter or error count)
- Effective tool names inside a session (`posthog:
:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.
Repo: posthog/posthog
Other skills on posthog.
- /analyzing-expensive-users
Analyze the most expensive users in AI observability and explain why they cost so much. Use when the user asks about top spenders, expensive users, per-user LLM cost, user-level cost drivers, or patterns behind high AI observability spend.
Open skill - /creating-online-evaluations
Author continuously-running online evaluations in PostHog AI observability, grounded in real failure modes you've identified. Use when the user wants evaluations that automatically score new generations or whole traces going forward — "create an eval to catch X", "continuously
Open skill - /exploring-ai-failures
Find where an AI/LLM application is failing in production and surface the failure patterns, working from real traces. Use when someone wants to understand what's going wrong with an AI feature, find and categorize failure modes, triage errors, or investigate quality issues
Open skill - /exploring-llm-clusters
Investigate AI observability clusters — understand usage patterns in AI/LLM traffic, compare cluster behavior, compute cost/latency metrics, and drill into individual traces within clusters.
Open skill - /exploring-llm-costs
Investigate LLM spend in PostHog — total cost over time, cost by model, provider, user, trace, or custom dimension, token and cache-hit economics, and cost regressions. Use when the user asks "how much are we spending on LLMs?", "which model / user / feature is most expensive?",
Open skill - /exploring-llm-evaluations
Investigate AI observability evaluations — `hog` (deterministic code-based), `llm_judge` (LLM-prompt-based), and `sentiment` (user-message sentiment). Find existing evaluations, inspect their configuration, run them against specific generations, query individual results, and
Open skill

