Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

that's what the MCP server is, except I don't always want a cli.

If I need to call API on top of a cli tool, i don't have to have a second wrapper, or extend my existing wrapper. You're suggesting I recreate everything MCP does, just so..it's my own?

MCP is just a way to use use wrappers other people have built, and to easily manage wrapping "tools", those could be cli tools, api calls, database query,etc..

cli tools aren't aware of the context window either, they're not keeping track of it. I might want my cli tool to output lots of useful text but maybe I don't want some of that for the LLM to save on tokens. Sure, I could create another cli tool to wrap my cli tool, now i have two cli tools to maintain. I'd prefer to do all the wrapping and pre-llm cleanup done in one consistent place. The instructions for the LLM letting it know what tools, parameters,etc.. are available is also defined in a consistent way, instead of me inventing my own scheme. I'd rather just focus on getting a usable agent.

I don't get the issue people in this thread have with MCP, is there some burden about it I haven't ran into? It's pretty easy to set one up.



> I don't get the issue people in this thread have with MCP, is there some burden about it I haven't ran into? It's pretty easy to set one up.

Doesn’t an MCP server require running a process for the endpoint? A CLI tool doesn’t have this problem.


It does not, your MCP server can be a small python file, your agent would execute it as a process and use stdio to communicate with it. You can also run it as an HTTP server, but if it's all on the same machine, I don't see the point. I'm pretty sure in under 15 loc of python you can wrap subprocess.check_ouptput as an stdio MCP server for example to let your agent run any commands or a specific command.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: