Top
Best
New

Posted by maharshi365 1 day ago

MCP was always a bad idea?(maharship.com)
329 points | 326 commentspage 7
Peteriishak 1 day ago|
I used this tool for 1 month since then I never used it again
air217 1 day ago||
i feel like MCP was bad, but people are saying recent improvements have made it worthwhile now? i.e. stateless http
pjmlp 1 day ago||
Well, SaaS don't do CLIs for extension APIs.

Plus the performance issues to restarting processes all the time.

fooster 1 day ago|
Neither of those things are true?

Also you are seriously comparing process startup time with the latency of a network call, or worse an llm call?

pjmlp 1 day ago||
Yes, if the SaaS application needs to fork subprocesses for every little step of agentic workflows.

Welcome to CGIs, a great 1990's technology for Web applications.

fooster 1 day ago||
We do that, and the cost of forking the cli vs the llm or network call is very small. It works really well.
fb03 21 hours ago||
Related to this discussion, I have written a manifesto against the excessive usage of MCP and other "tools" when using coding agents. I believe sticking to the basics yields the better quality overall in output

https://www.just-prompt-motherfucker.com/

bithammerthunde 1 day ago||
Summaries aren't a bad idea though.
woodpanel 14 hours ago||
I happen to be much more token efficient by

- installing a cli tool

- exposing it via a simple SKILL.md

- turn repetitive patterns into bash scripts fast

aldonius 1 day ago||
If your customers are normal people who use ChatGPT in the browser, they want ChatGPT Apps, which are based on MCP.
0x445442 1 day ago||
MCPs are a bad idea because they encourage token burn at runtime when a deterministic program that uses the API should be used.

Of course Mario, Sammy, Jensen et al. would be for this.

est 1 day ago||
MCP is a good idea

JSON is a bad format/transport.

cruffle_duffle 1 day ago|
> JSON is a bad format/transport.

I've cut token counts significantly for some of my MCP servers by returning csv or tabular data or sometimes even just good old fashioned plaintext "template style" words. JSON is highly repetitious. In some instances like 30% or more of the token response was just boilerplate JSON.

Once you realize that to an LLM JSON is just a stream of tokens no different than XML, markdown, or a punctuation-less stream of conciseness.... you start to realize there is no reason not to just make up your own crazy formats. The LLM isn't throw parsing errors if your MCP is returning something other than JSON. The LLM is smart enough to figure it out. It's far more important to make sure your tool descriptions and parameter descriptions properly "market" what it is you do (and dont do) than return syntactically correct JSON.

Same with versioning.... it's all ephemeral. There is no backwards compatibility to speak of with MCP (at least for tooling "contracts".... what the tool actually does however... that is a different level and is product requirements not API contracts).

levelZero 1 day ago|
https://github.com/kunchenguid/axi
More comments...