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

261–270 of 348 posts

Re: A critical look at MCP

#261

Post by never_inline »

meander_water wrote: post #193
lolinder wrote: post #165

> the documentation is poorly written (all LLM vendors seem to have an internal competition in writing confusing documentation). This is almost certainly because they're all using LLMs to write the documentation, which is still a very bad idea. The MCP spec [0] has LLM fingerprints all over it. In fact, misusing LLMs to build a spec is much worse than misusing them to avoid writing good docs because when it comes to…

I can't say whether the original spec was written with AI assistance, but having a cursory look through the commit history [0] it doesn't look like they're just blatantly auto-generating the docs. The git history indicates that they do think about the spec and manually update the docs as the spec changes. [0] https://github.com/modelcontextprotocol/modelcontextprotocol...

I don't write perfect English. Far from it. But I'd prefer broken English any day over default LLM verbiage. It seems so unnatural and facetitious. I always have this in my prompts: "Be succinct and use simple English sentences".

Re: A critical look at MCP

#262

Post by never_inline »

jerf wrote: post #186
lolinder wrote: post #165

> the documentation is poorly written (all LLM vendors seem to have an internal competition in writing confusing documentation). This is almost certainly because they're all using LLMs to write the documentation, which is still a very bad idea. The MCP spec [0] has LLM fingerprints all over it. In fact, misusing LLMs to build a spec is much worse than misusing them to avoid writing good docs because when it comes to…

It had not occurred to me that the AI coding vendors are basically positively motivated to themselves produce code that is not documented. They want code that is comprehensible to AIs but actively not comprehensible to humans. Then you need their AIs to manipulate it. AI code as the biggest "lock you in the box" in programming history. That takes rather a lot of the luster out of it.... They'd better be right that th…

To be honest I don't think they have any plans either.

Re: A critical look at MCP

#263

Post by DonHopkins »

delian66 wrote: post #234
ComplexSystems wrote: post #227

Earlier quoted context omitted.

This has fascinated me for years. I'll just re-link this comment of mine from a few years ago: https://news.ycombinator.com/item?id=37544019#37548278 . This was about Amazon products rather than government documentation, but the point is the same. I'll just quote the relevant part: > The people who make these products have to spend millions and millions of dollars setting up factories, hiring people, putting things i…

It may have been A/B tested, and people do prefer the "INTIMATE SERVICE" version more...

Because A/B testing always has a happy ending.

Re: A critical look at MCP

#264

Post by azeirah »

Timwi wrote: post #207
volemo wrote: post #131

Earlier quoted context omitted.

Could you throw on a couple of examples of calcified early mistakes of Python? GIL is/was one, I presume?

Static functions (len, map/filter,...) that should have been methods on objects.

This one frustrates me so, so much.

Re: A critical look at MCP

#265

Post by qldp »

first off, very well done. this article captures exactly the uneasiness i've felt as an mcp implementer.

doing seemingly in-the-box, mundane things like asking the server to dynamically register a new resource after a tool call yields new local files is met with surprising errors like "resources cannot be registered after transport connection."

i reached for the official kotlin sdk, found it did not work (mcp clients refused stdio comms), looked at the source and saw that the transport layer had recently been converted to a proprietary implementation, leaving commented-out code in-place that showed the previous transport details. reimplementing the former, assumedly-functional interface yielded the same broken stdio behavior, and everything being package-private meant i couldn't easily modify sdk components to fiddle with a solution without rewriting the entire transport mechanism. i wasn't willing to do this on a lark and hope the rest of the sdk behaved as promised, so my team is now stuck with a typescript mcp server that no one is comfortable maintaining.

what's really concerning is that openai threw in the towel on a competing standard, so we're now being corraled into accepting mcp as the only reliable tool interface, because every llm (frontier, and derivatives trained on these models) will end up conforming to mcp whether they intend to or not.

i haven't yet mentioned that there's an implicit hierarchy in the three capabilities exposed to mcp clients/servers -- tools above resources and resources above prompts, the latter of which is flat-out ignored by clients. the instructions aspect of server initialization was the only reliable way to bootstrap context with actionable exemplars, and that's just a big, inlined markdown document.

all of that said, the mcp contract is not pretty, but it works. in ~200 lines of code, i can spin up a wrapper over existing APIs (web and/or local binaries) and provide a workable plugin that adds real value to my team's day-to-day activities. mcp hasn't really promised more than that, and what it's promised, it's delivered.

Re: A critical look at MCP

#266

Post by DonHopkins »

stuaxo wrote: post #258
ljm wrote: post #185

Earlier quoted context omitted.

Sometimes I wonder if I have ADHD or if it's induced by the content, because I can spend hours soaking up interesting literature and putting my weird thoughts down onto paper but I can barely make it a few words through LLM-driven drivel. It's crazy seeing bots posting AITA rage bait on Reddit that always follows the same pattern: some inter-personal conflict that escalates to a wider group: "I told my husband I wasn…

Yeah it's unreadable for me. There's been a trend to post LLM slop about tech subjects and they anger me - I don't know why someone wanted to waste people's time like that. Even worse - I've come across an AI slop site that masquerades as dev information, with just plain wrong information.

I let the domain "micropolisonline.com" expire, which I was using for the old OpenLaszlo/Flash Python/SWIG/C++ client/server based version of open source SimCity, and somebody took it over and replaced it with AI generated claptrap, stealing a lot of my own and other's images without any credit. It even promises the source code, but doesn't actually link to it, just has promises and placeholders.

It totally misrepresents what Micropolis is, which was based on the original SimCity classic, and confuses it with all the subsequent versions of SimCity and other made-up stuff. And it never mentions the GPL-3 license, EA's license and restrictions on the use of their SimCity trademark, or Micropolis's license to use their trademark. I have no idea what the point of it is.

https://micropolisonline.com/

https://micropolisonline.com/source-code/

>How to Access the Source Code: For those eager to explore the Micropolis Online Source Code, it is available on our dedicated GitHub repository. Visit [Link] to access the repository, where you can browse the code, contribute to ongoing projects, or initiate your own.

The source code is actually not at [Link] but at:

https://github.com/SimHacker/MicropolisCore

Not even so much as a link to the my demo!

https://www.youtube.com/watch?v=8snnqQSI0GE

They could be in some legal jepordy since they didn't mention or link to the Micropolis GPL License or the Micropolis Public Name License, which they may be violating.

https://github.com/SimHacker/MicropolisCore/blob/main/Microp...

https://github.com/SimHacker/MicropolisCore/blob/main/Microp...

The have a "Meet the Team" page that mentions nobody, just hand waves about "we" and the community. They couldn't even bother to generate generic looking fake profiles of non-existent people. Suffice it to say I never heard back from anyone after using the "Contact Us" page.

They even have a cute little Terms and Conditions page with their very own license, which doesn't allow anyone to do to them what they did to me, and is not particularly GPL-v3 compatible:

https://micropolisonline.com/terms-conditions/

>License to Use Micropolis Online

>Unless otherwise stated, Micropolis Online and/or its licensors own the intellectual property rights for all material on Micropolis Online. All intellectual property rights are reserved. You may view and/or print pages from micropolisonline.com for your own personal use subject to restrictions set in these terms and conditions.

>You must not:

>Republish material from micropolisonline.com Sell, rent, or sub-license material from micropolisonline.com Reproduce, duplicate, or copy material from micropolisonline.com

They also claim all rights to all user created content:

>By displaying Your Content, you grant Micropolis Online a non-exclusive, worldwide irrevocable, sub-licensable license to use, reproduce, adapt, publish, translate, and distribute it in any and all media.

Kind of ironic for an LLM to go around stealing people's content, then telling them that not only can't anyone copy it back, but it owns the rights to everything anyone else may contribute in the future.

Re: A critical look at MCP

#267

Post by DonHopkins »

cruffle_duffle wrote: post #233
jes5199 wrote: post #213

Earlier quoted context omitted.

someone is going to write an MCP adaptor that lets Claude use OpenAPI and then we can forget that MCP was a thing

How would that even work?

South Park explored that question:

https://www.youtube.com/watch?v=sbCj0i8WQA0

Re: A critical look at MCP

#268

Post by DonHopkins »

hirsin wrote: post #13

In the same way that crypto folks speedran "why we have finance regulations and standards", LLM folks are now speedrunning "how to build software paradigms". The concept they're trying to accomplish (expose possibly remote functions to a caller in an interrogable manner) has plenty of existing examples in DLLs, gRPC, SOAP, IDL, dCOM, etc, but they don't seem to have learned from any of them, let alone be aware that t…

I agree they should learn from DLLs, gRPC, SOAP, IDL, dCOM, etc.

But they should also learn from how NeWS was better than X-Windows because instead of a fixed protocol, it allowed you to send executable PostScript code that runs locally next to the graphics hardware and input devices, interprets efficient custom network protocols, responds to local input events instantly, implements a responsive user interface while minimizing network traffic.

For the same reason the client-side Google Maps via AJAX of 20 years ago was better than the server-side Xerox PARC Map Viewer via http of 32 years ago.

I felt compelled to write "The X-Windows Disaster" comparing X-Windows and NeWS, and I would hate if 37 years from now, when MCP is as old as X11, I had to write about "The MCP-Token-Windows Disaster", comparing it to a more efficient, elegant, underdog solution that got out worse-is-bettered. It doesn't have to be that way!

https://donhopkins.medium.com/the-x-windows-disaster-128d398...

It would be "The World's Second Fully Modular Software Disaster" if we were stuck with MCP for the next 37 years, like we still are to this day with X-Windows.

And you know what they say about X-Windows:

>Even your dog won’t like it. Complex non-solutions to simple non-problems. Garbage at your fingertips. Artificial Ignorance is our most important resource. Don’t get frustrated without it. A mistake carried out to perfection. Dissatisfaction guaranteed. It could be worse, but it’ll take time. Let it get in your way. Power tools for power fools. Putting new limits on productivity. Simplicity made complex. The cutting edge of obsolescence. You’ll envy the dead. [...]

Instead, how about running and exposing sandboxed JavaScript/WASM engines on the GPU servers themselves, that can instantly submit and respond to tokens, cache and procedurally render prompts, and intelligently guide the completion in real time, and orchestrate between multiple models, with no network traffic or latency?

They're probably already doing that anyway, just not exposing Turing-complete extensibility for public consumption.

Ok, so maybe Adobe's compute farm runs PostScript by the GPU instead of JavaScript. I'd be fine with that, I love writing PostScript! ;) And there's a great WASM based Forth called WAForth, too.

https://news.ycombinator.com/item?id=34374057

It really doesn't matter how bad the language is, just look at the success and perseverance of TCL/Tk! It just needs to be extensible at runtime.

NeWS applications were much more responsive than X11 applications, since you download PostScript code into the window server to locally handle input events, provide immediate feedback, translate them to higher level events or even completely handle them locally, using a user interface toolkit that runs in the server, and only sends high level events over the network, using optimized application specific protocols.

You know, just what all web browsers have been doing for decades with JavaScript and calling it AJAX?

Now it's all about rendering and responding to tokens instead of pixels and mouse clicks.

Protocols that fix the shape of interaction (like X11 or MCP) can become ossified, limiting innovation. Extensible, programmable environments allow evolution and responsiveness.

Speed run that!

Re: A critical look at MCP

#269

Post by fullstackchris »

koakuma-chan wrote: post #144
fendy3002 wrote: post #142

Earlier quoted context omitted.

HTTP call may be blocked by firewalls even internally, and it's overkill to force stdio apps to expose http endpoints for this case only. As in, how MCP client can access `git` command without stdio? You can run a wrapper server for that or use stdio instead

> As in, how MCP client can access `git` command without stdio? MCP clients don't access any commands. MCP clients access tools that MCP servers expose.

Here's a custom MCP tool I use to run commands and parse stdout / stderr all the time:

    try {
        const execPromise = promisify(exec);
        const { stdout, stderr } = await execPromise(command);
        if (stderr) {
            return {
                content: [{
                    type: "text",
                    text: `Error: ${stderr}`
                }],
                isError: true
            };
        }
        return {
            content: [{
                type: "text",
                text: stdout
            }],
            isError: false
        };
    } catch (error: any) {
        return {
            content: [{
                type: "text",
                text: `Error executing command: ${error.message}`
            }],
            isError: true
        };
    }
Yeah, if you want to be super technical, it's Node that does the actual command running, but in my opinion, that's as good as saying the MCP client is...

Re: A critical look at MCP

#270

Post by bsenftner »

I'll say it: MPC is immature trash, and will be replaced with... nothing. It is not needed, nor necessary if one has any functional engineering experience. It's yet another poorly considered distraction created by the software industry that cannot tie it's own shoes.
Post reply on HN