Thank you so much Addy for this detailed post. I've read a lot about MCPs the past few months, and I've shared your post in my company's Slack saying that "Addy Osmani from Google just released what I consider to be the best short primer on what MCP is all about".
I still struggle to understand how you're able to pull this off next to a demanding full-time job and a family life. Kudos to you man!
Quick question: is there anything that MCP enables which wouldn't have been possible with the OpenAPI standard?
Developers were already able to to create a dumbed-down interface (i.e. simple wrapper) for the LLM by implementing a simpler OpenAPI spec, no?
And then the LLMs could also use the OpenAPI standard for discoverability using mydomain.com/openapi.json, so that they could know the API's capabilities.
Isn't MCP somehow reinventing the wheel here, pretending to enable what was already possible with existing and battle-tested technologies?
Truly curious to have your sincere opinion on this.
Hey Samuel, thanks for the kind words! Really happy you dug the MCP post. I'm all about squeezing in writing time whenever I can, it's a bit of a hustle!
That question you had about MCP vs. OpenAPI is spot on. Basically, while OpenAPI helps LLMs find and understand APIs, MCP is built for two-way chats between AI and apps, using regular language. It makes it easier for AI to figure out what different tools can do, and gives them a common language to talk to anything, not just web stuff.
The real cool thing about MCP is it sets up a standard way for AI to think about, pick, and use tools by just talking. Sure, there's some overlap with other tech, but whether MCP takes off and becomes *the* way AI and apps talk is the big question.
A few things have that have bothered me about MCPs so far is how the conversation and examples are all around "using" existing MCPs inside prebuilt host applications like Claude/Cursor etc. This seems fine for platform tools/apps (e.g., IDEs) where the user is a developer can can do things like hunt down the right MCP, install it, configure json files here and there etc.
But most developers need to build custom MCP servers and integrate this with their developer workflow. E.g, what would it take to replace my current business api with an MCP enabled version .. and highlights developer experience issues, integration issues (the MCP server transport itself adds latency beyond the actual too functionality) and security issues too.
Hi Victor! Thanks for the kind words. Your points about the gap between MCP excitement and real-world implementation are pretty spot on. Current discussions often overlook the challenges of building custom MCP servers that integrate with existing business APIs.
You're right about the developer experience issues in creating custom MCP servers. Replacing existing APIs with MCP-enabled versions requires addressing complex problems (abstraction, latency, security, and multi-tenancy) which the article only briefly touches upon.
The latency and security concerns you raise are critical. The added overhead from MCP calls and the lack of standardized authentication mechanisms are significant obstacles that must be overcome for MCPs to achieve mainstream adoption in enterprise settings.
Thanks, Addy! This is interesting; it feels quite similar to what GraphQL aims to achieve today. But MCP for AI? A GraphQL supergraph that connects to multiple endpoints to provide a unified API.
My pleasure! MCP does share (some) conceptual similarities with GraphQL, but for AI interactions rather than data fetching. Both aim to provide a unified interface to diverse endpoints - GraphQL creates a supergraph connecting multiple data sources with a standardized query language, while MCP establishes a common protocol for AI to interact with various tools and services. Think of MCP as GraphQL's AI-native cousin - instead of writing precise queries, the AI interprets intent and translates it to the appropriate tool actions.
It took me two days to reach the comments! 😱
Excellent, high-quality post. Thank you for sharing.
This is the best post i've read on MCP. Thanks Addy!
Great explanation - Thanks Addy for taking the time and writing this up!
This is a top tier article man.
Great explanation!
timely article, I have been just starting to look into MCP. Thanks a lot for such a detailed post and well-organized.
Thank you so much Addy for this detailed post. I've read a lot about MCPs the past few months, and I've shared your post in my company's Slack saying that "Addy Osmani from Google just released what I consider to be the best short primer on what MCP is all about".
I still struggle to understand how you're able to pull this off next to a demanding full-time job and a family life. Kudos to you man!
Quick question: is there anything that MCP enables which wouldn't have been possible with the OpenAPI standard?
Developers were already able to to create a dumbed-down interface (i.e. simple wrapper) for the LLM by implementing a simpler OpenAPI spec, no?
And then the LLMs could also use the OpenAPI standard for discoverability using mydomain.com/openapi.json, so that they could know the API's capabilities.
Isn't MCP somehow reinventing the wheel here, pretending to enable what was already possible with existing and battle-tested technologies?
Truly curious to have your sincere opinion on this.
Hey Samuel, thanks for the kind words! Really happy you dug the MCP post. I'm all about squeezing in writing time whenever I can, it's a bit of a hustle!
That question you had about MCP vs. OpenAPI is spot on. Basically, while OpenAPI helps LLMs find and understand APIs, MCP is built for two-way chats between AI and apps, using regular language. It makes it easier for AI to figure out what different tools can do, and gives them a common language to talk to anything, not just web stuff.
The real cool thing about MCP is it sets up a standard way for AI to think about, pick, and use tools by just talking. Sure, there's some overlap with other tech, but whether MCP takes off and becomes *the* way AI and apps talk is the big question.
This is a great article @addy.
A few things have that have bothered me about MCPs so far is how the conversation and examples are all around "using" existing MCPs inside prebuilt host applications like Claude/Cursor etc. This seems fine for platform tools/apps (e.g., IDEs) where the user is a developer can can do things like hunt down the right MCP, install it, configure json files here and there etc.
But most developers need to build custom MCP servers and integrate this with their developer workflow. E.g, what would it take to replace my current business api with an MCP enabled version .. and highlights developer experience issues, integration issues (the MCP server transport itself adds latency beyond the actual too functionality) and security issues too.
https://newsletter.victordibia.com/p/no-mcps-have-not-won-yet
Hi Victor! Thanks for the kind words. Your points about the gap between MCP excitement and real-world implementation are pretty spot on. Current discussions often overlook the challenges of building custom MCP servers that integrate with existing business APIs.
You're right about the developer experience issues in creating custom MCP servers. Replacing existing APIs with MCP-enabled versions requires addressing complex problems (abstraction, latency, security, and multi-tenancy) which the article only briefly touches upon.
The latency and security concerns you raise are critical. The added overhead from MCP calls and the lack of standardized authentication mechanisms are significant obstacles that must be overcome for MCPs to achieve mainstream adoption in enterprise settings.
Thanks for writing this, Addy
My pleasure. I hope it's a useful read.
Thanks, Addy! This is interesting; it feels quite similar to what GraphQL aims to achieve today. But MCP for AI? A GraphQL supergraph that connects to multiple endpoints to provide a unified API.
My pleasure! MCP does share (some) conceptual similarities with GraphQL, but for AI interactions rather than data fetching. Both aim to provide a unified interface to diverse endpoints - GraphQL creates a supergraph connecting multiple data sources with a standardized query language, while MCP establishes a common protocol for AI to interact with various tools and services. Think of MCP as GraphQL's AI-native cousin - instead of writing precise queries, the AI interprets intent and translates it to the appropriate tool actions.
Very thorough and interesting article! Thanks!
This was a great read. Very helpful, thank you.
Awesome writeup, Addy. Just wanted to toss in https://mcpservers.com/ as a resource here for finding good servers to try!
Excellent post.
Too deep, This post is also act as MCP server for understanding MCP.
Happy to reach here..
Great article.
I personally follow you Addy for all the AI stuff happening.
just keep your word of "making us win" < this race.