241–250 of 348 posts
Who cares which client side protocol turns a structured message into a function call? There will be as many of them as there are RPC protocols because that's effectively what it is.
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://m…
Earlier quoted context omitted.
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 y…
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.
Why would anyone want to write a non-scalable wrapper around a service that already is well documented using OpenAPI endpoints is beyond me.
Anyway, we ended up implementing it just because but I already know it is a mistake and a potential source of many hours wasted by our engineering team.
Earlier quoted context omitted.
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.
> 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…
Where do you store this state?
I tried asking some LLMs for from-scratch implementations of MCP hosts and clients, and they did a terrible job of it. This seemed odd to me.
It turns out that both of these problems likely have the same cause. The spec (if you can even call it that) really is horrendous. It doesn't really spell out the protocol properly at all!
This enables practically the same functionality, only with less fuzz. Long term memory can then instead be implemented via RAG, exposed as function calls, instead of keeping it in the context of the MCP.
An "agent" is a pre-prompted server which receives external requests, by any API (the AI interface is not exposed, since there's no need for it to be). The server then performs query by announcing which tools the LLM should use via function calling + conversation flow.
The only downside of this approach is that you can't have a MCP "marketplace" (but it's perfectly possible to expose standardized structs for different tools [2], which ultimately achieves the same thing).
[1]: https://platform.openai.com/docs/guides/function-calling?api... [2]: https://github.com/baalimago/clai/blob/main/internal/tools/b...
Earlier quoted context omitted.
> What benefit is SSE providing here? Let the client decide when a session starts/ends by generating IDs and let the server maintain that session internally. The response is generated asynchronously, instead of within the HTTP request/response cycle, and sent over SSE later. But emulating WS with HTTP requests+SSE seems very iffy, indeed.
Well with SSE the server and client are both holding a HTTP connection open for over a relatively long period of time. If the server is written with a language that supports async paradigms, then a http request that needs async IO will use about the same amount of resource anyways. And when the response if finished, that connection is closed and resources are freed. Whereas SSE will keep them for much longer.
By async I meant a process that may take longer than you are willing to do within the request/response cycle, not necessarily async IO.
Earlier quoted context omitted.
> "Our response times may be slower" would be more natural. How can the time be slower? Response times may be longer, but not slower
In colloquial English my construction is just fine, but sure, you'd be welcome to pick longer too. Some examples of my usage in the wild ("response times may be slower" is present verbatim on each page): https://github.com/aquasecurity/trivy/discussions/8133 https://www.ameristarstaffingny.com/the-negative-effects-of-... https://oci.wi.gov/Pages/Regulation/Bulletin20200320Regulato... https://playrix.helpshift.com/hc/…
Earlier quoted context omitted.
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?
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’…