I wait for the day when the employer, the management, the business analyst, and the customer can get to state expected behaviour. Nevermind using AI. On all my projects programme was never a problem, it was non-competent people going "Make it good, if it makes big bucks and line go up, don't even bother with that. Make what good? Everything.".
If you think LLMs will make irrational people go "Ahhh I get it, I can't throw money and yelling at a shower idea and be the next Xooglebookflix" you will be surprised.
I don't think anyone killed old school engineering, whatever that means for you. But if someone indeed did kill it, incompetence, management and incompetent management is the culprit
I've found that most of LLM generated docs are diluted and unfocused. Spending 3 paragraphs on some quirk of a library, then 2 simple examples of a command.
I write README and docs by hand, thus only important stuff goes in there. If it is not worth my attention to write down, it's not worth writing down.
Hi! I've dabbled in implementing an MCP server/client back in March. To me a proper REST API and/or cli tool seems sufficient enough, agents use them with good efficiency.
Any reason not to provide CLI or REST interface for your tools, but MCP for agents specifically?
In my apps, CLI came first which works through Mach ports as the IPC, so the "REST equivalent" of macOS apps is also present. MCP takes advantage of the same client-server architecture I created for the CLI, so there's nothing you can't do with the CLI that needs an MCP.
But in my case, a CLI was not enough.
Like, to the MCP I might say:
Set Clop to make every video copied in ~/shots smaller, 2x and silent
Then the MCP can use elicitation and say:
By smaller, you mean re-encode to compress file size (factor can be 0 to 100 max compression) or downscale resolution (100% same size, 50% half size)?
And does 2x mean faster speed? In which case do you want to keep frames so the video plays smoother or drop frames for size? Or does 2x mean upscale?
And the agent will present those as nice choice menus I can decide schematically on.
With the CLI I have to first read, learn and memorize the requests and commands needed for each app, the accepted values and formats and the steps to reach a specific result.
There's only so much space in my head I can leave for implementation details of arbitrary apps. I'd rather have an agent care about that.
And yes I get the irony, those are my apps, I coded them by hand for years, I should know their implementation details, yet even I forget if I should pass 50% or 0.5 for half size.
You answered "Why use MCP with your agent instead of using CLI manually?" but the more interesting question is "Why build an MCP when you could already point your agent to the CLI?". The user experience of "the agent will present those as nice choice menus I can decide schematically on" will probably be the same since agents are very adept at using cli tools and gathering required/optional arguments, examples, and warnings/errors to present you with useful choices on how to proceed.
The most important reason is that I can keep the CLI output and help for humans, while the MCP can be crammed with information for agents.
Plus I can add some complex commands like in the rcmd Stages [1] case where the agent can create a 4 monitor layout with apps and windows placed where you want, with every window opening the document/folder/project/URL you want and running the terminal commands you need. Sure you can do that with the CLI, but it's hard enough to get right because of shell quoting issues, that even an agent can get it wrong.
For simple tasks though, sure, the CLI is just enough and the agent can use it without needing to install yet another MCP. You'll know when you need it.
EDIT: I just remembered, you can even hook the Claude/Codex/Gemini desktop app to the MCP, while you can't get it to use the CLI. so there's that for users that still don't feel comfortable at a terminal, which is a number higher than you might estimate.
reply