Comment by notepad0x90

5 hours ago

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.