Based on the comments here, a lot of folks are assuming the primary users of mcp are the end users connecting their claude/vscode/etc to whatever saas platform they're working on. While this _is_ a huge benefit and super cool to use, imo the main benefit is for things like giving complex tool access to centralized agents. Where the mcp servers allow you to build agents that have the tools to do a sort of "custom deep research."
We have deployed this internally at work where business users are giving it a list of 20 jira tickets and asking it to summarize or classify them based on some fuzzy contextual reasoning found in the description/comments. It will happly run 50+ tool calls poking around in Jira/confluence and respond in a few seconds what would have taken them hours to do manually. The fact that it uses mcp under the hood is completely irrelevant but it makes our job as builders much much easier.
As someone who does both, I have to say that the only reason I am writing MCP stuff is that all the user-side tools seem to support it.
And the moment we, as an industry, settle on something sane, I will rip out the whole thing and adopt that, because MCP brings _nothing_ to the table that I could not do with a "proper" API using completely standard tooling.
Then again, I have run the whole gamut since the EDI and Enterprise JavaBeans era, XML-RPC, etc. - the works. Our industry loves creating new API surfaces and semantics without a) properly designing them from the start and b) aiming for a level of re-use that is neither pathological nor wasteful of developer time, so I'm used to people from "new fields of computing" ignoring established wisdom and rolling their own API "conventions".
But, again, the instant something less contrived and more integratable comes along, I will gleefully rm -rf the entire thing and move over, and many people in the enterprise field feel exactly the same - we've spent decades builting API management solutions with proper controls, and MCP bodges all of that up.
> And the moment we, as an industry, settle on something sane, I will rip out the whole thing and adopt that, because MCP brings _nothing_ to the table that I could not do with a "proper" API using completely standard tooling.
100%. I suppose I understand MCP for user-side tooling but people seem to be reinventing the wheel because they don't understand REST. making REST requests with a well defined schema from an LLM is not all that hard.
Looks like the GraphQL beginnings, it feels fresh now and the AI products kind of nudge everything that way but fundamentally the main point is being able to package an API into a standard format, with documented endpoints, support for authentication, and different transports.
Nothing that couldn't be solved by a well designed REST API with Swagger documentation (and authentication, and websockets), but by being the same interface for all APIs it reduces the burden on the LLM.
> because MCP brings _nothing_ to the table that I could not do with a "proper" API using completely standard tooling.
This is what drives me crazy and has stopped my tinkering with MCP in its tracks: what is the point? It's not bringing anything new. It's usually not easier to set-up than what you're describing. Or, if you absolutely must have an LLM in the mix, normal function calling does just as well as MCP.
It's a real, "I feel like I'm taking crazy pills" moment: there's all this hype and bluster and "wow look at this", but there is no "this". Everyone's talking about "it can do" and "it'll be amazing when", but there's nothing actually built and present and ready that is impressive.
Where I struggle conceptually is this works fine without MCP.
Write a CLI tool that does the same thing (including external service access) and tell any agentic CLI tool (or Cursor or IDE tool) to use the tool. Much simpler, established security models, etc.
You're thinking like a SW engineer. Instead, think like someone who just happens to know a bit of programming. MCP is much, much easier than tool calling, I think.
As an example, I wrote a function in Python that, given a query string, executes a command line tool and returns the output. To make it an MCP server, I simply added type annotations to the function definition, and wrote a nice docstring, and added a decorator.
That's it. And now it works with all providers and all tools that support MCP. No REST APIs, etc needed. Not tied to a particular agentic tool.
Every time I've written a tool, I've ended up with "Wow, was it really that simple?"
As for security: If you write your own tool, the security implications are the same.
Sure, and MCP is just a standardized way of exposing tools. This is where I feel MCP is both overhyped (waaaaaaay too much LinkedIn influencer hot air) but also genuinely quite useful.
I've done stuff very much like the above with just regular tool calls through the various LLM APIs, but there are tons of disparate frameworks for how to harness up a tool, how they execute, how they are discovered, etc. None of it is rocket science.
But the nice thing about having a standard is that it's a well-lit path, but more importantly in the corporate workflow context is that it allows tools to be composed together really easily - often without any coding at all.
An analyst who has zero coding experience can type in a prompt, click "add" on some MCP tools, and stand up a whole workflow in a minute or two.
That's pretty cool.
And yeah, none of it is impossible to implement yourself (nor even very hard!) but standardization has a value in and of itself in terms of lowering barriers to entry.
Yes, MCP adds no new fundamental capabilities. What it does is solve an N x M problem, where to hook up a given tool to a given LLM scaffold you have to write specific integration code for that combination of scaffold and tool.
With MCP that's decoupled, the tool and the software speak a common protocol, and it's one line of configuration to hook the tool up to the LLM. Makes it easy to mix and match, reuse code, etc.
This is pretty fair: in claude code, I have the github mcp server installed, but the agent actually prefers to use the CLI. There's also other advantages too, such as incremental discovery of subcommands for more complex CLIs. Certainly agents already don't have a problem using CLIs.
That said, this doesn't fully work in environments on websites like claude.ai. Perhaps you could have an org-wide Dockerfile or something that opens every time you start a chat which gives it MCP-like capabilities, but that sounds more complicated in many ways than what MCP does. There's also more problems that MCP solves, like with Prompts and Sampling (which are pretty under-used at the moment), and there aren't great analogs for that in the CLI world.
Also developers like you and I might find it trivial to install CLIs, set up auth, and open an agent locally, but this isn't widely true. As an example, at Stainless we have non-engineer folks who ask questions like "who are the most interesting people who have signed up yesterday", and with the right MCP tools wired to claude.ai, claude actually does an excellent job of answer these kinds of questions, all in the browser. This was all without a doubt possible before MCP, but MCP reduces the friction enough, such that it becomes worth-it/easy-enough to develop these tools.
Yeah, CLIs actually often do seem better for agents with access to bash, like Claude Code.
That said, many "business users" like those referenced above interact more with a web UI, and asking them to audit bash/CLI interactions might not always work well.
(disclaimer: I work at Stainless; we're actually exploring ways to make MCP servers more "CLI-like" for API use-cases.)
If the CLI tool does IO with the agentic CLI tool of choice over STDIO, then it's MCP by definition, with the only caveat being that it runs locally on each user's machine instead of a server. For dev-teams, CLI would work but for non-coders, web-apps or Slack-channel with LLM/MCP integration would be better.
I'll take a CLI over http ten times out of ten. However, I'm skeptical that that's the ideal long term interface because it gives the model too much freedom.
I want to be the one deciding which CWD to use, which user to run as, whether to see the whole filesystem or to restrict to a chroot, etc.
So far it hasn't been malicious but I've had a number of cases while using cursor where the model has gotten confused and is now editing repos outside the open workspace.
Maybe the answer is still a CLI, but I want a standardized interface for equipping that CLI with handcuffs.
The problem with that is it doesn’t work for people who are not technical. Remote mcp is pretty good even if I would have preferred a rest api helper endpoint to support existing apis
I've found it to be amazing purely as a new form factor for software delivery. There's a middle ground so common in enterprise where there's a definite need for some kind of custom solution to something, but not enough scale or resourcing to justify building out a whole front end UI, setting up servers, domains, deploying, and maintaining it. Now you can just write a little MCP tool that does exactly what the non-technical end user needs and deliver it as a locally installed "plugin" to whatever agentic tooling they are using already (Claude Desktop, etc). And using Smithery, you don't even have to worry about the old updating concerns of desktop software either; users get the latest version of your tooling every time they start their host application.
It’s actually surprising just how powerful 1-5 tools can be if you document it well and the llm knows how to pass arguments from other tool responses you had higher up in the thread
Yep, we've built some really useful agents with some simple tools (3-5 templated snowflake queries with really good descriptions). The LLM is useful for shaping your question into function params and then interpreting the results based on the context it got from the tool description.
I suppose it shouldn't bother me that the people doing that are 'business users' but I have to wonder if adults these days are so illiterate that they can't read through 20 jira tickets and categorize them in less than an hour.
More concerning is people thinking that the document you output is the outcome, when the mental models and the domain understanding are what we ought to strive for.
Organizations are primarily systems for learning. Substituting machine learning (from a vendor) for human learning inside the team is a bad strategy.
This leaves more time to spend arguing with the chatbot about miscategorized tickets; the chatbot exclaiming "you're right, I'll do better next time" and then making the same mistake tomorrow.
At Stainless we use https://github.com/dgellow/mcp-front to make it easy for anyone on the team (including non-technical folks) to OAuth into a pretty wide variety of tools for their AI chats, using their creds. All proxied on infra we control.
Even our read replica postgres DB is available, just push a button.
MCP allows you to bring tools to agents you don't control. It's awesome, but it isn't the right match for every problem. If you believe the hype of X/LinkedIn you would think that MCP everywhere is going to be the solution.
Bringing tools to your local Claude client is awesome, but there are still challenges with MCP that need to be solved and like all technology, it isn't applicable universally.
MCP is pretty cool, but the way every AI influencer pivoted to producing MCP glorification posts at the same time has been groan-inducing. I can usually ignore the hype cycles, but I've been bombarded with so much MCP influencer content in the past few months that I feel exhausted every time I see those three letters.
It's basically the story of the last 3 years. Can't ignore the technology, but every loser grifter in existence has been on AI full time. On average, the more they are fanatics of it, the less they're able to take advantage of what it actually can do, most often due to an inordinate amount of skill issues unrelated to AI.
All influencer content is groan-inducing, but the idea behind MCP is pretty huge: it's the ability to link LLM agent loops into basically arbitrary APIs. It would be weird if it wasn't attracting a lot of attention.
MCP is a major lifeline for OpenAI and Anthropic. Their only reasonable way to compete with the big vertical AI integrators is if the "community" does all the hard work of integration, hence MCP. After the initial burst of greenfield enthusiasm I suspect it will stagnate as a yet another maintenance burden.
Any kind of open extensions can be framed as "lifeline" but it's also the only way a platform can evolve and actually cater to consumers' need. The alternative is the company somehow knowing how every consumer thinks. It can happen over time just not on any realistic time frame. If it take too long it's not exactly great for the people building on the platform either.
Simple - you use MCP agents to update your MCP servers. I made 2 MCPs both 100% vibe coded. Keep the constraints - docs+tests - and you can regenerate the code as needed.
Along with burning tokens, how MCP servers are ran and managed is resource wasteful. Running a whole Docker container just to have some model call a single API? Want to call a small CLI utility, people say to run another Docker container for that
A "whole Docker container" is not very heavyweight. Other than having their own filesystem view and separate shared libraries, container processes are nearly as light as non-container processes. It's not like running a VM.
I don’t think running these commands in a docker container is the standard way of doing this, I’ve seen “npx” et al being used way more often.
Furthermore, the “docker” part wouldn’t even be the most resource wasteful if you consider the general computational costs of LLMs.
The selling point of MCP servers is that they are composable and plug in into any AI agent. A monolith doesn’t achieve that, unless I’m misunderstanding things.
What I find annoying is that it’s very unpredictable when exactly an LLM will actually invoke an MCP tool function. Different LLM providers’ models behave differently, and even within the same provider different models behave differently.
Eg it’s surprisingly difficult to get an AI agent to actually use a language server to retrieve relevant information about source code, and it’s even more difficult to figure out a prompt for all language server functions that works reliably across all models.
And I guess that’s because of the fuzzy nature of it all.
I’m waiting to see how this all matures, I have the highest expectations of Anthropic with this. OpenAI seems to be doing their own thing (although ChatGPT supposedly will come with MCP support soon). Google’s models appear to be the most eager to actually invoke MCP functions, but they invoke them way too much, in turn causing a lot of context to get wasted / token noise.
It's not the solution to every problem but it's a great substitute for a infrequently used app with mediocre UX and most of the world's apps probably do fall into that category actually.
I don't think that the goal of MCP is for software developers.
MCP is great for: "I would like Claude Desktop/VSCode/Cursor to know about my JIRA tickets". AFAIK Most of the tools that are being used for AI Coding tools are not delivered through MCP.
FastMCP author here -- (maybe surprisingly) I agree with many of the observations here.
FastMCP exists because I found the original spec and SDK confusing and complicated. It continues to exist because it turns out there's great utility in curating an agent-native API, especially when so many great dev tools have adopted this client interface.
But the spec is still so young and at such risk of being co-opted by hype (positive and negative). I would invite everyone to participate constructively in improving it.
Lastly: this article is plainly AI generated, as `from mcp import tool` is completely hallucinated. Just some food for thought for the "AI should be able to figure out my complex REST API" crowd that seems well represented here.
I would invite everyone to participate constructively in improving it.
How do you recommend that I participate? I've written a few MCP servers (based on FastMCP - great work!), and contributed one to Anthropic's list. How do I actually participate in maintaining or improving the core MCP spec? I was under the impression that it was being driven by Anthropic.
You're right, that snippet was ai-generated and I forgot to action one of my todos to fix that snippet. This was negligent on my part, and I hope you'll forgive me.
We're fixing that right now, thank you for the correction!
It should be added that the company where the blog is hosted makes MCP tools. So a post from a company making MCP tools that MCP is the new Messiah isn't exactly earth shaking.
They need a better PR department. When I read "MCP is eating the world" I took it as, "this is a bad thing." Which, based on the last blog post I read from a knowledgeable person[0], it is.
And the more I read this article, I feel like it still is. "The models finally got good enough" is followed by:
> Of course, models and agents are still far from perfect—the better models are pretty slow, context sizes are still limited, and performance degrades when more and more context is present.
> What’s important is that the models are good enough—once models cross that threshold, the overhead of integrating tool use drops dramatically. MCP just showed up right on time.
That's like saying we invented worker ants just in time to help an insane queen.
I searched the article for the word "secure" or "security" and quit reading when I couldn't find it.
Well you see I run dozens of agents at once so my hours of experience accumulate at 10-100x real time. I've got about 200 years of experience in MCP. I accumulated another 3 years of experience while typing this
Hi, I work at Stainless. We don’t make money from generating MCP servers. You can do it for free, it’s just a config option in your Typescript SDK config
Taking this question at face value, because you asked: Stainless generates MCP servers for REST APIs (a ~simple[0] translation of an OpenAPI to a suite of MCP tools).
We actually generate MCP for free (we charge for SDKs), so we're technically not selling, but I don't begrudge GP's comment/sentiment.
[0]https://www.stainless.com/blog/what-we-learned-converting-co... describes some ways in which this is less simple than you think. The "Handling large APIs dynamically" section near the bottom covers the most salient challenge related to converting large APIs to MCP tools, but there's more work to do.
> Heck, even MCP itself isn’t new—the spec was released by Anthropic in November, but it suddenly blew up in February, 3 months later.
Wow, the idea of what's "new" in software has always been really short, but damn, it's becoming questionable whether anything can be considered new these days.
Yeah, if this was the Javascript ecosystem 3 months would mean the original implementation has been moved to maintenance mode and only gets security updates from here forward. Everyone would need to start migrating to the replacement as soon as possible.
yeah it's crazy to think that claude 4 has only been out a month. And the previous iteration 3.7 was launched only in February!
but also I think the interesting thing is that people didn't jump on MCP immediately after it launched - it seemed to go almost unnoticed until February. Very unusual for AI tech - I guess it took time for servers to get built, clients to support the protocol, and for the protocol itself to go through a few revisions before people really understood the value.
I won’t speak to the technical merits of MCP but I will say this: it doesn’t matter for many use cases, in particular consumer tech.
The entire digital consumer economy is built around ownership of the screen real estate, due to a simple reason: ads. Whoever owns the sidebar sets the rules, period. Web2.0 was all about APIs (usually Rest/json) and in hindsight we see a clear distinction on where they’re used: in commercial B2B apps. Conversely, big B2C players shut down the little open they had - Facebook, Gmail removed their XMPP support, and these days Twitter etc even gatekeep content when you’re not signed in or using the app, and aggressively fortify against even basic scraping. When you’re using other clients, you are bypassing their sidebar, meaning their opportunity to deliver ads.
So no, your iOS apps and Twitter are not gonna ”open up” their APIs in any way, not through Rest and not through MCP, simply because it goes directly against their incentives. The exceptions are (1) temporary to ride a hype train, and (2) services you pay money for (but even that is wishful and hypothetical).
The trouble with MCP is that it requires a trip through an LLM for every transaction. It's not like the ends negotiate a simple protocol so that later queries are cheap. That's a huge cost increase as traffic increases.
I'm not sure I understand what you mean by "it requires a trip through an LLM for every transaction"?
In a normal case of "production software", yeah, you would not want to add an LLM in the middle to make an API call. That's silly – just write the code to make the API call if you can do it deterministically.
If you're talking to an LLM in a chat experience, and you want that LLM to go interact with some foreign system (i.e., hit an API), you need _some way_ of teaching the LLM how to make that API call. MCP is one such way, and it's probably the easiest at this point.
Doing it through MCP does introduce some latency due to a proxy server, but it doesn't introduce an additional LLM "in the middle".
(Disclaimer: I work at Stainless. Note that we actually sell SDKs at Stainless; our MCP generator is free.)
You're right that per-request LLM inference is costly, especially at scale. But I think the bet with MCP (Model Coordinated Protocol) isn’t that every interaction will always hit the LLM, it’s that the LLM bootstraps flexible protocol negotiation, and then clients can cache or formalize the result.
Think of it more like a just-in-time protocol generator. The LLM defines how to talk, once, and the rest of the interaction can be optimized. Expensive at first, but potentially cheaper than baking in rigid APIs for every use case.
Still, lots of unknowns, especially around latency, consistency, and cost.
There is no reason you couldn't design the system to hand off to a simple protocol through an MCP call, it's entirely up to what works in the specific situation. There is nothing in the design that mandates a path through the LLM for every request or transaction.
Readit News
We have deployed this internally at work where business users are giving it a list of 20 jira tickets and asking it to summarize or classify them based on some fuzzy contextual reasoning found in the description/comments. It will happly run 50+ tool calls poking around in Jira/confluence and respond in a few seconds what would have taken them hours to do manually. The fact that it uses mcp under the hood is completely irrelevant but it makes our job as builders much much easier.
And the moment we, as an industry, settle on something sane, I will rip out the whole thing and adopt that, because MCP brings _nothing_ to the table that I could not do with a "proper" API using completely standard tooling.
Then again, I have run the whole gamut since the EDI and Enterprise JavaBeans era, XML-RPC, etc. - the works. Our industry loves creating new API surfaces and semantics without a) properly designing them from the start and b) aiming for a level of re-use that is neither pathological nor wasteful of developer time, so I'm used to people from "new fields of computing" ignoring established wisdom and rolling their own API "conventions".
But, again, the instant something less contrived and more integratable comes along, I will gleefully rm -rf the entire thing and move over, and many people in the enterprise field feel exactly the same - we've spent decades builting API management solutions with proper controls, and MCP bodges all of that up.
100%. I suppose I understand MCP for user-side tooling but people seem to be reinventing the wheel because they don't understand REST. making REST requests with a well defined schema from an LLM is not all that hard.
Nothing that couldn't be solved by a well designed REST API with Swagger documentation (and authentication, and websockets), but by being the same interface for all APIs it reduces the burden on the LLM.
This is what drives me crazy and has stopped my tinkering with MCP in its tracks: what is the point? It's not bringing anything new. It's usually not easier to set-up than what you're describing. Or, if you absolutely must have an LLM in the mix, normal function calling does just as well as MCP.
It's a real, "I feel like I'm taking crazy pills" moment: there's all this hype and bluster and "wow look at this", but there is no "this". Everyone's talking about "it can do" and "it'll be amazing when", but there's nothing actually built and present and ready that is impressive.
Write a CLI tool that does the same thing (including external service access) and tell any agentic CLI tool (or Cursor or IDE tool) to use the tool. Much simpler, established security models, etc.
As an example, I wrote a function in Python that, given a query string, executes a command line tool and returns the output. To make it an MCP server, I simply added type annotations to the function definition, and wrote a nice docstring, and added a decorator.
That's it. And now it works with all providers and all tools that support MCP. No REST APIs, etc needed. Not tied to a particular agentic tool.
Every time I've written a tool, I've ended up with "Wow, was it really that simple?"
As for security: If you write your own tool, the security implications are the same.
I've done stuff very much like the above with just regular tool calls through the various LLM APIs, but there are tons of disparate frameworks for how to harness up a tool, how they execute, how they are discovered, etc. None of it is rocket science.
But the nice thing about having a standard is that it's a well-lit path, but more importantly in the corporate workflow context is that it allows tools to be composed together really easily - often without any coding at all.
An analyst who has zero coding experience can type in a prompt, click "add" on some MCP tools, and stand up a whole workflow in a minute or two.
That's pretty cool.
And yeah, none of it is impossible to implement yourself (nor even very hard!) but standardization has a value in and of itself in terms of lowering barriers to entry.
With MCP that's decoupled, the tool and the software speak a common protocol, and it's one line of configuration to hook the tool up to the LLM. Makes it easy to mix and match, reuse code, etc.
That said, this doesn't fully work in environments on websites like claude.ai. Perhaps you could have an org-wide Dockerfile or something that opens every time you start a chat which gives it MCP-like capabilities, but that sounds more complicated in many ways than what MCP does. There's also more problems that MCP solves, like with Prompts and Sampling (which are pretty under-used at the moment), and there aren't great analogs for that in the CLI world.
Also developers like you and I might find it trivial to install CLIs, set up auth, and open an agent locally, but this isn't widely true. As an example, at Stainless we have non-engineer folks who ask questions like "who are the most interesting people who have signed up yesterday", and with the right MCP tools wired to claude.ai, claude actually does an excellent job of answer these kinds of questions, all in the browser. This was all without a doubt possible before MCP, but MCP reduces the friction enough, such that it becomes worth-it/easy-enough to develop these tools.
That said, many "business users" like those referenced above interact more with a web UI, and asking them to audit bash/CLI interactions might not always work well.
(disclaimer: I work at Stainless; we're actually exploring ways to make MCP servers more "CLI-like" for API use-cases.)
I want to be the one deciding which CWD to use, which user to run as, whether to see the whole filesystem or to restrict to a chroot, etc.
So far it hasn't been malicious but I've had a number of cases while using cursor where the model has gotten confused and is now editing repos outside the open workspace.
Maybe the answer is still a CLI, but I want a standardized interface for equipping that CLI with handcuffs.
It’s actually surprising just how powerful 1-5 tools can be if you document it well and the llm knows how to pass arguments from other tool responses you had higher up in the thread
Organizations are primarily systems for learning. Substituting machine learning (from a vendor) for human learning inside the team is a bad strategy.
At Stainless we use https://github.com/dgellow/mcp-front to make it easy for anyone on the team (including non-technical folks) to OAuth into a pretty wide variety of tools for their AI chats, using their creds. All proxied on infra we control.
Even our read replica postgres DB is available, just push a button.
MCP allows you to bring tools to agents you don't control. It's awesome, but it isn't the right match for every problem. If you believe the hype of X/LinkedIn you would think that MCP everywhere is going to be the solution.
Bringing tools to your local Claude client is awesome, but there are still challenges with MCP that need to be solved and like all technology, it isn't applicable universally.
Not to mention it's a recipe for burning tokens!
MCP is pretty cool, but the way every AI influencer pivoted to producing MCP glorification posts at the same time has been groan-inducing. I can usually ignore the hype cycles, but I've been bombarded with so much MCP influencer content in the past few months that I feel exhausted every time I see those three letters.
Feels like a monolith would be better
Furthermore, the “docker” part wouldn’t even be the most resource wasteful if you consider the general computational costs of LLMs.
The selling point of MCP servers is that they are composable and plug in into any AI agent. A monolith doesn’t achieve that, unless I’m misunderstanding things.
What I find annoying is that it’s very unpredictable when exactly an LLM will actually invoke an MCP tool function. Different LLM providers’ models behave differently, and even within the same provider different models behave differently.
Eg it’s surprisingly difficult to get an AI agent to actually use a language server to retrieve relevant information about source code, and it’s even more difficult to figure out a prompt for all language server functions that works reliably across all models.
And I guess that’s because of the fuzzy nature of it all.
I’m waiting to see how this all matures, I have the highest expectations of Anthropic with this. OpenAI seems to be doing their own thing (although ChatGPT supposedly will come with MCP support soon). Google’s models appear to be the most eager to actually invoke MCP functions, but they invoke them way too much, in turn causing a lot of context to get wasted / token noise.
What have we come to when losing control in software development is called “awesome”.
MCP is great for: "I would like Claude Desktop/VSCode/Cursor to know about my JIRA tickets". AFAIK Most of the tools that are being used for AI Coding tools are not delivered through MCP.
FastMCP exists because I found the original spec and SDK confusing and complicated. It continues to exist because it turns out there's great utility in curating an agent-native API, especially when so many great dev tools have adopted this client interface.
But the spec is still so young and at such risk of being co-opted by hype (positive and negative). I would invite everyone to participate constructively in improving it.
Lastly: this article is plainly AI generated, as `from mcp import tool` is completely hallucinated. Just some food for thought for the "AI should be able to figure out my complex REST API" crowd that seems well represented here.
https://www.youtube.com/watch?v=m2VqaNKstGc&ab_channel=Laten...
TL;DR If you want to engage with the MCP protocol you can do so here. https://github.com/modelcontextprotocol
You're right, that snippet was ai-generated and I forgot to action one of my todos to fix that snippet. This was negligent on my part, and I hope you'll forgive me.
We're fixing that right now, thank you for the correction!
You may be interested in the verb "to act". If you are an AI, you must have been trained on some sad corporate dataset.
And the more I read this article, I feel like it still is. "The models finally got good enough" is followed by:
> Of course, models and agents are still far from perfect—the better models are pretty slow, context sizes are still limited, and performance degrades when more and more context is present.
> What’s important is that the models are good enough—once models cross that threshold, the overhead of integrating tool use drops dramatically. MCP just showed up right on time.
That's like saying we invented worker ants just in time to help an insane queen.
I searched the article for the word "secure" or "security" and quit reading when I couldn't find it.
[0] https://xeiaso.net/blog/2025/rolling-ladder-behind-us/
[1] https://a16z.com/why-software-is-eating-the-world/
written by a company that sells this "new technology".
woosh!
We actually generate MCP for free (we charge for SDKs), so we're technically not selling, but I don't begrudge GP's comment/sentiment.
[0]https://www.stainless.com/blog/what-we-learned-converting-co... describes some ways in which this is less simple than you think. The "Handling large APIs dynamically" section near the bottom covers the most salient challenge related to converting large APIs to MCP tools, but there's more work to do.
Wow, the idea of what's "new" in software has always been really short, but damn, it's becoming questionable whether anything can be considered new these days.
but also I think the interesting thing is that people didn't jump on MCP immediately after it launched - it seemed to go almost unnoticed until February. Very unusual for AI tech - I guess it took time for servers to get built, clients to support the protocol, and for the protocol itself to go through a few revisions before people really understood the value.
The entire digital consumer economy is built around ownership of the screen real estate, due to a simple reason: ads. Whoever owns the sidebar sets the rules, period. Web2.0 was all about APIs (usually Rest/json) and in hindsight we see a clear distinction on where they’re used: in commercial B2B apps. Conversely, big B2C players shut down the little open they had - Facebook, Gmail removed their XMPP support, and these days Twitter etc even gatekeep content when you’re not signed in or using the app, and aggressively fortify against even basic scraping. When you’re using other clients, you are bypassing their sidebar, meaning their opportunity to deliver ads.
So no, your iOS apps and Twitter are not gonna ”open up” their APIs in any way, not through Rest and not through MCP, simply because it goes directly against their incentives. The exceptions are (1) temporary to ride a hype train, and (2) services you pay money for (but even that is wishful and hypothetical).
By a seller of MCP.
The trouble with MCP is that it requires a trip through an LLM for every transaction. It's not like the ends negotiate a simple protocol so that later queries are cheap. That's a huge cost increase as traffic increases.
In a normal case of "production software", yeah, you would not want to add an LLM in the middle to make an API call. That's silly – just write the code to make the API call if you can do it deterministically.
If you're talking to an LLM in a chat experience, and you want that LLM to go interact with some foreign system (i.e., hit an API), you need _some way_ of teaching the LLM how to make that API call. MCP is one such way, and it's probably the easiest at this point.
Doing it through MCP does introduce some latency due to a proxy server, but it doesn't introduce an additional LLM "in the middle".
(Disclaimer: I work at Stainless. Note that we actually sell SDKs at Stainless; our MCP generator is free.)
Think of it more like a just-in-time protocol generator. The LLM defines how to talk, once, and the rest of the interaction can be optimized. Expensive at first, but potentially cheaper than baking in rigid APIs for every use case.
Still, lots of unknowns, especially around latency, consistency, and cost.