All the code I work on now has an MCP interface so that the LLM can debug more easily. I'd argue it is as important as the UI these days. The amount of time it has saved me is unreal. It might be worth investing a very small amount of your time in it to see if it is a good fit. Even a poor protocol can provide useful functionality.

Sniff tests are useful, but they're not wisdom. Most of these stacks are churn wrapped in a repo, so bailing early is usually the right call, yet every so often some ugly little tool sticks because it cuts through one miserable integration problem better than the cleaner options and people keep it around long after the pitch deck evaporates.

The failure mode is turning taste into a religion. If you never touch anything that looks crude on day one, you also miss the occasional weird thing that later becomes boring infra.

LangChain is not over-engineered; it's not engineered at all. Pure Chaos.

What part of MCP do you think is over-engineered?

This is quite literally the opposite opinion I and many others had when first exploring MCP. It's so _obviously_ simple, which is why it gained traction in the first place.

I still don't really understand what LangChain even is.

So let's say you have a rag llm chat api connected to an enterprises document corpus.

Do you not expose an mcp endpoint? Literally every vscode or opencode node gets it for free (a small json snippet in their mcp.json config) If you do auth right

What are you investing time in instead?

> if something looks like crud, it probably is crud

Yes, technically, but you've probably meant cruft here.