Ask HN: Why MCP instead of just HTTP?
Why create a new protocol for fetching data instead of using existing protocols like HTTP?
There's far more training data already for just using fetch. I bet LLMs are better at fetch than MCP.
Why not extend LLMs with basic browser technology instead?
I also wonder about storing the fetches data in context (polluting it) vs elsewhere.
Is there a better way?
(
3 comments
| 2 points
| on HN
)
MCP isn't a replacement for HTTP; it's a higher-level protocol built on top of existing tech (including, optionally, HTTP as a transport) to solve a different problem. HTTP is great for request-response interactions on the web. MCP is designed for persistent, two-way communication between an LLM-powered application (the "client", frequently within a host like an IDE or chatbot UI) and one or more "servers" that provide access to data and capabilities.
Sampling for instance allows MCP servers to request LLM completions through the client. If you implemented this with HTTP, you'd need to build custom authentication, API key management, and permission systems. Each tool would implement its own custom HTTP endpoints and payloads for requesting AI completions as well as provide a structured way to include relevant context. The human approval flow would need to be custom-built for each implementation in addition. Also, HTTP request/response patterns don't easily support the bidirectional streaming needed for real-time AI interactions.
MCP is not exclusive to Anthropic models, it can be implemented with any of the AI providers.
[0] https://github.com/modelcontextprotocol/specification
[1] https://modelcontextprotocol.io/llms-full.txt
If anyone could point me in the direction of MCP error handling flow it would probably make sense.
Not much on Google