| ▲ | codemog 15 hours ago |
| As soon as MCP came out I thought it was over engineered crud and didn’t invest any time in it. I have yet to regret this decision. Same thing with LangChain. This is one key difference between experienced and inexperienced devs; if something looks like crud, it probably is crud. Don’t follow or do something because it’s popular at the time. |
|
| ▲ | fartfeatures 15 hours ago | parent | next [-] |
| 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. |
| |
| ▲ | kybernetikos 14 hours ago | parent | next [-] | | I've just been discovering this pattern too. It's made a huge difference. Trying to get Claude to remote control an app for testing via the various other means was miserable and unreliable. I got it to build an MCP server into the app that supported sending commands to allow Claude to interact with it as if it was a user, including keypresses and grabbing screenshots, and the difference was immediate and really beneficial. Visual issues were previously one of the things it would tend to struggle with. | | |
| ▲ | behehebd 13 hours ago | parent [-] | | How does it compare to my goto: a test suite that uses Playwright? > Claude imolement plan.md until all unit and browser tests pass | | |
| ▲ | kybernetikos 12 hours ago | parent [-] | | I assume that this is dependent on app, and it's quite possible that your approach is best in some cases. In my case I started with something somewhat like Playwright, and claude had a habit of interacting with the app more directly than a user would be able to and so not spotting problems because of it. Forcing it to interact by pressing keys rather than delving into the dom or executing random javascript helped. In particular I wanted to be able to chat with it as it tried things interactively. This is more to help with manual tests or exploratory testing rather than classic automated testing. My current app is a desktop app, so playwright isn't as applicable. |
|
| |
| ▲ | moralestapia 15 hours ago | parent | prev | next [-] | | Our workflows must be massively different. I code in 8 languages, regularly, for several open source and industry projects. I use AI a lot nowadays, but have never ever interacted with an MCP server. I have no idea what I'm missing. I am very interested in learning more about what do you use it for. | | |
| ▲ | Kaliboy 14 hours ago | parent | next [-] | | I've managed to ignore MCP servers for a long time as well, but recently I found myself creating one to help the LLM agents with my local language (Papiamentu) in the dialect I want. I made a prolog program that knows the valid words and spelling along with sentence conposition rules. Via the MCP server a translated text can be verified. If its not faultless the agent enters a feedback loop until it is. The nice thing is that it's implemented once and I can use it in opencode and claude without having to explain how to run the prolog program, etc. | |
| ▲ | CharlieDigital 15 hours ago | parent | prev | next [-] | | > I have no idea what I'm missing.
The questions I'd ask: - Do you work in a team context of 10+ engineers?
- Do you all use different agent harnesses?
- Do you need to support the same behavior in ephemeral runtimes (GH Agents in Actions)?
- Do you need to share common "canonical" docs across multiple repos?
- Is it your objective to ensure a higher baseline of quality and output across the eng org?
- Would your workload benefit from telemetry and visibility into tool activation?
If none of those apply, then it's not for you. Server hosted MCP over streamable HTTP benefits orgs and teams and has virtually no benefit for individuals. | | |
| ▲ | monsieurbanana 13 hours ago | parent | next [-] | | What I want to know is what's the difference between a remote mcp and an api with an openapi.json endpoint for self-discovery? It's just as centralized | |
| ▲ | fartfeatures 15 hours ago | parent | prev [-] | | MCP is useful for the above. I work on my own more often than not and the utility of MCP goes far beyond the above. (see my other comment above). |
| |
| ▲ | fartfeatures 15 hours ago | parent | prev | next [-] | | I can't go into specifics about exactly what I'm doing but I can speak generically: I have been working on a system using a Fjall datastore in Rust. I haven't found any tools that directly integrate with Fjall so even getting insight into what data is there, being able to remove it etc is hard so I have used https://github.com/modelcontextprotocol/rust-sdk to create a thin CRUD MCP. The AI can use this to create fixtures, check if things are working how they should or debug things e.g. if a query is returning incorrect results and I tell the AI it can quickly check to see if it is a datastore issue or a query layer issue. Another example is I have a simulator that lets me create test entities and exercise my system. The AI with an MCP server is very good at exercising the platform this way. It also lets me interact with it using plain english even when the API surface isn't directly designed for human use: "Create a scenario that lets us exercise the bug we think we have just fixed and prove it is fixed, create other scenarios you think might trigger other bugs or prove our fix is only partial" One more example is I have an Overmind style task runner that reads a file, starts up every service in a microservice architecture, can restart them, can see their log output, can check if they can communicate with the other services etc. Not dissimilar to how the AI can use Docker but without Docker to get max performance both during compilation and usage. Last example is using off the shelf MCP for VCS servers like Github or Gitlab. It can look at issues, update descriptions, comment, code review. This is very useful for your own projects but even more useful for other peoples: "Use the MCP tool to see if anyone else is encountering similar bugs to what we just encountered" | |
| ▲ | 8note 14 hours ago | parent | prev | next [-] | | Its very similar to the switch from a text editor + command line, to having an IDE with a debugger. the AI gets to do two things: - expose hidden state
- do interactions with the app, and see before/after/errors it gives more time where the LLM can verify its own work without you needing to step in. Its also a bit more integration test-y than unit. if you were to add one mcp, make it Playwright or some similar browser automation mcp. Very little has value add over just being able to control a browser | | |
| ▲ | CPLX 14 hours ago | parent [-] | | I’ve been using Chrome DevTools MCP a lot for this purpose and have been very happy with it. |
| |
| ▲ | winrid 15 hours ago | parent | prev [-] | | Many products provide MCP servers to connect LLMs. For example I can have claude examine things through my ahrefs account without me using the UI etc | | |
| ▲ | 8n4vidtmkvmk 14 hours ago | parent [-] | | That's also one of the things that worries me the most. What kind of data is being sent to these random endpoints? What if they to rogue or change their behavior? A static set of tools is safer and more reliable. | | |
| ▲ | 8note 14 hours ago | parent [-] | | mcp is generally a static set of tools, where auth is handled by deterministic code and not exposed to the agent. the agent sees tools as allowed or not by the harness/your mcp config. For the most part, the same company that you're connecting to is providing the mcp, so its not having your data go to random places, but you can also just write your own. its fairly thin wrappers of a bit of code to call the remote service, and a bit of documentation of when/what/why to do so |
|
|
| |
| ▲ | mlnj 15 hours ago | parent | prev [-] | | You are right. Although I have been a skeptic of MCPs, it has been an immense help with agents. I do not have an alternative at the moment. |
|
|
| ▲ | hrmtst93837 3 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | ph4rsikal 15 hours ago | parent | prev | next [-] |
| LangChain is not over-engineered; it's not engineered at all. Pure Chaos. |
| |
| ▲ | embedding-shape 15 hours ago | parent [-] | | Much like how "literally" doesn't literally mean "literally" anymore, "over-engineered" in most cases doesn't mean "too much engineering happened" but "wrong design/abstractions", which of course translates to "designs/abstractions I don't like". | | |
|
|
| ▲ | jamesrom 14 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | tptacek 14 hours ago | parent | prev | next [-] |
| I still don't really understand what LangChain even is. |
|
| ▲ | gtirloni 13 hours ago | parent | prev | next [-] |
| What are you investing time in instead? |
|
| ▲ | whattheheckheck 15 hours ago | parent | prev | next [-] |
| 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 |
| |
| ▲ | CharlieDigital 15 hours ago | parent [-] | | Not only editors, but also different runtime contexts like GitHub Agents running in Actions. We can plug in MCP almost anywhere with just a small snippet of JSON and because we're serving it from a server, we get very clear telemetry regardless of tooling and envrionment. | | |
| ▲ | chatmasta 15 hours ago | parent [-] | | What are you using for hosting and deploying the MCP servers? I’d like something low friction for enterprise teams to be able to push their MCP definitions as easily as pushing a Git repo (or ideally, as part of a Git repo, kinda like GitHub pages). It’s obviously not sustainable for every team to host their own MCP servers in their own way. So what’s the best centralized gateway available today, with telemetry and auth and all the goodness espoused in this blog post? | | |
| ▲ | CharlieDigital 15 hours ago | parent | next [-] | | We built our own (may open source eventually). MCP is effectively "just another HTTP REST API"; OAuth and everything. The key parts of the protocol is the communication shape and sequence with the client, which most SDKs abstract for you. The SDKs for MCPs make it very straightforward to do so now and I would recommend experimenting with them. It is as easy to deploy as any REST API. | |
| ▲ | whattheheckheck 14 hours ago | parent | prev [-] | | ROSA https://docs.aws.amazon.com/whitepapers/latest/overview-depl... it should be part of your app and coordinated in a way that everyone in the enterprise can find all the available mcps. Like backstage or something |
|
|
|
|
| ▲ | kubanczyk 15 hours ago | parent | prev [-] |
| > if something looks like crud, it probably is crud Yes, technically, but you've probably meant cruft here. |