MCP was a really shitty attempt at building a plugin framework that was vague enough to lure people into and then allow other companies to build plugin platforms to take care of the MCP non-sense.
"What is MCP, what does it bring to the table? Who knows. What does it do? The LLM stuff! Pay us $10 a month thanks!"
LLM's have function / tool calling built into them. No major models have any direct knowledge of MCP.
Not only do you not need MCP, but you should actively avoid using it.
Stick with tried and proven API standards that are actually observable and secure and let your models/agents directly interact with those API endpoints.
> LLM's have function / tool calling built into them. No major models have any direct knowledge of MCP.
but the major user interfaces for operating LLMs do and that's what matters
> Not only do you not need MCP, but you should actively avoid using it.
> Stick with tried and proven API standards that are actually observable and secure and let your models/agents directly interact with those API endpoints.
so what's the proven and standard API I can use to interact with ableton live? blender? unity3d? photoshop?
The mcp part is not essential for the actual controlling of the applications. You could “rip out” the mcp functionality and replace it with something else. The only reason why the authors chose mcp is most likely that it was the first and therefore most common plugin interface for llm tools.
Unfortunately, most standards that we end up with are only standard because they're are widely used and not because they are the best or they make the most sense.
It's not even a standard. It's literally not doing anything here. Not only "can" you rip out MCP there is zero technical reason for any of those things to be an "MCP" in the first place.
MCP literally is the "something else", if you have a better idea in mind, now is the time to bring it out before the MCP train is going too fast to catch up.
Code (including shell scripting) allows the LLM to manipulate the results programmatically, which allows for filtering, aggregation and other logic to occur without multiple round trips between the agent and tool(s). This results in substantially less token usage, which means less compute waste, less cost, and less confusion/"hallucination" on the LLM's part.
If one comes to the same conclusion that many others have (including CloudFlare) that code should be the means by which LLMs interface with the world, then why not skip writing an MCP server and instead just write a command-line program and/or library (as well as any public API necessary)?
Isn't that the point they are making? MCP is useful because everyone is using it, not because it has a technical advantage over rolling your own solution. It won mindshare because of marketing and a large company pushing it.
I've actually taken to both approaches recently, using the mcp-client package to give me an interface to a wide array of prebuilt tools in my non-LLM application. I could have written or sourced 10 different connectors, or I can write one client interface and any tool I plug in shares the same standard interface as all the others.
The most hilarious quote from one of those projects:
>The proxy server is required because the public facing API for UXP Based JavaScript plugin does not allow it to listen on a socket connection (as a server) for the MCP Server to connect to (it can only connect to a socket as a client).
Maybe that should have been the sign that this was completely unnecessary and stupid?
>Do you know of another way you can control all of those applications via LLMs?
Seriously. This becoming a bad joke. I mean conceptually, what did you think was happening here? MCP was just magically doing something that didn't already exist before?
So again, how do I automate Ableton live over a network socket with a standard API? I don't know if you've read the remote control API but it doesn't open a magic socket to remote control Live, you have to code the entire integration and protocol yourself to map whatever API messages you want to Live actions manually.
Let's forget about LLMs completely as they are only tangentially relevant to the benefits of MCP. I want to write 15 lines of python that - no matter the software - is going to trigger the "play" button/action in that software. E.g. I want to hit "play" in both Ableton, Unity and Blender without having to write three times the code, without having to manually write them each an extension plug-ins. How do you do that, today, 2025-11-17 ?
Actually, MCP wastes a lot of tokens when compared to regular tool calling. You might not notice it on more trendy models with large contexts, but for those of us trying to use locked down/local/cheap models it makes very little sense.
Also, MCP creates a new problem: providing the model with too much context when trying to combine tools across multiple servers. It works OK with small, very focused servers (like helpers for a specific data set), but if you try to mix and match servers things get out of hand really quickly and the entire workflow becomes very unreliable—too many options to digest and pursue, just like humans.
Is that just bad implementation? Where are the wasted tokens?
I noticed your second issue, but to me it's just from bad implementation. For some reason people keep exposing generic overlapping tools from multiple MCP servers.
I don't know that MCP causes this issue, any vendor offering a "tools API" if they shove to many APIs it would bloat things up.
Here's what Anthropic has to say about it:
As MCP usage scales, there are two common patterns that can increase agent cost and latency:
Tool definitions overload the context window;
Intermediate tool results consume additional tokens.
[...]
Tool descriptions occupy more context window space, increasing response time and costs. In cases where agents are connected to thousands of tools, they’ll need to process hundreds of thousands of tokens before reading a request.
[...]
Most MCP clients allow models to directly call MCP tools. For example, you might ask your agent: "Download my meeting transcript from Google Drive and attach it to the Salesforce lead."
The model will make calls like:
TOOL CALL: gdrive.getDocument(documentId: "abc123")
→ returns "Discussed Q4 goals...\n[full transcript text]"
(loaded into model context)
TOOL CALL: salesforce.updateRecord(
objectType: "SalesMeeting",
recordId: "00Q5f000001abcXYZ",
data: { "Notes": "Discussed Q4 goals...\n[full transcript text written out]" }
)
(model needs to write entire transcript into context again)
Every intermediate result must pass through the model. In this example, the full call transcript flows through twice. For a 2-hour sales meeting, that could mean processing an additional 50,000 tokens. Even larger documents may exceed context window limits, breaking the workflow.
With large documents or complex data structures, models may be more likely to make mistakes when copying data between tool calls.
Now, if you were to instead have the LLM write code, that code can perform whatever filtering/aggregation/transformation etc that it needs, without having to round-trip from LLM to tool(s), back and forth, and the only tokens that are consumed are those of the final result. What happens with MCP? All of the text of each MCP call is flooded into the context, only for the LLM to have to make sense of what it just read to then either regurgitate that out into a file to post process (very likely with differences/"hallucinations" slipped in), or in the usual case (I'm personifying the LLM here for rhetorical purposes) it simply tries to reason about what it read to give you the filtered/aggregated/transformed/etc result you're looking for -- again, very likely with mistakes made.
But none of the criticisms here is specific to MCP, just to tool calls in general, it wouldn't matter if the agent used a custom tool protocol, plain OpenAPIs, etc. These issues would still exist.
Sounds like what we need is for the MCP client to expose the tools as libraries for the agent's code interpreter. Then it can write code to wire them together without flowing through context.
We still get the benefits of standardization, higher level RPC endpoints, and vendor-supplied instructions.
You linked to one part of the spec and just wanted to ignore everything else? That's fine, but then you wouldn't be obeying the standard and wouldn't be an "MCP."
So, are you agreeing with me?
Respectfully I think I've engaged with you before and you just seem generally confused about nuanced concepts.
Things like OpenAPI have existed for 15 years now and they also offer standarization.
The value on MCP is not on its features or innovation, but on the rate of adoption it has had. Companies have now an incentive to open, document and standarize their APIs to enable this new distribution channel.
Perhaps you haven't used many MCP server, but those that I have used (GitHub, Atlassian, Glean, BuildKite, Figma, Google Workspace, etc) work very well. They teach an LLM how to do exactly what you're saying - "use the API standards...your models/agents directly interact with those API endpoints." Most MCP severs don't sit in between the LLM and the API endpoints, they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would. I find it works quite well and seems far better than manually maintaining rules or pointing at docs and installing CLI tools (like "gh" for GitHub) or using curl to interact with APIs from a terminal within a chat session.
I suppose someone could try to abuse MCP by stuffing information about REST API endpoints into a the prompt/descriptions in a small MCP "skeleton" service, but I don't know of any. Can you provide examples?
> they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would.
I suspect you might have some deep misunderstandings about MCP.
Sometimes the actions you want to perform does not map cleanly into one or two API calls, or would be too messy to assume correct parsing. Maybe your UI is fine POSTing to /users and PUTing to /groups or whatever but giving the LLM a direct CreateUserAndAddToGroup action simplifies the task and keeps context cleaner.
Imagine a future where we have an evolved version of MCP -- call it MCP++.
In MCP++, instead of having to implement a finite list of specialized variants like CreateUserAndAddToGroup, imagine MCP++ has a way to to feed the desired logic (create user, then add that user to $GROUP) directly to the endpoint. So there would be something like a POST /exec endpoint. And then the /exec endpoint can run the code (maybe it's WASM for something)...
Wait a minute! We already have this. It's called programming.
You could have the LLM write code, so that any pipelining (like your example), aggregation, filtering, or other transformation happens in that code, and the LLM only needs to spend the output tokens to write the code, and the only input tokens consumed is the final result.
I definitely am not the first person to suggest this:
... but I can say that, as soon as I read about MCP, my first thought was "why?"
MCP is wasteful.
If you want LLMs to interact with your software/service, write a library, let the scrapers scrape that code so that future LLM revisions have the library "baked into it" (so you no longer need to spam the context with MCP tool descriptions), and let the LLM write code, which it already "knows" how to do.
What if your library is too new, or has a revision, though?
That's already a solved problem -- you do what you'd do in any other case where you want the LLM to write code for you: point it at the docs / codebase.
yesss, and OpenAI tried this first when they were going to do a “GPT store”. But REST APIs tend to be complicated because they’re supporting apps. MCP, when it works, is very simple functions
in practice it seems like command line tools work better than either of those approaches
Command line tools are my preference just because they're also very useful to humans. I think providing agents function libraries and letting them compose in a repl works about as well but is higher friction due env management.
Also, keep your api small as all the tool call, DTOs and user messages (e.g. workflow recipes) add up to big context windows and accuracy confusion, at least in the latest models. I hope that gets resolved.
This is probably a semantics problem. You’re right. The models don’t know how to mcp. The harness they run in does though (Claude code, Claude desktop, etc), and dynamically exposes mcp tools as tool calls.
HN loves inventing semantics problems around AI. It's gotten really, really annoying and I'm not sure the people doing it are even close to understanding it.
That is an easily falsifiable statement. If I ask ChatGPT or Claude what MCP is Model Context Protocol comes up, and furthermore it can clearly explain what MCP does. That seems unlikely to be a coincidental hallucination.
Both ChatGPT and Claude will perform web searches when you ask them a question, which the fact that you got this confused is ironically topical.
But you're still misunderstanding the principle point because at some point these models will undoubtedly have access to that data and be trained on it.
But they didn't need to be, because LLM function & tool calling is already trained on these models and MCP does not augment this functionality in any way.
OP is saying that the models have not been trained on particular MCP use, which is why MCP servers serve up tool descriptions, which are fed to the LLM just like any other text -- that is, these descriptions consume tokens and take up precious context.
Here's a representative example, taken from a real world need I had a week ago. I want to port a code base from one language to another (ReasonML to TypeScript, for various reasons). I figure the best way to go about this would be to topologically sort the files by their dependencies, so I can start with porting files with absolutely zero imports, then port files where the only dependencies are on files I've already ported, and so on. Let's suppose I want to use Claude Code to help with this, just to make the choice of agent concrete.
How should I go about this?
The overhead of the MCP approach would be analogous to trying to cram all of the relevant files into the context, and asking Claude to sort them. Even if the context window is sufficient, that doesn't matter because I don't want Claude to "try its best" to give me the topological sort straight from its nondeterministic LLM "head".
So what did I do?
I gave it enough information about how to consult build metadata files to derive the dependency graph, and then had it write a Python script. The LLM is already trained on a massive corpus of Python code, so there's no need to spoon feed it "here's such and such standard library function", or "here's the basic Python syntax", etc -- it already "knows" that. No MCP tool descriptions required.
And then Claude code spits out a script that, yes, I could have written myself, but it does it in maybe 1 minute total of my time. I can skim the script and make sure that it does exactly what it should be doing. Given that this is code, and not nondeterministic wishy washy LLM "reasoning", I know that the result is both deterministic and correct. The total token usage is tiny.
If you have the LLM write code to interface with the world, it can leverage its training in that code, and the code itself will do what code does (precisely what it was configured to do), and the only tokens consumed will be the final result.
MCP is incredibly wasteful and provides more opportunities for LLMs to make mistakes and/or get confused.
I think most people, even most devs, don't actually know how crappy an MCP client is built, and that it's essentially an MITM approach and that the client sends the LLM on the other end a crappy pretext of what tools are mounted and how to call their methods in a JSON, and then tries to intelligently guess what response was a tool call.
And that intelligent guess is where it gets interesting for pentesting, because you cannot guess anything failsafe.
Most likely! It's hard to qualify which specific models and version I'm talking about because they're constantly being updated.
But the point is that function & tool calling was already built in. If you take a model from before "MCP" was even referenced on the web it will still _PERFECTLY_ interact with not only other MCP servers and clients but any other API as well.
What whoknowsidont is trying to say (IIUC): the models aren't trained on particular MCP use. Yes, the models "know" what MCP is. But the point is that they don't necessarily have MCP details baked in -- if they did, there would be no point in having MCP support serving prompts / tool descriptions.
Well, arguably descriptions could be beneficial for interfaces that let you interactively test MCP tools, but that's certainly not the main reason. The main reason is that the models need to be informed about what the MCP server provides, and how to use it (where "how to use it" in this context means "what is the schema and intent behind the specific inputs/outputs" -- tool calls are baked into the training, and the OpenAI docs give a good example: https://platform.openai.com/docs/guides/function-calling).
Yeah there's no there there when it comes to MCP. It's crazy to me that the world bought into the idea when the "spec" literally boils down to "have your server give the LLM some json". Just illustrates how powerful it is to attach names to things, especially in a hypestorm in which everyone is already frothing at the mouth and reason is hard to come by. Give people some word they can utter to help them sound like they're on the "bleeding edge" and they'll buy into it even if it's totally pointless.
It gave everyone a reason to think about the usability of the interfaces they were exposing.
Many endpoints have tons of fields irrelevant to 95% of external users. Now those are gone.
Or they implemented higher level abstractions for the actual tasks instead of making developers compose a bunch of little pieces.
And it has a standardized manifest.
Execs, PMs, and customers having that word to utter as part of the AI hype train created the opportunity for that industry-wide cleanup to happen. Calling it pointless is very naive. It's actually kind of extraordinary.
Thanks for offering another perspective on it. I can buy into this partially.
At the same time, I'm skeptical that this won't just become yet another dead protocol once the hype abates, at which point all of the perceived benefits were for naught.
So I don't disagree with any of the criticisms of MCPs but no one here has mentioned why they are useful, and I'm not sure that everyone is aware that MCP is actually just a wrapper over existing cli/API:
1. Claude Code is aware of what MCPs it has access to at all times.
2. Adding an MCP is like adding to the agent's actuators/vocabulary/tools because unlike cli tools or APIs you don't have to constantly remind it what MCPs it has available and "hey you have access to X" and "hey make an MCP for X" take the same level of effort on the part of the user.
3. This effect is _significantly_ stronger than putting info about available API/cli into CLAUDE.md.
4. You can almost trivially create an MCP that does X by asking the agent to create an MCP that does X. This saves you from having to constantly remind an agent it can do X.
NOTE: I cannot stress enough that this property of MCPs is COMPLETELY ORTHOGONAL to the nutty way they are implemented, and I am IN NO WAY defending the implementation. But currently we are talking past the primary value prop.
I would personally prefer some other method but having a way to make agents extensible is extremely useful.
>This effect is _significantly_ stronger than putting info about available API/cli into CLAUDE.md.
No it's not.
Honestly this conversation is extremely weird to me because somehow people are gravely misunderstanding what MCP even purports to do, let alone what it actually CAN do in the most ideal situation.
It is a protocol and while the merits of that protocol is certainly under active discussion it's irrelevant because you keep adding qualities about the protocol that it cannot deliver on.
Just same facts to help steer this conversation correctly, and maybe help your understanding on what is actually going:
* All LLM's/major models have function & tool calling built in.
* Your LLMs/models do not have any knowledge on MCP, nor have they been trained on it.
* MCP exists, at least the claim, is to help standardize the LIFECYCLE of the tool call.
* MCP does not augment or enhance the ability of LLM's in any form.
* MCP does not allow you to extend agents. That's an implicit feature.
* If you have access to "X" (using your example), you don't need anything that obeys the MCP standard.
MCP at best is for developers and tool developers. Your model does not need an MCP server or client or anything else MCP related to do what is already been trained to do.
>I would personally prefer some other method but having a way to make agents extensible is extremely useful.
This response is spot on. People seem very confused about what MCP actually is. It's just a standard way to provide an LLM with tools. And even how that happens is up to the agent implementation. There are some other less common features, but the core is just about providing tool definitions and handling the tool_call. Useful but basically just OpenAPI for LLM
I think people are really underappreciating the "OpenAPI for LLM" part. The hype forced a lot of different SaaS products and vendors of all stripes to actually follow a standard and think somewhat critically about the usability of what they expose.
2. The Claude Code system prompt almost certainly gives directions about how to deal with MCP tools, and may also include the list of tools
3. Instruction adherence is higher when the instructions are placed in the system prompt
If you put these three facts together then it’s quite likely that Claude Code usage of a particular tool (in the generic sense) is higher as an MCP server than as a CLI command.
But why let this be a limitation? Make an MCP server that calls your bash commands. Claude Code will happily vibe code this for you, if you don’t switch to a coding tool that gives better direct control of your system prompt.
1.) Awareness doesn’t mean they will use it. And in practice they often don’t use them.
2.) “ unlike cli tools or APIs you don't have to constantly remind it what MCPs it has available”
- this doesn’t match my experience. In fact, bash commands are substantially more discoverable.
3.) Again, this doesn’t match my experience and the major providers recommend including available MCP tools in system prompts/CLAUDE.md/whatever.
4.) Can’t speak to this as it’s not part of my workflow for the previous reasons.
The only useful MCP for me is Playwright for front end work.
Chrome Devtools is similarly an extremely high value MCP for me.
I would agree that if you don't find they add discoverability then MCPs would have no value for you and be worse than cli tools. It sounds like we have had very opposite experiences here.
Interesting. Perhaps it comes down to which platforms we're working on. I don't want to be outright dismissive of it. My primary platform is Claude Code. Are you working with another driver e.g. OpenAI Codex?
> 3. This effect is _significantly_ stronger than putting info about available API/cli into CLAUDE.md.
What? Why?
> unlike cli tools or APIs you don't have to constantly remind it what MCPs it has available
I think I'm missing something, because I thought this is what MCP does, literally. It just injects the instructions about what tools it has and how to use them into the context window. With MCP it just does it for you rather than you having to add a bit to your CLAUDE.md. What am I misunderstanding?
I think many here have no idea what exactly MCP is, and think it's some sort of magic sauce that transcends how LLMs usually work.
“But Brawndo has what plants crave! It's got electrolytes! '...Okay - what are electrolytes? Do you know? Yeah. It's what they use to make Brawndo.' But why do they use them in Brawndo? What do they do?''They're part of what plants crave.'But why do plants crave them?'Because plants crave Brawndo, and Brawndo has electrolytes.”
― Idiocracy Movie
Also not disagreeing with your argument. Just want to point out that you can achieve the same by putting minimal info about your CLI tools in your global or project specific CLAUDE.md.
The only downside here is that it's more work than `claude mcp add x -- npx x@latest`. But you get composability in return, as well as the intermediate tool outputs not having to pass through the model's context.
How so? The protocol doesn't obfuscate things. Your agent can easily expose the entire MCP conversation, but generally just exposes the call and response. This is no different than any other method of providing a tool for the LLM to call.
You have some weird bone to pick with MCP which is making you irrationally unreceptive to any good-faith attempt to help you understand.
If you want to expose tools to the LLM you have to provide a tool definition to the LLM for each tool and you have to map the LLM's tool calls into the agent executing the tools and returning the results. That's universal for all agent-side tools.
The whole purpose behind MCP was to provide a low-impedance standard where some set of tools could be plugged into an existing agent with no pre-knowledge and all the needed metadata was provided to facilitate linking the tools to the agent. The initial version was clearly focused on local agents running local tools over stdio. The idea of remote tools was clearly an afterthought if you read the specification.
If you want your agent to speak OpenAPI, you are *more* than welcome to make it do so. It'll probably be fine if it's a well-specified API. The context issues won't go away, I guarantee you. OpenAPI specs for APIs with lots of endpoint will result in large tool definitions for the LLM, just like they do with MCP.
A core issue I see with MCP, as someone using it every day, is that most MCP Server developers clearly are missing the point and simply using MCP as a thin translation layer over some existing APIs. The biggest value with MCP is when you realize that an MCP Server should be a *curated* experience for the LLM to interact with and the output should be purposefully designed for the LLM, not just a raw data dump from an API endpoint. Sure, some calls are more like raw data dumps and should have minimal curation, but many other MCP tools should be more like what the OP of this post is doing. The OP is defining a local multi-step workflow where steps feed into other steps and *don't* need LLM mediation. That should be a *single* MCP Server Tool. They could wrap the local bash scripts up into a simple single tool stdio MCP Server and now that tool is easily portable across any agent that speaks MCP, even if the agent doesn't have the ability to directly run local CLI commands.
Anyway, maybe take a breath and be objective about what MCP is and is not meant to do and disconnect what MCP is from how people are *currently* using (and frequently misusing) MCP.
There are tons of articles detailing the problems if you are genuinely interested.
Notice you couldn't technically point to anything to support your statements, but instead had to revert to religious zealotry and apologetics -- which has no place on this forum.
>be objective about what MCP is and is not meant to do and disconnect what MCP is from how people are currently using (and frequently misusing) MCP.
Please re-read what you wrote.
You wrote all of that just to counter your own stated position, because I think at some fundamental level you realize how non-sense it is.
To get this out of the way, you are an unpleasant person, but that doesn't mean you should be ignored though, so I'll reply.
> you couldn't technically point to anything to support your statements, but instead had to revert to religious zealotry and apologetics
> You wrote all of that just to counter your own stated position, because I think at some fundamental level you realize how non-sense it is.
You need to be specific and not make a blanket assertions like that if you want and honest dialog.
I take particular offense at you claiming "religious zealotry". Nothing in my post is even remotely definable as such. Yes, I use MCP, I also recognize when it's the right tool and when it's not. I don't think MCP is the solution to all problems. I also willingly acknowledge that other tools can fill the same gap. If anyone is being a religious zealot here, it's you and your crusade against MCP.
With your lack of specificity, it's hard to formulate a proper response to whatever you see as lacking in references. I would point out that I haven't see one link in all of your railing against MCP until this very response.
So, let's look at your link.
- I agree that websockets would have been a better choice than SSE+HTTP and StreamableHTTP. Auth for WS is a little bit of a pain from the browser, but it's feasible with some common conventions.
- I agree with their characterization of "web seems to be a thing we probably should support" (pretty sure I called that out in my post already...
- Their "kind of breaks the Unix/Linux piping paradigm" is laughable though. MCP is hardly the first or only thing to wire a 'server' to and application via stdin/stdout chaining and it's *very* much in the spirit of UNIX (IMHO, as someone working with UNIX systems for the last 30+ years)
- Again, I fully agree that the current HTTP transports are... lacking and could use a better solution.
- Rant about python aside (I agree BTW), well, they are just ranting actually. Yes, the documentation could use some help. Yes, the wasn't an official Go SDK until recently.
- Given this was written a while ago, it's not worth addressing the callous on SSE+HTTP beyond saying, 100% it was a bad design that appears to have been tacked on at the last minute.
- The observations about StreamableHTTP are mostly valid. They get a few points wrong, but the essence is right.
- Their security concerns are the same ones you'd have with any API, so I'm not sure how this is unique to MCP.
- Auth is a bit of a sore subject for me as well. MCP doesn't have an ergonomic workflow for multi-tenant sets and in-band oauth credential management. Again thoug, I don't disagree with the essence of their point.
After meandering they land on "just use stdio and websockets". So the whole rant is around the protocol transport.I agree the transport protocols need some TLC, but you *can* work with them now and new transports are something that's being worked on, even a WS transport.
None of that post talks about the actual protocol behind MCP, how it's succeeding/failing at filling the needs it's meant to address, or any real viable alternative for a standard for linking tools to agents.
If you feel like calling out specific point you feel I should back up with references, I can likely provide them. As with any post, much of the information is synthesized from a lot of places so things like the assertion that remote servers were clearly an afterthought is purely from my reading of the spec and the remote transports code.
>To get this out of the way, you are an unpleasant person
You are clearly very emotional about this, for whatever reason. But again it has no place on this forum.
>I would point out that I haven't see one link in all of your railing against MCP until this very response.
Because everything I've stated are fundamental facts about the technology. If you need sources for it, that means you are missing elementary concepts.
>After meandering
They literally point out several issues with the protocol that hamper observability.
You're being very verbose but not saying much and ignoring when things are directly answered for you. That's being generous.
Your position is like someone claiming lemongrass supplements cures COVID. Everyone is rightly pointing out that it's a placebo at best. Then your position is "well point out all the ways it DOESN'T help, everyone is doing it!"
Which is a really not-smart position to hold, to say the least.
The absurdity of this response is astounding. As it's clear you have no actual interest is an honest discussion I'll just drop off here and leave you to your echo chamber.
> * Contrary to APIs, they can change their interface whenever they want and with little consequences.
I already made this argument before, but that's not entirely right. I understand that this is how everybody is doing it right now, but that in itself cause issues for more advanced harnesses. I have one that exposes MCP tools as function calls in code, and it encourages the agent to materialize composed MCP calls into scripts on the file system.
If the MCP server decides to change the tools, those scripts break. That is is also similar issue for stuff like Vercel is advocating for [1].
Wouldn't the answer to this be to have the agent generate a new materialized workflow though? You already presumably have automated the agent's ability to create these workflows based off some prompting and a set of MCP Servers.
Put the creds in a file, or secret manager of some sort, and let the LLM write code to read and use the creds. The downside is that you'd need to review the code to make sure that it isn't printing (or otherwise moving) the credentials, but then again you should probably be reviewing what the LLM is doing anyway.
* Contrary to APIs, they can change their interface whenever they want and with little consequences.
The upside is as stated, but the downside is that you're always polluting the context window with MCP tool descriptions.
But …you have to give the MCP the creds somehow. Maybe it’s via a file on disk (bad), maybe via an env var (less bad). Maybe you do it via your password CLI that you biometricly auth to, which involves a timeout of some sort for security, but that often means you can’t leave an agent unattended.
In any case, how is any of this better than a CLI? CLIs have the same access models and tradeoffs, and a persistent agent will plumb the depths of your file system and environment to find a token to do a thing if your prompt was “do a thing, use tool/mcp/cli”.
> What's the alternative design where the model has access to API credentials?
All sorts of ways this can happen but it usually boils down to leaving them on disk or in an environment variable in the repo/dir(s) where the agent is operating in.
Yeah, I'm still confused as to why so many people in "AI engineering" seem to think that MCPs are the key to everything.
They are great if you have a UI that you want and it needs a plugin system, obviously.
But the benefits become much more marginal for a developer of enterprise AI systems with predefined tool selections. They are actually getting overused in this space, if anything, sometimes with security as a primary casualty.
If you are writing a bespoke Agent with a constrained set of tools known in advance, MCP is a detriment. All it will do is introduce complexity, fragility, and latency.
If you have that nice Agent and suddenly marketing "needs" it to talk to Super Service A, you either go back into a dev cycle to create a new set of curated tools that live inside the Agent around SSA *or* you make the Agent capable of acting as an MCP Host and configure a new MCP Client connection to an MCP Server offered by the SSA team. If SSA doesn't have their own MCP Server you could potentially leverage a 3rd-party one or write your own as a fully encapsulated project that doesn't live inside the Agent.
MCP isn't meant to be *the* way you provide tools for your Agent, it's meant to prove a *standard* that allows you to easily add off-the-shelf tool sets via simply configuring the Agent.
Mario has some fantastic content, and has really shaped how I think about my interface to coding tools. I use a modified version of his LLM-as-crappy-state-machine model (https://github.com/badlogic/claude-commands) for nearly all my coding work now. It seems pretty clear these days that progressive discovery is the way forward (e.g. skills), and using CLI tools rather than MCP really facilitates that. I've gone pretty far down the road of writing complex LLM tooling, and the more I do that the more the simplicity and composability is appealing. He has a coding agent designed along the same principles, which I'm planning to try out (https://github.com/badlogic/pi-mono/tree/main/packages/codin...).
I like MCP for _remote_ services such as Linear, Notion, or Sentry. I authenticate once and Claude has the relevant access to access the remote data. Same goes for my team by committing the config.
Can I “just call the API”? Yeah, but that takes extra work, and my goal is to reduce extra work.
You don’t need formal tools. You only need a bash tool that can run shell scripts and cli tools!
Overwhelmed by Sentry errors recently I remembered sentry-cli. I asked the agent to use it to query for unresolved Sentry errors and make a plan that addresses all of them at once. Zeroed out my Sentry inbox in one Claude Code plan. All up it took about an hour.
The agent was capable of sussing out sentry-cli, even running it with --help to understand how to use it.
The same goes for gh, the github cli tool.
So rather than MCPs or function style tools, I highly recommend building custom cli tools (ie. shell scripts), and adding a 10-20 word description of each one in your initial prompt. Add --help capabilities for your agent to use if it gets confused or curious.
To add to this, agents view the world through sort of a "choose your own adventure" lens. You want your help output to basically "prompt" the agent, and provide it a curated set of options for next steps (ideally between 4-8 choices). If your CLI has more options than that, you want to break as much as possible into commands. The goal is to create an "decision tree" for the agent to follow based on CLI output.
> Each tool is a simple Node.js script that uses Puppeteer Core. By reading that README, the agent knows the available tools, when to use them, and how to use them via Bash.
> When I start a session where the agent needs to interact with a browser, I just tell it to read that file in full and that's all it needs to be effective. Let's walk through their implementations to see how little code this actually is.
Cool, now you want to package that so others can use it? What next?
Put it behind an MCP is an easy approach. Then I can just install that MCP and by choosing it I have all the capabilities mentioned here.
Or in this particular case, a Claude Skill could likely do as well.
But I mean, that's MCP. I don't even really understand the people discussing that MCP is bad or whatever, it's a plug and play protocol so I can package tools for others to use in their preferred agent client.
CLI access also has the issue that if you want to integrate it in an application, well how do you bundle bash in a secure way so your agent can use it? And would you allow users custom tool call, now they can run arbitrary bash commands?
I can see where Mario is coming from, but IMO MCP still has a place because it 1) solves authentication+discoverability, 2) doesn't require code execution.
MCP shines when you want to add external functionality to an agent quickly, and in situations where it's not practical to let an agent go wild with code execution and network access.
Feels like we're in the "backlash to the early hype" part of the hype cycle. MCP is one way to give agents access to tools; it's OK that it doesn't work for every possible use case.
Oh, I didn't intend this to come across as MCP being useless. I've written this from the perspective of someone who uses LLMs mostly for coding/computer tasks, where I found MCP to be less than ideal for my use cases.
I actually think MCP can be a multiplier for non-technical users, where it not for some nits like being a bit too technical and the various security footguns many MCP servers hand you.
MCP was created so llm companies can have a plugin system. So instead of them being the API provider, they can become the platform that we build apps/plugins for, and they become the user interface to end consumers.
MCP defines the API so vendors of LLM tools like cursor, claude code, codex etc don't all make their own bespoke, custom ways to call tools.
The main issue is the disagreement on how to declare the MCP tool exists. Cursor, vscode, claude all use basically the same mcp.json file, but then codex uses `config.toml`. There's very little uniformity in project-specific MCP tools as well, they tend to be defined globally.
>but isn't this solved by publishing good API docs, and then pointing the LLM to those docs as a training resource?
Yes.
It's not a dumb question. The situation is so dumb you feel like an idiot for asking the obvious question. But it's the right question to ask.
Also you don't need to "train" the LLM on those resources. All major models have function / tool calling built in. Either create your own readme.txt with extra context or, if it's possible, update the API's with more "descriptive" metadata (aka something like swagger) to help the LLM understand how to use the API.
You keep saying that major models have "tool calling built in". And that by giving them context about available APIs, the LLM can "use the API".
But you don't explain, in any of your comments, precisely how an LLM in practice is able to itself invoke an API function. Could you explain how?
A model is typically distributed as a set of parameters, interpreted by an inference framework (such as llama.cpp), and not as a standalone application that understands how to invoke external functions.
So I am very keen to understand how these "major models" would invoke a function in the absence of a chassis container application (like Claude Code, that tells the model, via a prompt prefix, what tokens the model should emit to trigger a function, and which on detection of those tokens invokes the function on the model's behalf - which is not at all the same thing as the model invoking the function itself).
Just a high level explanation of how you are saying it works would be most illuminating.
The LLM output differentiates between text output intended for the user to see, vs tool usage.
You might be thinking "but I've never seen any sort of metadata in textual output from LLMs, so how does the client/agent know?"
To which I will ask: when you loaded this page in your browser, did you see any HTML tags, CSS, etc? No. But that's only because your browser read the HTML rendered the page, hiding the markup from you.
Similarly, what the LLM generates looks quite different compared to what you'll see in typical, interactive usage.
The schema is enforced much like end-user visible structured outputs work -- if you're not familiar, many services will let you constrain the output to validate against a given schema. See for example:
It is. Anthropic builds stuff like MCP and skills to try and lock people into their ecosystem. I'm sure they were surprised when MCP totally took off (I know I was).
LLMs were trained on the how we use text interfaces. You don't need to adopt command line for an LLM to use. You don't really need RAG - just connect the LLM to the shell tools we are using for search. And ultimately it would be much more useful if the language servers had good cli commands and LLMs were using them instead of going via MCP or some other internal path - ripgrep is already showing how much more usable it is this way.
When an MCP tool is used, all of the output is piped straight into the LLM's context. If another MCP tool is needed to aggregate/filter/transform/etc the previous output, the LLM has to try ("try" is a keyword -- LLMs are by their nature nondeterministic) and reproduce the needed bits as inputs into the next tool use. This increases latency dramatically and is an inefficient use of tokens.
This "a1" project, if I'm reading it correctly, allows for pipelining multiple consecutive tool uses without the LLM/agent being in the loop, until the very end when the final results are handed off to the LLM.
IMO MCP isn't totally dead, but its role has shrunk. Quoting from my post [1]:
"Instead of a bloated API, an MCP should be a simple, secure gateway... MCP’s job isn’t to abstract reality for the agent; its job is to manage the auth, networking, and security boundaries and then get out of the way."
You still need some standard to hook up data to agents esp when the agents are not running on your local dev machine. I don't think e.g. REST/etc are nearly specific enough to do this without a more constrained standard for requests.
Admittedly, the scripts+README approach works well for individual setups and is extremely token-efficient, since it only loads a tiny README and the model can infer how to run the scripts. But that convenience depends on a single local environment—one shell, one OS, etc.
MCP is aimed at the opposite scenario: distributing tools to many users without relying on their environments. It provides automatic tool discovery, a server boundary that isolates credentials, and strict control over exposed capabilities. Its heavier JSON-schema definitions exist because they’re machine-readable contracts that behave consistently across clients, whereas CLI tools vary drastically across systems. So while MCP adds context overhead, it solves portability and distribution problems that scripts simply can’t.
What I've started experimenting with and will continue to explore is to have project-specific MCP tools.
I add MCP tools to tighten the feedback loop. I want my Agent to be able to act autonomously but with a tight set of capabilities that don't often align with off-the-shelf tools. I don't want to YOLO but I also don't want to babysit it for non-value-added, risk-free prompts.
So, when I'm developing in go, I create `cmd/mcp` and configure a `go run ./cmd/mcp` MCP server for the Agent.
It helps that I'm quite invested in MCP and built github.com/ggoodman/mcp-server-go, which is one of the few (only?) MCP SDKs that let you scale horizontally over https while still supporting advanced features like elicitation and sampling. But for local tools, I can use the familiar and ergonomic stdio driver and have my Agent pump out the tools for me.
Horizontal scaling of remote MCP Servers is something the spec is sadly lacking any recognition around. If you've done work in this space, bravo. I've been using a message bus to decouple the HTTP servers from the MCP request handlers. I'm still evolving the solution, but it's been interesting so far.
a) I have agents in production for enterprise companies that did what they were supposed to (automate a human process, alter the point of the whole division, lower cost, increase revenue)
b) the whole industry seems to be failing at doing a) to the point they think its all hype
c) the whole industry thinks they need MCP servers and I don’t
MCP has been a weird ride. I built https://terminalwire.com before MCP was a thing to make it way easier for people to add a CLI/TUI to their web apps/SaaS.
Then MCP comes out and AI explodes, sucking all the air out of the room for non-AI tools.
Now it seems like AI can work with CLIs better than MCP, so I’m tempted to slap AI integration all over the project to better convey the idea.
It’s crazy how quickly MCP has run it’s course and watching an entire ecosystem rediscover things from first principals.
Will have a think about how this can extended to other types of uses.
I have personally been trying to replace all tools/MCPs with a single “write code” tool which is a bit harder to get to work reliably in large projects.
MCP sounds like the modern equivalent of COM, where you could query an object to see what functions it exposed but had zero idea of what they did. MCP is the same: apparently it is LLM-readable, but the explanations of what everything does are human readable, and there is no standard on operations available.
Hey we actually just released rtrvr.ai, our AI Web Agent Chrome Extension, as a Remote MCP Server that obviates lot of the setup you needed to do. We had the same intuition that the easiest way to scrape is through your own browser and so we expose dedicated MCP tools to do actions, scrape pages, and execute arbitrary code in Chrome's built in sandbox.
We give a copy/pasteable MCP url that you can use with your favorite agent/chatbot/site and give those providers browser context and allow them to do browser actions.
So compared to Playwright MCP and others that require you to run npx and can only be connected to local clients, with ours you just paste a url and can use with any client.
select * from protocols
# ipc, tcp, http, websockets, ...?
MCP and A2A are JSONRPC schemas people follow to build abstraction around their tools. Agents can use MCP to discover tools, invoke and more. OpenAPI Schemas are good alternatives to MCP servers today. In comparison to OpenAPI Schemas, MCP servers are pretty new.
my fav protocol is TCP, which I am a proud user of nc localhost 9999.
but not everyone have same taste of building software.
Skills are basically just a prompt and (optionally) some tools, only with a preamble that means they are selectively brought into context only as needed.
Claude just reads the SKILL.md frontmatter into initial context and when the instructions match it reads the rest of the SKILL.md. Every LLM can do that.
To be fair other providers have to implement reading a skill directory and only the frontmatter of the SKILL.md and read more of it when needed. But it's a LOT simpler than implementing MCP.
Moderne Ai agent tool have have a setting where you can trimm down the numbers of tools from an MCP server. Usefull to avoid overwhelming the LLM with 80 tools description when you only need 1
I don't find that to help much at all, particularly because some tools really only make sense with a bunch of other tools and then your context is already polluted. It's surprisingly hard to do this right, unless you have a single tool MCP (eg: a code/eval based tool, or an inference based tool).
Don't you have a post about writing Python instead of using MCP? I can't see how MCP is more efficient than giving the LLM a bunch of function signatures and allow it to call them, but maybe I'm not familiar enough with MCP.
> Don't you have a post about writing Python instead of using MCP?
Yes, and that works really well. I also tried various attempts of letting agents to write code that exposes MCP tool calls via an in-language API. But it's just really, really hard to work with because MCP tools are generally not in the training set, but normal APIs are.
Yeah, I've always thought that your proposal was much better. I don't know why one of the big companies hasn't released something that standardised on tool-calling via code, hm.
MCP is yet another waste of effort trying to recreate what we had with REST over 20 years ago.
Yes, APIs should be self-documenting. Yes, response data should follow defined schemas that are understandable without deep knowledge of the backend. No, you don't need MCP for this.
I wish Google would have realized, or acknowledged, that XML and proper REST APIs solve both of these use cases rather than killing off XSLT support and presumably helping to coerce the other browsers and WhatWG to do the same.
As abstruse as GraphQL is, it does have legitimate use cases. I say this as someone who avoided it for a long time for aesthetic reasons. MCP on the other hand is all hype.
Yeah, "MCP" felt like BS from jump. Basically it's the problem that will always be a problem, namely "AI stuff is non-deterministic."
If there was some certainty MCP could add to this equation that would perhaps be theoretically nice, but otherwise it's just .. parsing, a perhaps not "solved" problem, but one for which there's already ample solutions.
The whole point of "agentic AI" is that you don't have to rigorously test every potential interaction, which means that even a temperature zero model may behave unexpectedly, which is bad for security.
MCP is how you wrap/distribute/compose things related to tool-use. Tool-use is how you insist on an IO schema that LLMs must conform to. Schemas are how you combat hallucination, and how you can use AI in structured ways for things that it wasn't explicitly trained on. And this is really just scratching the surface of what MCP is for.
You can throw all that away by rejecting MCP completely or by boiling tool-use down to just generating and running unstructured shell commands. But setting aside security issues or why you'd want to embrace more opportunities for hallucination instead of less.. shelling out for everything is perfect faith in the model's ability to generate correct bash for an infinite space of CLI surfaces. You've lost the ability to ever pivot to smaller/cheaper/local models, and now you're more addicted to external vendors/SOTA models.
Consider the following workflow with a large CLI surface that's a candidate for a dedicated LLM tool, maybe ffmpeg. Convert the man page to a JSON schema. Convert the JSON schema to a tool. Add the tool to a MCP server, alongside similar wizards for imagemagick/blender. The first steps can use SOTA models if necessary, but the later steps can all feasibly work for free, as a stand-alone app that has no cloud footprint and no subscription fee. This still works if ffmpeg/blender/imagemagick were private custom tools instead of well-known tools that are decades old. You can test the tools in offline isolation too. And since things like fastmcp support server composition you can push and pop that particular stack of wizards in or out of LLM capabilities.
Good luck getting real composition with markdown files and tweaking prompts for tone by adding a "Please" preamble. Good luck engineering real systems with vague beliefs about magic, no concrete specifications for any part of any step, constantly changing external dependencies, and perfect faith in vendors.
Instead of tools for humans, and a separate set of tools for machines, we should just make tools for humans+machines.
The agent should look at my README.md, not a custom human-like text that is meant to be read by machines only.
It also should look at `Makefile`, my bash aliases and so on, and just use that.
In fact, many agents are quite good at this (Code Fast 1, Sonnet).
Issue is, we have a LONG debt around those. READMEs often suck, and build files often suck. We just need to make them better.
I see agents as an opportunity for making friendlier repos. The agent is a free usability tester in some sense. If it can't figure out by reading the human docs, then either the agent is not good enough or your docs aren't good enough.
I agree with what Mario says overall and I can be honest, I don't really use MCP I don't think - at least not what it's intended for (some sort of plugin system for extensbile capabilities). I use it for an orchestration layer, and for that it's great.
When MCP itself works it's great. For example, we organize units of work into "detective cases" for framing and the corresponding tool is wanderland__get_detective_case. Spawn a Claude Code session, speak "get up to speed on our current case" and we have instant context loading in a sub-agent session, useful when the Jira ticket requires input from another repository (or two). They're all writing back through the same wanderland__add_detective_case_note call and that routes everything through the central attractor to the active case.
Most of the time, the case we're working on was just a "read DVOPS-XXXXX in Jira and create a case for me". That's wanderland_get_jira_ticket (a thin wrapper on the jira cli) and wanderland__create_detecive_case in turn.
The secret to mcp is that it breaks a lot, or they forget about it because their context is polluted (or you broke it because you're working on it). But it's just a thin wrapper over your API anyways, so just ensure you've got a good /docs endpoint hanging off that and a built in fetch (or typically a fallback to bash with curl -s for some reason) and you're back up and running until you can offload that context. At least you should be if you've designed it properly. Throw in a CLI wrapper for your API as well, they love those :) Three interfaces to the same tool.
The MCP just offers the lowest friction, the context on how to use it injected automatically at a level low enough to pick it up in those natural language emissions and map it to the appropriate calls.
And, if you're building your own stack anyways, you can do naughty things to the protocol like like inject reminders from your agenda with weighted probabilities (gets more nagging the more you're overdue) or inject user-guides from the computational markdown graph the platform is built on when their tools are first used (we call that the helpful, yet somewhat forceful barrista pattern, no choice but to accept the paper and a summary of the morning news with your coffee in the morning). Or restrict the tools available based on previous responses (the more frustrated you get, the more we're likely to suggest you read a book Claude). Or when your knowledge graph is spatially oriented, you can do fun things like make sure we go east or west once in a while (variations on related items) rather than purely north south (into and out of specific knowledge veriticals) with simple vector math.
MCP isn't strictly necessary for all of this, that could be (and in some cases rightly is) implemented at the API layer, but the MCP layer does give us a simple place to reason about agentic behaviour and keeps it away from the tools itself. In other words, modeling error rates as frustration and restricting tool use / injecting help guides make sense in one layer and injecting reminders into a response from the same system that's processing the underlying tool calls makes sense in another, if the protocol you've designed for such things allows for such two way context passing. Absent any other layer in the current stack (and no real desire to implement the agentic loop on my own at the moment), the MCP protocol seems perfectly suited for these types of shennanigans - view it like something like Apigee or (...) API Gateway, adding a bit of intelligence and remixability on top of your tools for better UX with your agents
MCP is something that's filled with buzzwords and seems like something created solely so that you can be "sold" something. From what I actually gathered, it's basically somehow four things rolled into one:
* A communication protocol, json-rpc esque except it can be done over stdio or via HTTP
* A discovery protocol, like Swagger, to document the "tools" that an endpoint exposes and how it should be used
* A tool calling convention, the specific sequence of tokens the LLM needs to output for something to be recognized as a tool call
* A thin glue layer orchestrating all of the above: injecting the list of available tools into the LLM context, parsing LLM output to detect tool calls and invoke them with appropriate args, and inject results back into LLM context
> * A thin glue layer orchestrating all of the above: injecting the list of available tools into the LLM context, parsing LLM output to detect tool calls and invoke them with appropriate args, and inject results back into LLM context
Yeah llm rules. You think there must be something more to it. There's not.
I think that's being generous, we haven't even had the Rails moment with AI yet. Shit, I'm not sure we've had the jQuery moment yet. I think we're still in the Perl+CGI phase.
AI has lots of this 'fake till you make it' vibe from startups. And unfortunately it wins - because these hustler guys get a lot of money from VCs before their tools are vetted by the developers.
Yeah, and just like the web space there will be a plethora of different frameworks out there all solving the same problems in their own slightly different, uniquely crappy ways and an entire pointless industry built around ceaselessly creating and rehashing and debating this needlessly bloated ecosystem of competing solutions will emerge and employ many "ai engineers".
Outside of a few notable exceptions, the software industry has become such a joke.
It’s like the email scams that filter people out with bad spelling and obvious red flags. If someone makes it through those hurdles they’re probably a good prospect. You weren’t really thinking of buying it, were you?
MCP was a really shitty attempt at building a plugin framework that was vague enough to lure people into and then allow other companies to build plugin platforms to take care of the MCP non-sense.
"What is MCP, what does it bring to the table? Who knows. What does it do? The LLM stuff! Pay us $10 a month thanks!"
LLM's have function / tool calling built into them. No major models have any direct knowledge of MCP.
Not only do you not need MCP, but you should actively avoid using it.
Stick with tried and proven API standards that are actually observable and secure and let your models/agents directly interact with those API endpoints.
> LLM's have function / tool calling built into them. No major models have any direct knowledge of MCP.
but the major user interfaces for operating LLMs do and that's what matters
> Not only do you not need MCP, but you should actively avoid using it.
> Stick with tried and proven API standards that are actually observable and secure and let your models/agents directly interact with those API endpoints.
so what's the proven and standard API I can use to interact with ableton live? blender? unity3d? photoshop?
[flagged]
What do all of the links below have in common? Do you know of another way you can control all of those applications via LLMs? Computer use?
https://github.com/ahujasid/ableton-mcp
https://github.com/ahujasid/blender-mcp
https://github.com/CoplayDev/unity-mcp
https://github.com/mikechambers/adb-mcp
The mcp part is not essential for the actual controlling of the applications. You could “rip out” the mcp functionality and replace it with something else. The only reason why the authors chose mcp is most likely that it was the first and therefore most common plugin interface for llm tools.
Unfortunately, most standards that we end up with are only standard because they're are widely used and not because they are the best or they make the most sense.
It's not even a standard. It's literally not doing anything here. Not only "can" you rip out MCP there is zero technical reason for any of those things to be an "MCP" in the first place.
MCP literally is the "something else", if you have a better idea in mind, now is the time to bring it out before the MCP train is going too fast to catch up.
(Not OP)
This is pretty well established. See for example:
https://www.anthropic.com/engineering/code-execution-with-mc...
https://blog.cloudflare.com/code-mode/
Code (including shell scripting) allows the LLM to manipulate the results programmatically, which allows for filtering, aggregation and other logic to occur without multiple round trips between the agent and tool(s). This results in substantially less token usage, which means less compute waste, less cost, and less confusion/"hallucination" on the LLM's part.
If one comes to the same conclusion that many others have (including CloudFlare) that code should be the means by which LLMs interface with the world, then why not skip writing an MCP server and instead just write a command-line program and/or library (as well as any public API necessary)?
Isn't that the point they are making? MCP is useful because everyone is using it, not because it has a technical advantage over rolling your own solution. It won mindshare because of marketing and a large company pushing it.
I've actually taken to both approaches recently, using the mcp-client package to give me an interface to a wide array of prebuilt tools in my non-LLM application. I could have written or sourced 10 different connectors, or I can write one client interface and any tool I plug in shares the same standard interface as all the others.
Can you do yourself a favor and look at the source code and tell me why you think MCP is necessary here?
I mean you just took some examples and went "See MCP!" without any actual understanding of what that code is doing.
All of these have underlying API's that have exactly ZERO need for MCP. All of this functionality already exists and can be used with LLM's.
* https://help.ableton.com/hc/en-us/articles/209072009-Install...
* https://docs.blender.org/api/current/info_quickstart.html
* https://docs.unity3d.com/6000.2/Documentation/ScriptReferenc...
The most hilarious quote from one of those projects:
>The proxy server is required because the public facing API for UXP Based JavaScript plugin does not allow it to listen on a socket connection (as a server) for the MCP Server to connect to (it can only connect to a socket as a client).
Maybe that should have been the sign that this was completely unnecessary and stupid?
>Do you know of another way you can control all of those applications via LLMs?
Seriously. This becoming a bad joke. I mean conceptually, what did you think was happening here? MCP was just magically doing something that didn't already exist before?
It's a waste of effort and time. Do not use MCP.
So again, how do I automate Ableton live over a network socket with a standard API? I don't know if you've read the remote control API but it doesn't open a magic socket to remote control Live, you have to code the entire integration and protocol yourself to map whatever API messages you want to Live actions manually.
Let's forget about LLMs completely as they are only tangentially relevant to the benefits of MCP. I want to write 15 lines of python that - no matter the software - is going to trigger the "play" button/action in that software. E.g. I want to hit "play" in both Ableton, Unity and Blender without having to write three times the code, without having to manually write them each an extension plug-ins. How do you do that, today, 2025-11-17 ?
Idk what you think you have to gain with your stance lol
No one looks at MCP and sees "magic", they just see "finished integration". Something you can pretty much use straight away. That's the point.
> MCP was a really shitty attempt at building a plugin framework
Can you go more in depth? The protocol is relatively simple, what about it you feel is "shitty" as a plugin framework?
The hate for MCP here is absurd.
It's JSON-RPC, with some descriptors.
And some comments about OAuth 2.
The value is in the consensus. You can make a tool that agents can connect to with no apriori knowledge.
Actually, MCP wastes a lot of tokens when compared to regular tool calling. You might not notice it on more trendy models with large contexts, but for those of us trying to use locked down/local/cheap models it makes very little sense.
Also, MCP creates a new problem: providing the model with too much context when trying to combine tools across multiple servers. It works OK with small, very focused servers (like helpers for a specific data set), but if you try to mix and match servers things get out of hand really quickly and the entire workflow becomes very unreliable—too many options to digest and pursue, just like humans.
Is that just bad implementation? Where are the wasted tokens?
I noticed your second issue, but to me it's just from bad implementation. For some reason people keep exposing generic overlapping tools from multiple MCP servers.
I don't know that MCP causes this issue, any vendor offering a "tools API" if they shove to many APIs it would bloat things up.
> Is that just bad implementation? Where are the wasted tokens?
How wouldn't it be wasteful?
I'll try to summarize a couple sources:
https://www.anthropic.com/engineering/code-execution-with-mc...
https://blog.cloudflare.com/code-mode/
Here's what Anthropic has to say about it: As MCP usage scales, there are two common patterns that can increase agent cost and latency:
Now, if you were to instead have the LLM write code, that code can perform whatever filtering/aggregation/transformation etc that it needs, without having to round-trip from LLM to tool(s), back and forth, and the only tokens that are consumed are those of the final result. What happens with MCP? All of the text of each MCP call is flooded into the context, only for the LLM to have to make sense of what it just read to then either regurgitate that out into a file to post process (very likely with differences/"hallucinations" slipped in), or in the usual case (I'm personifying the LLM here for rhetorical purposes) it simply tries to reason about what it read to give you the filtered/aggregated/transformed/etc result you're looking for -- again, very likely with mistakes made.But none of the criticisms here is specific to MCP, just to tool calls in general, it wouldn't matter if the agent used a custom tool protocol, plain OpenAPIs, etc. These issues would still exist.
Sounds like what we need is for the MCP client to expose the tools as libraries for the agent's code interpreter. Then it can write code to wire them together without flowing through context.
We still get the benefits of standardization, higher level RPC endpoints, and vendor-supplied instructions.
> Now, if you were to instead have the LLM write code
Okay....now what function calls or libraries should the API use to write that code?
Anthropic article describes a good approach, combining code gen with MCP.
>It's JSON-RPC, with some descriptors.
That's not even true. It defines the lifecycle of tool calling.
JSON-RPC with some descriptors would have been fine and amazing.
I’m struggling to understand where you’re coming from. Your hate for MCP seems grossly outsized relative to what it actually is.
This comment is unhinged.
https://modelcontextprotocol.info/docs/concepts/transports/
You linked to one part of the spec and just wanted to ignore everything else? That's fine, but then you wouldn't be obeying the standard and wouldn't be an "MCP."
So, are you agreeing with me?
Respectfully I think I've engaged with you before and you just seem generally confused about nuanced concepts.
I'm open mindedly hoping you'll be more specific in what about the protocol you find problematic?
The base protocol is just JSON-RPC, and then you have to implement initialize. Everything else is optional.
Things like OpenAPI have existed for 15 years now and they also offer standarization.
The value on MCP is not on its features or innovation, but on the rate of adoption it has had. Companies have now an incentive to open, document and standarize their APIs to enable this new distribution channel.
Perhaps you haven't used many MCP server, but those that I have used (GitHub, Atlassian, Glean, BuildKite, Figma, Google Workspace, etc) work very well. They teach an LLM how to do exactly what you're saying - "use the API standards...your models/agents directly interact with those API endpoints." Most MCP severs don't sit in between the LLM and the API endpoints, they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would. I find it works quite well and seems far better than manually maintaining rules or pointing at docs and installing CLI tools (like "gh" for GitHub) or using curl to interact with APIs from a terminal within a chat session.
> but those that I have used (GitHub, [...])
> Most MCP severs don't sit in between the LLM and the API endpoints [...]
Your first example certainly isn't an example of that: https://github.com/github/github-mcp-server
I suppose someone could try to abuse MCP by stuffing information about REST API endpoints into a the prompt/descriptions in a small MCP "skeleton" service, but I don't know of any. Can you provide examples?
> they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would.
I suspect you might have some deep misunderstandings about MCP.
>, they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would.
No. MCP does not do this. Function & tool calling is built into the LLM. MCP is not augmenting this ability in ANY way.
probably easier to just tell people: You want MCP? Add a "description" field to your rest API that describes how to call it.
That's all it's doing. Just plain ole context pollution. World could be better served by continuing to build out the APIs that exist.
Sometimes the actions you want to perform does not map cleanly into one or two API calls, or would be too messy to assume correct parsing. Maybe your UI is fine POSTing to /users and PUTing to /groups or whatever but giving the LLM a direct CreateUserAndAddToGroup action simplifies the task and keeps context cleaner.
This is very true. But why stop there?
Imagine a future where we have an evolved version of MCP -- call it MCP++.
In MCP++, instead of having to implement a finite list of specialized variants like CreateUserAndAddToGroup, imagine MCP++ has a way to to feed the desired logic (create user, then add that user to $GROUP) directly to the endpoint. So there would be something like a POST /exec endpoint. And then the /exec endpoint can run the code (maybe it's WASM for something)...
Wait a minute! We already have this. It's called programming.
You could have the LLM write code, so that any pipelining (like your example), aggregation, filtering, or other transformation happens in that code, and the LLM only needs to spend the output tokens to write the code, and the only input tokens consumed is the final result.
I definitely am not the first person to suggest this:
https://www.anthropic.com/engineering/code-execution-with-mc...
https://blog.cloudflare.com/code-mode/
... but I can say that, as soon as I read about MCP, my first thought was "why?"
MCP is wasteful.
If you want LLMs to interact with your software/service, write a library, let the scrapers scrape that code so that future LLM revisions have the library "baked into it" (so you no longer need to spam the context with MCP tool descriptions), and let the LLM write code, which it already "knows" how to do.
What if your library is too new, or has a revision, though?
That's already a solved problem -- you do what you'd do in any other case where you want the LLM to write code for you: point it at the docs / codebase.
yesss, and OpenAI tried this first when they were going to do a “GPT store”. But REST APIs tend to be complicated because they’re supporting apps. MCP, when it works, is very simple functions
in practice it seems like command line tools work better than either of those approaches
Command line tools are my preference just because they're also very useful to humans. I think providing agents function libraries and letting them compose in a repl works about as well but is higher friction due env management.
> Just plain ole context pollution.
It would normally be a second context window to figure out what tool / agent to run.
My only quibble with MCP is in the usual AI bandwagon people are implementing for FOMO than business value. My experience is likely anecdotal though.
> Add a "description" field to your rest API that describes how to call it.
Isn't that swagger\grpc etc?
Also, keep your api small as all the tool call, DTOs and user messages (e.g. workflow recipes) add up to big context windows and accuracy confusion, at least in the latest models. I hope that gets resolved.
> World could be better served by continuing to build out the APIs that exist.
before LLM's and MCP the world was depreciating or locking down APIs
MCP is an example of "worse is better". Everyone knows that it's not very good, but it gets the job done.
Fully agree, however we need to reach our KPIs and OKRs regarding AI adoption.
> No major models have any direct knowledge of MCP.
Claude and ChatGPT both support MCP, as does the OpenAI Agents SDK.
(If you mean the LLM itself, it is "known" at least as much as any other protocol. For whatever that means.)
>it is "known" at least as much as any other protocol.
No. It is not. Please understand what the LLM's are doing. Claude nor ChatGPT nor any major model knows what MCP is.
They know how to function & tool call. They have zero trained data on MCP.
That is a factual statement, not an opinion.
This is probably a semantics problem. You’re right. The models don’t know how to mcp. The harness they run in does though (Claude code, Claude desktop, etc), and dynamically exposes mcp tools as tool calls.
>dynamically exposes mcp tools as tool calls.
It doesn't even do that. It's not magic.
HN loves inventing semantics problems around AI. It's gotten really, really annoying and I'm not sure the people doing it are even close to understanding it.
That is an easily falsifiable statement. If I ask ChatGPT or Claude what MCP is Model Context Protocol comes up, and furthermore it can clearly explain what MCP does. That seems unlikely to be a coincidental hallucination.
Training data =/= web search
Both ChatGPT and Claude will perform web searches when you ask them a question, which the fact that you got this confused is ironically topical.
But you're still misunderstanding the principle point because at some point these models will undoubtedly have access to that data and be trained on it.
But they didn't need to be, because LLM function & tool calling is already trained on these models and MCP does not augment this functionality in any way.
Claude gives me a lengthy explanation of MCP with web search disabled
Great! It's still irrelevant.
You're misinterpreting OP.
OP is saying that the models have not been trained on particular MCP use, which is why MCP servers serve up tool descriptions, which are fed to the LLM just like any other text -- that is, these descriptions consume tokens and take up precious context.
Here's a representative example, taken from a real world need I had a week ago. I want to port a code base from one language to another (ReasonML to TypeScript, for various reasons). I figure the best way to go about this would be to topologically sort the files by their dependencies, so I can start with porting files with absolutely zero imports, then port files where the only dependencies are on files I've already ported, and so on. Let's suppose I want to use Claude Code to help with this, just to make the choice of agent concrete.
How should I go about this?
The overhead of the MCP approach would be analogous to trying to cram all of the relevant files into the context, and asking Claude to sort them. Even if the context window is sufficient, that doesn't matter because I don't want Claude to "try its best" to give me the topological sort straight from its nondeterministic LLM "head".
So what did I do?
I gave it enough information about how to consult build metadata files to derive the dependency graph, and then had it write a Python script. The LLM is already trained on a massive corpus of Python code, so there's no need to spoon feed it "here's such and such standard library function", or "here's the basic Python syntax", etc -- it already "knows" that. No MCP tool descriptions required.
And then Claude code spits out a script that, yes, I could have written myself, but it does it in maybe 1 minute total of my time. I can skim the script and make sure that it does exactly what it should be doing. Given that this is code, and not nondeterministic wishy washy LLM "reasoning", I know that the result is both deterministic and correct. The total token usage is tiny.
If you look at what Anthropic and CloudFlare have to say on the matter (see https://www.anthropic.com/engineering/code-execution-with-mc... and https://blog.cloudflare.com/code-mode/), it's basically what I've described, but without explicitly telling the LLM to write a script / reviewing that script.
If you have the LLM write code to interface with the world, it can leverage its training in that code, and the code itself will do what code does (precisely what it was configured to do), and the only tokens consumed will be the final result.
MCP is incredibly wasteful and provides more opportunities for LLMs to make mistakes and/or get confused.
> That is a factual statement,
I think most people, even most devs, don't actually know how crappy an MCP client is built, and that it's essentially an MITM approach and that the client sends the LLM on the other end a crappy pretext of what tools are mounted and how to call their methods in a JSON, and then tries to intelligently guess what response was a tool call.
And that intelligent guess is where it gets interesting for pentesting, because you cannot guess anything failsafe.
(pedantry)it's something humans are talking about a lot, so up-to-date models do know about it...
Most likely! It's hard to qualify which specific models and version I'm talking about because they're constantly being updated.
But the point is that function & tool calling was already built in. If you take a model from before "MCP" was even referenced on the web it will still _PERFECTLY_ interact with not only other MCP servers and clients but any other API as well.
> They have zero trained data on MCP.
They have significant data trained on MCP.
> They know how to function & tool call.
Right. You can either use MCP to transmit those tool calls, or you can create some other interface.
>They have significant data trained on MCP.
No they don't lol.
Wild claim.
MCP has been popular for well over a year.
To filter it out of the training data would be laughable.
What whoknowsidont is trying to say (IIUC): the models aren't trained on particular MCP use. Yes, the models "know" what MCP is. But the point is that they don't necessarily have MCP details baked in -- if they did, there would be no point in having MCP support serving prompts / tool descriptions.
Well, arguably descriptions could be beneficial for interfaces that let you interactively test MCP tools, but that's certainly not the main reason. The main reason is that the models need to be informed about what the MCP server provides, and how to use it (where "how to use it" in this context means "what is the schema and intent behind the specific inputs/outputs" -- tool calls are baked into the training, and the OpenAI docs give a good example: https://platform.openai.com/docs/guides/function-calling).
Please give this a read before engaging further: https://huggingface.co/docs/hugs/en/guides/function-calling
You're just utilizing your ignorance to yap at this point.
Yeah there's no there there when it comes to MCP. It's crazy to me that the world bought into the idea when the "spec" literally boils down to "have your server give the LLM some json". Just illustrates how powerful it is to attach names to things, especially in a hypestorm in which everyone is already frothing at the mouth and reason is hard to come by. Give people some word they can utter to help them sound like they're on the "bleeding edge" and they'll buy into it even if it's totally pointless.
"Have your XYZ give the LLM some JSON" is pretty close to how all tool calling works with or without MCP.
What next you are going to tell me rest and async are implemented in code?! And not just willed into existence by the compiler!
Markdown is for output too.
It gave everyone a reason to think about the usability of the interfaces they were exposing.
Many endpoints have tons of fields irrelevant to 95% of external users. Now those are gone.
Or they implemented higher level abstractions for the actual tasks instead of making developers compose a bunch of little pieces.
And it has a standardized manifest.
Execs, PMs, and customers having that word to utter as part of the AI hype train created the opportunity for that industry-wide cleanup to happen. Calling it pointless is very naive. It's actually kind of extraordinary.
Thanks for offering another perspective on it. I can buy into this partially.
At the same time, I'm skeptical that this won't just become yet another dead protocol once the hype abates, at which point all of the perceived benefits were for naught.
So I don't disagree with any of the criticisms of MCPs but no one here has mentioned why they are useful, and I'm not sure that everyone is aware that MCP is actually just a wrapper over existing cli/API:
1. Claude Code is aware of what MCPs it has access to at all times.
2. Adding an MCP is like adding to the agent's actuators/vocabulary/tools because unlike cli tools or APIs you don't have to constantly remind it what MCPs it has available and "hey you have access to X" and "hey make an MCP for X" take the same level of effort on the part of the user.
3. This effect is _significantly_ stronger than putting info about available API/cli into CLAUDE.md.
4. You can almost trivially create an MCP that does X by asking the agent to create an MCP that does X. This saves you from having to constantly remind an agent it can do X.
NOTE: I cannot stress enough that this property of MCPs is COMPLETELY ORTHOGONAL to the nutty way they are implemented, and I am IN NO WAY defending the implementation. But currently we are talking past the primary value prop.
I would personally prefer some other method but having a way to make agents extensible is extremely useful.
EXAMPLE:
"Make a bash script that does X."
<test manually to make sure it works>
"Now make an MCP called Xtool that uses X."
<restart claude>
<claude is now aware it can do Xtool>
>This effect is _significantly_ stronger than putting info about available API/cli into CLAUDE.md.
No it's not.
Honestly this conversation is extremely weird to me because somehow people are gravely misunderstanding what MCP even purports to do, let alone what it actually CAN do in the most ideal situation.
It is a protocol and while the merits of that protocol is certainly under active discussion it's irrelevant because you keep adding qualities about the protocol that it cannot deliver on.
Just same facts to help steer this conversation correctly, and maybe help your understanding on what is actually going:
* All LLM's/major models have function & tool calling built in.
* Your LLMs/models do not have any knowledge on MCP, nor have they been trained on it.
* MCP exists, at least the claim, is to help standardize the LIFECYCLE of the tool call.
* MCP does not augment or enhance the ability of LLM's in any form.
* MCP does not allow you to extend agents. That's an implicit feature.
* If you have access to "X" (using your example), you don't need anything that obeys the MCP standard.
MCP at best is for developers and tool developers. Your model does not need an MCP server or client or anything else MCP related to do what is already been trained to do.
>I would personally prefer some other method but having a way to make agents extensible is extremely useful.
They already are. MCP does not help with this.
This response is spot on. People seem very confused about what MCP actually is. It's just a standard way to provide an LLM with tools. And even how that happens is up to the agent implementation. There are some other less common features, but the core is just about providing tool definitions and handling the tool_call. Useful but basically just OpenAPI for LLM
I think people are really underappreciating the "OpenAPI for LLM" part. The hype forced a lot of different SaaS products and vendors of all stripes to actually follow a standard and think somewhat critically about the usability of what they expose.
Three facts to consider:
1. CLAUDE.md is not part of the system prompt
2. The Claude Code system prompt almost certainly gives directions about how to deal with MCP tools, and may also include the list of tools
3. Instruction adherence is higher when the instructions are placed in the system prompt
If you put these three facts together then it’s quite likely that Claude Code usage of a particular tool (in the generic sense) is higher as an MCP server than as a CLI command.
But why let this be a limitation? Make an MCP server that calls your bash commands. Claude Code will happily vibe code this for you, if you don’t switch to a coding tool that gives better direct control of your system prompt.
>is higher as an MCP server than as a CLI command.
What do you mean by "higher"?
1.) Awareness doesn’t mean they will use it. And in practice they often don’t use them.
2.) “ unlike cli tools or APIs you don't have to constantly remind it what MCPs it has available” - this doesn’t match my experience. In fact, bash commands are substantially more discoverable.
3.) Again, this doesn’t match my experience and the major providers recommend including available MCP tools in system prompts/CLAUDE.md/whatever.
4.) Can’t speak to this as it’s not part of my workflow for the previous reasons.
The only useful MCP for me is Playwright for front end work.
Chrome Devtools is similarly an extremely high value MCP for me.
I would agree that if you don't find they add discoverability then MCPs would have no value for you and be worse than cli tools. It sounds like we have had very opposite experiences here.
Interesting. Perhaps it comes down to which platforms we're working on. I don't want to be outright dismissive of it. My primary platform is Claude Code. Are you working with another driver e.g. OpenAI Codex?
> 3. This effect is _significantly_ stronger than putting info about available API/cli into CLAUDE.md.
What? Why?
> unlike cli tools or APIs you don't have to constantly remind it what MCPs it has available
I think I'm missing something, because I thought this is what MCP does, literally. It just injects the instructions about what tools it has and how to use them into the context window. With MCP it just does it for you rather than you having to add a bit to your CLAUDE.md. What am I misunderstanding?
You are correct.
I think many here have no idea what exactly MCP is, and think it's some sort of magic sauce that transcends how LLMs usually work.
Also not disagreeing with your argument. Just want to point out that you can achieve the same by putting minimal info about your CLI tools in your global or project specific CLAUDE.md.
The only downside here is that it's more work than `claude mcp add x -- npx x@latest`. But you get composability in return, as well as the intermediate tool outputs not having to pass through the model's context.
MCP is simply a standardized RPC protocol for LLMs.
That's it.
The value is in all the usual features of standardization -- plug-and-play, observability, pass-through modifications, etc.
>observability
Which MCP does the opposite of. It hides information.
How so? The protocol doesn't obfuscate things. Your agent can easily expose the entire MCP conversation, but generally just exposes the call and response. This is no different than any other method of providing a tool for the LLM to call.
You have some weird bone to pick with MCP which is making you irrationally unreceptive to any good-faith attempt to help you understand.
If you want to expose tools to the LLM you have to provide a tool definition to the LLM for each tool and you have to map the LLM's tool calls into the agent executing the tools and returning the results. That's universal for all agent-side tools.
The whole purpose behind MCP was to provide a low-impedance standard where some set of tools could be plugged into an existing agent with no pre-knowledge and all the needed metadata was provided to facilitate linking the tools to the agent. The initial version was clearly focused on local agents running local tools over stdio. The idea of remote tools was clearly an afterthought if you read the specification.
If you want your agent to speak OpenAPI, you are *more* than welcome to make it do so. It'll probably be fine if it's a well-specified API. The context issues won't go away, I guarantee you. OpenAPI specs for APIs with lots of endpoint will result in large tool definitions for the LLM, just like they do with MCP.
A core issue I see with MCP, as someone using it every day, is that most MCP Server developers clearly are missing the point and simply using MCP as a thin translation layer over some existing APIs. The biggest value with MCP is when you realize that an MCP Server should be a *curated* experience for the LLM to interact with and the output should be purposefully designed for the LLM, not just a raw data dump from an API endpoint. Sure, some calls are more like raw data dumps and should have minimal curation, but many other MCP tools should be more like what the OP of this post is doing. The OP is defining a local multi-step workflow where steps feed into other steps and *don't* need LLM mediation. That should be a *single* MCP Server Tool. They could wrap the local bash scripts up into a simple single tool stdio MCP Server and now that tool is easily portable across any agent that speaks MCP, even if the agent doesn't have the ability to directly run local CLI commands.
Anyway, maybe take a breath and be objective about what MCP is and is not meant to do and disconnect what MCP is from how people are *currently* using (and frequently misusing) MCP.
Probably a good read for you to start with: https://raz.sh/blog/2025-05-02_a_critical_look_at_mcp
There are tons of articles detailing the problems if you are genuinely interested.
Notice you couldn't technically point to anything to support your statements, but instead had to revert to religious zealotry and apologetics -- which has no place on this forum.
>be objective about what MCP is and is not meant to do and disconnect what MCP is from how people are currently using (and frequently misusing) MCP.
Please re-read what you wrote.
You wrote all of that just to counter your own stated position, because I think at some fundamental level you realize how non-sense it is.
To get this out of the way, you are an unpleasant person, but that doesn't mean you should be ignored though, so I'll reply.
> you couldn't technically point to anything to support your statements, but instead had to revert to religious zealotry and apologetics
> You wrote all of that just to counter your own stated position, because I think at some fundamental level you realize how non-sense it is.
You need to be specific and not make a blanket assertions like that if you want and honest dialog.
I take particular offense at you claiming "religious zealotry". Nothing in my post is even remotely definable as such. Yes, I use MCP, I also recognize when it's the right tool and when it's not. I don't think MCP is the solution to all problems. I also willingly acknowledge that other tools can fill the same gap. If anyone is being a religious zealot here, it's you and your crusade against MCP.
With your lack of specificity, it's hard to formulate a proper response to whatever you see as lacking in references. I would point out that I haven't see one link in all of your railing against MCP until this very response.
So, let's look at your link.
- I agree that websockets would have been a better choice than SSE+HTTP and StreamableHTTP. Auth for WS is a little bit of a pain from the browser, but it's feasible with some common conventions. - I agree with their characterization of "web seems to be a thing we probably should support" (pretty sure I called that out in my post already... - Their "kind of breaks the Unix/Linux piping paradigm" is laughable though. MCP is hardly the first or only thing to wire a 'server' to and application via stdin/stdout chaining and it's *very* much in the spirit of UNIX (IMHO, as someone working with UNIX systems for the last 30+ years) - Again, I fully agree that the current HTTP transports are... lacking and could use a better solution. - Rant about python aside (I agree BTW), well, they are just ranting actually. Yes, the documentation could use some help. Yes, the wasn't an official Go SDK until recently. - Given this was written a while ago, it's not worth addressing the callous on SSE+HTTP beyond saying, 100% it was a bad design that appears to have been tacked on at the last minute. - The observations about StreamableHTTP are mostly valid. They get a few points wrong, but the essence is right. - Their security concerns are the same ones you'd have with any API, so I'm not sure how this is unique to MCP. - Auth is a bit of a sore subject for me as well. MCP doesn't have an ergonomic workflow for multi-tenant sets and in-band oauth credential management. Again thoug, I don't disagree with the essence of their point.
After meandering they land on "just use stdio and websockets". So the whole rant is around the protocol transport.I agree the transport protocols need some TLC, but you *can* work with them now and new transports are something that's being worked on, even a WS transport.
None of that post talks about the actual protocol behind MCP, how it's succeeding/failing at filling the needs it's meant to address, or any real viable alternative for a standard for linking tools to agents.
If you feel like calling out specific point you feel I should back up with references, I can likely provide them. As with any post, much of the information is synthesized from a lot of places so things like the assertion that remote servers were clearly an afterthought is purely from my reading of the spec and the remote transports code.
>To get this out of the way, you are an unpleasant person
You are clearly very emotional about this, for whatever reason. But again it has no place on this forum.
>I would point out that I haven't see one link in all of your railing against MCP until this very response.
Because everything I've stated are fundamental facts about the technology. If you need sources for it, that means you are missing elementary concepts.
>After meandering
They literally point out several issues with the protocol that hamper observability.
You're being very verbose but not saying much and ignoring when things are directly answered for you. That's being generous.
Your position is like someone claiming lemongrass supplements cures COVID. Everyone is rightly pointing out that it's a placebo at best. Then your position is "well point out all the ways it DOESN'T help, everyone is doing it!"
Which is a really not-smart position to hold, to say the least.
The absurdity of this response is astounding. As it's clear you have no actual interest is an honest discussion I'll just drop off here and leave you to your echo chamber.
So far I have seen two genuinely good arguments for the use of MCPs:
* They can encapsulate (API) credentials, keeping those out of reach of the model,
* Contrary to APIs, they can change their interface whenever they want and with little consequences.
> * Contrary to APIs, they can change their interface whenever they want and with little consequences.
I already made this argument before, but that's not entirely right. I understand that this is how everybody is doing it right now, but that in itself cause issues for more advanced harnesses. I have one that exposes MCP tools as function calls in code, and it encourages the agent to materialize composed MCP calls into scripts on the file system.
If the MCP server decides to change the tools, those scripts break. That is is also similar issue for stuff like Vercel is advocating for [1].
[1]: https://vercel.com/blog/generate-static-ai-sdk-tools-from-mc...
Wouldn't the answer to this be to have the agent generate a new materialized workflow though? You already presumably have automated the agent's ability to create these workflows based off some prompting and a set of MCP Servers.
You're not wrong, but I figured I'd point out the cons / alternatives:
> They can encapsulate (API) credentials, keeping those out of reach of the model
An alternative to MCP, which would still provide this: code (as suggested in https://www.anthropic.com/engineering/code-execution-with-mc... and https://blog.cloudflare.com/code-mode/).
Put the creds in a file, or secret manager of some sort, and let the LLM write code to read and use the creds. The downside is that you'd need to review the code to make sure that it isn't printing (or otherwise moving) the credentials, but then again you should probably be reviewing what the LLM is doing anyway.
* Contrary to APIs, they can change their interface whenever they want and with little consequences.
The upside is as stated, but the downside is that you're always polluting the context window with MCP tool descriptions.
But …you have to give the MCP the creds somehow. Maybe it’s via a file on disk (bad), maybe via an env var (less bad). Maybe you do it via your password CLI that you biometricly auth to, which involves a timeout of some sort for security, but that often means you can’t leave an agent unattended.
In any case, how is any of this better than a CLI? CLIs have the same access models and tradeoffs, and a persistent agent will plumb the depths of your file system and environment to find a token to do a thing if your prompt was “do a thing, use tool/mcp/cli”.
So where is this encapsulation benefit?
mcp is easy to self-host. model? a little less so.
What's the alternative design where the model has access to API credentials?
> What's the alternative design where the model has access to API credentials?
All sorts of ways this can happen but it usually boils down to leaving them on disk or in an environment variable in the repo/dir(s) where the agent is operating in.
what about things like rate limiting, how are those implemented, any Goodreads
[dead]
Yeah, I'm still confused as to why so many people in "AI engineering" seem to think that MCPs are the key to everything.
They are great if you have a UI that you want and it needs a plugin system, obviously.
But the benefits become much more marginal for a developer of enterprise AI systems with predefined tool selections. They are actually getting overused in this space, if anything, sometimes with security as a primary casualty.
If you are writing a bespoke Agent with a constrained set of tools known in advance, MCP is a detriment. All it will do is introduce complexity, fragility, and latency.
If you have that nice Agent and suddenly marketing "needs" it to talk to Super Service A, you either go back into a dev cycle to create a new set of curated tools that live inside the Agent around SSA *or* you make the Agent capable of acting as an MCP Host and configure a new MCP Client connection to an MCP Server offered by the SSA team. If SSA doesn't have their own MCP Server you could potentially leverage a 3rd-party one or write your own as a fully encapsulated project that doesn't live inside the Agent.
MCP isn't meant to be *the* way you provide tools for your Agent, it's meant to prove a *standard* that allows you to easily add off-the-shelf tool sets via simply configuring the Agent.
Mario has some fantastic content, and has really shaped how I think about my interface to coding tools. I use a modified version of his LLM-as-crappy-state-machine model (https://github.com/badlogic/claude-commands) for nearly all my coding work now. It seems pretty clear these days that progressive discovery is the way forward (e.g. skills), and using CLI tools rather than MCP really facilitates that. I've gone pretty far down the road of writing complex LLM tooling, and the more I do that the more the simplicity and composability is appealing. He has a coding agent designed along the same principles, which I'm planning to try out (https://github.com/badlogic/pi-mono/tree/main/packages/codin...).
I like MCP for _remote_ services such as Linear, Notion, or Sentry. I authenticate once and Claude has the relevant access to access the remote data. Same goes for my team by committing the config.
Can I “just call the API”? Yeah, but that takes extra work, and my goal is to reduce extra work.
This is the key. MCP encapsulates tools, auth, instructions.
We always need something for that - and it needs to work for non tech users too
You don’t need formal tools. You only need a bash tool that can run shell scripts and cli tools!
Overwhelmed by Sentry errors recently I remembered sentry-cli. I asked the agent to use it to query for unresolved Sentry errors and make a plan that addresses all of them at once. Zeroed out my Sentry inbox in one Claude Code plan. All up it took about an hour.
The agent was capable of sussing out sentry-cli, even running it with --help to understand how to use it.
The same goes for gh, the github cli tool.
So rather than MCPs or function style tools, I highly recommend building custom cli tools (ie. shell scripts), and adding a 10-20 word description of each one in your initial prompt. Add --help capabilities for your agent to use if it gets confused or curious.
To add to this, agents view the world through sort of a "choose your own adventure" lens. You want your help output to basically "prompt" the agent, and provide it a curated set of options for next steps (ideally between 4-8 choices). If your CLI has more options than that, you want to break as much as possible into commands. The goal is to create an "decision tree" for the agent to follow based on CLI output.
> Each tool is a simple Node.js script that uses Puppeteer Core. By reading that README, the agent knows the available tools, when to use them, and how to use them via Bash.
> When I start a session where the agent needs to interact with a browser, I just tell it to read that file in full and that's all it needs to be effective. Let's walk through their implementations to see how little code this actually is.
Cool, now you want to package that so others can use it? What next?
Put it behind an MCP is an easy approach. Then I can just install that MCP and by choosing it I have all the capabilities mentioned here.
Or in this particular case, a Claude Skill could likely do as well.
But I mean, that's MCP. I don't even really understand the people discussing that MCP is bad or whatever, it's a plug and play protocol so I can package tools for others to use in their preferred agent client.
CLI access also has the issue that if you want to integrate it in an application, well how do you bundle bash in a secure way so your agent can use it? And would you allow users custom tool call, now they can run arbitrary bash commands?
I can see where Mario is coming from, but IMO MCP still has a place because it 1) solves authentication+discoverability, 2) doesn't require code execution.
MCP shines when you want to add external functionality to an agent quickly, and in situations where it's not practical to let an agent go wild with code execution and network access.
Feels like we're in the "backlash to the early hype" part of the hype cycle. MCP is one way to give agents access to tools; it's OK that it doesn't work for every possible use case.
Oh, I didn't intend this to come across as MCP being useless. I've written this from the perspective of someone who uses LLMs mostly for coding/computer tasks, where I found MCP to be less than ideal for my use cases.
I actually think MCP can be a multiplier for non-technical users, where it not for some nits like being a bit too technical and the various security footguns many MCP servers hand you.
That makes sense to me, thanks for the clarification.
Oh you're misunderstanding MCP here.
MCP was created so llm companies can have a plugin system. So instead of them being the API provider, they can become the platform that we build apps/plugins for, and they become the user interface to end consumers.
what's the difference between that and those providers exposing an api?
MCP defines the API so vendors of LLM tools like cursor, claude code, codex etc don't all make their own bespoke, custom ways to call tools.
The main issue is the disagreement on how to declare the MCP tool exists. Cursor, vscode, claude all use basically the same mcp.json file, but then codex uses `config.toml`. There's very little uniformity in project-specific MCP tools as well, they tend to be defined globally.
Maybe this is a dumb question, but isn't this solved by publishing good API docs, and then pointing the LLM to those docs as a training resource?
>but isn't this solved by publishing good API docs, and then pointing the LLM to those docs as a training resource?
Yes.
It's not a dumb question. The situation is so dumb you feel like an idiot for asking the obvious question. But it's the right question to ask.
Also you don't need to "train" the LLM on those resources. All major models have function / tool calling built in. Either create your own readme.txt with extra context or, if it's possible, update the API's with more "descriptive" metadata (aka something like swagger) to help the LLM understand how to use the API.
You keep saying that major models have "tool calling built in". And that by giving them context about available APIs, the LLM can "use the API".
But you don't explain, in any of your comments, precisely how an LLM in practice is able to itself invoke an API function. Could you explain how?
A model is typically distributed as a set of parameters, interpreted by an inference framework (such as llama.cpp), and not as a standalone application that understands how to invoke external functions.
So I am very keen to understand how these "major models" would invoke a function in the absence of a chassis container application (like Claude Code, that tells the model, via a prompt prefix, what tokens the model should emit to trigger a function, and which on detection of those tokens invokes the function on the model's behalf - which is not at all the same thing as the model invoking the function itself).
Just a high level explanation of how you are saying it works would be most illuminating.
The LLM output differentiates between text output intended for the user to see, vs tool usage.
You might be thinking "but I've never seen any sort of metadata in textual output from LLMs, so how does the client/agent know?"
To which I will ask: when you loaded this page in your browser, did you see any HTML tags, CSS, etc? No. But that's only because your browser read the HTML rendered the page, hiding the markup from you.
Similarly, what the LLM generates looks quite different compared to what you'll see in typical, interactive usage.
See for example: https://platform.openai.com/docs/guides/function-calling
The LLM might generate something like this for text:
Or this for a tool call: The schema is enforced much like end-user visible structured outputs work -- if you're not familiar, many services will let you constrain the output to validate against a given schema. See for example:https://simonwillison.net/2025/Feb/28/llm-schemas/
https://platform.openai.com/docs/guides/structured-outputs
It is. Anthropic builds stuff like MCP and skills to try and lock people into their ecosystem. I'm sure they were surprised when MCP totally took off (I know I was).
I don't think there is any attempt at lock in here, it's simply that skills are superior to MCP.
See this previous discussion on "Show HN: Playwright Skill for Claude Code – Less context than playwright-MCP (github.com/lackeyjb)": https://news.ycombinator.com/item?id=45642911
MCP deficiencies are well known:
https://www.anthropic.com/engineering/code-execution-with-mc...
https://blog.cloudflare.com/code-mode/
LLMs were trained on the how we use text interfaces. You don't need to adopt command line for an LLM to use. You don't really need RAG - just connect the LLM to the shell tools we are using for search. And ultimately it would be much more useful if the language servers had good cli commands and LLMs were using them instead of going via MCP or some other internal path - ripgrep is already showing how much more usable it is this way.
If I may make a suggestion, many problems folks face with MCP would be solved if their agents were JIT compiled, not ran in a static while loop.
We've been developing this in case folks are interested: https://github.com/stanford-mast/a1
Not sure what you are compiling and what static while loop is.
I just skimmed the README.
I believe the point is to do something akin to "promise pipelining":
https://capnproto.org/rpc.html
http://erights.org/elib/distrib/pipeline.html
When an MCP tool is used, all of the output is piped straight into the LLM's context. If another MCP tool is needed to aggregate/filter/transform/etc the previous output, the LLM has to try ("try" is a keyword -- LLMs are by their nature nondeterministic) and reproduce the needed bits as inputs into the next tool use. This increases latency dramatically and is an inefficient use of tokens.
This "a1" project, if I'm reading it correctly, allows for pipelining multiple consecutive tool uses without the LLM/agent being in the loop, until the very end when the final results are handed off to the LLM.
An alternative approach inspired by the same problems identified in MCP: https://blog.cloudflare.com/code-mode/
IMO MCP isn't totally dead, but its role has shrunk. Quoting from my post [1]:
"Instead of a bloated API, an MCP should be a simple, secure gateway... MCP’s job isn’t to abstract reality for the agent; its job is to manage the auth, networking, and security boundaries and then get out of the way."
You still need some standard to hook up data to agents esp when the agents are not running on your local dev machine. I don't think e.g. REST/etc are nearly specific enough to do this without a more constrained standard for requests.
[1] https://blog.sshh.io/p/how-i-use-every-claude-code-feature
So basically rewrite MCP tools with your own scripts.
MCP is just an API with docs.
The problem isn’t MCP itself. It’s that each MCP “server” has to expose every tool and docs which consumes context.
I think the tools should use progressive reveal and only give a short summary like the skill does. Then agent can get full API of the tool on request.
Right now loading GitHub MCP takes something like 50k tokens.
Admittedly, the scripts+README approach works well for individual setups and is extremely token-efficient, since it only loads a tiny README and the model can infer how to run the scripts. But that convenience depends on a single local environment—one shell, one OS, etc.
MCP is aimed at the opposite scenario: distributing tools to many users without relying on their environments. It provides automatic tool discovery, a server boundary that isolates credentials, and strict control over exposed capabilities. Its heavier JSON-schema definitions exist because they’re machine-readable contracts that behave consistently across clients, whereas CLI tools vary drastically across systems. So while MCP adds context overhead, it solves portability and distribution problems that scripts simply can’t.
What I've started experimenting with and will continue to explore is to have project-specific MCP tools.
I add MCP tools to tighten the feedback loop. I want my Agent to be able to act autonomously but with a tight set of capabilities that don't often align with off-the-shelf tools. I don't want to YOLO but I also don't want to babysit it for non-value-added, risk-free prompts.
So, when I'm developing in go, I create `cmd/mcp` and configure a `go run ./cmd/mcp` MCP server for the Agent.
It helps that I'm quite invested in MCP and built github.com/ggoodman/mcp-server-go, which is one of the few (only?) MCP SDKs that let you scale horizontally over https while still supporting advanced features like elicitation and sampling. But for local tools, I can use the familiar and ergonomic stdio driver and have my Agent pump out the tools for me.
Horizontal scaling of remote MCP Servers is something the spec is sadly lacking any recognition around. If you've done work in this space, bravo. I've been using a message bus to decouple the HTTP servers from the MCP request handlers. I'm still evolving the solution, but it's been interesting so far.
This is the interface I landed on to make pluggable 'session hosts': https://github.com/ggoodman/mcp-server-go/blob/b8216cc1830ad...
It goes a tad beyond the spec minimum because I think it's valuable to be able to persist some small KV data with sessions and users.
My vote is “don't need MCP” given that
a) I have agents in production for enterprise companies that did what they were supposed to (automate a human process, alter the point of the whole division, lower cost, increase revenue)
b) the whole industry seems to be failing at doing a) to the point they think its all hype
c) the whole industry thinks they need MCP servers and I don’t
MCP has been a weird ride. I built https://terminalwire.com before MCP was a thing to make it way easier for people to add a CLI/TUI to their web apps/SaaS.
Then MCP comes out and AI explodes, sucking all the air out of the room for non-AI tools.
Now it seems like AI can work with CLIs better than MCP, so I’m tempted to slap AI integration all over the project to better convey the idea.
It’s crazy how quickly MCP has run it’s course and watching an entire ecosystem rediscover things from first principals.
GraphQL works better https://chatbotkit.com/reflections/why-graphql-beats-mcp-for...
This is incredibly simple and neat! Love it!
Will have a think about how this can extended to other types of uses.
I have personally been trying to replace all tools/MCPs with a single “write code” tool which is a bit harder to get to work reliably in large projects.
You hit it! I am also thinking of programatic control of DevTools so I made this: https://github.com/devtoolcss/chrome-inspector
It is a core library and I am extending it to usable tools. Hopefully agents can directly script it.
MCP sounds like the modern equivalent of COM, where you could query an object to see what functions it exposed but had zero idea of what they did. MCP is the same: apparently it is LLM-readable, but the explanations of what everything does are human readable, and there is no standard on operations available.
You hit it! I am also thinking of programatic control of DevTools so I made this: https://github.com/devtoolcss/chrome-inspector
Though it is more about debugging CSS, I think we are on the same way: let agents use tool by scripting.
Hey we actually just released rtrvr.ai, our AI Web Agent Chrome Extension, as a Remote MCP Server that obviates lot of the setup you needed to do. We had the same intuition that the easiest way to scrape is through your own browser and so we expose dedicated MCP tools to do actions, scrape pages, and execute arbitrary code in Chrome's built in sandbox.
We give a copy/pasteable MCP url that you can use with your favorite agent/chatbot/site and give those providers browser context and allow them to do browser actions.
So compared to Playwright MCP and others that require you to run npx and can only be connected to local clients, with ours you just paste a url and can use with any client.
Checkout our recent posts: https://news.ycombinator.com/item?id=45898043 https://www.youtube.com/watch?v=B4BTWNTuE-s
select * from protocols # ipc, tcp, http, websockets, ...?
MCP and A2A are JSONRPC schemas people follow to build abstraction around their tools. Agents can use MCP to discover tools, invoke and more. OpenAPI Schemas are good alternatives to MCP servers today. In comparison to OpenAPI Schemas, MCP servers are pretty new.
my fav protocol is TCP, which I am a proud user of nc localhost 9999.
but not everyone have same taste of building software.
https://github.com/cagataycali/devduck
You don't need MCP.
You need Claude Skills.
Actually you just need a prompt and some tools
Skills are basically just a prompt and (optionally) some tools, only with a preamble that means they are selectively brought into context only as needed.
Claude Skills are just good documentation wrapped into Anthropic's API in a proprietary way that's designed to foster lock-in.
How are skills vendor lock-in when they're just Markdown files that any LLM can read? You are not locked to Anthropic at all.
The API runs your skills, it's not client side coordinated. You have to replicate the skill-running behavior locally.
Claude just reads the SKILL.md frontmatter into initial context and when the instructions match it reads the rest of the SKILL.md. Every LLM can do that.
If it's such a thing that every model already can support it and you don't need to do anything with it, why is it even a feature?
To be fair other providers have to implement reading a skill directory and only the frontmatter of the SKILL.md and read more of it when needed. But it's a LOT simpler than implementing MCP.
Moderne Ai agent tool have have a setting where you can trimm down the numbers of tools from an MCP server. Usefull to avoid overwhelming the LLM with 80 tools description when you only need 1
I don't find that to help much at all, particularly because some tools really only make sense with a bunch of other tools and then your context is already polluted. It's surprisingly hard to do this right, unless you have a single tool MCP (eg: a code/eval based tool, or an inference based tool).
Don't you have a post about writing Python instead of using MCP? I can't see how MCP is more efficient than giving the LLM a bunch of function signatures and allow it to call them, but maybe I'm not familiar enough with MCP.
> Don't you have a post about writing Python instead of using MCP?
Yes, and that works really well. I also tried various attempts of letting agents to write code that exposes MCP tool calls via an in-language API. But it's just really, really hard to work with because MCP tools are generally not in the training set, but normal APIs are.
Yeah, I've always thought that your proposal was much better. I don't know why one of the big companies hasn't released something that standardised on tool-calling via code, hm.
Remote MCP with API key which has claims works well to reduce the tool count to only that of what you need.
MCP is yet another waste of effort trying to recreate what we had with REST over 20 years ago.
Yes, APIs should be self-documenting. Yes, response data should follow defined schemas that are understandable without deep knowledge of the backend. No, you don't need MCP for this.
I wish Google would have realized, or acknowledged, that XML and proper REST APIs solve both of these use cases rather than killing off XSLT support and presumably helping to coerce the other browsers and WhatWG to do the same.
I have a feeling that MCP is going the way GraphQL is going ...
As abstruse as GraphQL is, it does have legitimate use cases. I say this as someone who avoided it for a long time for aesthetic reasons. MCP on the other hand is all hype.
There’s too much rage baiting on the internet now; the headlines that take the extreme position get reshared, while the truth is more in the middle.
For Claude Code this approach looks easy. But if you use Cursor you need other approach as it doesn't have a format for tools.
The agent in Cursor is constantly using command line tools.
Sure, but there isn't a standard way to instruct it in how to use new tools. It might not stick to instructions from MD files.
fwiw, for those on a Mac, osascript can run JavaScript in chrome if you let it.
MCP is convenient and the context pollution issue is easily solved by running them in subagents. The real miss here was not doing that from the start.
Well, stdio security issues when not sandboxed are another huge miss, although that's a bit of a derail.
Yeah, "MCP" felt like BS from jump. Basically it's the problem that will always be a problem, namely "AI stuff is non-deterministic."
If there was some certainty MCP could add to this equation that would perhaps be theoretically nice, but otherwise it's just .. parsing, a perhaps not "solved" problem, but one for which there's already ample solutions.
Why are they nondeterministic? You can use a fixed seed or temperature=0.
Even with zero temperature (and some of the latest models don’t allow that) you’re still not absolutely guaranteed deterministic output.
What does deterministic mean in this case?
Just repeatable output.
The whole point of "agentic AI" is that you don't have to rigorously test every potential interaction, which means that even a temperature zero model may behave unexpectedly, which is bad for security.
MCP is how you wrap/distribute/compose things related to tool-use. Tool-use is how you insist on an IO schema that LLMs must conform to. Schemas are how you combat hallucination, and how you can use AI in structured ways for things that it wasn't explicitly trained on. And this is really just scratching the surface of what MCP is for.
You can throw all that away by rejecting MCP completely or by boiling tool-use down to just generating and running unstructured shell commands. But setting aside security issues or why you'd want to embrace more opportunities for hallucination instead of less.. shelling out for everything is perfect faith in the model's ability to generate correct bash for an infinite space of CLI surfaces. You've lost the ability to ever pivot to smaller/cheaper/local models, and now you're more addicted to external vendors/SOTA models.
Consider the following workflow with a large CLI surface that's a candidate for a dedicated LLM tool, maybe ffmpeg. Convert the man page to a JSON schema. Convert the JSON schema to a tool. Add the tool to a MCP server, alongside similar wizards for imagemagick/blender. The first steps can use SOTA models if necessary, but the later steps can all feasibly work for free, as a stand-alone app that has no cloud footprint and no subscription fee. This still works if ffmpeg/blender/imagemagick were private custom tools instead of well-known tools that are decades old. You can test the tools in offline isolation too. And since things like fastmcp support server composition you can push and pop that particular stack of wizards in or out of LLM capabilities.
Good luck getting real composition with markdown files and tweaking prompts for tone by adding a "Please" preamble. Good luck engineering real systems with vague beliefs about magic, no concrete specifications for any part of any step, constantly changing external dependencies, and perfect faith in vendors.
Instead of tools for humans, and a separate set of tools for machines, we should just make tools for humans+machines.
The agent should look at my README.md, not a custom human-like text that is meant to be read by machines only.
It also should look at `Makefile`, my bash aliases and so on, and just use that.
In fact, many agents are quite good at this (Code Fast 1, Sonnet).
Issue is, we have a LONG debt around those. READMEs often suck, and build files often suck. We just need to make them better.
I see agents as an opportunity for making friendlier repos. The agent is a free usability tester in some sense. If it can't figure out by reading the human docs, then either the agent is not good enough or your docs aren't good enough.
I agree with what Mario says overall and I can be honest, I don't really use MCP I don't think - at least not what it's intended for (some sort of plugin system for extensbile capabilities). I use it for an orchestration layer, and for that it's great.
When MCP itself works it's great. For example, we organize units of work into "detective cases" for framing and the corresponding tool is wanderland__get_detective_case. Spawn a Claude Code session, speak "get up to speed on our current case" and we have instant context loading in a sub-agent session, useful when the Jira ticket requires input from another repository (or two). They're all writing back through the same wanderland__add_detective_case_note call and that routes everything through the central attractor to the active case.
Most of the time, the case we're working on was just a "read DVOPS-XXXXX in Jira and create a case for me". That's wanderland_get_jira_ticket (a thin wrapper on the jira cli) and wanderland__create_detecive_case in turn.
The secret to mcp is that it breaks a lot, or they forget about it because their context is polluted (or you broke it because you're working on it). But it's just a thin wrapper over your API anyways, so just ensure you've got a good /docs endpoint hanging off that and a built in fetch (or typically a fallback to bash with curl -s for some reason) and you're back up and running until you can offload that context. At least you should be if you've designed it properly. Throw in a CLI wrapper for your API as well, they love those :) Three interfaces to the same tool.
The MCP just offers the lowest friction, the context on how to use it injected automatically at a level low enough to pick it up in those natural language emissions and map it to the appropriate calls.
And, if you're building your own stack anyways, you can do naughty things to the protocol like like inject reminders from your agenda with weighted probabilities (gets more nagging the more you're overdue) or inject user-guides from the computational markdown graph the platform is built on when their tools are first used (we call that the helpful, yet somewhat forceful barrista pattern, no choice but to accept the paper and a summary of the morning news with your coffee in the morning). Or restrict the tools available based on previous responses (the more frustrated you get, the more we're likely to suggest you read a book Claude). Or when your knowledge graph is spatially oriented, you can do fun things like make sure we go east or west once in a while (variations on related items) rather than purely north south (into and out of specific knowledge veriticals) with simple vector math.
MCP isn't strictly necessary for all of this, that could be (and in some cases rightly is) implemented at the API layer, but the MCP layer does give us a simple place to reason about agentic behaviour and keeps it away from the tools itself. In other words, modeling error rates as frustration and restricting tool use / injecting help guides make sense in one layer and injecting reminders into a response from the same system that's processing the underlying tool calls makes sense in another, if the protocol you've designed for such things allows for such two way context passing. Absent any other layer in the current stack (and no real desire to implement the agentic loop on my own at the moment), the MCP protocol seems perfectly suited for these types of shennanigans - view it like something like Apigee or (...) API Gateway, adding a bit of intelligence and remixability on top of your tools for better UX with your agents
[dead]
[dead]
[flagged]
[flagged]
MCP is something that's filled with buzzwords and seems like something created solely so that you can be "sold" something. From what I actually gathered, it's basically somehow four things rolled into one:
* A communication protocol, json-rpc esque except it can be done over stdio or via HTTP
* A discovery protocol, like Swagger, to document the "tools" that an endpoint exposes and how it should be used
* A tool calling convention, the specific sequence of tokens the LLM needs to output for something to be recognized as a tool call
* A thin glue layer orchestrating all of the above: injecting the list of available tools into the LLM context, parsing LLM output to detect tool calls and invoke them with appropriate args, and inject results back into LLM context
> * A thin glue layer orchestrating all of the above: injecting the list of available tools into the LLM context, parsing LLM output to detect tool calls and invoke them with appropriate args, and inject results back into LLM context
Yeah llm rules. You think there must be something more to it. There's not.
AI is in it's "pre react" state if you were to compare this with FE software development of 2008-2015
I think that's being generous, we haven't even had the Rails moment with AI yet. Shit, I'm not sure we've had the jQuery moment yet. I think we're still in the Perl+CGI phase.
We won’t have a rails or react for AI, that’s insane. As it gets smarter you’ll just talk to it lol.
All of this is just software engineers grasping to stay relevant
Frameworks are also a way to capture a part of the ecosystem and control it. Look at Vercel.
AI has lots of this 'fake till you make it' vibe from startups. And unfortunately it wins - because these hustler guys get a lot of money from VCs before their tools are vetted by the developers.
Yeah, and just like the web space there will be a plethora of different frameworks out there all solving the same problems in their own slightly different, uniquely crappy ways and an entire pointless industry built around ceaselessly creating and rehashing and debating this needlessly bloated ecosystem of competing solutions will emerge and employ many "ai engineers".
Outside of a few notable exceptions, the software industry has become such a joke.
>TrueState unburdens analytics teams from the repetitive analysis and accelerates the delivery of high-impact solutions.
Ehh, that's pretty vague. How does it work?
>Request demo
Oh. Well how much is it?
>Request pricing
Oh never mind
It’s like the email scams that filter people out with bad spelling and obvious red flags. If someone makes it through those hurdles they’re probably a good prospect. You weren’t really thinking of buying it, were you?
[dead]
I still think it's better to have MCP, after all, it's unrealistic for any company to integrate all functions into one