MCP isn't going anywhere. Some developers can't seem to see past their terminal or dev environment when it comes to MCP. Skills, etc do not replace MCP and MCP is far more than just documentation searching.
MCP is a great way for an LLM to connect to an external system in a standardized way and immediately understand what tools it has available, when and how to use them, what their inputs and outputs are,etc.
For example, we built a custom MCP server for our CRM. Now our voice and chat agents that run on elevenlabs infrastructure can connect to our system with one endpoint, understand what actions it can take, and what information it needs to collect from the user to perform those actions.
I guess this could maybe be done with webhooks or an API spec with a well crafted prompt? Or if eleven labs provided an executable environment with tool calling? But at some point you're just reinventing a lot of the functionality you get for free from MCP, and all major LLMs seem to know how to use MCP already.
Yeah, I don't think I was particularly clear in that section.
I don't think MCP is going to go away, but I do think it's unlikely to ever achieve the level of excitement it had in early 2025 again.
If you're not building inside a code execution environment it's a very good option for plugging tools into LLMs, especially across different systems that support the same standard.
But code execution environments are so much more powerful and flexible!
I expect that once we come up with a robust, inexpensive way to run a little Bash environment - I'm still hoping WebAssembly gets us there - there will be much less reason to use MCP even outside of coding agent setups.
I disagree. MCP will remain the best way to do most things for the same reason REST APIs are the main way to access non local services: they provide a way to secure and audit access to systems in a way that a coding environment cannot. And you can authorize actions depending on the well defined inputs and outputs. You can’t do that using just a bash script unless said script actually does SSO and calls REST APIs but then you just have a worse MCP client without any interoperability.
I find it very hard to pick winners and losers in this environment where everything changes so quickly. Right now a lot of people are using bash as a glue environment for agents, even if they are not for developers.
My favorite setup so far is using the Claude code extension in VScode. All the power of CC, but it opens files and diffs in VScode. Easy to read and modify as needed.
1. A racing car has only ONE objective: to WIN motor races. If it does not do this it is nothing but a waste of time, money, and effort.
This may sound obvious but remember it does not matter how clever it is, or how inexpensive, or how easy to maintain, or even how safe, if it does not consistantly win it is NOTHING!
2. Having established this what do we have to do to make it win:
(i) Simply stated it must firstly be capable of lapping a racing circuit quicker than any other car, with the least possible skill from the driver, and doing it long enough to finish the race.
(ii) After this, and only after this, and with absolutely no compromising of objective (2)(i) one has to consider how expensive it is, how simple, how safe, & how easy to maintain, etc. NONE of these aspects must detract one iota from (2)(i). “Good enough” is just NOT good enough to win and keep winning.[1]
I think the worst accident was the 1955 Le Mans Accident that killed 85 spectators.[1]
It looks like the years (between 1952-1980) of 1956, 1963, 1965, 1972, 1976 and 1979 are noteworthy because those are the 6 of 28 years when a driver wasn't killed[2]...
Yep, but car racing today is orders of magnitude safer than it was decades ago, especially in F1. An insane amount of money, research and regulations has been poured into increasing safety by the FIA.
F1 tracks, cars, suits and helmets today are so safe that even on violent crashes at >45G[1] or flaming infernos[2] of gasoline and lithium, the driver can walk out of the wreck with a just a broken rib or a burned hand, whereas in the past that would have meant certain death or at least being crippled for life.
Early race cars were not paragons of safety. I don't think I'd go so far as to say that Chapman intentionally made his cars less safe to make them faster, but I also don't know that he'd have spent any weight budget to make them safer than the regulations required.
IE
"if it's possible to make a winning car win by having the wheels fall off of it as it crosses the finish lines" -- that's okay
VS
"If it's possible to make a winning car win by having the wheels fall off of it as it crosses the finish line, then it bursts into flame and kills the driver" -- that's probably no okay.
But there's a lot of grey area between the two, and that's where winning teams won (and occasionally lost drivers / spectators). Old time car racing was blood sport.
They were death traps, racing drivers were way more cautious back in those days because any slightly severe accident was likely to result in death or severe injuries. Reliability was garbage too so basically just crossing the finish line was a great result.
I think having recently been through WW2 where "reasonable things" included tasks like "hey let's disarm this unexploded bomb by chilling it in liquid oxygen." fundamentally altered people's risk calculus for a generation or two.
I mainly talking about driving styles, modern F1 drivers pull all kinds of maneuvers and drive so close to the limit that would be totally suicidal back in those days (especially for overtaking, you aren't going to fight as hard when you know that any crash might result in death or severe injury)
Of course a lot of that is because of the cars. 50s to 60s cars had basically no downforce and would be undriveable on modern tracks amongst other things.
I'm certainly not implying that modern drivers are less risk-averse these days, just that the risks were massively higher and drivers generally took that into account.
For a professional race car, I don't think safety is an overriding concern, given its intended use case.
I think the late Robert Dewar (of AdaCore fame) made a similar comment about fighter jets: Is it really a domain for safety-critical engineering if the only thing that prevents the plane from disintegrating mid-air is a continuously running computer program?
I am curious, did this small business actually provide the service you were searching for or not? If they do, then it sounds like it was ultimately useful.
MCP is a great way for an LLM to connect to an external system in a standardized way and immediately understand what tools it has available, when and how to use them, what their inputs and outputs are,etc.
For example, we built a custom MCP server for our CRM. Now our voice and chat agents that run on elevenlabs infrastructure can connect to our system with one endpoint, understand what actions it can take, and what information it needs to collect from the user to perform those actions.
I guess this could maybe be done with webhooks or an API spec with a well crafted prompt? Or if eleven labs provided an executable environment with tool calling? But at some point you're just reinventing a lot of the functionality you get for free from MCP, and all major LLMs seem to know how to use MCP already.