Norcim133

FWIW HN truncated the ellipses at the end of my title.

Anyone know how this will compare to Mem0 or Zep?

Seems like it isn't all the protocol? A lot of it is the and the current tools. If you have a hardcore dev who knows auth they can implement to spec and be safe/simple-ish.

MCP Client builders have been asking SDK builders to enforce Structured Output schemas on MCP Servers. The Python SDK has agreed.

Here I assert this is another example of an old paradigm misunderstanding a new one.

Specifically, it is traditional builders and "agentic workflow" builders misunderstanding the various roles in an MCP flow.

Namely, an MCP Client's role is to thinly connect an LLM, a user, and an API... and then get out of the way.

The LLM doesn't gain from wrapping tool output in additional metadata and boilerplate. That just makes the output harder to parse while also making it less similar to the patterns the LLM trained on.

The Client doesn't need the structure to help it orchestrate/route tools... it is the LLM's job to orchestrate.

If you want the Client to orchestrate, that's totally fine. Build with Langchain, not MCP.

The reason agentic workflows need strict adherence to structured input/output is because they are so rigid. Each interaction between one step and another is highly coupled and basically "one-shot".

To get "flexibility" across tasks, you have to layer many of these "one-shot" and coupled flows on top of each other. This is what makes agentic workflows like RPA.

Implicitly, we often treat LLMs as one-shot too. If we ask it to do a coding task, it might make up a method name and we say it hallucinated. But that's raising the bar far above what a human would face. A human would get to goole the method or see in the IDE the warning that the method doesn't exist. Our experience with flaky LLM coding is actually caused by this "one shot" assumption.

MCP flows are the opposite of one-shot. The LLM can use a tool, make a mistake with the data structure, read the error, fix it and move on. There is much lower gain to optimizing to avoid that specific mistake because the LLM still got to the right answer and, with infinite Servers/Tools, the LLM may never do that exact same flow again.

MCP affords a much more self-correcting and flexible system. To the extent there is an art to improving the LLM-Tool interaction, it lies in having the Server builder be thoughtful about how to name the tools and parameters and docstrings.

Enforcing schemas from the client actually makes the least important player (the Client) slightly better off by hamstringing the stars of the show (the LLM and the tool). The real answer, build your clients differently.

You nailed it. I've been serving banks who have this exact problem. They have to be so careful with their data they can only buy over-engineered solutions that barely meet their actual need.

Nice little site. What did you build it with?

I once leaked an API key and instantly got a mail from GitGuardian informing me of the leak. It was a) super helpful as I wouldn't have known otherwise b) it seemed like a clever way to spread their name/biz

(in case that's helpful to your model)

It is a fair point.

But I found this article landed different than most self-help. It spoke in terms of mindsets one can adopt to do the things you mentioned.

And it made those mindsets compact/memorable so I'm more likely to use them.

I'm getting an endless "Preparing Space" loop for the "See it Action" section... does that still TBD or should it work?

Def true when I'm using Gemini with 400k tokens in context... I toggle to Youtube while I wait and have usually started working for a new company by the time I remember to go back to what I was prompting.

Cool approach.

I suspect one additional unstated rule: be opinionated on tech stack.

I've noticed LLMs struggle with the seams, whenever you're using a rare stack combo.

No problem - React front + Node.js back

Runaway death spiral - Streamlit Front + iFrame React Component + Python back + running in WASM via Pyodide

Better than Outlook?

AI is an accelerator if you know one language and you're trying to go full-stack, say. The learning you get is incredible. All other use-cases are dubious. If you're a senior dev, you're still faster (once you include the debugging). If you're a junior dev it's too buggy and gets out of control as complexity increases.

Correct-ish. LlamaCloud and GroundX do everything up to retrieval. Here is an interactive graphic of major players along RAG flow: https://claude.ai/public/artifacts/b872435b-1d9c-461e-a29c-b...

It was definitely that thing with any actors/actresses. To be "good looking enough" for the screen means they are a different species IRL.

I spent the last 2 months trying out RAG/parsing plays. My use-case required high accuracy on complex tables and figures.

Ranking: 1. LlamaCloud/LlamaParse 2. GroundX 3. Unstructured.io 4. Google RAG Engine 5. Docling ... capability gap... 6. Azure - Document Intelligence 7. AWS - Textract 8. LlamaIndex (DIY)

This title speaks truth