*after forking and modifying it for my use case
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.
[1] https://developer.apple.com/documentation/foundationmodels
What do you mean? The curve for "Small Contract" is mostly flat compared to MCP: https://trends.google.com/trends/explore?q=Smart%20Contract,...
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.
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.
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.
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.
?
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 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.
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.
..but while it's true we have too many standards, I'm also not drowning in micro-USB and mini-USB cables anymore. There are paths of reduction.
With MCP that's decoupled, the tool and the software speak a common protocol, and it's one line of configuration to hook the tool up to the LLM. Makes it easy to mix and match, reuse code, etc.
That said, 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.
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!
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.
- 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 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).
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.
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)
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.)
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
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"?
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.
>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.
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.
0x500x79•6h ago
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!
tempodox•6h ago
What have we come to when losing control in software development is called “awesome”.
loloquwowndueo•6h ago
0x500x79•5h ago
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.
0x457•4h ago
theOGognf•6h ago
Feels like a monolith would be better
MaxLeiter•6h ago
MyOutfitIsVague•5h ago
jcelerier•5h ago
why does the smallest script take seconds to even start then?
stingraycharles•5h ago
antonvs•1h ago
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.
stingraycharles•5h ago
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.
pydry•6h ago
0x500x79•5h ago
pydry•5h ago
Aurornis•6h ago
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.
0x500x79•5h ago
qsort•5h ago
tptacek•4h ago
brandensilva•4h ago
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.
tptacek•4h ago
I think as a developer, as opposed to an IT integrator or something like that, you should be the most excited about this situation.
pphysch•5h ago