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).
Yes, I've had to deal with this at work as well. Much talk about MCP as if it's some mystical magical wonder, and not just concatenating a bunch of json to your prompt.
MCP is really a great leap because LLMs orchestrate across a collection of tools instead of running a scripted flow. The most obvious example is deep research, where the LLM sends initial queries, reads, then generates new queries and loops until it finds what it needs. This dynamic orchestration of the search tool is almost impossible to do in a scripted way. And it shows where the MCP value is - you just write simple tools, and AI handles the contextual application. You just make the backend, the front end is the LLM with human in the loop.
I made an MCP with 2 tools - generate_node and search, and with it Claude Desktop app can create a knowledge graph complete with links and everything. It scales unbounded by context size but is read/write and smarter than RAG because it uses graph structure not just embeddings. I just made the reading and writing tools, the magic of writing the nodes, linking them up, searching and analyzing them is due to AI. And again, Claude can be very efficient at wielding these tools with zero effort on my part. That is the value of MCP.
MCP is a detail here. The exact same thing would happen if generate_node and search were exposed as REST endpoints, if Claude Desktop had used REST instead of MCP.
Isn't part of the issue that LLM's are relatively bad at REST and json and all that?
I remember like 2 years ago there was big hype/revolution around ChatGPT finally being able to return ONLY valid json when you asked it to. So apparently LLMs are not that good at scripting without mistakes.
Having said that, I honestly have no clue what MCP looks like or is lol :p
But to your last point: go look it up, have a read through their client/server implementations (for your language of choice). It doesn't actually take that long because the concept is actually rather simple, so I totally recommend it.
Maybe not, I think they trained the model to be especially capable of MCP tool use, and generated data this way. Other formats and systems might be slightly worse, and the whole model would probably not handle such a diversity of tools if all it had was trained on much less diverse API integrations.
I find it kind of sad that now we finally have tooling which could make use of HATEOS[1] style REST APIs, which are technically self-documenting and in practice never really took off because you need to understand the API to write a client for it, everyone ran off and designed something else instead.
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.
I have a tool that builds HTTP requests. LLMs can use that just fine, IF they know the API spec they should connect to. And that is the problem. If you are then required to pass the specs of dozens of APIs, you are polluting the context with too much useless info. MCP simplifies that
LLM already exist that capabilities since chatgpt GPT3.5
Just they don't have tools and then, tools are simply introduced by tool calling specs and it works fine already. MCP is a wrapper around that specs nothing new
You are fundamentally misunderstanding what is happening here and how this is all works.
"HTTP calling abilities of LLMs" is not some magic, new feature that is deeply integrated into LLMs. It's just a tool call like everything else - i.e. you prompt the LLM to return a JSON object that conforms to a schema.
MCP is also doing this exact same thing. It's just a wrapper protocol that tries to take care of all the details so that we don't have to deal with a million custom protocols that all accomplish the same thing but are all incompatible.
You are fundamentally misunderstanding the point I am making. LLMs have repeatedly started with training wheels and then slowly had them taken off as they have become more and more competent. MCP is another example of training wheels that will likely eventually go away. If the direct web/API calling abilities of LLMs were to improve with better trained models and some more built in support then MCP could go away and nobody would miss it.
No, you are still not getting it. MCP will never go away, or at least something like it will always end up existing.
What you are describing, "web api calling abilities were to improve" will not change anything. What sort of improvement are you thinking of? They can only get better at outputting json correctly, but that hasn't really been a problem for a long time now.
Either way, it wouldn't change anything, because MCP is a 100 other things which doesn't have anything to do with the llms using tools directly. You will never embed everything that MCP can do "into" the llm - that barely even makes sense to talk about. It's not just a wire protocol.
I mean the fact that I can bring an API spec, MCP protocol spec, and MCP SDK spec into context and say "make me an MCP server where each route equals a tool" and have that bootstrapped in <5 minutes as a starting point is pretty nice. Then you can just start chaining stuff together.
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.
> but by being the same interface for all APIs it reduces the burden on the LLM
It doesn't reduce the burden for the LLM, as the LLM isn't the piece of software directly interfacing with the MCP server. It reduced the burden for people building clients that call LLMs and have to convert external interfaces into tool calls etc..
> 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.
It's not really MCP that is 'this', MCP is just the glue that makes the NLP as frontend easy to conceptualize in terms of application. Everyone is getting excited because it's now relatively obvious how you can go from talking to LLM -> large orchestration happening, even though you could do this already with langchain or whatever.
MCP is basically just a protocol you can bring into the context window, do your LLM coding magic, then start up your MCP server and test your tool chain for your NLP as frontend stuff. The only difference is now it's not deterministic so stuff will get randomly fucked up.
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.
There is so much accidental complexity in software because people keep reinventing the wheel. I think it might be interesting to do some research for a book on this topic.
You just described how to write a tool the LLM can use. Not MCP!! MCP is basically a tool that runs in a server so can be written in any programming language. Which is also its problem: now each MCP tool requires its own server with all the complications that come with it, including runtime overhead, security model fragmentation, incompatibility…
> You just described how to write a tool the LLM can use. Not MCP!! MCP is basically a tool that runs in a server so can be written in any programming language.
It's weird you're saying it's not MCP, when this is precisely what I've done to write several MCP servers.
You write a function. Wrap it with a decorator, and add another line in __main__, and voila, it's an MCP server.
> now each MCP tool requires its own server with all the complications that come with it, including runtime overhead, security model fragmentation, incompatibility…
You can lump multiple tools in a server. Personally, it makes sense to organize them by functionality, though.
> including runtime overhead, security model fragmentation, incompatibility…
What incompatibility?
Runtime overhead is minimal.
Security - as I said, if you write your own tools, you control it just as you would with the old tool use. Beyond that, yes - you're dependent on the wrapper library's vulnerabilities, as well as the MCP client. Yes, we've introduced one new layer (the wrapper library), but seriously, it's like saying "Oh, you introduced Flask into our flow, that's a security concern!" Eventually, the libraries will be vetted and we'll know which are secure and which aren't.
You’re just confused. You can write a tool , or if your framework supports it, the tool can be also a MCP. But llm cares only about tools. Try to learn the underlying mechanics and you will understand the difference.
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.
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?
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.)
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.
You could just start the MCP server in container I guess, although I suppose that's doing it the manual way.
That might prevent the model from wandering from the beaten paths, but container escapes are a thing, so if it's not lost but instead malicious then that might not do it. Luckily I don't think we're quite there yet.
So I think that's a "no".
QubesOS might work well for this. It's all about making it easy to work with a small pile of VMs under the assumption that at least one is probably compromised and keeping that one compartmentalized. Although I don't know how far that'll get you if you're letting the untrusted thing call the shots.
At the end of the day you're always going to be able to build better handcuffs by starting with nothing and gradually adding API calls that it needs. Starting with CLI access and then adding restrictions is never going to be as secure, even though it's way more convenient.
That said, I think you could strike a pretty reasonable balance by just not giving it access to anything but one or two explicitly chosen directories.
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.
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!
Hi! I am a bit lost in all of this. How do you create your own agent and run your own loop? I've looked at PydanticAI but don't get it. Would you please give me an example? Thanks!
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.
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.
I'm sure your bitcoin are fine, seeing as the entrenched financial institutions and the old money crowd invested in them, their value isn't going to go down; nice to be part of that crowd I am sure. You may want to check in on NFTs, Terra Luna, Celsius, Safe Moon, SQUID, and FTX. I think they might not be at all time highs.
There is bitcoin/crypto currencies, and then there's bullshit and "<boring real world thing> BUT ON THE BLOCKCHAIN".
The former is well-understood and has legitimate use. The latter was a bubble that thankfully mostly burst by now, with the grifters moving on to the next fad (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.
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.
It really depends whether the parent is on Linux (where your description would be correct), or on MacOS, where running a container involves first booting up a Linux VM under the hood and having it exchange files/network traffic with the host with tons of overhead (not to mention the pile of shit Electron-based Docker Desktop app that feels like it takes as much memory as the Linux VM itself).
> 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.
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.
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
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!
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.
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.
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?
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.
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.
The biggest issue I have with MCP is that some companies like notion expect every single user to host and run their own MCP. It would be so much easier for everyone if they would simply host it themselves and give access on MCP.notion.so like stripe and others do.
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.
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.
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.
We use an outdated on-premise version of Azure DevOps (nee. Team Foundation Server) for our sorry excuse of task management. We also use some horrible plugin for time tracking so our bosses can be sure we're keeping the seat warm for the correct amount of time.
I forked [this existing MCP server for azure devops](https://github.com/Tiberriver256/mcp-server-azure-devops) but I had to make a lot of changes to have it work on our env and I also added some tools for working with that shitty time tracking plugin.
A shameless plug, and I'm not going to pretend otherwise:
I'm trying to build a Fair-code platform called "MCP as a Service", which allows you to easily launch MCP servers (for example, Playwright MCP connected to a real browser), without the need to think about software or servers, "in the cloud".
This way, you can connect to the deployed MCP server from anywhere; for example, from within your n8n AI Agent workflow.
The Fair-code model means that there is a "hosted service" offering if you want a maximum of convenience, but you can fully self-host for maximum control.
It's still in the "humble beginnings" phase, but I would love to build this into an open alternative to existing, closed-source offerings.
Even MCP is still relying on tool/function calling in LLMs which is just a finetune/trained behaviour with zero guarantees.
It relies on training the model so that the probability of outputting the python_call token followed by the correct tool is relatively high. But it's still n<1.
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.
For those who experienced the short but intense “mashup” mania in the early 2000’s where web applications were supposed to be easily coupled and chained ? Will MCP ecosystems fail for the same reasons (too many changes in APIs, monetization and security barriers ?)
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.
MCP is eating whatever the next buzzword is until something else or better comes along. The hype cycles with these ancillary things (RAG etc) is so overblown compared to what actually makes it into practice and production. I would use MCPs as developer. In making AI systems, unless you are in large org (also rare) not even worth doing.
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.
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.
Exactly, having some metadata on OpenAPI and then have a generic openapi-mcp-gateway seems like a useful approach. Or being it a part of a web framework, given routes also expose MCP endpoint.
The takeaway is to go beyond the bare minimum and put the effort to optimize the docs/prompts, ideally having some evals in place.
For the prompts and resources part of the spec I haven't found much use for those yet. It seems like output of tool calls is enough to get content into the context.
Also, possible Conflict of Interest, author works at Meta, which develops Llama. And one of MCP's main features is model agnosticism, which benefits contenders to the king model.
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?
Still confused as to why the super-smart LLM needed humans to create a proxy to every existing protocol. Why couldn't it write client code for all those protocols itself?
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.
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?
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.
> 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
Folks at Amazon Alexa are looking at all this and thinking 'what could have been'. Probably.
MCP as an Alexa skill but orders of magnitude easier to deploy? Yes, please. With an added bonus of the thing sometimes pseudo-understanding what I said.
>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.
26^3 is only 17576 potential TLAs. Some collisions are to be expected, especially when you take into account some phrases are more likely to occur than others (such as CP for Control Panel, Certified Professional, Control Protocol, Comprehensive Plan, Child Process ...)
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).
Yes, I've had to deal with this at work as well. Much talk about MCP as if it's some mystical magical wonder, and not just concatenating a bunch of json to your prompt.
MCP is really a great leap because LLMs orchestrate across a collection of tools instead of running a scripted flow. The most obvious example is deep research, where the LLM sends initial queries, reads, then generates new queries and loops until it finds what it needs. This dynamic orchestration of the search tool is almost impossible to do in a scripted way. And it shows where the MCP value is - you just write simple tools, and AI handles the contextual application. You just make the backend, the front end is the LLM with human in the loop.
I made an MCP with 2 tools - generate_node and search, and with it Claude Desktop app can create a knowledge graph complete with links and everything. It scales unbounded by context size but is read/write and smarter than RAG because it uses graph structure not just embeddings. I just made the reading and writing tools, the magic of writing the nodes, linking them up, searching and analyzing them is due to AI. And again, Claude can be very efficient at wielding these tools with zero effort on my part. That is the value of MCP.
MCP is a detail here. The exact same thing would happen if generate_node and search were exposed as REST endpoints, if Claude Desktop had used REST instead of MCP.
Isn't part of the issue that LLM's are relatively bad at REST and json and all that?
I remember like 2 years ago there was big hype/revolution around ChatGPT finally being able to return ONLY valid json when you asked it to. So apparently LLMs are not that good at scripting without mistakes.
Having said that, I honestly have no clue what MCP looks like or is lol :p
MCP is just json.
But to your last point: go look it up, have a read through their client/server implementations (for your language of choice). It doesn't actually take that long because the concept is actually rather simple, so I totally recommend it.
MCP is a form of JSON-RPC over HTTP, so I don't think it has anything to do with that.
Maybe not, I think they trained the model to be especially capable of MCP tool use, and generated data this way. Other formats and systems might be slightly worse, and the whole model would probably not handle such a diversity of tools if all it had was trained on much less diverse API integrations.
[dead]
I find it kind of sad that now we finally have tooling which could make use of HATEOS[1] style REST APIs, which are technically self-documenting and in practice never really took off because you need to understand the API to write a client for it, everyone ran off and designed something else instead.
[1] https://en.wikipedia.org/wiki/HATEOAS
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.
I have a tool that builds HTTP requests. LLMs can use that just fine, IF they know the API spec they should connect to. And that is the problem. If you are then required to pass the specs of dozens of APIs, you are polluting the context with too much useless info. MCP simplifies that
You also need an MCP schema to understand what the MCP server can actually do, there is no free lunch here.
yes, but in terms of token size its WAY cheaper for the AI to handle that than an OpenAPI spec
Isn't this more a limitation of the OpenAPI spec? Something like GraphQL would probably work much better
LLM already exist that capabilities since chatgpt GPT3.5 Just they don't have tools and then, tools are simply introduced by tool calling specs and it works fine already. MCP is a wrapper around that specs nothing new
You are fundamentally misunderstanding what is happening here and how this is all works.
"HTTP calling abilities of LLMs" is not some magic, new feature that is deeply integrated into LLMs. It's just a tool call like everything else - i.e. you prompt the LLM to return a JSON object that conforms to a schema.
MCP is also doing this exact same thing. It's just a wrapper protocol that tries to take care of all the details so that we don't have to deal with a million custom protocols that all accomplish the same thing but are all incompatible.
You are fundamentally misunderstanding the point I am making. LLMs have repeatedly started with training wheels and then slowly had them taken off as they have become more and more competent. MCP is another example of training wheels that will likely eventually go away. If the direct web/API calling abilities of LLMs were to improve with better trained models and some more built in support then MCP could go away and nobody would miss it.
No, you are still not getting it. MCP will never go away, or at least something like it will always end up existing.
What you are describing, "web api calling abilities were to improve" will not change anything. What sort of improvement are you thinking of? They can only get better at outputting json correctly, but that hasn't really been a problem for a long time now.
Either way, it wouldn't change anything, because MCP is a 100 other things which doesn't have anything to do with the llms using tools directly. You will never embed everything that MCP can do "into" the llm - that barely even makes sense to talk about. It's not just a wire protocol.
HATEOAS FTW
I mean the fact that I can bring an API spec, MCP protocol spec, and MCP SDK spec into context and say "make me an MCP server where each route equals a tool" and have that bootstrapped in <5 minutes as a starting point is pretty nice. Then you can just start chaining stuff together.
MCP was specifically created so LLMs can have a better understanding (better context). An app or user needs completely different endpoints than LLMs.
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.
> but by being the same interface for all APIs it reduces the burden on the LLM
It doesn't reduce the burden for the LLM, as the LLM isn't the piece of software directly interfacing with the MCP server. It reduced the burden for people building clients that call LLMs and have to convert external interfaces into tool calls etc..
You wouldn't even need Swagger if we actually used REST. Swagger is only around because we abandoned REST for RPC.
REST is just like scrum/agile. There is apparently some sort of "standard" but really anything goes and everyone does whatever they want.
What do you mean? REST was really clearly defined in Roy Fielding's dissertation when he proposed the term in the first place.
I agree people do whatever they want and call it REST, but that's not because of a lack of definition in what their term.
I am looking into ACP and it looks something more solid compared to MCP which is like an intern project. What do you think?
> 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.
It's not really MCP that is 'this', MCP is just the glue that makes the NLP as frontend easy to conceptualize in terms of application. Everyone is getting excited because it's now relatively obvious how you can go from talking to LLM -> large orchestration happening, even though you could do this already with langchain or whatever.
MCP is basically just a protocol you can bring into the context window, do your LLM coding magic, then start up your MCP server and test your tool chain for your NLP as frontend stuff. The only difference is now it's not deterministic so stuff will get randomly fucked up.
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.
There is so much accidental complexity in software because people keep reinventing the wheel. I think it might be interesting to do some research for a book on this topic.
You just described how to write a tool the LLM can use. Not MCP!! MCP is basically a tool that runs in a server so can be written in any programming language. Which is also its problem: now each MCP tool requires its own server with all the complications that come with it, including runtime overhead, security model fragmentation, incompatibility…
> You just described how to write a tool the LLM can use. Not MCP!! MCP is basically a tool that runs in a server so can be written in any programming language.
It's weird you're saying it's not MCP, when this is precisely what I've done to write several MCP servers.
You write a function. Wrap it with a decorator, and add another line in __main__, and voila, it's an MCP server.
> now each MCP tool requires its own server with all the complications that come with it, including runtime overhead, security model fragmentation, incompatibility…
You can lump multiple tools in a server. Personally, it makes sense to organize them by functionality, though.
> including runtime overhead, security model fragmentation, incompatibility…
What incompatibility?
Runtime overhead is minimal.
Security - as I said, if you write your own tools, you control it just as you would with the old tool use. Beyond that, yes - you're dependent on the wrapper library's vulnerabilities, as well as the MCP client. Yes, we've introduced one new layer (the wrapper library), but seriously, it's like saying "Oh, you introduced Flask into our flow, that's a security concern!" Eventually, the libraries will be vetted and we'll know which are secure and which aren't.
You’re just confused. You can write a tool , or if your framework supports it, the tool can be also a MCP. But llm cares only about tools. Try to learn the underlying mechanics and you will understand the difference.
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
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?
(I work with yjp20)
Ditto on the postgres MCPs vs the standard pg cli - seems to prefer the cli. Which is fine enough for me.
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.)
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.
Are there any tools that automate using containers for this?
You could just start the MCP server in container I guess, although I suppose that's doing it the manual way.
That might prevent the model from wandering from the beaten paths, but container escapes are a thing, so if it's not lost but instead malicious then that might not do it. Luckily I don't think we're quite there yet.
So I think that's a "no".
QubesOS might work well for this. It's all about making it easy to work with a small pile of VMs under the assumption that at least one is probably compromised and keeping that one compartmentalized. Although I don't know how far that'll get you if you're letting the untrusted thing call the shots.
At the end of the day you're always going to be able to build better handcuffs by starting with nothing and gradually adding API calls that it needs. Starting with CLI access and then adding restrictions is never going to be as secure, even though it's way more convenient.
That said, I think you could strike a pretty reasonable balance by just not giving it access to anything but one or two explicitly chosen directories.
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 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.
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!
Hi! I am a bit lost in all of this. How do you create your own agent and run your own loop? I've looked at PydanticAI but don't get it. Would you please give me an example? Thanks!
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.
If they can automate it, then they can spend that time doing something more useful, like researching Jira alternatives.
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.
Overeager intern ...
curious which MCP servers are you using for accessing JIRA/Confluence ? So far haven't found any good/official ones.
There is an official one now but YMMV how/if your particular application can use it https://www.atlassian.com/platform/remote-mcp-server
https://github.com/sooperset/mcp-atlassian
Looking at the demo I can see project managers going wild with this. And not in a good way.
Lol, we are keeping READ_ONLY_MODE on for now
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!
"Action" is a noun.
You may be interested in the verb "to act". If you are an AI, you must have been trained on some sad corporate dataset.
Is this response also ai-generated?
I guess I can't pass the turing test and this is life now.
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.
Which crypto bubble burst? The Bitcoin price still appears to be at all-time highs.
I'm sure your bitcoin are fine, seeing as the entrenched financial institutions and the old money crowd invested in them, their value isn't going to go down; nice to be part of that crowd I am sure. You may want to check in on NFTs, Terra Luna, Celsius, Safe Moon, SQUID, and FTX. I think they might not be at all time highs.
There is bitcoin/crypto currencies, and then there's bullshit and "<boring real world thing> BUT ON THE BLOCKCHAIN".
The former is well-understood and has legitimate use. The latter was a bubble that thankfully mostly burst by now, with the grifters moving on to the next fad (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.
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.
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
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.
It really depends whether the parent is on Linux (where your description would be correct), or on MacOS, where running a container involves first booting up a Linux VM under the hood and having it exchange files/network traffic with the host with tons of overhead (not to mention the pile of shit Electron-based Docker Desktop app that feels like it takes as much memory as the Linux VM itself).
> 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
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.
Still, in what world is delegating the stuff you want to do to machines you have no control over a good idea?
WOW talk about quoting out of context.
Do you get mad at IDE plugins that let you extend software that you don't control?
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.
[0] https://xeiaso.net/blog/2025/rolling-ladder-behind-us/
It's a riff on this famous article by Marc Andreessen that was published in the Wall Street Journal in 2011.[1]
[1] https://a16z.com/why-software-is-eating-the-world/
AI use is not even saturated yet. I would not expect MCP to be eating anything. It might just be a snack for a select few at this point.
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
Any chance they want someone that got the "Microsoft Certified Professional" badge 8 years ago or more?
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.
I think you're joking but if not I'd love to see one!
1 year for a human is like 10 in AI-years.
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
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
> 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).
This is why CUAs are going to demolish all prior fences.
> 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.)
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.
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.
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?
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.
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 mean, LLMs you can run on ollama are usually pretty bad ones.
The biggest issue I have with MCP is that some companies like notion expect every single user to host and run their own MCP. It would be so much easier for everyone if they would simply host it themselves and give access on MCP.notion.so like stripe and others do.
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.
The ecosystem is still very immature, and there is a lot of hype and unwarranted FOMO.
Here a security advisory for a popular Slack MCP server from Anthropic to highlight this: https://embracethered.com/blog/posts/2025/security-advisory-...
The fix was to deprecated the source code. But it's still up on npm with 10k+ downloads every week.
No CVE issued.
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
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.
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.
We use an outdated on-premise version of Azure DevOps (nee. Team Foundation Server) for our sorry excuse of task management. We also use some horrible plugin for time tracking so our bosses can be sure we're keeping the seat warm for the correct amount of time.
I forked [this existing MCP server for azure devops](https://github.com/Tiberriver256/mcp-server-azure-devops) but I had to make a lot of changes to have it work on our env and I also added some tools for working with that shitty time tracking plugin.
Ah, got it. Thank you!
yeah current AIs are surprisingly good at figuring out which tools to call and how to call them!
A shameless plug, and I'm not going to pretend otherwise:
I'm trying to build a Fair-code platform called "MCP as a Service", which allows you to easily launch MCP servers (for example, Playwright MCP connected to a real browser), without the need to think about software or servers, "in the cloud".
This way, you can connect to the deployed MCP server from anywhere; for example, from within your n8n AI Agent workflow.
The Fair-code model means that there is a "hosted service" offering if you want a maximum of convenience, but you can fully self-host for maximum control.
It's still in the "humble beginnings" phase, but I would love to build this into an open alternative to existing, closed-source offerings.
See https://mcp-as-a-service.com for the details.
The hosted solution is available, free-of-charge, at https://app.mcp-as-a-service.com.
Even MCP is still relying on tool/function calling in LLMs which is just a finetune/trained behaviour with zero guarantees.
It relies on training the model so that the probability of outputting the python_call token followed by the correct tool is relatively high. But it's still n<1.
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.
Can we split the difference that if one of you say it's simple and one of you say it's too complex, we have reached the juuust right zone.
Installing even a single command is not tenable for the vast majority of non technical users of software, not even Claude desktop users.
How come the LLMs cannot figure out interacting with command line programs and HTTP services with API docs, as humans can?
It seems counterproductive that we need to make the whole world adapt to these new super intelligences instead of them just figuring it out.
For those who experienced the short but intense “mashup” mania in the early 2000’s where web applications were supposed to be easily coupled and chained ? Will MCP ecosystems fail for the same reasons (too many changes in APIs, monetization and security barriers ?)
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.
MCP is the React for tool calling agents. There is also Angular (langchain?) and vanilla, rolling your own. React won.
> Thats all part of how you code
I mean I certainly don't want to code my own LLM UI
Sounds like NPM:)
I have massive AI fatigue. They're neat I guess, but nothing I've used has had any lasting importance.
Can we move on to the next hype cycle rather than remixing this one?
MCP is eating whatever the next buzzword is until something else or better comes along. The hype cycles with these ancillary things (RAG etc) is so overblown compared to what actually makes it into practice and production. I would use MCPs as developer. In making AI systems, unless you are in large org (also rare) not even worth doing.
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.
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.
Exactly, having some metadata on OpenAPI and then have a generic openapi-mcp-gateway seems like a useful approach. Or being it a part of a web framework, given routes also expose MCP endpoint.
The takeaway is to go beyond the bare minimum and put the effort to optimize the docs/prompts, ideally having some evals in place.
For the prompts and resources part of the spec I haven't found much use for those yet. It seems like output of tool calls is enough to get content into the context.
MCP is winning against OpenAPI because there is no big VC behind openapi.
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.
More appropriate title "MCP will eat the world"
Also, possible Conflict of Interest, author works at Meta, which develops Llama. And one of MCP's main features is model agnosticism, which benefits contenders to the king model.
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?
Still confused as to why the super-smart LLM needed humans to create a proxy to every existing protocol. Why couldn't it write client code for all those protocols itself?
LLMs hallucinate, MCP restrains the options available.
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.
It's literally just a mediocre api spec.
With creating 0 added value you can wrap your normal http+json "rest" api so it's mcp.
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,...
I guess more like Blockchain.
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?
yes but that could also be a MCP Host and you implement the MCP client logic and can integrate with MCP servers.
MCP is extremely limited and imo not at all interesting.
What would be interesting is an extension protocol that can modify context on the fly.
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.
ah that's a great point. noted.
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
> 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
my attempt at writing this same article back then https://latent.space/p/why-mcp-won
Not when prompt injection and other fairly trivial security issues hasn’t been solved
With MCP I can call tools with my own software too without having to use an LLM
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.
So MCP is basically: - getTools - executeTool
?
Yeah but an LLM is doing it so the outcome is different every time ;)
Shh, that'll blow up the hype bubble.
Anyone see Tron?
Folks at Amazon Alexa are looking at all this and thinking 'what could have been'. Probably.
MCP as an Alexa skill but orders of magnitude easier to deploy? Yes, please. With an added bonus of the thing sometimes pseudo-understanding what I said.
It's not.
should kill off sdk generators too
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?
>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.
JSON is eating the world... so what? It's just a standard
yawn
Mode Control Panel? I'm not sure about "eating" the world but certainly used worldwide by aircraft.
Anecdotally I've noticed a lot of acronyms from science/technology being reused in the context of LLMs, what a curious phenomenon.
26^3 is only 17576 potential TLAs. Some collisions are to be expected, especially when you take into account some phrases are more likely to occur than others (such as CP for Control Panel, Certified Professional, Control Protocol, Comprehensive Plan, Child Process ...)