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.
Yes, MCP adds no new fundamental capabilities. What it does is solve an N x M problem, where to hook up a given tool to a given LLM scaffold you have to write specific integration code for that combination of scaffold and tool.
With MCP that's decoupled, the tool and the software speak a common protocol, and it's one line of configuration to hook the tool up to the LLM. Makes it easy to mix and match, reuse code, etc.
This is pretty fair: in claude code, I have the github mcp server installed, but the agent actually prefers to use the CLI. There's also other advantages too, such as incremental discovery of subcommands for more complex CLIs. Certainly agents already don't have a problem using CLIs.
That said, this doesn't fully work in environments on websites like claude.ai. Perhaps you could have an org-wide Dockerfile or something that opens every time you start a chat which gives it MCP-like capabilities, but that sounds more complicated in many ways than what MCP does. There's also more problems that MCP solves, like with Prompts and Sampling (which are pretty under-used at the moment), and there aren't great analogs for that in the CLI world.
Also developers like you and I might find it trivial to install CLIs, set up auth, and open an agent locally, but this isn't widely true. As an example, at Stainless we have non-engineer folks who ask questions like "who are the most interesting people who have signed up yesterday", and with the right MCP tools wired to claude.ai, claude actually does an excellent job of answer these kinds of questions, all in the browser. This was all without a doubt possible before MCP, but MCP reduces the friction enough, such that it becomes worth-it/easy-enough to develop these tools.
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?
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.
I suppose it shouldn't bother me that the people doing that are 'business users' but I have to wonder if adults these days are so illiterate that they can't read through 20 jira tickets and categorize them in less than an hour.
More concerning is people thinking that the document you output is the outcome, when the mental models and the domain understanding are what we ought to strive for.
Organizations are primarily systems for learning. Substituting machine learning (from a vendor) for human learning inside the team is a bad strategy.
This leaves more time to spend arguing with the chatbot about miscategorized tickets; the chatbot exclaiming "you're right, I'll do better next time" and then making the same mistake tomorrow.
At Stainless we use https://github.com/dgellow/mcp-front to make it easy for anyone on the team (including non-technical folks) to OAuth into a pretty wide variety of tools for their AI chats, using their creds. All proxied on infra we control.
Even our read replica postgres DB is available, just push a button.
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'm going to reiterate something that has been said already. Everything around auditing and pedaling permissions in my mid sized company snowflake account is a gigantic pain in the neck.
I've been trying (albeit not very hard) to build an accessibility library and toolset that can be exposed via mcp server. I think it has the potential to be much more ergonomic for generalized computer-use agents than stuff like playwright or the classic screenshot approach. Low latency computer use is another thing that I'd like to solve.
The issue is mac and windows accessibility APIs are opaque and I have no idea what I'm doing so I'm forced to vibe code it all which is not turning out too well... :-)
I suffer from mild carpal tunnel so I want to build a really low latency computer use agent that can do anything on my computer without me having to learn the talon voice syntax or some other traditional accessibility software like mac dictation.
Rock Auto has a fantastic to use website. It uses a very intuitive tree based representation and has search that actually works. It also shows you if a part is going to be shipped from the same warehouse as another part in your cart so you can save on shipping.
I've got something very similar as a function in my ~/.zshrc, except instead of days separated by lines I start a new file for each topic.
Most of my notes are write-only for a day or so but I keep the old ones around just in case I need to grep through everything (and I've saved myself doing this a few times).
function notes {
THIS_MONTH="$(date '+%Y-%m')"
mkdir -p "$NOTES_FOLDER/$THIS_MONTH" # create folder if it doesn't exist.
cd "$NOTES_FOLDER/$THIS_MONTH"
if [ -z "$1" ]; then
return 0
fi
vim $1
cd -
}
Running `notes` will take you to today's directory to poke around, and `notes file.md` will open file.md in the appropriate dir.
I do something very similar for my public notes as well! I have `tn` to search for a note and open it in a browser, and `tne foo` to open my `foo.md` note in my editor, which in this case is not vim. I then commit them to git, where a post-commit hook uses mkdocs to build them, and gh-deploy to publish them EG https://danielhoherd.com/tech-notes/exiftool/ is the output of my exiftool.md note.
There's been garbage online forever. But you had to seek it out and if you didn't visit those sites you weren't going to come across this content organically in the same way.
Now you just have an infinite feed that shows you this stuff organically and unless you are diligent in clicking "not interested" over and over, it'll show up in your feed more and more often.
It is the user's fault when the user says in his post that he doesn't interact with the algorithm or give it anything to go on except to click on content he doesn't like and then lo and behold it gives him content he doesn't like.
So the algorithm should show an elephant stomping a man to death to anyone who starts a new account until they "correct" "their algorithm" by interacting with better content?
The issue is that users are being pushed towards violence, gore, and pornography by default.
The bar for these giant multi billion dollar tech companies with hundreds of thousands of employees and the most advanced AI tech in the world is truly as low as it's ever been.
I've been fighting trying to chunk SEC filings properly, specifically surrounding the strange and inconsistent tabular formats present in company filings.
>>I've been fighting trying to chunk SEC filings properly, specifically surrounding the strange and inconsistent tabular formats present in company filings.
For this specific use case you can also try edgartools[1] which is a library that was relatively recently released that ingests SEC submissions and filings. They don't use OCR but (from what I can tell) directly parse the XBRL documents submitted by companies and stored in EDGAR, if they exist.
XBRL is what I'm using currently, but it's still kind of a mess (maybe I'm just bad at it) for some of the non-standard information that isn't properly tagged.
I've wanted to do something like this for years. I might have to actually stop fiddling with the idea in my head and give it a real shot in 2025.
I'm curious - how does the design process go? Do you propose a design, do they usually have a pretty complete vision or do you have templates that they can take inspiration from?
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.