We’re talking about agents here. (These are, after all, what MCP servers are meant to serve to.) Thus we’re talking about the need for services to be efficiently agent (computer) accessible, not efficiently end-user accessible.
Does tool calling in general bloat context, or is there something particular about MCP?
One thing I have read recently is that when you make a tool call it forces the model to go back to the agent. The effect of this is that the agent then has to make another request with all of the prompt (include past messages), these will be "cached" tokens, but they're still expensive. So if you can amortize the tool calls by having the model either do many at once or chaining them with something like bash you'll be better off.
I suspect this might be why cursor likes writing bash scripts so much, simple shell commands are going to be very token heavy because of the frequency of interrupts.
MCPs are like a wall full of tools in an already crowded workshop, you can easily access everything but they're also in the way if you need the space for something else.
Skills are like boxes on shelves with a note of "open this if you want to create or edit PDFs", they take way less space and you only open them when you need the contents.
As for tools, harnesses in general don't usually have many of those, maybe 6-10 for reading/writing/searching/web in total.
This is because there's a government price cap on home electricity, but not on commercial electricity - and rapid chargers are all commercial (and of course for-profit).
It is if you use a rapid charger. If you're fortunate enough to be able to do what you need with a car within 50 miles or so of your house and leave it overnight to charge, it's cheaper.
Very few people would use 100% rapid charging. Even on a long journey, they can arrive home with, say, 5-10% remaining, and recharge at home. (The car calculates this automatically.)
That's... weird? Maybe it's blocked in your country? The link opens just fine for me.
Those were tested numbers, not advertised though. I don't see how you'd get a drop from 200 to 120 miles, that's a 40% drop. Maybe in a gasoline powered car, but EVs can regeneratively break, so I don't think it'd make that much of a difference.
Reading some more, there are a handful of different ratings. the old European one: NEDC, the new European one: WLTP, the US EPA, and China's CLTC.
Generally the ratings from lowest to highest go EPA, WLTP, NEDC, then CLTC. The EPA rating is just a tad high I've read when you look at fast highway driving (e.g., 75 MPH), but should be within ballpark range.
I think you're under estimating the range of modern EVs.
I've driven some brand new 3-digit-miles Kia Niro EVs, which start off indicating 200 miles range but have dropped to 150 by the time I get across town, and after about 100 miles total driving they're screaming at me to find a charging point.
The real-world performance does not match the advertised performance.
Ehh, the Hindenburg had a flammable skin. Barrage balloons from the World Wars were most often filled with hydrogen and yet were extremely difficult to ignite or take down even with purpose build incindiary ammo for that purpose shows hydrogen balloons can be safe. Often they would be riddled with dozens of holes but still take many hours for them to lose enough hydrogen to float back down to the ground.
The only real downsides are slow travel speed and vulnerability to extreme storms since there arent many places to put it with a large enough hanger even with days of warning beforehand.
That's because regular bullets are actually pretty cold, especially by the time they reach the height of anti-air balloons.
But hydrogen itself is SCARY. It has an extremely wide range of ignitable concentrations, and it has very low ignition energy. It also tends to leak through ~everything.
But hydrogen is also so easy to produce on demand that you can design your balloon to be at small positive pressure all the time and always leaks outwards into the open air. If oxygen is allowed to leaked in undetected, yeah that's a death trap. The same if hydrogen leaked into semi contained oxygen enclosures. But leaking through the skin of the balloon to open sky even with decent size holes and a bit of positive pressure doesn't ignite particularly well, despite hydrogen's wide range of ignition conditions.
It is not such a fool proof technology that everybody should have one, but to me building and operating a hydrogen balloon isn't dissimilar to running a steam locomotive. It can be dangerous if done badly or incorrectly, but it can also be done safely with pretty well known and understood technologies and methods and practices. And considering the massive efficiency of lighter-than-air transport I find it hard to dismiss its potential even so long after their heyday and previous problems.
> And considering the massive efficiency of lighter-than-air transport
What efficiency? You still need to orient it and propel it in the desired direction, unless you don't mind to simply float around on the wind (in which case, yes, we have weather balloons precisely for that and nothing much else).
Slow moving free floating objects are super easy to move around. You can push a 100 ton piece of equipment with your hands if it is floating. That is why cargo boats still beat out shipping efficiency of rail. There is almost no practical size or weight limits, your only real potential loss, and potential gain, is the movement of your floating fluid be it wind or water, which in the case of air is fairly predictable these days, on top of moving in different directions at different altitudes.
Pointing to the Hindenburg as an example of why hydrogen is a bad idea is the same as pointing to Chernobyl as an example of why nuclear is a bad idea.
What do the calls being sequential have to do with tokens? Do you just mean that the LLM has to think everytime they get a response (as opposed to being able to compose them)?
LLMs can use CLI interfaces to compose multiple tool calls, filter the outputs etc. instead of polluting their own context with a full response they know they won't care about. Command line access ends up being cleaner than the usual MCP-and-tool-calls workflow. It's not just Anthropic, the Moltbot folks found this to be the case too.
That makes sense! The only flaw here imo is that sometimes that thinking is useful. Sub-agents for tool calls imo make a nice sort of middle ground where they can both be flexible and save context. Maybe we need some tool call composing feature, a la io_uring :)
No, I don't think you're thinking about this right. It's more like hacker news would expose an MCP when you visit it that would present an alternative and parallel interface to the page, not "click button" tools.
You're both right. The page can expose MCP tools like via a form element which is as simple as adding an attribute to an existing form and completely aligns with existing semantic HTML - eg submitting an HN "comment". Additionally, the page can define additional tools in javascript that aren't in forms - eg YouTube could provide a transcript MCP defined in JS which fetches the video's transcript
I think that rest and html could probably be already used for this purpose BUT html is often littered with elements used for visual structure rather than semantics.
In an ideal world html documents should be very simple and everything visual should be done via css, with JavaScript being completely optional.
In such a world agents wouldn’t really need a dedicated protocol (and websites would be much faster to load and render, besides being much lighter on cpu and battery)
> html could probably be already used for this purpose
You’re right, and it already is, and tools like playwright MCP can easily parse a webpage to use it and get things done with existing markup today.
> BUT html is often littered with elements used for visual structure rather than semantics.
This actually doesn’t make much of a difference to a tool like playwright because it uses a snapshot of the accessibility tree, which only looks at semantic markup, ignoring any presentation
> In such a world agents wouldn’t really need a dedicated protocol
They still do though, because they can work more better when given specific tools. WebMCP could provide tools not available on the page. Like an agent hits the dominoes.com landing page. The page could provide an order_pizza tool that the agent could interact with, saving a bunch of navigation, clicks and scrolling and whatnot. It calls the order_pizza tool with “Two large pepperoni pizzas for John at <address>”, and the whole process is done.
I've been having much the same thoughts. What will work look like, say, 10 years from now? I'm beginning to think that we might have all the knowledge worker type jobs largely filled, or filled with significantly less workers, (hopefully) more free time for everyone, and the remaining people working in more physical positions.
In many ways, I think this is probably better for society than the opposite, since in general there are fewer knowledge workers than not.
It will only in the same way computers and machines that automated past work such as farming and textiles has created lots of free time for today's workers.
Wow, I wouldn't have thought that it would be possible to do this (at least, not ergonomically, although now that you mention it I guess I don't see why not). That would be amazing to see.
reply