18 ms·
I don’t want to undermine the author’s enthusiasm for the universality of the MCP. But part of me can’t help wondering: isn’t this the idea of APIs in general?
by jadar 1y ago
I don’t want to undermine the author’s enthusiasm for the universality of the MCP. But part of me can’t help wondering: isn’t this the idea of APIs in general? Replace MCP with REST and does that really change anything in the article? Or even an Operating System API? POSIX, anyone? Programs? Unix pipes? Yes, MCP is far simpler/universal than any of those things ended up being — but maybe the solution is to build simpler software on good fundamental abstractions rather than rebuilding the abstractions every time we want to do something new.
- bayesianbot 1y agoMy first thought as well. But maybe at least people wanting to plug their apps to their AI forces developers to actually implement the interface, unlike APIs that are mostly unheard of in general population and thus not offered?
- kvdveer 1y agoThe main difference between MCP and Rest is that MCP is self described from the very start. REST may have OpenAPI, but it is a later addon, and we haven't quite standardised on using it. The first step of exposing an MCP is describing it, for Rest is is an optional step that's often omitted.
- light_hue_1 1y agoBut you're describing it in a way that is useless to anything but an LLM. It would have been much better if the description language had been more formalized.
- 0x696C6961 1y agoThe description includes an input and output json schema.
- jcheng 1y agoOnly input, not output. https://modelcontextprotocol.io/specification/2025-03-26/server/tools#tool https://modelcontextprotocol.io/specification/2025-03-26/ser...
- 0x696C6961 1y agoYou're not looking at the latest version. They added output schemas.
- jcheng 1y agoThank you!
- Majromax 1y ago> It would have been much better if the description language had been more formalized. To speculate about this, perhaps the informality is the point. A full formal specification of something is somewhere between daunting and Sisyphean, and we're more likely to see supposedly formal documentation that nonetheless is incomplete or contains gaps to be filled with background knowledge or common sense. A mandatory but informal specification in plain language might be just the trick, particularly since vibe-APIing encourages rapid iteration and experimentation.
- Szpadel 1y agoisn't also SOAP self described?
- souldeux 1y agoAnd gRPC with reflection, yeah?
- hansonkd 1y agoand GQL with reflection?
- notpushkin 1y agoJSON-LD?
- gaunds 1y ago[flagged]
- kerng 1y agoWhen I read about MCP the first time and saw that it requires a "tools/list" API reminded me of COM/DCOM/ActiveX from Microsoft, it had things like QueryInterface and IDispatch. And I'm sure that wasn't the first time someone came up with dynamic runtime discovery of APIs a server offers. Interestingly, ActiveX was quite the security nightmare for very similar reasons actually, and we had to deal with infamous "DLL Hell". So, history repeats itself.
- xg15 1y agoIs it "self-described" in the sense I can get a list of endpoints or methods, with a human- (or LLM-) readable description for each - or does it supply actual schemata that I could also use with non-AI clients? (Even if only the former, it would of course be a huge step forward, as I could have the LLM generate schemata. Also, at least, everyone is standardizing on a base protocol now, and a way to pass command names, arguments, results, etc. That's already a huge step forward in contrast to arbitrary Rest+JSON or even HTTP APIs)
- spenczar5 1y agohonestly, yes - but MCP includes a really simple 'reflection' endpoint to list the capabilities of an API, with human readable docs on methods and types. That is something that gRPC and OpenAPI and friends have supported as an optional extension for ages, but it has largely been a toy. MCP makes it central and maybe that makes all the difference.
- spudlyo 1y agoAt a previous job most of our services supported gRPC reflection, and exploring and tinkering with these APIs using the grpc_cli tool was some of the most fun I had while working there. Building and using gRPC services in golang left a strong positive impression on me.
- lobsterthief 1y agoI had the same experience working with GQL :)
- Jonovono 1y agoMCP is not REST. In your comparison, its more that MCP is a protocol for discovering REST endpoints at runtime and letting users configure what REST endpoints should be used at runtime. Say i'm building a app and I want my users to be able to play spotify songs. Yea, i'll hit the spotify api. But now, say i've launched my app, and I want my users to be able to play a song from sonofm when they hit play. Alright, now I gotta open up the code and do some if statements hard code the sonofm api and ship a new version, show some update messages. MCP is literally just a way to make this extensible so instead of hardcoding this in, it can be configured at runtime
- nikolayasdf123 1y agoso... is this OpenAPI then?
- lobsterthief 1y agoBasically, yes. But with much more enthusiasm!
- doug_durham 1y agoOpenAPI doesn't have a baked in discoverability mechanism. It isn't compatible with LLMs out of the box. It is a lower level abstraction. I don't want to write a blob of code that talks to an Open API service every time I want to do something with an LLM.
- falcor84 1y ago>OpenAPI doesn't have a baked in discoverability mechanism. Well, Swagger was there from the start, and there's nothing stopping an LLM from connecting to an openapi.json/swagger.yaml endpoint, perhaps meditated by a small xslt-like filter that would make it more concise.
- smohare 1y ago[dead]
- 1y ago
- caust1c 1y agoIn my mind the only thing novel about MCP is requiring the schema is provided as part of the protocol. Like, sure it's convenient that the shape of the requests/response wrappers are all the same, that certainly helps with management using libraries that can wrap dynamic types in static types, but everyone was already doing that with APIs already we just didn't agree on what that envelope's shape should be. BUT, with the requirement that schema be provided with the protocol, and the carrot of AI models seamlessly consuming it, that was enough of an impetus.
- marcosdumay 1y ago> the only thing novel about MCP is requiring the schema is provided as part of the protocol You mean, like OpenAPI, gRPC, SOAP, and CORBA?
- sneak 1y agoYou can’t connect to a gRPC endpoint and ask to download the client protobuf, but yes.
- ahmedtd 1y agoIt's not enabled by default, but you can --- gRPC Reflection: * https://github.com/grpc/grpc-java/blob/master/documentation/server-reflection-tutorial.md https://github.com/grpc/grpc-java/blob/master/documentation/... * https://grpc.io/docs/guides/reflection/ https://grpc.io/docs/guides/reflection/ You can then use generic tools like grpc_cli or grpcurl to list available services and methods, and call them.
- doug_durham 1y agoWhere is the mandatory human readable prose description of the purpose of the tool in any of those specs. It isn't. Also the simplicity of JSON interface descriptions is key.
- deleted 1y ago[deleted]
- TZubiri 1y agoDamn, I just read this and it's comforting to see how similar it is to my own response. To elaborate on this, I don't know much about MCP, but usually when people speak about it is in a buzzword-seeking kind of way, and the people that are interested in it make these kinds of conceptual snafus. Second, and this applies not just to MCP, but even things like JSON, Rust, MongoDB. There's this phenomenon where people learn the complex stuff before learning the basics. It's not the first time I've cited this video on Homer studying marketing where he reads the books out of order https://www.youtube.com/watch?v=2BT7_owW2sU https://www.youtube.com/watch?v=2BT7_owW2sU . It makes sense that this mistake is so common, the amount of literature and resources is like an inverted pyramid, there's so little classical foundations and A LOT of new stuff, most of which will not stand the test of time. Typically you have universities to lead the way and establish a classical corpus and path, but being such a young discipline, 70 years in and we are still not finding much stability, Universities have gone from teaching C, to teaching Java, to teaching Python (at least in intro to CS), maybe they will teach Rust next, but this buzzwording seems more in line with trying to predict the future, and there will be way more losers than winners in that realm. And the winners will have learned the classicals in addition to the new technology, learning the new stuff without the classics is a recipe for disaster.
- gdecaso 1y agoThe main difference between MCP and REST is `list-tools`. REST APIs have 5 or 6 ways of doing that, including "read it from our docs site", HATEOAS, OAS running on an endpoint as part of the API. MCP has a single way of listing endpoints.
- gavinray 1y agoWSDL + XML API's have been around since 1998. OpenAPI, OData, gRPC, GraphQL I'm sure I'm missing a few...
- doug_durham 1y agoWhere is "list-tools" in any of those low level protocols?
- deleted 1y ago[deleted]
- debugnik 1y agoAll of them already provide an IDL with text descriptions and a way to query a server's current interface, what else do we need? Just force those two optional features to be required for LLM tool calls and done. Is there anything stopping generic MCP servers for bridging those protocols as-is? If not, we might as well keep using them.
- opliko 1y agoI don't know enough about OData, but: - Introspection (__schema queries) for every graphQL server. You can even see what it exposes because most services expose a web playground for testing graohQL APIs, e.g. GitHub: https://docs.github.com/en/graphql/overview/explorer https://docs.github.com/en/graphql/overview/explorer - Server Reflection for gRPC, though here it's optional and I'm not aware of any hosted web clients, so you'll need a tool like gRPCCurl if you want to see how it looks in real services yourself. - OpenAPI is not a protocol, but a standard for describing APIs. It is the list-tools for REST APIs.
- 1y ago
- rco8786 1y agoOne major difference is that MCP has discovery built into the protocol. There’s nothing in REST that informs clients what the API can do, what resources are available, etc.
- adverbly 1y agoApis do not need to necessarily tell you everything about themselves. Anyone who has used poorly documented or fully undocumented apis knows exactly what I'm talking about here. Obviously, for http apis you might often see something like an open API specification or graphql which both typically allow an api to describe itself. But this is not commonly a thing for non-http, which is something that mcp supports. MCP might be the first standard for self-described apis across all protocols(I might be misusing protocols here but not sure what the word technically should be. I think the MCP spec calls it transport but I might be wrong there), making it slightly more universal. I think the author is wrong to discount the importance of an llm as an interface here though. I do think the majority of mcp clients will be llms. An API might get you 90% of the way there but if the llm gets you 99.9% by handling that last bit of plumbing it's going to go mainstream.
- int_19h 1y agoThis is exactly what the author is saying. It is "the idea of APIs in general" that has suddenly become a fad under the guise of MCP, riding the AI wave. And it may well be a very imperfect way to build APIs, but if it eventually becomes the standard to the point where every app has to offer it, it's still "good enough" and would massively improve interoperability all around as a side effect.