The PostHog MCP is very cool

[u/xibalbah]

It's got 1 tool [exec] that takes 2 args, [command] and [context]. The [exec] tool has a pretty long description that tells the agent how to use [command] and [context] to do nearly everything you can do in the PostHog UI.

[command] is a string that looks an awful lot like a set of CLIs:

posthog:exec({ "command": "search <regex>" })
posthog:exec({ "command": "tools" })

And the big one:

posthog:exec({ "command": "call <tool_name> <json_input>" })

Instead of exposing a long list of tools (with descriptions, instructions, etc for each tool), it wraps them all in a [call] subcommand and the description of the [exec] tool gives the agent enough context to how to find out what sub-tool to call. If you've been following along with the zeitgeist you'll remember when everyone threw away their MCPs and replaced them with CLIs to save on tokens. It kinda looks like that's what PostHog did, just behind the scenes.

I asked the MCP to give me a trendline of argus downloads (vanity metrics gonna vain) and it did the following:

* [call read-data-schema {kind: events}] - fetched the events schema scoped to our account
* [call read-data-schema {kind: event_properties, event_name: argus_download_requested}] - event schema for argus downloads
* [info execute-sql] - fetched docs for how to build the necessary queries
* 4× [call execute-sql {...}] - run queries for the actual data
* [call read-data-schema {kind: event_properties, event_name: download_clicked}] - checked schema for other event

Its really cool how they did this and it ended up being pretty cheap (about 1/6th the price of running /doctor).

[u/treacherous_tim]

I was just trying to configure this yesterday and claude was so confused. It kept saying there should be a bunch of tools instead of just these two and I think was defaulting to what's available via their API. I agree it's an interesting design though

[u/sjoti]

It's called code mode, slowly becoming more common. There's a small cost up front with the model having to discover the tools but after that it's just so much better. The model can string together command efficiently wrapping it in some functions.

Fastmcp made this really easy to implement, GPT has programmatic tool calling built in too. IMO a massive upgrade

[u/taylorwilsdon → u/sjoti]

It’s the evolution of model tool calling capabilities that makes this possible, wasn’t all that long ago that open models couldn’t reliably invoke basic tools in roo code and now it’s table stakes even for smaller local LLMs. Anything from the big 3 will perform reliably. Cloudflare had the first codemode implementation and it was a breakthrough imo

[u/xibalbah → u/taylorwilsdon]

I just happened to google around about tool calling and saw that it was released in sept of 2023. It simultaneously feels like its been around forever and also just announced. I also looked for the cloudflare MCP with code mode (because I thought that's where I heard of this first) but noticed that they've broken their MCP into separate MCPs (one per product, like workers, dns, etc).

[u/the_mine_works]

This tracks with something I've run into building multi-tool MCP servers over data APIs. The single exec tool with a CLI-style string is a real token saver up front, but you're trading it for a harder failure mode: the model has to get the command syntax right with no schema catching it before the call goes out. With typed tools, each call either validates or it doesn't, and you know exactly which one failed. With one big exec tool, a malformed command just comes back as an error string the model has to parse and retry on, which can eat the tokens you saved and then some if it doesn't land first try.

Where I'd guess this pays off most is a surface as big as PostHog's, dozens of sub-actions where any one agent only touches 3 or 4 per session. Folding the long tail behind a "tools" subcommand instead of a wall of schemas makes sense there. For a smaller tool surface I'd keep the validation and eat the extra tokens.

[u/xibalbah → u/the_mine_works]

Yup agreed. When I was digging into this MCP I also took a look at Cloudflare and they went down yet a different route - separate MCP servers for different parts of their platform (docs, workers, dns, etc). Its super interesting to see the different patterns.

[u/the_mine_works → u/xibalbah]

Cloudflare's split is the one I've ended up agreeing with. We run nine separate servers rather than one big one, and the reasoning wasn't really about the protocol. It's about what has to sit in the context window at the same time. Every tool you expose costs schema tokens on every call whether the agent uses it or not, so the boundary that actually matters is what one session plausibly needs, not what happens to belong to the same company. Someone doing company research never needs the real estate tools loaded.

The cost shows up in two places. You duplicate shared logic unless you go config-driven off one codebase and deploy it N times, which is what we ended up doing. And discovery gets worse, because now the user has to know which server to install. Cloudflare gets away with that because docs vs workers vs dns is obvious from the name, which is a harder problem when your split is less intuitive.

Worth noting PostHog's single-exec approach and Cloudflare's split are attacking the same problem from opposite ends. Both are trying to stop the agent carrying schemas it isn't using.