PostHog vs Lodd: 446 tools vs 42 (and when fewer is better)

446 MCP tools vs 42. More sounds better until you realise your agent loads every tool description into its context window, reasons over all of them to pick one, and gets back responses padded with dashboard metadata. If all you want is traffic data, 404 of those tools are overhead. Lodd has 42 tools, all web analytics, with responses built for agents instead of dashboards.

What does PostHog's MCP server include?

PostHog's MCP covers the full platform: trends, funnels, retention, paths, session recordings, feature flag management, experiment results, error tracking, LLM traces, notebooks, cohorts, surveys, and data pipeline configuration. 446 tools in total. If you're running PostHog and want your agent to manage all of that, the breadth is there. But most of these tools aren't analytics, and if you're asking "how's my traffic," your agent is sifting through hundreds of irrelevant tool descriptions to find the right one.

How do the two compare?

How does the query format differ?

PostHog uses a nested query structure built around its HogQL engine. To get daily pageviews for the last week:

{"kind": "InsightVizNode",
 "source": {"kind": "TrendsQuery",
   "series": [{"kind": "EventsNode",
     "event": "$pageview",
     "custom_name": "Pageviews"}],
   "dateRange": {"date_from": "-7d"},
   "interval": "day"}}

The same query on Lodd:

{"site": "example.com", "period": "7d"}

PostHog's format supports arbitrary combinations of events, filters, breakdowns, and formulas in a single query, which matters for product analytics across custom event taxonomies. For standard web analytics queries, the nested structure adds token overhead without adding insight. Lodd uses separate tools with flat parameters, keeping individual calls simple at the cost of needing multiple calls for complex analysis.

How do the response formats compare?

PostHog's responses include metadata, display configuration, and full property names designed for dashboard rendering. Lodd's responses use shortened keys (v instead of visitors, pv instead of pageviews, sr instead of source) and return only the data the agent asked for. A full analytics snapshot comes back as roughly 55 tokens.

An example. Traffic sources on PostHog: {"breakdown_value": "google", "count": 1234, "data": [...]} with timestamp metadata per data point. On Lodd: {"sr": "google", "v": 1234, "pv": 2100}. Same information, fewer tokens. This matters when your agent is working with multiple data sources in a single conversation and context window space is finite.

When is PostHog the better choice?

If you actually use feature flags, experiments, session recordings, and error tracking, and you want your agent to manage all of them, PostHog is the only option that covers the full stack through one MCP. It's open source and self-hostable, and the free tier is generous at 1 million analytics events per month. The question is whether you use enough of those features to justify 446 tools in your agent's context. Most developers running a side project or early-stage SaaS don't need feature flags or session recordings. They need to know if their traffic went up or down.

When does fewer tools make more sense?

446 tools is a real cost, not just a number. MCP clients load every tool description into the system prompt, which means your agent is carrying the weight of feature flag management, experiment configuration, and error tracking definitions in its context window even when you're asking about pageviews. That's context space your agent could be using for actual analysis.

There's also a reliability question. I've watched agents pick the wrong tool when the surface is large and several tools sound similar. With 42 focused analytics tools, the right one is almost always obvious from the query. With 446 spanning a dozen domains, the agent has to reason about which category of tool to use before it can pick the specific one. More surface means more room for the agent to take a wrong turn.

And the response format compounds this. Every PostHog response includes display metadata and full property names because those responses were built to render dashboards. Every Lodd response is stripped to what the agent needs: {"sr":"google","v":1234} instead of {"breakdown_value":"google","count":1234,"data":[...]}. Over a conversation with 5-10 analytics queries, the token difference adds up to thousands, and that's context window space you're losing for the rest of the work.

Setup matters too. PostHog requires an existing account and OAuth. Lodd is one prompt: "add lodd.dev analytics to this project." The agent handles auth, site creation, and script embedding. If you're evaluating whether to add traffic data to your agent's context, the friction difference between "one prompt" and "create an account, configure OAuth, navigate 446 tools" is the difference between doing it today and putting it on the backlog.

What about pricing?

PostHog's free tier is more generous on volume: 1 million analytics events per month. Lodd's free tier is 2,500 events per month, with €9.99/mo for 100K. If you're tracking high volumes and cost is the priority, PostHog wins on pure numbers. But PostHog's pricing gets complex across products (separate limits for recordings, flags, surveys), while Lodd is flat: all 42 tools, all features, one price.

Can you use both?

Yes, and it might be the best option if you're already on PostHog. Keep PostHog for product analytics, feature flags, and experiments. Add Lodd for the web analytics your agent queries during coding sessions. The responses are compact, the tool surface is small, and the setup takes two minutes. You get PostHog's depth for product decisions and Lodd's focus for the traffic questions your agent answers twenty times a day.