bosshogg.
Every session paid the MCP tax
Agents don’t need a fat MCP. They need a CLI.
I wanted my coding agent to actually touch PostHog. Pull the numbers, toggle a flag, run a HogQL query, without me leaving the terminal to go click around a web app.
The official way in for an agent is the PostHog MCP server. It’s good at what it does. But it loads about 44,000 tokens into every session before you’ve typed a single word. Every agent session pays it, whether or not you ever ask about PostHog. That’s the tax.
And an MCP only runs inside an agent. It doesn’t work in a shell script, a CI job, a make target. So the thing I actually wanted, operate a running PostHog project from a terminal, had no good tool. The official CLI stops at source-map uploads. The SDK is for sending data in, not reading it out. The MCP covers everything but eats your context to do it.
BossHogg covers the gap in the middle
BossHogg is a tiny Rust CLI for PostHog. One binary. It covers 31 of PostHog’s resources: feature flags, HogQL queries, insights, dashboards, cohorts, persons, events, experiments, surveys, session replays, error tracking. Pretty much anything you’d want to do to a running project from the outside.
It ships a Claude Code skill that skips that tax almost entirely, about 200 tokens when it’s sitting idle. The skill sits in the binary and only pulls the parts it needs when it needs them.
HogQL is the center of it. bosshogg query run "SELECT ...", get JSON back, pipe it to jq, done.
For a tool an agent drives, the pretty human-readable table barely matters. The --json is the product. So I treated it like a public contract: stable field names, a schema for every command validated in CI, deterministic exit codes, and structured errors with a code, a hint, and a retry path, so an agent can read the failure and fix itself. It works against US, EU, and self-hosted PostHog out of one config, kubectl-style.
And it doesn’t try to replace PostHog’s own tools. Chart rendering, the wizards, source-map uploads, that stays theirs. BossHogg covers the gap in the middle, operating the project from a shell.
I'd already built this once, for Linear
I got fed up with Linear’s MCP server, too slow, too token-heavy, so I wrote a small Rust CLI for it instead. Called it lin. It worked. BossHogg is that same pattern pointed at PostHog, same architecture, same JSON-first contract, same skill in the binary.
PostHog already ships its own hog command, the interpreter for their Hog language, so calling mine hog would collide with theirs and confuse everyone. Squatting posthog-anything invites a trademark fight I don’t want. So, BossHogg. Two G’s, the Dukes of Hazzard nod, and PostHog already has a hedgehog. Easy to Google, and it steps on nobody’s namespace.
I ran the whole demo without opening a browser
I shipped it with CI, crates.io, and a Homebrew tap, and dogfooded it on my own sites, querying their actual traffic, before I told anyone it existed.
A couple weeks after the first commit I demoed it at a PostHog community event in Toronto. Ten minutes, developer to developer, no pitch. I used BossHogg from the terminal to query its own usage data, built a live dashboard from what came back, then launched a survey on a real site, all without opening a browser or touching any code. The last event showing up in PostHog was one of the commands I’d just run.
The deck from that talk:
BossHogg is free and open source, up on crates.io and featured on Product Hunt.