[HN Gopher] A Critical Look at MCP
___________________________________________________________________
A Critical Look at MCP
Author : ablekh
Score : 274 points
Date : 2025-05-10 14:37 UTC (8 hours ago)
(HTM) web link (raz.sh)
(TXT) w3m dump (raz.sh)
| moralestapia wrote:
| 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.
| OJFord wrote:
| I think 'bidirectional' is unclear there, they really mean a
| back and forth dialogue, _interactive_ bidirectional
| communication. Which, yeah, a socket (as they said) seems a
| better choice.
| moralestapia wrote:
| I think stdin and stdio are meant to always be piped forward,
| and a program further down the pipe cannot modify a tool back
| in the pipeline, maybe that's what he's trying to convey with
| "bidirectional"?
| kelnos wrote:
| > _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.
| moralestapia wrote:
| 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?
| justanotheratom wrote:
| It is indeed quite baffline why MCP is taking off, but facts are
| facts. I would love to be enlightened how MCP is better than an
| OpenAPI Spec of an existing Server.
| tedivm wrote:
| I'm not saying MCP is perfect, but it's better than OpenAPI for
| LLMs for a few reasons.
|
| * MCP tools can be described simply and without a lot of text.
| OpenAPI specs are often huge. This is important because the
| more context you provide an LLM the more expensive it is to
| run, and the larger model you need to use to be effective. If
| you provide a lot of tools then using OpenAPI specs could take
| up way too much for context, while the same tools for MCP will
| use much less.
|
| * LLMs aren't actually making the calls, it's the engine
| driving it. What happens when an LLM wants to make a call is it
| responds directly with a block of text that the engine catches
| and uses to run the command. This allows LLMs to work like
| they're used to: figuring out text to output. This has a lot of
| benefits: less tokens to output than a big JSON blob is going
| to be cheaper.
|
| * OpenAPI specs are static, but MCP allows for more dynamic
| tool usage. This can mean that different clients can get
| different specs, or that tools can be added after the client
| has connected (possibly in response to something the client
| sent). OpenAPI specs aren't nearly that flexible.
|
| This isn't to say there aren't problems. I think the transport
| layer can use some work, as OP sent, but if you play around in
| their repo you can see websocket examples so I wouldn't be
| surprised if that was coming. Also the idea that "interns" are
| the ones making the libraries is an absolute joke, as the
| FastMCP implementation (which was turned into the official
| spec) is pretty solid. The mixture of hyperbole with some
| reasonable points really ruins this article.
| armdave wrote:
| What does it mean that "different clients can get different
| specs"? Different in what dimension? I could imagine this
| makes creating repeatable and reliable workflows problematic.
| tedivm wrote:
| Using MCP you can send "notifications" to the server, and
| the server can send back notifications including the
| availability of new tools.
|
| So this isn't the same as saying "this user agent gets X,
| this gets Y". It's more like "this client requested access
| to X set of tools, so we sent back a notification with the
| list of those additional tools".
|
| This is why I do think websockets make more sense in a lot
| of ways here, as there's a lot more two way communication
| here than you'd expect in a typically API. This
| communication also is very session based, which is another
| thing that doesn't make sense for most OpenAPI specs which
| assume a more REST-like stateless setup.
| smartvlad wrote:
| If you look at the actual raw output of tools/list call you
| may find it surprisingly similar to the OpenAPI spec for the
| same interface. In fact they are trivially convertible to
| each other.
|
| Personally I find OpenAPI spec being more practical since it
| includes not just endpoints with params, but also outputs and
| authentication.
|
| Know all that from my own experience plugging dozens of APIs
| to both MCP/Claude and ChatGPT.
| 9dev wrote:
| > OpenAPI specs are static, but MCP allows for more dynamic
| tool usage.
|
| This is repeated everywhere, but I don't get it. OpenAPI
| specs are served from an HTTP endpoint, there's nothing
| stopping you from serving a dynamically rendered spec
| depending on the client or the rest of the world?
| hirsin wrote:
| This is one of the few places I think it's obvious why MCP
| provides value - an OpenAPI document is static and does no
| lifting for the LLM, forcing the LLM to handle all of the call
| construction and correctness on its own. MCP servers reduce LLM
| load by providing abstractions over concepts, with basically
| the same benefits we get by not having to write assembly by
| hand.
|
| In a literal sense it's easier, safer, faster, etc for an LLM
| to remember "use server Foo to do X" than "I read a document
| that talks about calling api z with token q to get data b, and
| I can combine three or four api calls using this http library
| to...."
| acchow wrote:
| I believe gp is saying the MCP's "tool/list" endpoint should
| return dynamic, but OpenAPI-format, content.
|
| Not that the list of tools and their behavior should be
| static (which would be much less capable)
| simonw wrote:
| My theory is that a lot of the buzz around MCP is actually buzz
| around the fact that LLM tool usage works pretty well now.
|
| OpenAI plugins flopped back in 2023 because the LLMs at the
| time weren't reliable enough for tool usage to be anything more
| than interesting-but-flawed.
|
| MCP's timing was much better.
| fhd2 wrote:
| I'm still having relatively disastrous results compared to
| just sending pre curated context (i.e. calling tools
| deterministically upfront) to the model.
|
| Doesn't cover all the use cases, but for information
| retrieval stuff, the difference is pretty light and day. Not
| to mention the deterministic context management approach is
| quite a bit cheaper in terms of tokens.
| visarga wrote:
| I find letting the agent iterate search leads to better
| results. It can direct the search dynamically.
| runekaagaard wrote:
| 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 with
| a way to look up details for individual paths and a custom
| message that explains the basics. For instance
| https://github.com/runekaagaard/mcp-redmine
| _raz wrote:
| 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
| pixl97 wrote:
| 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.
| Scotrix wrote:
| yeah, but it doesn't need to be that way. It can be
| simple and makes it easier adoptable, why over
| engineering and reinventing the wheel of at least 2
| decades experience and better practices.
| pixl97 wrote:
| Simple software is the most difficult software to make.
|
| Historically stated as
|
| >I apologize for such a long letter - I didn't have time
| to write a short one.
| practal wrote:
| The difficult part is figuring out what kind of
| abstractions we need MCP servers / clients to support. The
| transport layer is really not important, so until that is
| settled, just use the Python / TypeScript SDK.
| mmcnl wrote:
| But the spec is on the transport level. So for the
| specification, the transport layer is very important.
| practal wrote:
| This is the spec that counts: https://github.com/modelcon
| textprotocol/modelcontextprotocol...
|
| How exactly those messages get transported is not really
| relevant for implementing an mcp server, and easy to
| switch, as long as there is _some_ standard.
| vlovich123 wrote:
| You're ignoring the power of network effects - "shitty
| but widely adopted" makes "better but just starting
| adoption harder" to grow. Think about how long it takes
| to create a new HTTP standard - we've had 3 HTTP
| standards in the past 30 years, the first 19 of which so
| no major changes. HTTP/2 kind of saw no adoption in
| practice and HTTP/3 is still a mixed bag. In fact, most
| of the servers pretend HTTP/1 with layers in front
| converting the protocols.
|
| Underestimate network effects and ossification at your
| own peril.
| petesergeant wrote:
| This all sounds valid, but it's also the least interesting part
| of the whole thing. As a developer I'm expecting to be able to
| reach for a framework that'll just abstract away all the weird
| design decisions that he mentions.
| kelnos wrote:
| You're not the intended audience for this blog post. The people
| who care about this are the kinds of people who have to
| implement the protocol on either end, and deal with all of
| those complexities.
|
| You won't be able to fully insulate yourself from those
| complexities, though. Unnecessary complexity causes user-
| visible bugs and incompatibilities. You want to reach for a
| framework that will abstract all this stuff away, but because
| of poorly-designed protocols like MCP, those frameworks will
| end up being more unreliable than they need to be, in ways that
| will leak out to you.
| _raz wrote:
| Well put
| quantadev wrote:
| Just like I saw with protocols like ActivityPub and IPFS,
| what happens is the developers of these protocols do a couple
| of reference implementations in their favorite languages,
| which work, but then when they write the actual "spec" of
| what they _think_ they did in the code, they never get it
| fully correct, or even if they do it 's messy, incomplete, or
| not kept up to date.
|
| So as long as you're a developer working in one of those two
| languages you just take their code and run it, and all is
| fine. However for someone coming along trying to implement
| the protocol in a brand new language, it gets discovered that
| the protocol is insufficient and horrible and attempts to
| build based on the protocol are therefore doomed to fail.
|
| I'm not saying MCP has already reached this level of chaos,
| but I'm just saying this is the failure pattern that's fairly
| common.
| neuroelectron wrote:
| MCP is the moat to keep small players outside of the AI market.
| Not only does implementing it require a team, it is a tarpit of
| sabotage, where logging and state are almost impossible to track.
| triyambakam wrote:
| Have you tried it though? There are sdks where you can set up
| logging and MCP server or client in a few lines. Pydantic AI
| and Logfire as one example
| neuroelectron wrote:
| Yes, there are SDKs that abstract away some of the setup. But
| what exactly is being logged? Where is the data going? How
| tamper-proof is that logging? How is the network
| communication implemented? How do you check those logs? What
| exactly is being sent through the line? It's hard to audit,
| especially without deep visibility into the underlying layers
| which include binary blobs and their tokens for trust. How do
| you model internal state? How do you write regression tests?
| lelanthran wrote:
| SDKs aren't a spec.
|
| A spec is what I use to _write_ an SDK.
| esafak wrote:
| MCP is simple, as protocols go.
| stalfosknight wrote:
| I thought this was about the Master Control Program at first.
| homarp wrote:
| https://tron.fandom.com/wiki/Master_Control_Program
| hirsin wrote:
| 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 they exist.
|
| Give it more than a couple months though and I think we'll see it
| mature some more. We just got their auth patterns to use existing
| rails and concepts, just have to eat the rest of the camel.
| MuffinFlavored wrote:
| Isn't MPC based on JSON-RPC?
| hirsin wrote:
| Indeed! But seemingly only for the actual object
| representation - it's a start, and I wonder if JSON is
| uniquely suited to LLMs because it's so text-first.
| immibis wrote:
| I understand those with experience have found that XML
| works better because it's more redundant.
| wisemang wrote:
| Is it the redundancy? Or is it because markup is a more
| natural way to annotate language, which obviously is what
| LLMs are all about?
|
| Genuinely curious, I don't know the answer. But
| intuitively JSON is nice for easy to read payloads for
| transport but to be able to provide rich context around
| specific parts of text seems right up XML's alley?
| giantrobot wrote:
| The lack of inline context is a failing of JSON and a
| very useful feature of XML.
|
| Two simple but useful examples would be inline markup to
| define a series of numbers as a date or telephone number
| or a particular phrase tagged as being a different
| language from the main document. Inline semantic tags
| would let LLMs better understand the context of those
| tokens. JSON can't really do that while it's a native
| aspect of XML.
| solidasparagus wrote:
| Or is is because most text in existence is XML - or more
| specifically HTML.
| sitkack wrote:
| Hey, at least they didn't use yaml-rpc.
| _raz wrote:
| toml-rpc anyone? :)
| neuroelectron wrote:
| I think JSON is preferred because it adds more complexity.
| sroussey wrote:
| I think it works because json is verbose and reinforces
| what everything is in each record.
| visarga wrote:
| From this point of view XML offers all that and named
| brackets.
| sroussey wrote:
| True. Even better with inline attributes.
| _raz wrote:
| Yes, the protocol seems fine to me in and of itself. It's the
| transport portion that seems to be a dumpster fire on the
| HTTP side of things.
| foobarian wrote:
| Must have used GraphQL as a role model no doubt
| koakuma-chan wrote:
| This article feels like an old timer who knows WebSockets
| just doesn't want to learn what SSE is. I support the
| decision to ditch WebSockets because WebSockets would only
| add extra bloat and complexity to your server, whereas SSE
| is just HTTP. I don't understand though why have "stdio"
| transport if you could just run an HTTP server locally.
| fendy3002 wrote:
| 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
| koakuma-chan wrote:
| > 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.
| saurik wrote:
| I'm confused by the "old timer" comment, as SSE not only
| predates WebSockets, but the techniques surrounding its
| usage go really far back (I was doing SSE-like things--
| using script blocks to get incrementally-parsed data--
| back around 1999). If anything, I could see the opposite
| issue, where someone could argue that the spec was
| written by someone who just doesn't want to learn how
| WebSockets works, and is stuck in a world where SSE is
| the only viable means to implement this? And like, in
| addition to the complaints from this author, I'll note
| the session resume feature clearly doesn't work in all
| cases (as you can't get the session resume token until
| after you successfully get responses).
|
| That all said, the real underlying mistake here isn't the
| choice of SSE... it is trying to use JSON-RPC -- a
| protocol which very explicitly and very proudly is
| supposed to be stateless -- and to then use it in a way
| that is stateful in a ton of ways that aren't ignorable,
| which in turn causes all of this other insanity. If they
| had correctly factored out the state and not incorrectly
| attempted to pretend JSON-RPC was capable of state (which
| might have been more obvious if they used an off-the-
| shelf JSON-RPC library in their initial implementation,
| which clearly isn't ever going to be possible with what
| they threw together), they wouldn't have caused any of
| this mess, and the question about the transport wouldn't
| even be an issue.
| koakuma-chan wrote:
| > I'm confused by the "old timer" comment
|
| SSE only gained traction after HTTP/2 came around with
| multiplexing.
| matchagaucho wrote:
| Also missing in these strict, declarative protocols is a
| reliance on latent space, and the semantic strengths of LLMs.
|
| Is it sufficient to put a agents.json file in the root of the
| /.well-known web folder and let agents just "figure it out"
| through semantic dialogue?
|
| This forces the default use of HTTP as Agent stdio.
| snthpy wrote:
| Bravo. Agree with both of your examples.
| ethbr1 wrote:
| > _Give it more than a couple months though and I think we 'll
| see it mature some more._
|
| Or like the early Python ecosystem, mistakes will become
| ossified at the bottom layers of the stack, as people rapidly
| build higher level tools that depend on them.
|
| Except unlike early Python, the AI ecosystem community has no
| excuse, _BECAUSE THERE ARE ALREADY HISTORICAL EXAMPLES OF THE
| EXACT MISTAKES THEY 'RE MAKING._
| volemo wrote:
| Could you throw on a couple of examples of calcified early
| mistakes of Python? GIL is/was one, I presume?
| Doxin wrote:
| Possibly packaging too? though lately that has improved to
| the point where I'd not really consider it ossified at all.
| fullstackchris wrote:
| > early mistakes of Python?
|
| Python.
| worldsayshi wrote:
| I guess there's an incentive to quickly get a first version
| out the door so people will start building around your
| products rather than your competitors.
|
| And now you will outsource part of the thinking process.
| Everyone will show you examples when it doesn't work.
| wunderwuzzi23 wrote:
| Your comment reminds me that when I first wrote about MCP it
| reminded me of COM/DCOM and how this was a bit of a nightmare,
| and we ended up with the infamous "DLL Hell"...
|
| Let's see how MCP will go.
|
| https://embracethered.com/blog/posts/2025/model-context-prot...
| baxtr wrote:
| To this date I have not found a good explanation what an MCP
| is.
|
| What is it in old dev language?
| _raz wrote:
| A RPC standard that plays nicely with LLMs?
| kaoD wrote:
| In a nutshell: RPC with builtin discoverability for LLMs.
| jimmySixDOF wrote:
| old dev language is deterministic, llm in the loop now so the
| language is stochastic.
| jgalt212 wrote:
| it is amazing we used to prize determinism, but now it's
| like determinism is slowing me down. I mean how do you even
| write test cases for LLM agents. Do you have another LLM
| judge the results as close enough, or not close enough?
| victorbjorklund wrote:
| self documenting API
| mondrian wrote:
| It's a read/write protocol for making external data/services
| available to a LLM. You can write a tool/endpoint to the MCP
| protocol and plug it into Claude Desktop, for example. Claude
| Desktop has MCP support built-in and automatically queries
| your MCP endpoint to discover its functionality, and makes
| those functions available to Claude by including their
| descriptions in the prompt. Claude can then instruct Claude
| Desktop to call those functions as it sees fit. Claude
| Desktop will call the functions and then include the results
| in the prompt, allowing Claude to generate with relevant data
| in context.
|
| Since Claude Desktop has MCP support built-in, you can just
| plug off the shelf MCP endpoints into it. Like you could plug
| your Gmail account, and your Discord, and your Reddit into
| Claude Desktop provided that MCP integrations exist for those
| services. So you can tell Claude "look up my recent activity
| on reddit and send a summary email to my friend Bob about it"
| or whatever, and Claude will accomplish that task using the
| available MCPs. There's like a proliferation of MCP tools and
| marketplaces being built.
| fendy3002 wrote:
| If you know JSON-RPC: it's a JSON-RPC wrapper exposed for AI
| use and discovery.
|
| If you know REST / http request:
|
| it's single endpoint-only, partitioned / routed by single
| "type" or "method" parameter, with some different
| specification, for AI.
| northern-lights wrote:
| also called Vibe Designing.
| TZubiri wrote:
| "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.
| Seattle3503 wrote:
| 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.
| deadbabe wrote:
| Maybe we should though
| foobahhhhh wrote:
| I hate API keys. Get a horrible feeling when I see one.
| When will this have to expire and how do I remember to
| recycle it. And if it doesn't expire that is an issue too.
| rvz wrote:
| > 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.
| neuroelectron wrote:
| 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.
| danielbln wrote:
| Who is "they"?
| neuroelectron wrote:
| The AI houses buying up the entire market of GPUs. Have you
| heard about them?
| pixl97 wrote:
| 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.
| neuroelectron wrote:
| 3. The internal & enterprise models are better and not
| based on Python.
| owebmaster wrote:
| 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)
| hrpnk wrote:
| This critical look focuses just on the protocol. The fun starts
| with the actual MCP server implementations... Seems that
| providing an MCP server is the to be or not to be for all sorts
| of vendors. All REST APIs get wrapped into an MCP to make
| products LLM-compatible and tick checkmarks on newly extended
| checklists.
|
| Many pass REST responses directly to LLMs that quickly leads to
| token burn. Wish providers took a closer look on the actual
| engineering practices for the servers.
|
| Has someone seen a good implementation of an MCP server with a
| comprehensive test suite?
| _QrE wrote:
| 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'.
| _raz wrote:
| Glad to here, also thought I was alone :)
| dlandis wrote:
| Agree... this is an important blog. People need to press pause
| on MCP in terms of adoption...it was simply not designed with a
| solid enough technical foundation that would make it suitable
| to be an industry standard. People are hyped about it, kind of
| like they were for LangChain and many other projects, but
| people are going to gradually (after diving into
| implementations) that it's not actually what they were looking
| for..It's basically a hack thrown together by a few people and
| there are tons of questionable decisions, with websockets being
| just one example of a big miss.
| __loam wrote:
| The Langchain repo is actually hilariously bad if you ever go
| read the source. I can't believe they raised money with that
| crap. Right place right time I guess.
| worldsayshi wrote:
| Isn't that what a lot of this is about? It's a blue ocean
| and everyone are full of fomo.
| oxidant wrote:
| 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/
| 9dev wrote:
| I didn't believe you before clicking the link, but hot damn.
| That reads like the ideas I scribbled down in school about
| all the cool projects I could build. There is literally zero
| substance in there. Amazing.
| Aperocky wrote:
| MCP is a microcosm of LLM.
|
| Everything looks great works snappy and fast, until you look
| deeper inside or try to get it to do more complex stuff.
| nicomt wrote:
| The post misses the mark on why a stateless protocol like MCP
| actually makes sense today. Most modern devs aren't spinning up
| custom servers or fiddling with sticky sessions--they're using
| serverless platforms like AWS Lambda or Cloudflare Workers
| because they're cheaper, easier to scale, and less of a headache
| to manage. MCP's statelessness fits right into that model and
| makes life simpler, not harder.
|
| Sure, if you're running your own infrastructure, you've got other
| problems to worry about--and MCP won't be the thing holding you
| back. Complaining that it doesn't cater to old-school setups kind
| of misses the point. It's built for the way things work now, not
| the way they used to.
| progbits wrote:
| It's not really stateless. How do you want to support SSE or
| "Streamable HTTP" on your lambda? Each request will hit a new
| random worker, but your response is supposed to go on some
| other long-running SSE stream.
|
| The protocol is absolute mess both for clients and servers. The
| whole thing could have been avoided if they picked any sane
| bidirectional transport, even websocket.
| halter73 wrote:
| > Each request will hit a new random worker, but your
| response is supposed to go on some other long-running SSE
| stream.
|
| It seems your knowledge is a little out of date. The big
| difference between the older SSE transport and the new
| "Streamable HTTP" transport is that the JSON-RPC response is
| supposed to be in the HTTP response body for the POST request
| containing the JSON-RPC request, not "some other long-running
| SSE stream". The response to the POST can be a text/event-
| stream if you want to send things like progress notifications
| before the final JSON-RPC response, or it can be a plain
| application/json response with a single JSON-RPC response
| message.
|
| If you search the web for "MCP Streamable HTTP Lambda",
| you'll find plenty of working examples. I'm a little
| sympathetic to the argument that MCP is currently
| underspecified in some ways. For example, the spec doesn't
| currently mandate that the server MUST include the JSON-RPC
| response directly in the HTTP response body to the initiating
| POST request. Instead, it's something the spec says the
| server SHOULD do.
|
| Currently, for my client-side Streamable implementation in
| the MCP C# SDK, we consider it an error if the response body
| ends without a JSON-RPC response we're expecting, and we
| haven't gotten complaints yet, but it's still very early. For
| now, it seems better to raise what's likely to be an error
| rather than wait for a timeout. However, we might change the
| behavior if and when we add resumability/redelivery support.
|
| I think a lot of people in the comments are complaining about
| the Streamable HTTP transport without reading it [1]. I'm not
| saying it's perfect. It's still undergoing active
| development. Just on the Streamable HTTP front, we've removed
| batching support [2], because it added a fair amount of
| additional complexity without much additional value, and I'm
| sure we'll make plenty more changes. As someone who's
| implemented a production HTTP/1, HTTP/2 and HTTP/3 server
| that implements [3], and also helped implement automatic
| OpenAPI Document generation [4], no protocol is perfect. The
| HTTP spec misspells "referrer" and it has a race condition
| when a client tries to send a request over an idle "keep-
| alive" connection at the same time the server tries to close
| it. The HTTP/2 spec lets the client just open and RST streams
| without the server having any way to apply backpressure on
| new requests. I don't have big complaints about HTTP/3 yet
| (and I'm sure part of that is a lot of the complexity in
| HTTP/2 was properly handled by the transport layer which for
| Kestrel means msquic), but give it more time and usage and
| I'm sure I'll have some. That's okay though, real artists
| ship.
|
| 1: https://modelcontextprotocol.io/specification/2025-03-26/b
| as...
|
| 2: https://github.com/modelcontextprotocol/modelcontextprotoc
| ol...
|
| 3: https://learn.microsoft.com/aspnet/core/fundamentals/serve
| rs...
|
| 4: https://learn.microsoft.com/aspnet/core/fundamentals/opena
| pi...
| grogenaut wrote:
| I find the discussing of the quality of the MCP protocol funny.
| This space is constantly evolving very quickly. I consider MCP
| completely throw away, and I'm willing to deal with it as
| unimportant in that rapidly evolving space. I'm sure there will
| be a different implementation and approach in 6-12 months, or
| not. From the speed I'm able to turn on MCP integrations I don't
| think it'll take that long to swap to another protocol. We're in
| the sone age here. MCP may be crappy but it's a flint and steel
| versus a bowstring. Eventually we'll get to central or zoned
| heating.
|
| I'm using MCP locally on my laptop, the security requirements are
| different there than on a server. Logging can be done at the
| actual integration with external api level if you have standard
| clients and logging, which I do and push for.
|
| To me what is important right now is to glue my apis, data
| sources, and tools, to the AI tools my people are using. MCP
| seems to do that easily. Honestly I don't care about the
| protocol, at the end of the day, protocols are just ways for
| things to talk to each other, if they're interesting in and of
| themselves to you you're focusing on other things than I am. My
| goal is delivering power with the integration.
|
| MCP may be messy, but the AI tools I'm using them with seem just
| fine and dealing with that mess to help me build more power into
| the AI tools. That, at the end of the day is what I care about,
| can I get the info and power into the tools so that my employees
| can do stuff they couldn't do before. MCP seems to do that just
| fine. If we move to some other protocol in 6 months, I'm assuming
| I can do that with AI tools on a pretty quick basis, as fast as
| I'm building it right now.
| _heimdall wrote:
| I haven't dug too deeply into MCP yet so I may very well be wrong
| here, but it feels like get another attempt to paper over the
| fact that we abandoned REST APIs nearly 20 years ago.
|
| XML is ugly and building APIs that describe both the data and
| available actions is tough.
|
| Instead we picked JSON RPCs that we still call REST, and we
| inevitably run into situations like Alexa or LLMs where we want a
| machine to understand what actions are supported in an API and
| what the data schema is.
| ethical_source wrote:
| You must understand that when you deal with AI people, you deal
| with children. Imagine the author of the spec you're trying to
| implement is a new grad in San Francisco (Mission, not Mission
| Street, thanks).
|
| He feels infallible because he's smart enough to get into a hot
| AI startup and hasn't ever failed. He's read TCP 973 and 822 and
| 2126 and admitted the vibe or rigor but can't tell you why we
| have SYN and Message-ID or what the world might have been had
| alternatives one.
|
| He has strong opinions about package managers for the world's
| most important programming languages. (Both of them.) But he
| doesn't understand that implementation is incidental. He's the
| sort of person to stick "built in MyFavoriteFramework" above the
| food on his B2B SaaS burrito site. He doesn't appreciate that
| he's not the customer and customers don't give a fuck. Maybe he
| doesn't care, because he's never had to turn a real profit in his
| life.
|
| This is the sort of person building perhaps the most important
| human infrastructure since the power grid and the Internet
| itself. You can't argue with them in the way the author of the
| MCP evaluation article does. They don't comprehend. They CANNOT
| comprehend. Their brains do not have a theory of mind sufficient
| for writing a spec robust to implementation by other minds.
|
| That's why they ship SDKs. It's the only thing they can. Their
| specs might as well be "Servers SHOULD do the right thing. They
| MUST have good vibes." Pathetic.
|
| God help us.
| phillipcarter wrote:
| ...what? Literally nothing you wrote is accurate.
| ethical_source wrote:
| You'll come around to my perspective in time. Don't take it
| personally. This generation isn't any worse than prior ones.
| We go through this shit every time the tech industry turns
| over.
| phillipcarter wrote:
| The people who built MCP are seasoned software engineers,
| as are most folks who work for these labs. What are you
| even on about?
| ethical_source wrote:
| LOL
| phillipcarter wrote:
| Okay, well, clearly you have some funny beliefs, and I
| won't try to convince you otherwise. Just think first
| before posting weird screeds with no basis in reality
| next time.
| ethical_source wrote:
| > weird
|
| Adj, something the speaker wants the audience to dislike
| without the speaker being on the hook for explaining why.
|
| > screed
|
| Noun, document the speaker doesn't like but can't rebut.
|
| It's funny how people in the blue tribe milieu use the
| same effete vocabulary. I'll continue writing at the
| object level instead of affecting seven zillion layers of
| affected fake kindness, thanks.
| owebmaster wrote:
| The people building MCP are in the same cohort as the
| Doge "hackers". And we can see the result.
| auggierose wrote:
| I think you are wrong, but I upvoted anyway because it is so
| funny :-)
| elesbao wrote:
| my dude really got angry but forgot almost all cloud message
| queue offerings over HTTP works like this (minus SSE). Eventually
| MCP will take the same route as WS which started clunky with the
| http upgrade thing being standard but not often used and evolved.
| Then it will migrate to any other way of doing remote interface,
| as GRPC, REST and so on.
| zbentley wrote:
| I mean...the cloud message queues that use HTTP are _not_ good
| examples of quality software. They all end up being mediocre to
| poor on every axis: they're not generalizable enough to be high
| quality low level components in complex data routing (e.g.
| SQS's design basically precludes rapid redelivery on client
| failure, and is resistant to heterogenous workloads by
| requiring an up-front redelivery /deadletter timeout);
| simultaneously, HTTP's statelessness at the client makes
| extremely basic use cases flaky since e.g. consumer
| acknowledgment/"pop" failures are hard to differentiate as
| server-side issues, incorrect client behavior, or conceptual
| partitions in the consume transaction network
| link..."conceptual" because that connection doesn't actually
| exist, leading to all these problems. Transactionality between
| stream operations, too, is either a hell-no or a hella-slow
| (requiring all the hoop-jumping mentioned in TFA for clients'
| operations to find the server session that "owns" the
| transaction's pseudo connection) if built on top of HTTP.
|
| In other words, you can't emulate a stateful connection on top
| of stateless RPC--well, you can, but nobody does because it'd
| be slow and require complicated clients. Instead, they staple a
| few headers on top of RPC and assert that it's just as good as
| a socket. Dear reader: it is not.
|
| This isn't an endorsement of AMQP 0.9 and the like or anything.
| The true messaging/streaming protocols have plenty of their own
| issues. But at least they don't build on a completely self-
| sabotaged foundation.
|
| Like, I get it. HTTP is popular and a lot of client ecosystems
| balk at more complex protocols. But in the case of stateful
| duplex communication (of which queueing is a subset), _you
| don't save on complexity by building on HTTP._ You just move
| the complexity into the reliability domain rather than the
| implementation domain.
| vmaurin wrote:
| 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 ?
| Seattle3503 wrote:
| 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.
| auggierose wrote:
| I think it is a huge opportunity to dethrone established
| players that don't want to open up that way. Users will want
| it, and whoever gives it to them, wins.
| punnerud wrote:
| I don't agree with MCP being a bad standard, remember it's
| supposed to be as simple and easy as possible to not take up a
| lot of tokens and for the LLM to use.
|
| More complex stuff you can build on the "outside". So keeping it
| local seems ok, because it's just the LLM facing part.
| punkpeye wrote:
| 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 fewer than a few dozen
| servers. Then suddenly a few weeks later there was a thousand,
| and numbers just kept growing.
|
| However, lots and lots of those servers do not work. Majority of
| my time has gone into trying to identify servers that work (using
| various automated tests). All of this is in large part because
| MCP got picked up by the mainstream AI audience before the
| protocol reached any maturity.
|
| Things are starting to look better now though. We have a few
| frameworks that abstract the hard parts of the protocol. We have
| a few registries that do a decent job surfacing servers that work
| vs those that do not. We have a dozen or so clients that support
| MCPs, etc. All of this in less than half a year is unheard of.
|
| So yes, while it is easy to find flaws in MCP, we have to
| acknowledge that all of it happened in a super short amount of
| time - I cannot even think of comparisons to make. If the
| velocity remains the same, MCP future is very bright.
|
| For those getting started, I maintain a few resources that could
| be valuable:
|
| * https://github.com/punkpeye/awesome-mcp-servers/
|
| * https://github.com/punkpeye/awesome-mcp-devtools/
|
| * https://github.com/punkpeye/awesome-mcp-clients/
| rco8786 wrote:
| 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.
| punkpeye wrote:
| Yup. It's easy to focus on what's missing or broken in early-
| stage tech, but I'm more excited about where this kind of
| standardization could take us. Sometimes you need to look
| beyond imperfections and see the possibilities ahead.
| _raz wrote:
| 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
| punkpeye wrote:
| I think that transport is a non-issue.
|
| Whatever the transport evolves to, it is easy to create
| proxies that convert from one transport to another, e.g.
| https://github.com/punkpeye/mcp-proxy
|
| As an example, every server that you see on Glama MCP
| registry today is hosted using stdio. However, the proxy
| makes them available over SSE, and could theoretically make
| them available over WS, 'streamable HTTP', etc
|
| Glama is just one example of doing this, but I think that
| other registries/tools will emerge that will effectively make
| the transport the server chooses to implement irrelevant.
| ethical_source wrote:
| > 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.
| punkpeye wrote:
| Just focusing on worst-case scenarios tends to spread more
| FUD than move things forward. If you have specific proposals
| for how the protocol could be designed differently, I'm sure
| the community would love to hear them -
| https://github.com/orgs/modelcontextprotocol/discussions
| ethical_source wrote:
| The worst case scenario being, what, someone implementing
| the spec instead of using the SDK and doing it in a way you
| didn't anticipate? Security and interoperability will not
| yield to concerns about generating FUD. These concerns are
| important whether you like them or not. You might as well
| be whispering that ill news is a ill guest.
|
| At the least, MCP needs to clarify things like "SHOULD rate
| limit" in more precise terms. Imagine someone who is NOT
| YOU, someone who doesn't go to your offsites, someone who
| doesn't give a fuck about your CoC, implementing your spec
| TO THE LETTER in a way you didn't anticipate. You going to
| sit there and complain that you obviously didn't _intend_
| to do the things that weird but compliant server is doing?
| You don 't have a recourse.
|
| The recent MCP annotations work is especially garbage. What
| the fuck is "read only"? What's "destructive"? With respect
| to what? And hoo boy, "open world". What the fuck? You
| expect people to read your mind?
|
| What would be the point of creating GH issues to discuss
| these problems? The kind of mind that writes things like
| this isn't the kind of mind that will understand why they
| need fixing.
| quantadev wrote:
| 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.
| practal wrote:
| 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...
| stevev wrote:
| One major obstacle to grasping high-level abstractions and their
| implementations lies in poorly designed systems or language
| limitations. At this stage, any human-produced effort--be it
| documentation, explanations, or naming--should be reviewed by AI.
| Language models often excel at crafting clearer analogies and
| selecting more meaningful or intuitive naming conventions than we
| do. In short, let LLMs handle the documentation.
|
| -- written by ai
| mountainriver wrote:
| MCP is in a race to be valuable at all. Smarter agents will have
| no use for it
| foobahhhhh wrote:
| Because they can design a protocol in the blink of an eye? They
| can read docs, play with an API and then figure out how to call
| it?
| bosky101 wrote:
| I drew a cartoon/satire on mcp titled zombie prompting. You can
| find the original here
| https://x.com/0xBosky/status/1906356379486679521
|
| Tldr; it's json array passed to llms. Swagger would have
| sufficed. How and why youcome up with the array shouldn't matter.
| We shouldn't need 10000 redundant servers.
| Scotrix wrote:
| Couldn't agree more, played the whole day today trying to get a
| HTTP MCP server with Claude running.
|
| Absolutely terrible, no clear spec, absolute useless errors
| and/or just broken behaviour without telling what's wrong.
| Reference implementations and frameworks are not working either,
| so only reverse engineering + trial & error until it runs, yaaay.
|
| Feels like the early 2000 over and over again, trying to make
| something work.
| owebmaster wrote:
| > Feels like the early 2000 over and over again
|
| Exciting, right? Technology is unpredictable and fun again :)
| dend wrote:
| Just to add one piece of clarification - the comment around
| authorization is a bit out-of-date. We've worked closely with
| Anthropic and the broader security community to update that part
| of MCP and implement a proper separation between resource server
| (RS) and authorization server (AS) when it comes to roles. You
| can see this spec in draft[1] (it will be there until a new
| protocol version is ratified).
|
| [1]:
| https://modelcontextprotocol.io/specification/draft/basic/au...
| _raz wrote:
| Idk, I'm kind of agnostic and ended up throwing it in there.
|
| Regurgitating the OAuth draft don't seem that usefull imho, and
| why am I forced into it if I'm using http. Seems like there are
| plenty of usecases where un-attended thing would like to
| interact over http, where we usually use other things aside
| from OAuth.
|
| It all probably could have been replaced by
|
| - The Client shall implement OAuth2 - The Server may implement
| OAuth2
| dend wrote:
| For local servers this doesn't matter as much. For remote
| servers - you won't really have any serious MCP servers
| without auth, and you want to have some level setting done
| between client and servers. OAuth 2.1 is a good middle
| ground.
|
| That's also where, with the new spec, you don't actually need
| to implement anything from scratch. Server issues a 401 with
| WWW-Authenticate, pointing to metadata for authorization
| server locations. Client takes that and does discovery,
| followed by OAuth flow (clients can use many libraries for
| that). You don't need to implement your own OAuth server.
| vlovich123 wrote:
| Bearer tokens work elsewhere and imho are drastically
| simpler than oauth
| lolinder wrote:
| What percentage of the MCP spec is (was?) LLM output?
|
| It's setting off all kinds of alarm bells for me, and I'm
| wondering if I'm on to something or if my LLM-detector alarms
| are miscalibrated.
| keithwhor wrote:
| On MCP's Streamable HTTP launch I posted a issue asking if we
| should just simplify everything for remote MCP servers to just be
| HTTP requests.
|
| https://github.com/modelcontextprotocol/modelcontextprotocol...
|
| MCP as a spec is really promising; a universal way to connect
| LLMs to tools. But in practice you hit a lot of edge cases really
| quickly. To name a few; auth, streaming of tool responses, custom
| instructions per tool, verifying tool authenticity (is the server
| I'm using trustworthy?). It's still not entirely clear (*for
| remote servers*) to me what you can do with MCP that you can't do
| with just a REST API, the latter being a much more
| straightforward integration path.
|
| If other vendors do adopt MCP (OpenAI and Gemini have promised
| to) the problem they're going to run into very quickly is that
| they want to do things (provide UI elements, interaction layers)
| that go beyond the MCP spec. And a huge amount of MCP server
| integrations will just be lackluster at best; perhaps I'm wrong
| -- but if I'm { OpenAI, Anthropic, Google } I don't want a
| consumer installing Bob's Homegrown Stripe Integration from a
| link they found on 10 Best MCP Integrations, sharing their secret
| key, and getting (A) a broken experience that doesn't match the
| brand or worse yet, (B) credentials stolen.
| keithwhor wrote:
| Quick follow up:
|
| I anticipate alignment issues as well. Anthropic is building
| MCP to make the Anthropic experience great. But Anthropic's
| traffic is fractional compared to ChatGPT - 20M monthly vs 400M
| weekly. Gemini claims 350M monthly. The incentive structure is
| all out of whack; how long are OpenAI and Google going to let
| an Anthropic team (or even a committee?) drive an integration
| spec?
|
| Consumers have barely interacted with these things yet. They
| did once, with ChatGPT Plugins, and it failed. It doesn't
| entirely make sense to me that OpenAI is okay to do this again
| but let another company lead the charge and define the
| limitations of the end user experience (because that what the
| spec ultimately does, dictates how prompts and function
| responses are transported), when the issue wasn't the
| engineering effort (ChatGPT's integration model was objectively
| more elegant) but a consumer experience issue.
|
| The optimistic take on this is the community is strong and
| motivated enough to solve these problems as an independent
| group, and the traction is certainly there. I am interested to
| see how it all plays out!
| Scotrix wrote:
| OpenAI takes the backseat and wait until something
| stable/usable comes out of it which gains traction and takes
| it over then. Old classic playbook to let others make the
| mistakes and profit from it...
| _raz wrote:
| Once I published the blog post, I ended up doing a similar
| thing the other day.
| https://github.com/modelcontextprotocol/modelcontextprotocol...
|
| From reading your issue, I'm not holding my breath.
|
| It all kind of seems too important to fuck up
| keithwhor wrote:
| In the grand scheme of things I think we are still very
| early. MCP might be the thing which is why I'd rather try and
| contribute if I can; it does have a grassroots movement I
| haven't seen in a while. But the wonderful thing about the
| market is that incentives, e.g. good customer experiences
| that people pay for, will probably win. This means that MCP,
| if it remains the focal point for this sort of work, will
| become a lot better regardless of whether or not early pokes
| and prods by folks like us are successful or not. :)
| dboreham wrote:
| People love to invent new stuff, even when said stuff already
| exists. Other people love to embrace said unnecessary new stuff
| without question.
| traviscline wrote:
| Thanks for this, I've been feeling similarly.
|
| I'm working on some Go programs/tools with the explicit goal of
| describing existing servers in a language neutral manner to try
| to get some sanity into the mix.
|
| I was reenergized to pick this back up because Google is working
| on a version so I want to get these tools ready.
|
| Open to ideas and input, have been noodling on it for a bit now,
| lots not in form to share but figured I'd share early:
|
| https://github.com/tmc/mcp
| _raz wrote:
| I had to take a break from extending, our go LLM wrapper,
| https://github.com/modfin/bellman with mcp to write the blog
| entry. So some sort of server-like-thing will be added soon
| traviscline wrote:
| In the current state you can insert "mcpspy" in front of a
| server and it intercepts and streams out a plain text format
| that's nice for humans and machines. There's also a replay tool
| that emulates previous traffic, including in mock client and
| server modes, and a diffing program that is mcp protocol aware.
|
| Oh, and most importantly, a vim syntax plugin for the .mcp file
| format.
| traviscline wrote:
| https://github.com/tmc/mcp/blob/next/cmd/mcpdiff/testdata/sc.
| ..
|
| This is what the tests look like, for both the tools and to
| validate the servers.
| shivawu wrote:
| Obviously the article is making valid points. But a recent
| epiphany I had is, things by default are just mediocre but works.
| Of course the first shot at this problem is not going to be very
| good, very much like the first version of JavaScript is a
| shitshow and we'll take years to pay down the technical debts. In
| order to force a beautiful creation, significant effort and will
| power needs to be put in place. So Id say I'm not surprised at
| all and this is just how the world works, in most cases.
| keithwhor wrote:
| I think this is a cop out. OpenAI literally published a better
| integration spec two years ago, stored on `/.well-known/ai-
| plugin.json`. It just gave a summary of an OpenAPI spec, which
| ChatGPT could consume and then run your functions.
|
| It was simple and elegant, the timing was just off. So the
| first shot at this problem actually looked quite good, and
| we're currently in a regression.
| aristofun wrote:
| This is a part of the bigger problem. Near all of AI is done by
| mathematicians, (data) scientists, students and amateur
| enthusiasts. Not by professional software engineers.
|
| This is why nearly everything looks like a one weekend pet
| project by the standards of software engineering.
| doug_durham wrote:
| Speak for yourself. I see the majority of work being done by
| professional software engineers.
| aristofun wrote:
| Any popular examples to support your claim?
|
| My claim is supported by the post article and many points
| there, for example. Another example is my own experience
| working with python ecosystem and ai/ml libraries in
| particular. With rare exceptions (like pandas) it is mostly
| garbage from DevX perspective (in comparison of course).
|
| But I admit my exposure is very limited. I don't work in ai
| area professionally (which is another example of my point
| btw, lol))
| fleischhauf wrote:
| pytorch, tensorflow, numpy there are quite a few examples
| ai/ml has been steadily more commodetized, so it's far from
| only being developed by mathematicians. Hence every
| highschools student and his mother has an AI startup now.
| (And I'm not even mad, it's actually very exciting to see
| what people come up with nowadays)
| lolinder wrote:
| Unfortunately when someone says "AI" these days they're
| not talking about pytorch, tensorflow, or numpy. They're
| talking specifically about LLMs, which are built _on top_
| of those tools but which do show the tendency that OP is
| identifying to generally appear to be vibe-coded over a
| weekend rather than designed by a rigorous engineering
| process like what we 've come to expect from foundational
| tech like web browsers or operating systems (or, yes,
| pytorch or numpy).
| theturtle32 wrote:
| Regarding the WebSocket critiques specifically, as the author of
| https://www.npmjs.com/package/websocket, and having participated
| in the IETF working group that defined the WebSocket protocol, I
| completely agree with this blog post's author.
|
| The WebSocket protocol is the most ideal choice for a bi-
| directional streaming communication channel, and the arguments
| listed in
| https://github.com/modelcontextprotocol/modelcontextprotocol...
| for "Why Not WebSockets" are honestly bewildering. They are at
| best thin, irrelevant and misleading. It seems as though they
| were written by people who don't really understand the WebSocket
| protocol, and have never actually used it.
|
| The comment farther down the PR makes a solid rebuttal.
| https://github.com/modelcontextprotocol/modelcontextprotocol...
|
| Here are the stated arguments against using the WebSocket
| protocol, and my responses.
|
| ---
|
| Argument 1: Wanting to use MCP in an "RPC-like" way (e.g., a
| stateless MCP server that just exposes basic tools) would incur a
| lot of unnecessary operational and network overhead if a
| WebSocket is required for each call.
|
| Response 1: There are multiple better ways to address this.
|
| Option A.) Define a plain HTTP, non-streaming request/response
| transport for these basic use cases. That would be both
| DRAMATICALLY simpler than the "Streaming HTTP" HTTP+SSE transport
| they did actually define, while not clouding the waters around
| streaming responses and bi-directional communications.
|
| Option B.) Just leave the WebSocket connection open for the
| duration of the session instead of tearing it down and re-
| connecting it for every request. Conceptualizing a WebSocket
| connection as an ephemeral resource that needs to be torn down
| and reconstructed for every request is wrong.
|
| ---
|
| Argument 2: From a browser, there is no way to attach headers
| (like Authorization), and unlike SSE, third-party libraries
| cannot reimplement WebSocket from scratch in the browser.
|
| Response 2: The assertion is true. You cannot attach arbitrary
| headers to the initial HTTP GET request that initiates a
| WebSocket connection, not because of the WebSocket protocol's
| design, but because the design of the browser API doesn't expose
| the capability. However, such a limitation is totally irrelevant,
| as there are plenty of other ways that you could decide to convey
| that information from client to server:
|
| - You can pass arbitrary values via standard HTTP GET query
| parameters to be interpreted during the WebSocket handshake.
| Since we're initiating a WebSocket connection and not actually
| performing a GET operation on an HTTP resource, this does not
| create issues with caching infrastructure, and does not violate
| standard HTTP GET semantics. The HTTP GET that initiates a
| WebSocket connection is HTTP GET in name only, as the response in
| a successful WebSocket handshake is to switch protocols and no
| longer speak HTTP for the remainder of the connection's lifetime.
|
| - Cookies are automatically sent just as with any other HTTP
| request. This is the standard web primitive for correllating
| session state across connections. I'll grant, however, that it
| may be a less relevant mechanism if we're talking about cross-
| origin connections.
|
| - Your subprotocol definition (what messages are sent and
| received over the WebSocket connection) could simply require that
| the client sends any such headers, e.g. Authorization, as part of
| the first message it sends to the server once the underlying
| WebSocket connection is established. If this is sent pipelined
| along with the first normal message over the connection, it
| wouldn't even introduce an additional round-trip and therefore
| would have no impact on connection setup time or latency.
|
| These are not strange, onerous workarounds.
|
| ---
|
| Argument 3: Only GET requests can be transparently upgraded to
| WebSocket (other HTTP methods are not supported for upgrading),
| meaning that some kind of two-step upgrade process would be
| required on a POST endpoint, introducing complexity and latency.
|
| Response 3: Unless I'm missing something, this argument seems
| totally bewildering, nonsensical, and irrelevant. It suggests a
| lack of familiarity with what the WebSocket protocol is for. The
| semantics of a WebSocket connection are orthoganal to the
| semantics of HTTP GET or HTTP POST. There is no logical concept
| of upgrading a POST request to a WebSocket connection, nor is
| there a need for such a concept. MCP is a new protocol that can
| function however it needs to. There is no benefit to trying to
| constrain your conceptualization of its theoretical use of
| WebSockets to fit within the semantics of any other HTTP verbs.
| In fact, the only relationship between WebSockets and HTTP is
| that WebSockets utilizes standard HTTP only to bootstrap a
| connection, after which point it stops speaking HTTP over the
| wire and starts speaking a totally distinct binary protocol
| instead. It should be conceptualized as more analogous to a TCP
| connection than an HTTP connection. If you are thinking of
| WebSockets in terms of REST semantics, you have not properly
| understood how WebSockets differs, nor how to utilize it
| architecturally.
|
| Since the logical semantics of communication over a WebSocket
| connection in an MCP server are functionally identical to how the
| MCP protocol would function over STDIN/STDOUT, the assertion that
| you would need some kind of two-step upgrade process on a POST
| endpoint is just false, because there would not exist any POST
| endpoint for you to have interacted with in the first place, and
| if one did exist, it would serve some other purpose unrelated to
| the actual WebSocket connection.
|
| ---
|
| In my view, the right way to conceptualize WebSocket in MCP is as
| a drop-in, mostly transparent alternative to STDIO. Once the
| WebSocket connection is established, the MCP client/server should
| be able to speak literally EXACTLY the same protocol with each
| other as they do over STDIO.
| _raz wrote:
| Thanks, very nice! A very explanatory write-up
| fendy3002 wrote:
| Opinion aside (still reading),
|
| > Simply put, it is a JSON-RPC protocol with predefined
| methods/endpoints designed to be used in conjunction with an LLM.
|
| Is a spot on / simplest explanation of MCP, wonder why nobody use
| that or insist that it's usb-c for AI on their tutorials! Seeing
| this early can makes me understand MCP in 5 minutes
| mattw1810 wrote:
| MCP should just have been stateless HTTP to begin with. There is
| no good reason for almost any of the servers I have seen to be
| stateful at the request/session level --- either the server
| carries the state globally or it works fine with a session
| identifier of some sort.
| taocoyote wrote:
| I don't understand the logistics of MCP interactions. Can
| anyone explain why they aren't stateless. Why does a connection
| need to be held open?
| mattw1810 wrote:
| I think some of the advanced features around sampling from
| the calling LLM could theoretically benefit from a
| bidirectional stream.
|
| In practice, nobody uses those parts of the protocol (it was
| overdesigned and hardly any clients support it). The key
| thing MCP brings right now is a standardized way to discover
| & invoke tools. This would've worked equally well as a plain
| HTTP-based protocol (certainly for a v1) and it'd have made
| it 10x easier to implement.
| lo0dot0 wrote:
| I don't claim to have a lot of experience on this but my
| intuition tells me that a connection that ends after the
| request needs to be reopened for the next request. What is more
| efficient, keeping the session open or closing it, depends on
| the usage pattern, how much memory does the session consume,
| etc. etc.
| mattw1810 wrote:
| This is no different from a web app though, there's no
| obvious need to reinvent the wheel. We know how to do this
| very very well: the underlying TCP connection remains active,
| we multiplex requests, and cookies bridge the gap for multi-
| request context. Every language has great client & server
| support for that.
|
| Instead we ended up with a protocol that fights with load
| balancers and can in most cases not just be chucked into say
| an existing Express/FastAPI app.
|
| That makes everything harder (& cynically, it creates room
| for providers like Cloudflare to create black box tooling &
| advertise it as _the_ way to deploy a remote MCP server)
| DGAP wrote:
| I assume the docs, code, and design were done mostly by AI.
| doug_durham wrote:
| Meanwhile I'm happily writing MCP servers that meet my personal
| needs and installing complex packages over pip. The author seems
| to have a very narrow concept of what makes acceptable software.
| vlovich123 wrote:
| I too love to close out bugs with "works for me on my machine"
| quasarj wrote:
| > Be honest... when was the last time you ran pip install and
| didn't end up in dependency hell?
|
| Hasn't been in issue in at least 5 years. Maybe 10. Doubly so now
| that we're all using uv. You _are_ using, uv, right?
| lolinder wrote:
| > 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
| specifications and RFCs the process of writing the spec is _half
| the point_. You 're not just trying to get a reasonable output
| document at the end (which they didn't get anyway--just try
| reading it!), you're trying to figure out all the ways your
| current thinking is flawed, inadequate, and incomplete. You're
| reading it critically and identifying edge cases and massaging
| the spec until it answers every question that the humans
| designing the spec and the community surrounding it have.
|
| Which means in the end the biggest tell that the MCP spec is the
| product of LLMs isn't that it's somewhat incoherent or that it's
| composed entirely of bullet lists or that it has that uniquely
| bland style: it's that it shows every sign of having had very
| little human thought put into it relative to what we'd expect
| from a major specification.
|
| [0] https://modelcontextprotocol.io/specification/2025-03-26
| huqedato wrote:
| MCP is emerging technology. The mess is unavoidable for at least
| one year or so.
___________________________________________________________________
(page generated 2025-05-10 23:00 UTC)