181–190 of 348 posts
As I understand, the agent sdk/ADK can simply start a child process and use STDIO to execute MCP commands. Why not always use that approach? if some REST api needs to be queried, the child process can abstract that interaction and expose it by the same consistent MCP interface. That way, devs are free to use REST,SOAP,*RPC,etc.. or whatever they want.
> 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’m also using Rails to host MCP servers in the cloud.
I share the criticism of HTTP+SSE and the recent “Streamable HTTP” feature—WebSockets would have been a more appropriate choice for interactive, bidirectional communication. Rails’ native support for SSE via ActionController::Live is limited (blocking) and has led to significant scalability challenges, prompting me to migrate these endpoints to the Falcon web server, which is better suited to concurrent streaming workloads.
When I reviewed the pull request for “Streamable HTTP” (which allows streaming a single controller response via server-sent events), I noticed it was largely driven by engineers at Shopify. I’m curious why they opted for this approach instead of WebSockets, especially given that Rails already includes ActionCable for WebSocket support. My assumption is that their choice was informed by specific infrastructure or deployment constraints, possibly related to simplicity or compatibility with existing HTTP/2 tooling.
It’s worth noting that the transport layer in the Model Context Protocol is intentionally abstracted. Future implementations could leverage WebSockets or even WebRTC, depending on the needs of the host environment or client capabilities.
[1] https://ninja.ai
> 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…
Certainly a shame if true, there are some really sharp folks at Anthropic and this is an important building block in the emerging ecosystem.
> 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'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't into face-sitting and now all my colleagues are saying I should sit on his face to keep the peace."
That is one thing but using the same LLM to drive your tech specs, knowing it can say a whole lot of shit the 'author' isn't aware of, because they're illiterate and that is fucking normal... is worrying.
> 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…
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 they can get to the point that they can fully replace programmers in about two years, otherwise following this siren song will, well, demonstrate why I chose "siren song" as my metaphor. If AI code produces big piles of code that are simply incomprehensible to humans, but then the AIs can't handle it either, they'll crash out their own market by the rather disgusting mechanism of killing all their customers, precisely because the customers consumed their service.
Earlier quoted context omitted.
old dev language is deterministic, llm in the loop now so the language is stochastic.
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?
> 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…
"DeepSeek API does NOT constrain user's rate limit. We will try out best to serve every request. However, please note that when our servers are under high traffic pressure, your requests may take some time to receive a response from the server. During this period, your HTTP request will remain connected, and you may continuously receive contents in the following formats..."
The documentation is still mostly easy to read, so it doesn't *really" matter, but I always thought this was bizarre. I mean, I get the language barrier reading manuals from Chinese products off of Amazon or whatever, but this is a company that does nothing but work with language all day long, and even at one point had the world's leading English-speaking language model. Shouldn't they be able to produce professional-looking documentation without spelling and grammatical errors?
> 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…
Certainly a shame if true, there are some really sharp folks at Anthropic and this is an important building block in the emerging ecosystem.
Glad to see the sentiment isn't as rare as I thought.