61–70 of 281 posts
> Think of MCP like a USB-C port for AI applications. That analogy may be helpful for mom, but not for me as a software engineer.
MCP Isn’t the USB-C of AI — It’s Just a USB-C(laude) Dongle
https://dev.to/internationale/mcp-is-not-ai-usb-c-its-usb-cl...
The illustrations are on their official website.
I find it hard to respect a company that invented dongle and claims to have invented USB
> Think of MCP like a USB-C port for AI applications. That analogy may be helpful for mom, but not for me as a software engineer.
In LSP, you have editor (vscode, neovim), and language servers (rust, typescript, python).
In MCP, you have the client (chat window), and servers (providing context, tools, and prompts).
> Think of MCP like a USB-C port for AI applications. That analogy may be helpful for mom, but not for me as a software engineer.
https://modelcontextprotocol.io/quickstart/server
I don't think it's terribly difficult to drill down into their GitHub to see what's happening under the hood if you need that level of detail.
However, if you look at the specification it's clear bringing the LSP-style paradigm to remote HTTP servers is adding a bunch of extra complexity. This is a tool call, for example:
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "get_weather",
"arguments": {
"location": "New York"
}
}
}
I've made the suggestion to remove some of this complexity [1] and fall back to just a traditional HTTP server, where a session can be negotiated with an `Authorization` header and we rely on traditional endpoints / OpenAPI + JSON Schema endpoint definitions. I think it would make server construction a lot easier and web frameworks would not have to materially be updated to adhere to the spec -- perhaps just adding a single endpoint.
[0] https://spec.modelcontextprotocol.io/specification/2025-03-2...
[1] https://github.com/modelcontextprotocol/specification/issues...
MCP is now the standard everyone must conform to. Couldn't possibly have predicted that 2 months ago.
Earlier quoted context omitted.
Hype isn’t free. Maybe the benefit is mutual, but I can’t tell how Anthropic gets paid. Anthropic subsidizes an open standard, but proprietary extensions later emerge that lock you into servers from their marketplace or something? I need a sociopath to help me understand this.
The Anthropic models are running underneath everything (Claude Code, Windsurf, Cursor, etc). Whenever someone is using MCP they (in the generalized case, until now) ultimately end up using Anthropic as their LLM and Anthropic gets paid whenever someone does that.
service providers get more traffic, so they’re into it. makes sense.
claude 3.5 was great at the time, especially for stuff like web dev. but now deepseek v3 (0324) is way better value. gemini's my default for multimodal. openai still feels smartest overall. i’ve got qwq running locally. for deep research, free grok 3 and perplexity work fine. funny enough, claude 3.7 being down these two days didn’t affect me at all.
i checked mcp since i contribute to open source, but decided to wait. few reasons:
- setup’s kind of a mess. it’s like running a local python or node bridge, forwarding stuff via sse or stdio. feels more like bridging than protocol innovation
- I think eventually we need all the app to be somehow built-in AI-first protocol. I think only Apple (maybe Google) have that kind of influence. Think about the lightening vs usb-c.
- performance might be a bottleneck later, especially for multimodal.
- same logic as no.2 but the question is that do you really want every app to be AI-first?
main issue for me: tools that really improve productivity are rare. a lot of mcp use cases sound cool, but i'll never give full github access to a black box. same for other stuff. so yeah—interesting idea, but hard ceiling.
claude needed these those tools in 2024, so having the community contribute for free was actually a smart move. service providers get more traffic, so they’re into it. makes sense. claude 3.5 was great at the time, especially for stuff like web dev. but now deepseek v3 (0324) is way better value. gemini's my default for multimodal. openai still feels smartest overall. i’ve got qwq running locally. for deep research,…
> Think of MCP like a USB-C port for AI applications. That analogy may be helpful for mom, but not for me as a software engineer.
In traditional applications, you know at design-time which functionality will end up in the final product. For example, you might bundle AI tools into the application (e.g. by providing JSON schemas manually). Once you finish coding, you ship the application. Design-time is where most developers are operating in, and it's not where MCP excels. Yes, you can add tools via MCP servers at design-time, but you can also include them manually through JSON schemas and code (giving you more control because you're not restricted by the abstractions that MCP imposes).
MCP-native applications on the other hand can be shipped, and then the users can add tools to the application — at runtime. In other words, at design-time you don't know which tools your users will add (similar to how browser developers don't know which websites users will visit at runtime). This concept — combined with the fact that AI generalizes so well — makes designing this kind of application extremely fascinating, because you're constantly thinking about how users might end up enhancing your application as it runs.
As of today, the vast majority of developers aren't building applications of this kind, which is why there's confusion.