←back to thread

Tools: Code Is All You Need

(lucumr.pocoo.org)
313 points Bogdanp | 2 comments | 03 Jul 25 10:51 UTC | HN request time: 0s | source
Show context
pramodbiligiri ◴[03 Jul 25 16:49 UTC] No.44456964[source]▶
Wouldn't the sweet spot for MCP be where the LLM is able to do most of the heavy lifting on its own (outputting some kind of structured or unstructured output), but needs a bit of external/dynamic data that it can't do without? The list of MCP servers/tools it can use should nail that external lookup in a (mostly) deterministic way.

This would work best if a human is the end consumer of this output, or will receive manual vetting eventually. I'm not sure I'd leave such a system running unsupervised in production ("the Automation at Scale" part mentioned by the OP).

replies(1): >>44457068 #
1. ramoz ◴[03 Jul 25 17:00 UTC] No.44457068[source]▶
You don't solve the problem of being able to rely on the agent to call the MCP.

Hooks into the agent's execution lifecycle seem more reliable for deterministic behavior and supervision.

replies(1): >>44457607 #
2. pramodbiligiri ◴[03 Jul 25 17:59 UTC] No.44457607[source]▶
I agree. In any large backend software running on a server, it's the LLM invocation which would be a call out to an external system, and with proper validation around the results. At which point, calling an "MCP Server" is also just your backend software invoking one more library/service based on inspecting some part of the response from the LLM.

This doesn't take away from the utility of MCP when it comes Claude Desktop and the likes!