Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> However, I'm astonished by the apparent lack of mature engineering practices.

Exactly.

MCP is one of the worst 'standards' that I have seen come out from anywhere since JSON Web Tokens (JWTs) and the author rightfully points out the lack of engineering practices of a 'standard' that is to be widely used like any properly designed standard with industry-wide input.

> Increased Attack Surface: The multiple entry points for session creation and SSE connections expand the attack surface. Each entry point represents a potential vulnerability that an attacker could exploit.

JWTs have this same issue with multiple algorithms to use including the horrific 'none' algorithm. Now we have a similar issue with MCP with multiple entry points to chose from which is more ways to attack the protocol.

This one is the most damning.

> Python and JavaScript are probably one of the worst choices of languages for something you want to work on anyone else's computer. The authors seem to realize this since all examples are available as Docker containers.

Another precise point and I have to say that our industry is once again embracing the worst technologies to design immature standards like this.

The MCP spec appears to be designed without consideration for security or with any input from external companies like a normal RFC proposal should and is quite frankly repeating the same issues like JWTs.



I think it's clear that they want a proprietary solution that takes a year or more for others to copy. That gives them another year head start on the competition.


Who is "they"?


The AI houses buying up the entire market of GPUs. Have you heard about them?


This is paranoid drivel....

Tell me which is more likely.

1. There is a cabal of companies painstakingly working together to make the most convoluted software possible from scratch so they can dominate the market.

or

2. A few people threw together a bit of code to attempt to get something working without any deep engineering or systematic view of what they were trying to accomplish, getting something to work well enough that it took off quickly in a time where everyone wants to have tool use on LLMs.

I've been on the internet a long time and number 2 is a common software paradigm on things that are 'somewhat' open and fast moving. Number 1 does happen but it either is started and kept close by a single company, or you have a Microsoft "embrace, extend, extinguish" which isn't going on here.


2 works when you're making software, but not when you're making a specification.

The entire point of a specification is that it's well thought out. You SHOULD be considering ways it can be misused, vulnerabilities that might sneak into implementations.


there is a 1.5 option: VC-funded company decides what they want to achieve and inexperient engineers come up with a bugged implementation (that still focus on what VC-funded wanted, in this case more LLM calls with bloated context)


3. The internal & enterprise models are better and not based on Python.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: