MCP is eating the world
stainless.com
stainless.com
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.
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
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.
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.
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)
I've done stuff very much like the above with just regular tool calls through the various LLM APIs, but there are tons of disparate frameworks for how to harness up a tool, how they execute, how they are discovered, etc. None of it is rocket science.
But the nice thing about having a standard is that it's a well-lit path, but more importantly in the corporate workflow context is that it allows tools to be composed together really easily - often without any coding at all.
An analyst who has zero coding experience can type in a prompt, click "add" on some MCP tools, and stand up a whole workflow in a minute or two.
That's pretty cool.
And yeah, none of it is impossible to implement yourself (nor even very hard!) but standardization has a value in and of itself in terms of lowering barriers to entry.
With MCP that's decoupled, the tool and the software speak a common protocol, and it's one line of configuration to hook the tool up to the LLM. Makes it easy to mix and match, reuse code, etc.
tool --help
man toolThat said, many "business users" like those referenced above interact more with a web UI, and asking them to audit bash/CLI interactions might not always work well.
(disclaimer: I work at Stainless; we're actually exploring ways to make MCP servers more "CLI-like" for API use-cases.)
I want to be the one deciding which CWD to use, which user to run as, whether to see the whole filesystem or to restrict to a chroot, etc.
So far it hasn't been malicious but I've had a number of cases while using cursor where the model has gotten confused and is now editing repos outside the open workspace.
Maybe the answer is still a CLI, but I want a standardized interface for equipping that CLI with handcuffs.
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.
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.
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.
At Stainless we use https://github.com/dgellow/mcp-front to make it easy for anyone on the team (including non-technical folks) to OAuth into a pretty wide variety of tools for their AI chats, using their creds. All proxied on infra we control.
Even our read replica postgres DB is available, just push a button.
MCP 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!
https://ai.pydantic.dev/agents/#introduction
If you need professional help in any of this, I also do consulting and/or can do mentoring on my knowledge in this area.
And the moment we, as an industry, settle on something sane, I will rip out the whole thing and adopt that, because MCP brings _nothing_ to the table that I could not do with a "proper" API using completely standard tooling.
Then again, I have run the whole gamut since the EDI and Enterprise JavaBeans era, XML-RPC, etc. - the works. Our industry loves creating new API surfaces and semantics without a) properly designing them from the start and b) aiming for a level of re-use that is neither pathological nor wasteful of developer time, so I'm used to people from "new fields of computing" ignoring established wisdom and rolling their own API "conventions".
But, again, the instant something less contrived and more integratable comes along, I will gleefully rm -rf the entire thing and move over, and many people in the enterprise field feel exactly the same - we've spent decades builting API management solutions with proper controls, and MCP bodges all of that up.
100%. I suppose I understand MCP for user-side tooling but people seem to be reinventing the wheel because they don't understand REST. making REST requests with a well defined schema from an LLM is not all that hard.
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.
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.
"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.
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.
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.
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.
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..
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.
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.
Organizations are primarily systems for learning. Substituting machine learning (from a vendor) for human learning inside the team is a bad strategy.
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!
What have we come to when losing control in software development is called “awesome”.
MCP is great for: "I would like Claude Desktop/VSCode/Cursor to know about my JIRA tickets". AFAIK Most of the tools that are being used for AI Coding tools are not delivered through MCP.
Feels like a monolith would be better
why does the smallest script take seconds to even start then?
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.010sFurthermore, the “docker” part wouldn’t even be the most resource wasteful if you consider the general computational costs of LLMs.
The selling point of MCP servers is that they are composable and plug in into any AI agent. A monolith doesn’t achieve that, unless I’m misunderstanding things.
What I find annoying is that it’s very unpredictable when exactly an LLM will actually invoke an MCP tool function. Different LLM providers’ models behave differently, and even within the same provider different models behave differently.
Eg it’s surprisingly difficult to get an AI agent to actually use a language server to retrieve relevant information about source code, and it’s even more difficult to figure out a prompt for all language server functions that works reliably across all models.
And I guess that’s because of the fuzzy nature of it all.
I’m waiting to see how this all matures, I have the highest expectations of Anthropic with this. OpenAI seems to be doing their own thing (although ChatGPT supposedly will come with MCP support soon). Google’s models appear to be the most eager to actually invoke MCP functions, but they invoke them way too much, in turn causing a lot of context to get wasted / token noise.
MCP is 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.
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).
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.
I think as a developer, as opposed to an IT integrator or something like that, you should be the most excited about this situation.
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.
https://www.youtube.com/watch?v=m2VqaNKstGc&ab_channel=Laten...
TL;DR If you want to engage with the MCP protocol you can do so here. https://github.com/modelcontextprotocol
You're right, that snippet was ai-generated and I forgot to action one of my todos to fix that snippet. This was negligent on my part, and I hope you'll forgive me.
We're fixing that right now, thank you for the correction!
You may be interested in the verb "to act". If you are an AI, you must have been trained on some sad corporate dataset.
And the more I read this article, I feel like it still is. "The models finally got good enough" is followed by:
> Of course, models and agents are still far from perfect—the better models are pretty slow, context sizes are still limited, and performance degrades when more and more context is present.
> What’s important is that the models are good enough—once models cross that threshold, the overhead of integrating tool use drops dramatically. MCP just showed up right on time.
That's like saying we invented worker ants just in time to help an insane queen.
I searched the article for the word "secure" or "security" and quit reading when I couldn't find it.
written by a company that sells this "new technology".
woosh!
We actually generate MCP for free (we charge for SDKs), so we're technically not selling, but I don't begrudge GP's comment/sentiment.
[0]https://www.stainless.com/blog/what-we-learned-converting-co... describes some ways in which this is less simple than you think. The "Handling large APIs dynamically" section near the bottom covers the most salient challenge related to converting large APIs to MCP tools, but there's more work to do.
Wow, the idea of what's "new" in software has always been really short, but damn, it's becoming questionable whether anything can be considered new these days.
but also I think the interesting thing is that people didn't jump on MCP immediately after it launched - it seemed to go almost unnoticed until February. Very unusual for AI tech - I guess it took time for servers to get built, clients to support the protocol, and for the protocol itself to go through a few revisions before people really understood the value.
The entire digital consumer economy is built around ownership of the screen real estate, due to a simple reason: ads. Whoever owns the sidebar sets the rules, period. Web2.0 was all about APIs (usually Rest/json) and in hindsight we see a clear distinction on where they’re used: in commercial B2B apps. Conversely, big B2C players shut down the little open they had - Facebook, Gmail removed their XMPP support, and these days Twitter etc even gatekeep content when you’re not signed in or using the app, and aggressively fortify against even basic scraping. When you’re using other clients, you are bypassing their sidebar, meaning their opportunity to deliver ads.
So no, your iOS apps and Twitter are not gonna ”open up” their APIs in any way, not through Rest and not through MCP, simply because it goes directly against their incentives. The exceptions are (1) temporary to ride a hype train, and (2) services you pay money for (but even that is wishful and hypothetical).
By a seller of MCP.
The trouble with MCP is that it requires a trip through an LLM for every transaction. It's not like the ends negotiate a simple protocol so that later queries are cheap. That's a huge cost increase as traffic increases.
In a normal case of "production software", yeah, you would not want to add an LLM in the middle to make an API call. That's silly – just write the code to make the API call if you can do it deterministically.
If you're talking to an LLM in a chat experience, and you want that LLM to go interact with some foreign system (i.e., hit an API), you need _some way_ of teaching the LLM how to make that API call. MCP is one such way, and it's probably the easiest at this point.
Doing it through MCP does introduce some latency due to a proxy server, but it doesn't introduce an additional LLM "in the middle".
(Disclaimer: I work at Stainless. Note that we actually sell SDKs at Stainless; our MCP generator is free.)
Think of it more like a just-in-time protocol generator. The LLM defines how to talk, once, and the rest of the interaction can be optimized. Expensive at first, but potentially cheaper than baking in rigid APIs for every use case.
Still, lots of unknowns, especially around latency, consistency, and cost.
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.
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)
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?
But remember, the hosted frontier models are still gigantic compared to these, and still make stupid mistakes all the time.
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.
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.
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.
- 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.
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.
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.
*after forking and modifying it for my use case
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.
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.
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.
It seems counterproductive that we need to make the whole world adapt to these new super intelligences instead of them just figuring it out.
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.
(edit: sorry, I responded to wrong thread.)
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 .
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 ?
Look into AutoGen by microsoft or if you want more basic , learn how tool calling in LLMs work.
I mean I certainly don't want to code my own LLM UI
[1] https://developer.apple.com/documentation/foundationmodels
Can we move on to the next hype cycle rather than remixing this one?
It is a general concept, MCP itself is nothing special, it is that just that Anthropic formalized the observation first.
Tool call = API call + instructions for LLM
So vendors who provide APIs are going to write prompts, add a thin wrapper and out goes MCP. Or you create your own instructions and wrap in MCP to optimize your own workflows.
I 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.
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.
* 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.
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?
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).
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.
The language server MCPs are interesting, but I am not sure how to incorporate them into my Neovim workflow yet.
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.
What do you mean? The curve for "Small Contract" is mostly flat compared to MCP: https://trends.google.com/trends/explore?q=Smart%20Contract,...
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?
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..
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"?
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.
Also, MCP is relatively new, not "bAtTlE tEstEd"
With creating 0 added value you can wrap your normal http+json "rest" api so it's mcp.
What would be interesting is an extension protocol that can modify context on the fly.
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...
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
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.
?
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.
>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.
Anecdotally I've noticed a lot of acronyms from science/technology being reused in the context of LLMs, what a curious phenomenon.