←back to thread

MCP is eating the world

(www.stainless.com)
335 points emschwartz | 1 comments | 21 Jun 25 16:30 UTC | HN request time: 0.203s | source
Show context
0x500x79 ◴[24 Jun 25 15:52 UTC] No.44367530[source]▶
I believe that MCP is a bit over-marketed.

MCP allows you to bring tools to agents you don't control. It's awesome, but it isn't the right match for every problem. If you believe the hype of X/LinkedIn you would think that MCP everywhere is going to be the solution.

Bringing tools to your local Claude client is awesome, but there are still challenges with MCP that need to be solved and like all technology, it isn't applicable universally.

Not to mention it's a recipe for burning tokens!

replies(6): >>44367740 #>>44367752 #>>44367901 #>>44367968 #>>44368623 #>>44371990 #
theOGognf ◴[24 Jun 25 16:12 UTC] No.44367752[source]▶
Along with burning tokens, how MCP servers are ran and managed is resource wasteful. Running a whole Docker container just to have some model call a single API? Want to call a small CLI utility, people say to run another Docker container for that

Feels like a monolith would be better

replies(3): >>44368026 #>>44368074 #>>44368296 #
MyOutfitIsVague ◴[24 Jun 25 16:40 UTC] No.44368074[source]▶
A "whole Docker container" is not very heavyweight. Other than having their own filesystem view and separate shared libraries, container processes are nearly as light as non-container processes. It's not like running a VM.
replies(2): >>44368289 #>>44381725 #
jcelerier ◴[24 Jun 25 16:58 UTC] No.44368289[source]▶
> Other than having their own filesystem view and separate shared libraries, container processes are nearly as light as non-container processes. It's not like running a VM.

why does the smallest script take seconds to even start then?

replies(2): >>44368313 #>>44371146 #
1. antonvs ◴[24 Jun 25 21:15 UTC] No.44371146[source]▶
Below is a transcript of a "smallest script" which runs in 328 ms total on my machine. And that includes loading an ubuntu OS image, which could be optimized depending on what dependencies the script needs.

Of course, if you're invoking it on a remote cluster, there are many reasons it can talk longer, especially if the cluster has to scale to satisfy the request. But all those reasons are nothing to do with containers specifically - it's things like cluster capacity, node provisioning time, container pull time, network latency, etc. If you architect things properly, you can get the number below + network latency even for a remote cluster invocation.

    $ time docker run ubuntu echo hello world  
    hello world  

    real    0m0.328s  
    user    0m0.011s  
    sys     0m0.010s