It's mainly about robustness and deterministic outcomes.
There is a small level of noise in TUI output, and structures that are easily parsed by a human can be ambiguous for an agent (for instance column layouts). You could definitely let agents interact with Epiq purely through the CLI, but the idea behind the MCP server is to provide stable, predictable interfaces where determinism matters.
Maybe add --something to make your output agent-friendly then? MCP adds a lot of token overhead and is not pipeable, that is, you can't do mcpserver1 | something without the tokens first passing into the context window of the agent (if you use a subagent it's the same thing - you are still spending the tokens)
I think I can understand what you want, and the dev’s response about deterministic output is something I really appreciate. I don’t think I want an agent going and mucking around in git _at all_, and if it is going to, I’d prefer some level of predictability imo.
> Or maybe just publish a skill for the agent to use your CLI?
This. Skills effectively turned MCPs obsolete in the vast majority of MCP applications. A single CLI tool implemented following a progressive disclosure style doesn't even need a agent skill for coding agents to use it effectively.
There is a small level of noise in TUI output, and structures that are easily parsed by a human can be ambiguous for an agent (for instance column layouts). You could definitely let agents interact with Epiq purely through the CLI, but the idea behind the MCP server is to provide stable, predictable interfaces where determinism matters.