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.
I don't even mind it existing, it's just the way it's presented/documented/talked about like it's some special novel important concept that baffles me, and I think makes it more confusing for developer newcomers (but fine or maybe even helpful for not-particularly-technical but AI-keen/'power' users).
I personally wouldn't be surprised if the http calling abilities of LLMs end up killing MCP, or at least greatly reducing its use. If you train LLMs to start interacting with REST APIs as a great way to make them do more then a lot of the MCP use cases go away.
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.
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.
What you are actually saying is that you don't have a data platform with reporting and prefer using your own product because you designed your user tier to have an MCP server, which is kind of an ourobouros.
Hmm? We have a REST API, CLI, MCP server, and SDKs that all offer the same data/functionality.
MCP is for AI agents, the CLI is for one-off commands by devs who like to poke at things or CI scripts, the TypeScript SDK is for production software written in TypeScript, etc etc.
Was there something we're missing from the "data platform"? A SQL interface?
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.
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.)
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.
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.
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
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.
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.
This. If you are running your agent loop, MCP does nothing.
MCP is an inter-process (or inter-system) communication standard, and it's extremely successful at that. But some people try to shoehorn it into a single system where it makes for a cumbersome fit, like having your service talk to itself via MCP as a subprocess just for the sake of "hey, we have MCP".
If you own your loop AND your business logic lives in the same codebase/process as your agent loop, you don't need MCP at all, period. Just use a good agent framework like PydanticAI, define your tools (and have your framework forward your docstrings/arguments into the context) and you're golden!
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.
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!
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.
As a developer the hype is over the top for sure, but for the average marketer or influencer I can see how it is warranted.
Now if there is a good way to deal with authentication and authorization piece without agents gone wild that would excite me as a dev a lot more at this point.
If you're talking very specifically about MCP, and not about tool calling more generally, and you're just sort of making the point that the standards aren't fully baked or ready for general use --- that you can't yet reliably plug any API into an agent like Claude Code you don't control, then sure. But MCP is the public face of tool calling, and for tool calling generally that's not a real problem: you can make your own arrangements in your own agents, which are truly simple to write.
I think as a developer, as opposed to an IT integrator or something like that, you should be the most excited about this situation.
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.
> 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.
why does the smallest script take seconds to even start then?
Below is a transcript of a "smallest script" which runs in 328 ms total on my machine. And that includes loading an ubuntu OS image, which could be optimized depending on what dependencies the script needs.
Of course, if you're invoking it on a remote cluster, there are many reasons it can talk longer, especially if the cluster has to scale to satisfy the request. But all those reasons are nothing to do with containers specifically - it's things like cluster capacity, node provisioning time, container pull time, network latency, etc. If you architect things properly, you can get the number below + network latency even for a remote cluster invocation.
$ time docker run ubuntu echo hello world
hello world
real 0m0.328s
user 0m0.011s
sys 0m0.010s
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.
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.
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.
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
15x is a rookie multiplier, do you need me to explain how exponential curves work? Within mere months I'll need to start resorting to up-arrow notation to express my value as a developer. And someday I might even start making more money too!
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.
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.)
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.
MCP, in its current form, functions as a fun and profit remote exploit vector, primarily because it exposes AI systems to a wide range of attacks through under-specified security controls, heavy reliance on natural language context, and the ability for untrusted servers to manipulate model behavior. While MCP aims to standardize and simplify tool integration for AI, its half-implemented security features and architectural choices have made it a high-risk protocol, especially when deployed without additional safeguards.
A treasure trove of possibilities: OAuth tokens, almost impossible to build alarms for outside of transmission rates (what are you running your own LLM? How about a meta MCP for twice the API calls?) , assumed trusted input, the server can inject malicious instructions via tool descriptions, leading to prompt injection, data exfiltration, or even remote code execution, sometimes without any explicit tool use by the user.
> 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 tried using MCP to run some custom functions from ollama & openwebui. The experience was not great.
Doing anything with LLM feels more like arguing than debugging, but this was really surreal: I can see the LLM calling the function with the parameters I requested, but then instead of giving me the returned value, the LLM always pretends it doesn't know the function and tries to guess what the result should be based on its name.
The protocol itself is really weird, almost based on standards but not quite. It was made by one vendor to fix one problem. It has the benefit of existing, but I don't know if it is worthy of any praise?
Unless you are running DeepSeek/OpenAI/Anthropic models, I suspect your LLM will struggle with the complexity. That being said, except for Puppeteer and usebrowser, every MCP I have tried was complete sh+t. As: doesn't really work and will confuse the hell out of your LLM.
I don't know what model you're using through ollama but a lot of people pick up a 4b model and expect it to be ChatGPT when it's like 0.2% of the size. 4b models are mostly toys imo. The latest generation of 8b models are sometimes useful, but often still laughably stupid. 14b starts to have potential, 30b are pretty good.
But remember, the hosted frontier models are still gigantic compared to these, and still make stupid mistakes all the time.
MCP still feels so early. It's getting better - we went from "set up `npx` on your system and edit this JSON file in an obscure directory" to "set the name and URL of your MCP server" in claude.ai. But you're right, even knowing how to find a URL for the MCP server is a tall order for most.
I wonder what the optimal form factor is. Like what if your AI could /suggest/ connecting with some service? Like your AI is browsing a site and can discover the "official" MCP server (like via llms.txt). It then shows a prompt to the user - "can I access your data via X provider?". you click "yes", then it does the OAuth redirect and can immediately access the necessary tools. Also being able to give specific permissions via the OAuth flow would be really nice.
It's interesting how quickly my brain developed an AI detector for written language (this blog post screams ChatGPT).
I wonder if it will stay effective, or if LLMs figure out a way around it? Or maybe it's just that this is the new way that technical blog posts are written, sort of how nearly all press releases feel univocal.
Yeah I wonder just how much MCP is needed when the models seem fine at making REST requests as is, especially if there's an OpenAPI or similar spec available.
I'm inclined to agree with the conclusions of the article. A lot of people make good points here about manual tooling (and I personally prefer this myself) but: Worse Is Better.
The MCP way of accessing extra functionality and context will be more accessible to more people, with "recipes" they can easily set up once (or rarely) and thereafter continue to reap the benefits of enhanced LLM operation. There's already a huge arms race in the "orchestrator" space for tools to support MCP plus model routers plus Ollama local plus focused context RAG. I'm pretty sure we will look back at 2025 as a Great Leap Forward (yes, including the casualties implied in that reference) for LLM effectiveness.
It's going to be a whole new Eternal September[0] except for LLM usage this time. And a good number of the new "normies" this time are going to be Pointy-Haired Bosses.
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).
Today almost every public MCP server targets B2B workflows like GitHub, Jira, Linear, Slack, and similar developer or workplace tools.
In a recent talk, Andrej Karpathy argued that “LLMs are the new operating system.” If that analogy holds, the only “apps” we've built so far live in the enterprise quadrant of that OS.
I expect consumer facing MCP experiences to follow soon. I’m not yet sure what they’ll look like, perhaps games or other interactive content but the infrastructure is falling into place: OpenAI has said ChatGPT will support custom MCP connectors, ElevenLabs’ 11AI already ships with MCP integration, and Claude has added remote MCP support. As those channels reach mainstream users, everyday LLM users will start asking for richer experience and MCP is how developers will deliver them.
MCP is currently too difficult to setup and too complicated for consumers to understand. Once somebody big enough figures out distribution and integration a la the App Store, and the market starts to understand MCP integrations as extensions your AI client can orchestrate across (do one thing in App A, another in App B, etc all with a single prompt), it’ll be off to the races.
MCP is too simple actually. You just use one command? I think the problem is that most MCP "servers" do not work. They are either too early/alpha, not well supported, too limited, etc. Everyone is trying to write blog post but not actually do the product development.
This is true. Most of the MCP servers I have seen are also some of the worst examples of software I have ever seen. Given the people who are attracted to it, it's likely they're all vibe coded.
In some ways MCP is like the next evolution of API over HTTP.
We've exposed our APIs as SOAP endpoints. These were not well suited to web based clients, leading to the development of "RESTful" JSON endpoints. As web clients became more complex, GraphQL arose as a solution to some of the problems encountered. Maybe MCP is the next step.
I don't mean that MCP will supersede these protocols. My company exposes our endpoints as SOAP, REST, and GraphQL still as they fit different use cases and customer bases. We are piloting an MCP version to see how that goes now.
It is fun to work on something new and play with agents to see how they consume our endpoints in this form. I think there is a lot of potential.
Unecessary complication. LLM Can call tools without MCP 100% fine. You don't need a Stateful SSE JSORPC Meshedup server running APIs rebraneded as tools at somewhere on the cloud .
I think there's going to be a lot of places where you want the middleare that's only exposing a sub-set of apis. and the Ideas that you copy some URL, put it in your LLM Client, and then it magically gets all the tools/endpoints available to you, and you start interacting with it, simplifies the process greatly for a lot of users. No swagger, no http post, body vs params, etc....just play with with your prompt sentance until you get it to do what you want.
Thats all part of how you code the LLMHost Backend and Frontend.
I build several MCP and MCP-Less tool calling agents using autogen and they can ask the user permission. That is nothing to do with MCP at all.
Look into AutoGen by microsoft or if you want more basic , learn how tool calling in LLMs work.
The reason for MCP is that you get better results with optimized prompts rather than using existing API docstrings. So everybody is going to end up adopting it in some shape or form.
It is a general concept, MCP itself is nothing special, it is that just that Anthropic formalized the observation first.
Tool call = API call + instructions for LLM
So vendors who provide APIs are going to write prompts, add a thin wrapper and out goes MCP. Or you create your own instructions and wrap in MCP to optimize your own workflows.
I'm still getting the hang of this but Apple's Foundation Models framework [1] (the one recently announced in WWDC) follows this protocol, correct? Does this mean that MCP, as a protocol, can actually take on different forms depending on how platforms/OSes want to allow their users to integrate with LLMs?
Apple’s Foundation Models support “tool calling”, but that is not MCP. It is a different approach that those interested in MCP should check out, via Swift protocols and macros. Notably I think the structured Swift marshalling is cool. An understated part of WWDC this year.
One of the major miss right now seems to be in tool calling specs, you specify function names, description, inputs but not outputs. I believe with reasoning models planning things, it would be important to understand output format, descriptions as well?
The advice anthropic gives in building agents is to ditch the abstractions like agent frameworks etc and just code it yourself. I believe its also applicable to MCP to same degree?
I have various scripts that I tell claude about in all my CLAUDE.md files and it is successful at using them.
Am I missing out on something by not using an MCP? I guess I wouldn't have to paste it into every CLAUDE.md but is there any other noticeable advantage?
You don't need to aspire to use "MCP", but rather select some MCP servers that will be useful for you.
MCP servers basically expose pieces of the web/data that your LLM client has not been trained on. Maybe some private APIs, or internal data that isn't part of training data sets. Real-time data is another good use case.
I personally use the Kagi MCP server (allows an LLM client to execute searches against the Kagi search engine), and stochastic thinking/sequential thinking (some alternate thought patterns that help models escape the "valley of optimization" problem).
You can't tell Claude.md to "use the Kagi search engine"...it doesn't have an API key to do that. The MCP server basically just exposes the API. You're right, it's a lot less exciting than people make it sound. The future possibilities are where the excitement is at imo.
I'm excited about MCP more from a developer side, than from a user side. It really does feel like the first week of mobile apps still. Will it "revolutionize everything"? No, just like mobile apps didn't solve every problem (and made some worse).
I can see the value if I'm connecting to MCPs other people have written. Or sharing MCPs for a team.
As a solo dev though, I don't know of any MCPs that are really valuable to me that aren't more valuable exposed as a commandline tool. I have an "imagine" tool that creates/edits images and audio with various services available to it and guidance on how to use it, I have a "think" command that allows claude or (scripts claude or I write) to use different LLMs for different things and with a library of prompts for specialized tasks, etc. I don't have a kagi command but tbh that sounds useful and I may write a little wrapper for it so I can have it from the terminal too, rather than use an MCP.
(None of this is a complaint about MCP btw - just not sure if I'm missing anything that would make it also useful to me right now.)
Something I am interested in, is if claude code would do better with access to a language server. I love how claude produces most of it's diffs by string replace, rather than producing a diff and using an "apply model" like cursor does; but it seems it would be better off if it could "go to definition", "find references", and "rename" rather than use grep etc.
I do see one project in the list you linked to that seems like it's going for that. Although again I'm not sure if that's better than having a language server cli available.
I don't think you're missing anything. My day-to-day workflow hardly involves MCP, to be honest. I prefer custom tooling (and command-line tools) for most of my development work as well.
The language server MCPs are interesting, but I am not sure how to incorporate them into my Neovim workflow yet.
Obligatory note - if you're a backend developer, you do not need MCP. MCP is just tool/function calling. It has been around for a lot longer now. MCP is only needed if you need something to integrate with the frontend chat applications. If you need to automate something with LLMs, you do not need MCP. Right now, it's just the new cool buzzword to throw around.
You don't need to use RESTful JSON to get two computers to communicate with eachother, either. You can just implement your own thing, and if someone wants to interface with it, they can write their own adapter! Who needs decades of battle tested tooling? This can be a Not Invented Here safe-space. Why not.
You think you're being sarcastic, but you don't get the point - implementing 3rd party Saas tools in your Saas backend means one MCP server per service, which can quickly add up, not to mention is bad design. I'm not opposed MCP protocol itself, it's just not needed if you're providing a Saas that talks to many vendors, you don't necessarily need MCP for it.
AI coding tools have been improving/updating like craze over the past six months.
Honest question: what are some of the AI Dev tools (I prefer command line) that have leapt ahead recently, with good tool/function calling? Do you (or others) have a clear preference for Claude Code vs aider vs some other alternative? Or is the meta shifting toward the orchestrators like Taskmaster and Puppeteer?
I meant to say that MCP is just a wrapper around good old function/tool calling, it's not a new superpower by itself. So, if you're designing a Saas, you don't need to use MCP yourself, you can just use good old function/tool calling.
To answer your specific queries, I use the autocomplete in VS Code and I directly chat with ChatGPT-o3 for advanced problems because my background is in Elixir and most models that are hyped up fail badly with Elixir. I'm always a huge fan of o3 as it can solve the most complex problems I throw at it..
Yes, but if I'm implementing "good old function/tool calling" today, why would I not implement it as MCP? I suppose it complicates things? MCP, in addition to being tooling endpoints, would also open up my software to a rapidly growing ecosystem that requires minimal additional work.
AND I can still use those same endpoints as tools. What would be the argument for "you don't need MCP when implementing new stuff"?
I think you're confusing implementing MCP for your own software offering/Saas, which is different and I think you should do it, vs implementing third party MCP servers into a Saas backend, which is what I'm talking about.
Because, to do the latter, the standard design is one hosted MCP server per vendor. If you use more than even 5, that's a lot of servers to maintain in a Saas context.
This is a really nifty CLI tool that lets you fit an LLM into a shell environment. Check out examples like piping context into and out of the `llm` command.
It isn't hard to see why. I had a really hard time wrapping my head around why MCP was necessary and useful but I tried using* one recently and it's remarkable how big the gap between just being able to reply and being able to interact is.
I'm curious to hear which one you forked and found useful? I've looked at the awesome MCP list but was a bit struck by decision paralysis when trying to figure out what to try, so I ended up just not trying any.
> Maybe it was because OpenAI announced they would start to support MCP in their tools ? [0]
Author here, I assumed this would be the reason too, but the timelines don't really match up. Momentum was already strong by the time that OpenAI adopted it. And it's an educated guess on my part, but that's also probably why they adopted it in the first place.
Some sources point to the MCP talk at AI Engineer being the turning point (and the timelines match up), but like with all viral studies the answer is pretty complicated and multi-faceted, rather than having a single cause.
> Perhaps I'm being too harsh with the author, but this article definitely gives me vibes of "AI slop".
I think it's fine to be harsh! I don't like AI slop either but unfortunately this article was mostly handwritten, so it's just a skill-issue on my part. I'll try to do better next time
>Instead of serving 200 standalone tools, we serve three meta‑tools and let the LLM discover endpoints at run‑time.
>list_api_endpoints lets the model search the catalog (“what can I do with counterparties?”)
>get_api_endpoint_schema pulls the JSON‑schema for any route it finds
>invoke_api_endpoint executes that route with user‑supplied params
>This approach allows the LLM to dynamically discover, learn about, and invoke endpoints as needed, without requiring the entire API schema to be loaded into its context window at once. The LLM will use these tools together to search for, look up, and call endpoints on demand.
Congratulation, you have reinvented Microsoft COM, IUnknown, OLE, IDispatch, and ActiveX for LLMS!
I'm not being sarcastic or criticizing, it's actually a good idea! Just not new.
I'm also not saying there aren't better approaches, like "NeLLM": taking the NeWS approach to LLMs, where MCP is more like "X-LLM": taking the X-Windows approach to LLMs.
Sending JSON data back and forth between a Node based orchestrator and an LLM is one thing, all well and find and traditional, but why not send and evaluate JavaScript code itself? Both Node (or even a secure Node isolate) and the LLM can generate and evaluate JavaScript quite well thank you, and it's a hell of a lot more powerful and concise and extensible that a fixed JSON protocol, for the exact same reason that NeWS is a hell of a lot more powerful and concise and extensible than the fixed X-Windows protocol.
>I agree they should learn from DLLs, gRPC, SOAP, IDL, dCOM, etc.
>But they should also learn from how NeWS was better than X-Windows because instead of a fixed protocol, it allowed you to send executable PostScript code that runs locally next to the graphics hardware and input devices, interprets efficient custom network protocols, responds to local input events instantly, implements a responsive user interface while minimizing network traffic.
>For the same reason the client-side Google Maps via AJAX of 20 years ago was better than the server-side Xerox PARC Map Viewer via http of 32 years ago.
>I felt compelled to write "The X-Windows Disaster" comparing X-Windows and NeWS, and I would hate if 37 years from now, when MCP is as old as X11, I had to write about "The MCP-Token-Windows Disaster", comparing it to a more efficient, elegant, underdog solution that got out worse-is-bettered. It doesn't have to be that way!
>It would be "The World's Second Fully Modular Software Disaster" if we were stuck with MCP for the next 37 years, like we still are to this day with X-Windows.
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.
I don't even mind it existing, it's just the way it's presented/documented/talked about like it's some special novel important concept that baffles me, and I think makes it more confusing for developer newcomers (but fine or maybe even helpful for not-particularly-technical but AI-keen/'power' users).
I personally wouldn't be surprised if the http calling abilities of LLMs end up killing MCP, or at least greatly reducing its use. If you train LLMs to start interacting with REST APIs as a great way to make them do more then a lot of the MCP use cases go away.
HATEOAS FTW
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.
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.
Ditto on the postgres MCPs vs the standard pg cli - seems to prefer the cli. Which is fine enough for me.
What you are actually saying is that you don't have a data platform with reporting and prefer using your own product because you designed your user tier to have an MCP server, which is kind of an ourobouros.
Hmm? We have a REST API, CLI, MCP server, and SDKs that all offer the same data/functionality.
MCP is for AI agents, the CLI is for one-off commands by devs who like to poke at things or CI scripts, the TypeScript SDK is for production software written in TypeScript, etc etc.
Was there something we're missing from the "data platform"? A SQL interface?
(I work with yjp20)
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.
xkcd 927, every single time
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.
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.)
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.
Are there any tools that automate using containers for this?
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.
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
MCP is JDBC for LLM
I’ve managed to do the same thing!
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'm doing the same thing now (with Slack as a medium of interaction with the agent) --- but not with MCP, just with straight up tool call APIs.
How many tools does your agent have access to?
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.
Just 5 or 6. I'm just using the OpenAI tool call API for it; I own the agent (more people should!) so MCP doesn't do much for me.
This. If you are running your agent loop, MCP does nothing.
MCP is an inter-process (or inter-system) communication standard, and it's extremely successful at that. But some people try to shoehorn it into a single system where it makes for a cumbersome fit, like having your service talk to itself via MCP as a subprocess just for the sake of "hey, we have MCP".
If you own your loop AND your business logic lives in the same codebase/process as your agent loop, you don't need MCP at all, period. Just use a good agent framework like PydanticAI, define your tools (and have your framework forward your docstrings/arguments into the context) and you're golden!
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.
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.
IIRC they talk about it 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
(author here)
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!
I believe that MCP is a bit over-marketed.
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!
> I believe that MCP is a bit over-marketed
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 never fails that if you look at their title it's: VP of XYZ at something.ai as well!
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.
When the crypto bubble burst, the fad chasers had to go somewhere. It is a tale as old as time.
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.
As a developer the hype is over the top for sure, but for the average marketer or influencer I can see how it is warranted.
Now if there is a good way to deal with authentication and authorization piece without agents gone wild that would excite me as a dev a lot more at this point.
If you're talking very specifically about MCP, and not about tool calling more generally, and you're just sort of making the point that the standards aren't fully baked or ready for general use --- that you can't yet reliably plug any API into an agent like Claude Code you don't control, then sure. But MCP is the public face of tool calling, and for tool calling generally that's not a real problem: you can make your own arrangements in your own agents, which are truly simple to write.
I think as a developer, as opposed to an IT integrator or something like that, you should be the most excited about this situation.
Tool-calling is pretty huge, but MCP (a standard for calling a tool over HTTP) is way over-hyped, and neither here nor there really.
MCP means you can get arbitrary tool calling from existing shrink-wrapped agents, like Claude Code, without writing your own agent. It's a big deal.
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
Feels like a monolith would be better
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.
> 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.
why does the smallest script take seconds to even start then?
Below is a transcript of a "smallest script" which runs in 328 ms total on my machine. And that includes loading an ubuntu OS image, which could be optimized depending on what dependencies the script needs.
Of course, if you're invoking it on a remote cluster, there are many reasons it can talk longer, especially if the cluster has to scale to satisfy the request. But all those reasons are nothing to do with containers specifically - it's things like cluster capacity, node provisioning time, container pull time, network latency, etc. If you architect things properly, you can get the number below + network latency even for a remote cluster invocation.
That is not normal. Small scripts should launch in milliseconds, not several seconds.
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.
Remote MCPs should resolve some of this
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.
You just said the same thing three times and didn't explain why.
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.
Agree, but I think we should hold those Apps to a higher bar. Chat interfaces are not a replacement for good UX.
Have you tried holding Jira to a higher bar? I don't know how. I'd rather somebody just layered a conversational UX over it.
> … agents you don't control. It's awesome …
What have we come to when losing control in software development is called “awesome”.
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.
WOW talk about quoting out of context.
Do you get mad at IDE plugins that let you extend software that you don't control?
Another hyped/clickbait headline about a "new technology" that will "transform everything"
written by a company that sells this "new technology".
I just saw some job postings asking for 8+ years experience in MCP
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
Not a problem for the 15x programmer.
15x is a rookie multiplier, do you need me to explain how exponential curves work? Within mere months I'll need to start resorting to up-arrow notation to express my value as a developer. And someday I might even start making more money too!
>> >> Heck, even MCP itself isn’t new—the spec was released by Anthropic in November
woosh!
You need 10+ for senior though.
1 year for a human is like 10 in AI-years.
I think you're joking but if not I'd love to see one!
How does it sell a basic protocol that anyone can use?
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.
It's clearly a plot by Big MCP to sell us more MCP. /s
> At Stainless, we’re betting it’s here to stay.
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.
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.)
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.
Except that that's the easy path to implement.
MCP, in its current form, functions as a fun and profit remote exploit vector, primarily because it exposes AI systems to a wide range of attacks through under-specified security controls, heavy reliance on natural language context, and the ability for untrusted servers to manipulate model behavior. While MCP aims to standardize and simplify tool integration for AI, its half-implemented security features and architectural choices have made it a high-risk protocol, especially when deployed without additional safeguards.
A treasure trove of possibilities: OAuth tokens, almost impossible to build alarms for outside of transmission rates (what are you running your own LLM? How about a meta MCP for twice the API calls?) , assumed trusted input, the server can inject malicious instructions via tool descriptions, leading to prompt injection, data exfiltration, or even remote code execution, sometimes without any explicit tool use by the user.
Unfortunately, the "protocol" doesn't have any emphasis on security so far, its all a repeat of HTTP -> HTTPS.
However I feel the tooling built around MCP has been a lot and makes your work easier.
The perfect use today would be using a locally running MCP servers for execution of code[1], manipulation of local files etc.
1. CodeRunner - Generate and run LLM code locally on Apple containers (https://github.com/BandarLabs/coderunner) (I am one of the authors)
Okay. I guess someone could have said the same thing at the dawn of the microcomputer era, too. Get back to us when the world melts down.
I think "if you're not doing anything wrong you have nothing to hide" doesn't apply to B2B services.
> 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 tried using MCP to run some custom functions from ollama & openwebui. The experience was not great.
Doing anything with LLM feels more like arguing than debugging, but this was really surreal: I can see the LLM calling the function with the parameters I requested, but then instead of giving me the returned value, the LLM always pretends it doesn't know the function and tries to guess what the result should be based on its name.
The protocol itself is really weird, almost based on standards but not quite. It was made by one vendor to fix one problem. It has the benefit of existing, but I don't know if it is worthy of any praise?
Unless you are running DeepSeek/OpenAI/Anthropic models, I suspect your LLM will struggle with the complexity. That being said, except for Puppeteer and usebrowser, every MCP I have tried was complete sh+t. As: doesn't really work and will confuse the hell out of your LLM.
I don't know what model you're using through ollama but a lot of people pick up a 4b model and expect it to be ChatGPT when it's like 0.2% of the size. 4b models are mostly toys imo. The latest generation of 8b models are sometimes useful, but often still laughably stupid. 14b starts to have potential, 30b are pretty good.
But remember, the hosted frontier models are still gigantic compared to these, and still make stupid mistakes all the time.
I mean, LLMs you can run on ollama are usually pretty bad ones.
MCP still feels so early. It's getting better - we went from "set up `npx` on your system and edit this JSON file in an obscure directory" to "set the name and URL of your MCP server" in claude.ai. But you're right, even knowing how to find a URL for the MCP server is a tall order for most.
I wonder what the optimal form factor is. Like what if your AI could /suggest/ connecting with some service? Like your AI is browsing a site and can discover the "official" MCP server (like via llms.txt). It then shows a prompt to the user - "can I access your data via X provider?". you click "yes", then it does the OAuth redirect and can immediately access the necessary tools. Also being able to give specific permissions via the OAuth flow would be really nice.
It's interesting how quickly my brain developed an AI detector for written language (this blog post screams ChatGPT).
I wonder if it will stay effective, or if LLMs figure out a way around it? Or maybe it's just that this is the new way that technical blog posts are written, sort of how nearly all press releases feel univocal.
9 times out of 10 my Claude Code is using a bash script before I hook up an MCP to it.
- less tokens required in context (CLAUDE.md vs CLAUDE.md + MCP bloat per request)
- native agent tooling, relying on Bash(my-script params)
- less black box (you & the coding agent can read the scripts)
MCPs are often wrapping restful apis. Turns out agents can use those just fine.
Yeah I wonder just how much MCP is needed when the models seem fine at making REST requests as is, especially if there's an OpenAPI or similar spec available.
I'm inclined to agree with the conclusions of the article. A lot of people make good points here about manual tooling (and I personally prefer this myself) but: Worse Is Better.
The MCP way of accessing extra functionality and context will be more accessible to more people, with "recipes" they can easily set up once (or rarely) and thereafter continue to reap the benefits of enhanced LLM operation. There's already a huge arms race in the "orchestrator" space for tools to support MCP plus model routers plus Ollama local plus focused context RAG. I'm pretty sure we will look back at 2025 as a Great Leap Forward (yes, including the casualties implied in that reference) for LLM effectiveness.
It's going to be a whole new Eternal September[0] except for LLM usage this time. And a good number of the new "normies" this time are going to be Pointy-Haired Bosses.
[0] https://en.wikipedia.org/wiki/Eternal_September
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).
Today almost every public MCP server targets B2B workflows like GitHub, Jira, Linear, Slack, and similar developer or workplace tools.
In a recent talk, Andrej Karpathy argued that “LLMs are the new operating system.” If that analogy holds, the only “apps” we've built so far live in the enterprise quadrant of that OS.
I expect consumer facing MCP experiences to follow soon. I’m not yet sure what they’ll look like, perhaps games or other interactive content but the infrastructure is falling into place: OpenAI has said ChatGPT will support custom MCP connectors, ElevenLabs’ 11AI already ships with MCP integration, and Claude has added remote MCP support. As those channels reach mainstream users, everyday LLM users will start asking for richer experience and MCP is how developers will deliver them.
So far I am thinking of following uses for MCP:
* External tool calls.
* Generating status documents and other memories.
* Calling a planner/Prolog... to create a plan.
* You can wrap another specialized agent into the MCP.....
* You can call the tool yourself (at least in VSCode) with #MCPtool for precise tool use or just to generate context.
MCP is currently too difficult to setup and too complicated for consumers to understand. Once somebody big enough figures out distribution and integration a la the App Store, and the market starts to understand MCP integrations as extensions your AI client can orchestrate across (do one thing in App A, another in App B, etc all with a single prompt), it’ll be off to the races.
MCP is too simple actually. You just use one command? I think the problem is that most MCP "servers" do not work. They are either too early/alpha, not well supported, too limited, etc. Everyone is trying to write blog post but not actually do the product development.
This is true. Most of the MCP servers I have seen are also some of the worst examples of software I have ever seen. Given the people who are attracted to it, it's likely they're all vibe coded.
In some ways MCP is like the next evolution of API over HTTP.
We've exposed our APIs as SOAP endpoints. These were not well suited to web based clients, leading to the development of "RESTful" JSON endpoints. As web clients became more complex, GraphQL arose as a solution to some of the problems encountered. Maybe MCP is the next step.
I don't mean that MCP will supersede these protocols. My company exposes our endpoints as SOAP, REST, and GraphQL still as they fit different use cases and customer bases. We are piloting an MCP version to see how that goes now.
It is fun to work on something new and play with agents to see how they consume our endpoints in this form. I think there is a lot of potential.
Unecessary complication. LLM Can call tools without MCP 100% fine. You don't need a Stateful SSE JSORPC Meshedup server running APIs rebraneded as tools at somewhere on the cloud .
I think there's going to be a lot of places where you want the middleare that's only exposing a sub-set of apis. and the Ideas that you copy some URL, put it in your LLM Client, and then it magically gets all the tools/endpoints available to you, and you start interacting with it, simplifies the process greatly for a lot of users. No swagger, no http post, body vs params, etc....just play with with your prompt sentance until you get it to do what you want.
(edit: sorry, I responded to wrong thread.)
Yeah that but - Why SSE? - Why JsonRPC - Why Statefulness
REST based Tool Call Server would work 100% fine. Now auth have to be redone for those specifically.
And for users of MCP Tools - they are sending a lot of their information to whatever service they are running - that they have never control of
For developer it is not necessary and security nightmare if you use someone's MCP service or run your own.
For users , it is a privacy nightmare .
> LLM Can call tools without MCP 100% fine.
but can the LLM host UI ask me for permission (in an outside-of-LLM domain) if the LLM wants to call API foo.bar ?
Thats all part of how you code the LLMHost Backend and Frontend. I build several MCP and MCP-Less tool calling agents using autogen and they can ask the user permission. That is nothing to do with MCP at all.
Look into AutoGen by microsoft or if you want more basic , learn how tool calling in LLMs work.
Sounds like NPM:)
The reason for MCP is that you get better results with optimized prompts rather than using existing API docstrings. So everybody is going to end up adopting it in some shape or form.
It is a general concept, MCP itself is nothing special, it is that just that Anthropic formalized the observation first.
Tool call = API call + instructions for LLM
So vendors who provide APIs are going to write prompts, add a thin wrapper and out goes MCP. Or you create your own instructions and wrap in MCP to optimize your own workflows.
For pure OpenAPI APIs, why wouldn't you just update your API docstrings? Or maybe add a new attribute to the OpenAPI spec for LLM prompts?
I definitely see the value if you have a non standard API or undocumented API you wanted to expose.
And I see value in the resources and prompts parts of MCP, since they can offer clients more functionality that would be hard to put into an API spec.
I'm still getting the hang of this but Apple's Foundation Models framework [1] (the one recently announced in WWDC) follows this protocol, correct? Does this mean that MCP, as a protocol, can actually take on different forms depending on how platforms/OSes want to allow their users to integrate with LLMs?
[1] https://developer.apple.com/documentation/foundationmodels
Apple’s Foundation Models support “tool calling”, but that is not MCP. It is a different approach that those interested in MCP should check out, via Swift protocols and macros. Notably I think the structured Swift marshalling is cool. An understated part of WWDC this year.
One of the major miss right now seems to be in tool calling specs, you specify function names, description, inputs but not outputs. I believe with reasoning models planning things, it would be important to understand output format, descriptions as well?
The advice anthropic gives in building agents is to ditch the abstractions like agent frameworks etc and just code it yourself. I believe its also applicable to MCP to same degree?
I have various scripts that I tell claude about in all my CLAUDE.md files and it is successful at using them.
Am I missing out on something by not using an MCP? I guess I wouldn't have to paste it into every CLAUDE.md but is there any other noticeable advantage?
You don't need to aspire to use "MCP", but rather select some MCP servers that will be useful for you.
MCP servers basically expose pieces of the web/data that your LLM client has not been trained on. Maybe some private APIs, or internal data that isn't part of training data sets. Real-time data is another good use case.
This list has a lot of ideas:
https://github.com/modelcontextprotocol/servers?tab=readme-o...
I personally use the Kagi MCP server (allows an LLM client to execute searches against the Kagi search engine), and stochastic thinking/sequential thinking (some alternate thought patterns that help models escape the "valley of optimization" problem).
You can't tell Claude.md to "use the Kagi search engine"...it doesn't have an API key to do that. The MCP server basically just exposes the API. You're right, it's a lot less exciting than people make it sound. The future possibilities are where the excitement is at imo.
I'm excited about MCP more from a developer side, than from a user side. It really does feel like the first week of mobile apps still. Will it "revolutionize everything"? No, just like mobile apps didn't solve every problem (and made some worse).
I can see the value if I'm connecting to MCPs other people have written. Or sharing MCPs for a team.
As a solo dev though, I don't know of any MCPs that are really valuable to me that aren't more valuable exposed as a commandline tool. I have an "imagine" tool that creates/edits images and audio with various services available to it and guidance on how to use it, I have a "think" command that allows claude or (scripts claude or I write) to use different LLMs for different things and with a library of prompts for specialized tasks, etc. I don't have a kagi command but tbh that sounds useful and I may write a little wrapper for it so I can have it from the terminal too, rather than use an MCP.
(None of this is a complaint about MCP btw - just not sure if I'm missing anything that would make it also useful to me right now.)
Something I am interested in, is if claude code would do better with access to a language server. I love how claude produces most of it's diffs by string replace, rather than producing a diff and using an "apply model" like cursor does; but it seems it would be better off if it could "go to definition", "find references", and "rename" rather than use grep etc.
I do see one project in the list you linked to that seems like it's going for that. Although again I'm not sure if that's better than having a language server cli available.
I don't think you're missing anything. My day-to-day workflow hardly involves MCP, to be honest. I prefer custom tooling (and command-line tools) for most of my development work as well.
The language server MCPs are interesting, but I am not sure how to incorporate them into my Neovim workflow yet.
That Google Trends curve does/will look a bit like Smart Contracts.
> That Google Trends curve does/will look a bit like Smart Contracts.
What do you mean? The curve for "Small Contract" is mostly flat compared to MCP: https://trends.google.com/trends/explore?q=Smart%20Contract,...
So sick of this. LLMs are just a new paradigm on search.
Old Google: I don’t know the answer, but here are some links that might help you - with ads.
LLMs: I confidently know the answer, but I could be wrong and frequently am. No ads yet, but they are coming.
With MCP I can call tools with my own software too without having to use an LLM
Obligatory note - if you're a backend developer, you do not need MCP. MCP is just tool/function calling. It has been around for a lot longer now. MCP is only needed if you need something to integrate with the frontend chat applications. If you need to automate something with LLMs, you do not need MCP. Right now, it's just the new cool buzzword to throw around.
You don't need to use RESTful JSON to get two computers to communicate with eachother, either. You can just implement your own thing, and if someone wants to interface with it, they can write their own adapter! Who needs decades of battle tested tooling? This can be a Not Invented Here safe-space. Why not.
You think you're being sarcastic, but you don't get the point - implementing 3rd party Saas tools in your Saas backend means one MCP server per service, which can quickly add up, not to mention is bad design. I'm not opposed MCP protocol itself, it's just not needed if you're providing a Saas that talks to many vendors, you don't necessarily need MCP for it.
Also, MCP is relatively new, not "bAtTlE tEstEd"
AI coding tools have been improving/updating like craze over the past six months.
Honest question: what are some of the AI Dev tools (I prefer command line) that have leapt ahead recently, with good tool/function calling? Do you (or others) have a clear preference for Claude Code vs aider vs some other alternative? Or is the meta shifting toward the orchestrators like Taskmaster and Puppeteer?
I meant to say that MCP is just a wrapper around good old function/tool calling, it's not a new superpower by itself. So, if you're designing a Saas, you don't need to use MCP yourself, you can just use good old function/tool calling.
To answer your specific queries, I use the autocomplete in VS Code and I directly chat with ChatGPT-o3 for advanced problems because my background is in Elixir and most models that are hyped up fail badly with Elixir. I'm always a huge fan of o3 as it can solve the most complex problems I throw at it..
Yes, but if I'm implementing "good old function/tool calling" today, why would I not implement it as MCP? I suppose it complicates things? MCP, in addition to being tooling endpoints, would also open up my software to a rapidly growing ecosystem that requires minimal additional work.
AND I can still use those same endpoints as tools. What would be the argument for "you don't need MCP when implementing new stuff"?
I think you're confusing implementing MCP for your own software offering/Saas, which is different and I think you should do it, vs implementing third party MCP servers into a Saas backend, which is what I'm talking about.
Because, to do the latter, the standard design is one hosted MCP server per vendor. If you use more than even 5, that's a lot of servers to maintain in a Saas context.
This is a really nifty CLI tool that lets you fit an LLM into a shell environment. Check out examples like piping context into and out of the `llm` command.
https://github.com/simonw/llm
It isn't hard to see why. I had a really hard time wrapping my head around why MCP was necessary and useful but I tried using* one recently and it's remarkable how big the gap between just being able to reply and being able to interact is.
*after forking and modifying it for my use case
I'm curious to hear which one you forked and found useful? I've looked at the awesome MCP list but was a bit struck by decision paralysis when trying to figure out what to try, so I ended up just not trying any.
yeah current AIs are surprisingly good at figuring out which tools to call and how to call them!
> 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.
Maybe it was because OpenAI announced they would start to support MCP in their tools ? [0]
Perhaps I'm being too harsh with the author, but this article definitely gives me vibes of "AI slop".
[0] - https://techcrunch.com/2025/03/26/openai-adopts-rival-anthro...
> Maybe it was because OpenAI announced they would start to support MCP in their tools ? [0]
Author here, I assumed this would be the reason too, but the timelines don't really match up. Momentum was already strong by the time that OpenAI adopted it. And it's an educated guess on my part, but that's also probably why they adopted it in the first place.
Some sources point to the MCP talk at AI Engineer being the turning point (and the timelines match up), but like with all viral studies the answer is pretty complicated and multi-faceted, rather than having a single cause.
> Perhaps I'm being too harsh with the author, but this article definitely gives me vibes of "AI slop".
I think it's fine to be harsh! I don't like AI slop either but unfortunately this article was mostly handwritten, so it's just a skill-issue on my part. I'll try to do better next time
So MCP is basically: - getTools - executeTool
?
Not when prompt injection and other fairly trivial security issues hasn’t been solved
should kill off sdk generators too
It's not.
>Instead of serving 200 standalone tools, we serve three meta‑tools and let the LLM discover endpoints at run‑time.
>list_api_endpoints lets the model search the catalog (“what can I do with counterparties?”)
>get_api_endpoint_schema pulls the JSON‑schema for any route it finds
>invoke_api_endpoint executes that route with user‑supplied params
>This approach allows the LLM to dynamically discover, learn about, and invoke endpoints as needed, without requiring the entire API schema to be loaded into its context window at once. The LLM will use these tools together to search for, look up, and call endpoints on demand.
Congratulation, you have reinvented Microsoft COM, IUnknown, OLE, IDispatch, and ActiveX for LLMS!
I'm not being sarcastic or criticizing, it's actually a good idea! Just not new.
https://news.ycombinator.com/item?id=12975257
https://news.ycombinator.com/item?id=20266627
https://news.ycombinator.com/item?id=29593432
https://news.ycombinator.com/item?id=19837817
I'm also not saying there aren't better approaches, like "NeLLM": taking the NeWS approach to LLMs, where MCP is more like "X-LLM": taking the X-Windows approach to LLMs.
Sending JSON data back and forth between a Node based orchestrator and an LLM is one thing, all well and find and traditional, but why not send and evaluate JavaScript code itself? Both Node (or even a secure Node isolate) and the LLM can generate and evaluate JavaScript quite well thank you, and it's a hell of a lot more powerful and concise and extensible that a fixed JSON protocol, for the exact same reason that NeWS is a hell of a lot more powerful and concise and extensible than the fixed X-Windows protocol.
https://news.ycombinator.com/item?id=43952748
>I agree they should learn from DLLs, gRPC, SOAP, IDL, dCOM, etc.
>But they should also learn from how NeWS was better than X-Windows because instead of a fixed protocol, it allowed you to send executable PostScript code that runs locally next to the graphics hardware and input devices, interprets efficient custom network protocols, responds to local input events instantly, implements a responsive user interface while minimizing network traffic.
>For the same reason the client-side Google Maps via AJAX of 20 years ago was better than the server-side Xerox PARC Map Viewer via http of 32 years ago.
>I felt compelled to write "The X-Windows Disaster" comparing X-Windows and NeWS, and I would hate if 37 years from now, when MCP is as old as X11, I had to write about "The MCP-Token-Windows Disaster", comparing it to a more efficient, elegant, underdog solution that got out worse-is-bettered. It doesn't have to be that way!
>The X-Windows Disaster:
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
>It would be "The World's Second Fully Modular Software Disaster" if we were stuck with MCP for the next 37 years, like we still are to this day with X-Windows.
Finally the rapping spider makes it big
This is an aqua teen hunger force reference?
I want candy, bubblegum, and taffy…
Doesn't everyone get a unicorn?