71–80 of 194 posts
So far I have seen two genuinely good arguments for the use of MCPs: * They can encapsulate (API) credentials, keeping those out of reach of the model, * Contrary to APIs, they can change their interface whenever they want and with little consequences.
MCP was a really shitty attempt at building a plugin framework that was vague enough to lure people into and then allow other companies to build plugin platforms to take care of the MCP non-sense. "What is MCP, what does it bring to the table? Who knows. What does it do? The LLM stuff! Pay us $10 a month thanks!" LLM's have function / tool calling built into them. No major models have any direct knowledge of MCP. Not…
Yeah there's no there there when it comes to MCP. It's crazy to me that the world bought into the idea when the "spec" literally boils down to "have your server give the LLM some json". Just illustrates how powerful it is to attach names to things, especially in a hypestorm in which everyone is already frothing at the mouth and reason is hard to come by. Give people some word they can utter to help them sound like th…
Earlier quoted context omitted.
1.) Awareness doesn’t mean they will use it. And in practice they often don’t use them. 2.) “ unlike cli tools or APIs you don't have to constantly remind it what MCPs it has available” - this doesn’t match my experience. In fact, bash commands are substantially more discoverable. 3.) Again, this doesn’t match my experience and the major providers recommend including available MCP tools in system prompts/CLAUDE.md/wh…
Chrome Devtools is similarly an extremely high value MCP for me. I would agree that if you don't find they add discoverability then MCPs would have no value for you and be worse than cli tools. It sounds like we have had very opposite experiences here.
So far I have seen two genuinely good arguments for the use of MCPs: * They can encapsulate (API) credentials, keeping those out of reach of the model, * Contrary to APIs, they can change their interface whenever they want and with little consequences.
So far I have seen two genuinely good arguments for the use of MCPs: * They can encapsulate (API) credentials, keeping those out of reach of the model, * Contrary to APIs, they can change their interface whenever they want and with little consequences.
What's the alternative design where the model has access to API credentials?
All sorts of ways this can happen but it usually boils down to leaving them on disk or in an environment variable in the repo/dir(s) where the agent is operating in.
[flagged]
MCP was a really shitty attempt at building a plugin framework that was vague enough to lure people into and then allow other companies to build plugin platforms to take care of the MCP non-sense. "What is MCP, what does it bring to the table? Who knows. What does it do? The LLM stuff! Pay us $10 a month thanks!" LLM's have function / tool calling built into them. No major models have any direct knowledge of MCP. Not…
probably easier to just tell people: You want MCP? Add a "description" field to your rest API that describes how to call it. That's all it's doing. Just plain ole context pollution. World could be better served by continuing to build out the APIs that exist.
Earlier quoted context omitted.
Yeah there's no there there when it comes to MCP. It's crazy to me that the world bought into the idea when the "spec" literally boils down to "have your server give the LLM some json". Just illustrates how powerful it is to attach names to things, especially in a hypestorm in which everyone is already frothing at the mouth and reason is hard to come by. Give people some word they can utter to help them sound like th…
"Have your XYZ give the LLM some JSON" is pretty close to how all tool calling works with or without MCP.
MCP and A2A are JSONRPC schemas people follow to build abstraction around their tools. Agents can use MCP to discover tools, invoke and more. OpenAPI Schemas are good alternatives to MCP servers today. In comparison to OpenAPI Schemas, MCP servers are pretty new.
my fav protocol is TCP, which I am a proud user of nc localhost 9999.
but not everyone have same taste of building software.