MCP was a bucket of Not Invented Here nonsense, that ignored years of protocol design. It was incredibly jank and hard to run at any scale, for years and years.
They finally looked at how other protocols do things, and made something that behaves in recent versions. But it's hard as heck to take this company at all seriously. The don't really care about ecosystems (AGENTS.md), they don't seem to know think or care much about protocols until they have to (MCP's incredibly long redemption ark). The vibes are all off.
Maybe they avoid laying their own pitfalls this time. Maybe it's better. It'd be nice to start seeing some kind of cause to trust this company as vaguely capable computer-using people. But so far that hasn't been the case.
To actually add something to the discussion though: I guess getting LLMs to control robots is cool, but would potentially have more severe consequences than pure software since it interacts more with the physical world
In the context of lab hardware there’s a ton of proprietary software and barriers to automating things. I think this is less about how to communicate, and more guaranteeing that “yes, this piece of hardware can interface with an agent” and is meant to do so. Kind of like using MCP vs letting your agent make raw HTTP requests
More like MCP for robotics. IMO they are better off getting the robots to use existing human UIs than trying to get hardware manufacturers to play ball.
It seems more like a basic instruction set, that will then be translated to something actionable for each different device. Seems like most of the work then will be in developing the drivers for whatever devices you want the LLM to access.
As far as I can tell is these standards (MCP/MHS/etc) are just semi obvious tool inferfaces that Anthropic uses as training scenarios.
It’s actually really cool, and not just for AI. That should make it easy to automate some processes with simple scripts.
Nitpick: it’s annoying that they add Model to those acronyms, for what seems like a fairly universal software interface
MCP was a bucket of Not Invented Here nonsense, that ignored years of protocol design. It was incredibly jank and hard to run at any scale, for years and years.
They finally looked at how other protocols do things, and made something that behaves in recent versions. But it's hard as heck to take this company at all seriously. The don't really care about ecosystems (AGENTS.md), they don't seem to know think or care much about protocols until they have to (MCP's incredibly long redemption ark). The vibes are all off.
Maybe they avoid laying their own pitfalls this time. Maybe it's better. It'd be nice to start seeing some kind of cause to trust this company as vaguely capable computer-using people. But so far that hasn't been the case.
https://xkcd.com/927/
To actually add something to the discussion though: I guess getting LLMs to control robots is cool, but would potentially have more severe consequences than pure software since it interacts more with the physical world
Sounds like PyLabRobot:
https://docs.pylabrobot.org/stable/
I don't want to be that guy but did they invent bluetooth for ai? Like what is MHS actually? I read it twice and still don't get it
In the context of lab hardware there’s a ton of proprietary software and barriers to automating things. I think this is less about how to communicate, and more guaranteeing that “yes, this piece of hardware can interface with an agent” and is meant to do so. Kind of like using MCP vs letting your agent make raw HTTP requests
More like MCP for robotics. IMO they are better off getting the robots to use existing human UIs than trying to get hardware manufacturers to play ball.
What is the difference of MHS to MCP when it comes to features?
The whole text reads like everything is just a gRPC call that could've also been implemented with an MCP based wrapper.
Oh I see, yeah I guess this assumes manufacturers will just adopt this standard universally. Clears things a bit!
That 2 trillion dollar valuation ain't gonna make itself.
It seems more like a basic instruction set, that will then be translated to something actionable for each different device. Seems like most of the work then will be in developing the drivers for whatever devices you want the LLM to access.
Yes, it turns the hardware driver problem into a translation problem (translate the hardware manual/datasheet into this protocol.)
Guess what's really good/quick at translating things?