MCP is ultimately just an abstraction over APl calls using standard protocols like HTTPS. If someone is building an MCP for Spotify, a REST API likely already exists for that.
Any non-Al system can easily integrate with it. still believe MCP should be reserved for LLM-specific use cases. Don't drink tea with a spoon when you have a cup available.
I suspect you're going to find yourself starting a lot of sentences with 'It's like what we were doing in the 90s with...'. It's looking to me like all the ingredients are coming together for the return of shareware...
🤯 My mind just exploded on the wall, holy moly! You had my interest with this article heading, after reading now you have my attention🫡 How do I check out this APM?
Very good post. As I read through it I was thinking... these services will probably not all be free. I haven't investigated the protocol yet but wonder if there will be a way for one service to hire another and exchange tokens for services hired, automating how they purchase services. My guess is that it would be a place where crypto fits just right.
So far, paid services rely upon their billing happening outside the protocol. When the user configures an MCP server, the user usually has to provide some authentication token directly. The details are all internal in the server - many take it as a command line parameter, some use interactive authorization, and cache it.
Give me an eGPU and I'll run a local model *on the toaster*. I'll get it to listen to the surrouding conversations and have it set off the fire alarm to get me out of a conversation.
In all seriousness, this is fantastic, and I want to use it for a procedurally-generated UI project I'm working on
Thanks for this! I said something similar a few weeks ago to colleagues, but much less verbosely, and without practical examples. So this is my go to reference for now to share the idea.
It's just another kind of RPC. And all kinds of RPCs where with us for many years already. What prevented you to use some kind of RPC before? For example, I had my own implementation of bidirectional communication between server and client over Websocket connection with JSON-RPC and serialization to MessagePack. Many years ago before MCP. It was very special case to create a decorator around old banking SOAP API (which was actually an RPC implementation, too). It has always been here - once you deal with resources and CRUD, use REST, and if you need to execute remote procedure, use RPC, even though many people do RPC via RPC-ish "REST" endpoints.
Yeah, nothing really. I’ve been looking around trying to find other widespread uses of this to figure out why it hasn’t been done before. It looks like LSP uses the json rpc over stdio model, but it seems we could have done this for a long time.
I think what makes it different is that it’s taken on a life of its own and you have network effects of people building open source versions of connectors and lots of big players supporting and releasing official clients and servers.
Important ways MCP is different from most other previous RPC methods, primarily contrasting with REST, because it is the most ubiquitous recent RPC standard:
- Self-describing - Swagger/OpenAPI was an add-on to REST many years later and is not reliably available at a Well-Known URI.
- Including documentation is a basic requirement, not optional
- Authentication is already established, instead of some random assortment of API keys, custom OAuth implementations, and custom username/password APIs.
- The goal of being used by tool-using language models puts many fuzzy constraints on the complexity.
- The built-in documentation must be worded simply enough for a mid-range LLM to understand it.
- Many REST APIs dump a haphazardly developed granular internal API out to the public, with some polish added at the end. Tool-using LLMs are kinda terrible at successfully using those.
- Meaningful end-user actions must be accomplished without so many calls that the LLM loses track of what it is doing.
- Simpler is better for easy composability, but previous RPC methods didn't actively demonstrate this during basic internal testing.
I don't recall any previous RPC mechanisms being tied from the start to new popular fads with broad appeal, either. If MCP wasn't tied to the current AI fad, it would just suffer the fate of being yet another RPC standard.
Now I wonder if new MCP servers will worsen as tool-using LLMs get better. If so, at least in most cases, those LLMs will be able to "explain" how to use the terrible ones, or generate code for them.
Wow! what a brilliant perspective on MCP and come to think of it, its so true!
How do you get access to your beta?
Reach out and let's chat!
You can reach me at scott@sublayer.com, @scottwernerd on twitter, or hop in the discord and say hi: https://discord.gg/TvgHDNEGWa
Congrats, you discovered APIs!
MCP is ultimately just an abstraction over APl calls using standard protocols like HTTPS. If someone is building an MCP for Spotify, a REST API likely already exists for that.
Any non-Al system can easily integrate with it. still believe MCP should be reserved for LLM-specific use cases. Don't drink tea with a spoon when you have a cup available.
It’s like what we were doing in the 90s with system level scripting on the Mac.
I suspect you're going to find yourself starting a lot of sentences with 'It's like what we were doing in the 90s with...'. It's looking to me like all the ingredients are coming together for the return of shareware...
🤯 My mind just exploded on the wall, holy moly! You had my interest with this article heading, after reading now you have my attention🫡 How do I check out this APM?
Very good post. As I read through it I was thinking... these services will probably not all be free. I haven't investigated the protocol yet but wonder if there will be a way for one service to hire another and exchange tokens for services hired, automating how they purchase services. My guess is that it would be a place where crypto fits just right.
So far, paid services rely upon their billing happening outside the protocol. When the user configures an MCP server, the user usually has to provide some authentication token directly. The details are all internal in the server - many take it as a command line parameter, some use interactive authorization, and cache it.
Hey how can I sign up for APM? and thanks for this article it's incredibly insightful
Thanks for the post Scott! It is really smart and fun. You make my morning coffee better just talking about MCP
PD: Extra plus. Now my family understand what I do at works 😅🤓
Love it! Great read and so true! Thanks for writing and sharing this
Give me an eGPU and I'll run a local model *on the toaster*. I'll get it to listen to the surrouding conversations and have it set off the fire alarm to get me out of a conversation.
In all seriousness, this is fantastic, and I want to use it for a procedurally-generated UI project I'm working on
Great post! I've really been excited about the possibilities of MCP, for the reasons you describe as well.
Rex's toaster makes we wonder what we could do with furbies though. 🤔
(However that might be a direct path to the dark side.)
Talking about the 90s, or earlier, maybe it's time to resurrect Mr Protocol.....http://w0ep.us/AskMrProtocol/AMrP.1998.02.pdf as an example?
Thanks for this! I said something similar a few weeks ago to colleagues, but much less verbosely, and without practical examples. So this is my go to reference for now to share the idea.
It's just another kind of RPC. And all kinds of RPCs where with us for many years already. What prevented you to use some kind of RPC before? For example, I had my own implementation of bidirectional communication between server and client over Websocket connection with JSON-RPC and serialization to MessagePack. Many years ago before MCP. It was very special case to create a decorator around old banking SOAP API (which was actually an RPC implementation, too). It has always been here - once you deal with resources and CRUD, use REST, and if you need to execute remote procedure, use RPC, even though many people do RPC via RPC-ish "REST" endpoints.
Yeah, nothing really. I’ve been looking around trying to find other widespread uses of this to figure out why it hasn’t been done before. It looks like LSP uses the json rpc over stdio model, but it seems we could have done this for a long time.
I think what makes it different is that it’s taken on a life of its own and you have network effects of people building open source versions of connectors and lots of big players supporting and releasing official clients and servers.
Important ways MCP is different from most other previous RPC methods, primarily contrasting with REST, because it is the most ubiquitous recent RPC standard:
- Self-describing - Swagger/OpenAPI was an add-on to REST many years later and is not reliably available at a Well-Known URI.
- Including documentation is a basic requirement, not optional
- Authentication is already established, instead of some random assortment of API keys, custom OAuth implementations, and custom username/password APIs.
- The goal of being used by tool-using language models puts many fuzzy constraints on the complexity.
- The built-in documentation must be worded simply enough for a mid-range LLM to understand it.
- Many REST APIs dump a haphazardly developed granular internal API out to the public, with some polish added at the end. Tool-using LLMs are kinda terrible at successfully using those.
- Meaningful end-user actions must be accomplished without so many calls that the LLM loses track of what it is doing.
- Simpler is better for easy composability, but previous RPC methods didn't actively demonstrate this during basic internal testing.
I don't recall any previous RPC mechanisms being tied from the start to new popular fads with broad appeal, either. If MCP wasn't tied to the current AI fad, it would just suffer the fate of being yet another RPC standard.
Now I wonder if new MCP servers will worsen as tool-using LLMs get better. If so, at least in most cases, those LLMs will be able to "explain" how to use the terrible ones, or generate code for them.
but how is this any different from any other API protocol?
is there something specific about MCP that makes it more universal (in your opinion) than other protocols?