Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A critical look at MCP

raz.sh

Post reply on HN
Print view View original

61–70 of 348 posts

Re: A critical look at MCP

#61

Post by Seattle3503 »

vmaurin wrote: post #57

It will probably never work. Companies have spend probably the last decade(s?) closing everything on Internet: * no more RSS feed * paywall * the need to have an "app" to access a service * killing open protocols And all of the sudden, everyone will expose their data through simple API calls ?

Indeed I think a lot of companies will hate the idea of losing their analytics and app mediated control over their users.

I see it working in a B2B context where customers demand that their knowledge management systems (ticketing, docs, etc...) have an MCP interface.

Re: A critical look at MCP

#62

Post by quantadev »

MCP was invented by some very young LLM experts probably with limited experience in "protocol" design. They'll probably see this article you wrote criticizing it and realize they made a mistake. I bet there's a way to wrap that stdio stuff with WebSockets, like was recommended in the blog/article.

Frankly I'm not sure why an ordinary REST service (just HTTP posts) wasn't considered ok, but I haven't used MCP yet myself.

What MCP got right was very powerful of course which I'd summarize as giving all AI-related software the ability to call functions that reside on other servers during inference (i.e. tool calls), or get documents and prompt templates in a more organized way where said docs are specifically intended for consumption by AIs residing anywhere in the world (i.e. on other servers). I see MCP as sort of a 'function call' version of the internet where AIs are doing the calling. So MCP is truly like "The Internet for AIs". So it's huge.

But just like JavaScript sucks bad, yet we run the entire web on it, it won't be that bad if the MCP protocol is jank, as long as it works. Sure would better to have a clean protocol tho, so I agree with the article.

Re: A critical look at MCP

#63

Post by rco8786 »

punkpeye wrote: post #60

I am the founder of one of the MCP registries ( https://glama.ai/mcp/servers ). I somewhat agree with author’s comments, but also want to note that the protocol is in the extremely early stages of development, and it will likely evolve a lot over the next year. I think that no one (including me) anticipated just how much attention this will get straight out the door. When I started working on the registry, there were…

Agree with basically all of this.

The actual protocol of MCP is…whatever. I’m sure it will continue to evolve and mature. It was never going to be perfect out of the gate, because what is?

But the standardization of agentic tooling APIs is mind bogglingly powerful, regardless of what the standard itself actually looks like.

I can write and deploy code and then the AI just..immediately knows how to use it. Something you have to experience yourself to really get it.

Re: A critical look at MCP

#64

Post by Seattle3503 »

TZubiri wrote: post #14

"Why do I need to implement OAuth2 if I'm using HTTP as transport, while an API key is enough for stdio?" Because one is made for local and the other for connecting through the internet.

You need something like OAuth because you don't want your end users generating API keys for every service they want to use via LLM.

Re: A critical look at MCP

#65

Post by oxidant »

_QrE wrote: post #33

Agreed with basically the entire article. Also happy to hear that someone else was as bewildered as me when they visited the MCP site and they found nothing of substance. RFCs can be a pain to read, but they're much better than 'please just use our SDK library'.

I wish there was a clear spec on the site but there isn't https://modelcontextprotocol.io/specification/2025-03-26

It seems like half of it is Sonnet output and it doesn't describe how the protocol actually works.

For all its warts, the GraphQL spec is very well written https://spec.graphql.org/October2021/

Re: A critical look at MCP

#66

Post by _raz »

punkpeye wrote: post #60

I am the founder of one of the MCP registries ( https://glama.ai/mcp/servers ). I somewhat agree with author’s comments, but also want to note that the protocol is in the extremely early stages of development, and it will likely evolve a lot over the next year. I think that no one (including me) anticipated just how much attention this will get straight out the door. When I started working on the registry, there were…

Kind of my fear exactly. We are moving so fast and that mcp would create an accept a transport protocol that might take years or decades to get rid off for something better.

Kind of reminds me of the browser wars during 90s where everyone tried to run the fastest an created splits in standards and browsers what we didn't really det rid of for a good 20 year or more. IE11 was around for far to long

Re: A critical look at MCP

#67

Post by ethical_source »

punkpeye wrote: post #60

I am the founder of one of the MCP registries ( https://glama.ai/mcp/servers ). I somewhat agree with author’s comments, but also want to note that the protocol is in the extremely early stages of development, and it will likely evolve a lot over the next year. I think that no one (including me) anticipated just how much attention this will get straight out the door. When I started working on the registry, there were…

> I somewhat agree with author’s comments, but also want to note that the protocol is in the extremely early stages of development, and it will likely evolve a lot over the next year.

And that's why it's so important to spec with humility. When you make mistakes early in protocol design, you live with them FOREVER. Do you really want to live with a SSE Rube Goldberg machine forever? Who the hell does? Do you think you can YOLO a breaking change to the protocol? That might work in NPM but enterprise customers will scream like banshees if you do, so in practice, you're stuck with your mistakes.

Re: A critical look at MCP

#68

Post by practal »

There isn't much detailed technical spec on MCP on the spec site, but they have a link to a schema [1]. You can add that schema to a Claude project, and then examine it. That's very helpful, although you will quickly run into unsupported things, for example embedded resources in tool call responses in Claude Desktop.

I think MCP will be a huge deal for Practal. Implementing Practal as an MCP server, I basically don't need a frontend.

[1] https://github.com/modelcontextprotocol/modelcontextprotocol...

Re: A critical look at MCP

#69

Post by moralestapia »

kelnos wrote: post #52
moralestapia wrote: post #2

Context is stdin and stdio. "It kind of breaks the Unix/Linux piping paradigm using these streams for bidirectional communication." Uhm ... no? They were meant for that. But the rest of the critique is well founded. "Streamable HTTP" is quite an amateurish move.

> They were meant for that. No they weren't. If we look at it from the perspective of pipelines (and not interactive programs that take input directly from the user and display output on the screen), stdin is for receiving data from the program in the pipeline before you, and stdout is for sending data to the thing in the pipeline after you. That's not bidirectional, that's a unidirectional flow.

You are wrong.

STDIN means Standard INPUT.

STDOUT means Standard OUTPUT.

There is no design/hardware/software limitation to reading and writing to them at the same time. That's your bidirectional channel with that one process.

>stdin is for receiving data from the program in the pipeline before you, and stdout is for sending data to the thing in the pipeline after you

Yes, and you took that from my comment here: https://news.ycombinator.com/item?id=43947777

Did you just wanted to ratify my argument, or is there something else you want to add?

Re: A critical look at MCP

#70

Post by pixl97 »

_raz wrote: post #21
runekaagaard wrote: post #18

Earlier quoted context omitted.

I thinks a lot is timing and also that it's a pretty low bar to write your first mcp server: from mcp.server.fastmcp import FastMCP mcp = FastMCP("Basic Math Server") @mcp.tool() def multiply(a: int, b: int) -> int: return a * b mcp.run() If you have a large MCP server with many tools the amount of text sent to the LLM can be significant too. I've found that Claude works great with an OpenAPI spec if you provide it w…

That's kind of my point, that the protocols complexity is hidden in py sdk making it feel easy... But taking on large tech dept

I mean isn't this the point of a lot of, if not most successful software? Abstracting away the complexity making it feel easy, where most users of the software have no clue what kind of technical debt they are adopting?

Just think of something like microsoft word/excel for most of its existence. Seems easy to the end user, but attempting to move away from it was complex, the format had binary objects that were hard to unwind, and interactions that were huge security risks.

Post reply on HN