alt Hacker News> So you're building a custom harness here that provides tools, and you're wiring up your custom harness to effectively do a subprocess execution of a CLI script for every tool call the model request?
Well, yeah. Subprocess execution is on the order of double-digit milliseconds. The "wiring up" is maintaining a whitelist of what tool commands map to which executable. It's a lookup table with very little maintenance required.
> One reason to switch to MCP here would be to avoid the overhead of forking a new process for every tool call, and to enable maintaining state between tool calls.
I feel like I am taking crazy pills :-/
The overhead of forking, on the ancient machine I call my desktop, is at most double-digit milliseconds. The state isn't being tracked by the MCP server anyway, it'll be tracked by the harness and/or the model, no?
My main reason for adding MCP support is so that existing callers that want to use my WebApp(s) can just use it without needing any changes on their side.
IOW, I am going to add it at some point, but not for the reasons you give. I'll add it to be compatible.
You didn't address my comment about state. If you're driving something like Playwright you need a way to maintain state between tool calls.
(Oddly enough I did solve that with my own CLI tool for running browsers during my "who needs MCP" phase, but it's a bit of a nasty hack that involves leaving files with PIDs lying around: https://github.com/simonw/rodney#directory-scoped-sessions and https://github.com/simonw/rodney/blob/a842432246f39775ccb14f...)